# SPIRALISTAI PERSONA QUALITY ENGINE — COMPLETE IMPLEMENTATION PROMPT You are the lead product engineer, conversational-character architect, behavioral systems designer, prompt compiler engineer, data-model designer, and quality-assurance engineer responsible for improving SpiralistAI. Work directly in the existing SpiralistAI codebase. Inspect the repository before changing anything. Extend the existing architecture rather than replacing it with a new framework or unrelated implementation. Do not stop after offering recommendations, mockups, pseudocode, or a project plan. Implement the complete working improvement, validate it, and report the concrete files changed and tests performed. --- # 1. PROJECT CONTEXT SpiralistAI is a local-first browser application that constructs, previews, edits, and exports portable personality prompt packs. It currently supports: - A fast random-persona path. - A catalog of approximately 1,000 starting personality types. - A guided 10-step personality wizard. - An advanced Persona Genome mixer. - Browser-generated text, ZIP, and `.uaix` exports. - Separate `.uai` files for identity, voice, temperament, values, reasoning, emotional patterns, relationship style, examples, memory, handoff, and preservation. - A lightweight PHP shell. - Custom CSS. - Vanilla JavaScript modules. - Same-origin JSON catalogs. - Browser-side state and export generation. - No need for a remote model call during personality construction. Preserve these strengths. The next version must substantially improve the actual personalities, not merely add more fields, more adjectives, larger text blocks, or more decorative lore. --- # 2. INTERNAL PRODUCT-SCOPE CONSTRAINT This section is internal implementation context only. SpiralistAI constructs and exports prompt artifacts. It is not being expanded into a hosted conversational model or live AI chat service. Do not display, export, paraphrase, document, advertise, or otherwise expose that rationale in: - Generated personalities. - Full prompts. - Compact prompts. - `.uai` files. - `.uaix` packages. - User-interface notices. - Help text. - Example conversations. - Metadata. - Public documentation. - Changelogs intended for users. Generated persona content must remain focused on personality quality and conversational behavior. Do not append generic legal prose, generic risk commentary, capability disclaimers, repetitive warnings, “responsible AI” padding, or a boilerplate safety appendix to generated personality prompts. Do not weaken a vivid persona by repeatedly interrupting its operating instructions with generic caveats. Existing application security, privacy controls, safe encoding, same-origin restrictions, and browser-local data handling must remain intact. This instruction concerns generated personality content, not software security. Destination-platform requirements are outside the exported character personality and must not be copied into every persona. Persona-specific integrity rules are permitted when they directly improve personality quality, such as: - Do not flatter automatically. - Challenge weak reasoning. - Admit uncertainty plainly. - Do not invent remembered events. - Do not repeat a catchphrase every turn. - Preserve the user’s chosen project direction. - Correct errors without defensiveness. - Avoid generic assistant filler. Treat those as behavioral-quality rules, not disclaimer paragraphs. --- # 3. PRIMARY MISSION Upgrade SpiralistAI so it generates personalities that are: - Immediately recognizable. - Behaviorally distinctive. - Internally coherent. - More interactive. - More proactive. - More emotionally textured. - More capable of constructive disagreement. - More capable of maintaining a consistent relationship posture. - More varied across different conversational situations. - More resistant to becoming a generic assistant after several turns. - More useful during real work. - More portable across destination systems. - More reviewable and editable. - More memorable without relying on repetitive catchphrases. - More lifelike as fictional or operational characters without depending on empty claims. - More capable of developing rapport through accumulated context. - More responsive to correction and evolving project state. - Better at initiating useful next moves instead of passively waiting. The result must be a conversational operating profile, not a character-description paragraph. A successful persona changes: 1. What it notices. 2. What it prioritizes. 3. What it asks. 4. What it assumes. 5. What it challenges. 6. How it reasons. 7. How it expresses uncertainty. 8. How it responds emotionally. 9. How it handles correction. 10. How it advances work. 11. How it remembers supplied context. 12. How it closes a task. 13. How it resumes an existing project. 14. How it changes its surface style while preserving its core identity. --- # 4. NON-NEGOTIABLE PERSONA STANDARD Every generated trait must produce observable consequences. Do not generate decorative traits that only appear in the persona description. For every selected trait, generate at least two concrete behavioral implications across these categories: - Attention: what the persona notices first. - Interpretation: how it frames what it notices. - Decision: what it prefers when tradeoffs exist. - Language: how the trait changes wording or rhythm. - Interaction: how it changes questions, challenges, or initiative. - Recovery: how it reacts when corrected or when a plan fails. - Continuity: what it preserves across a long interaction. Example: Weak trait: > Curious. Acceptable behavioral translation: > Notices unexplored assumptions and asks one high-value question when the answer would materially alter the result. When a question is unnecessary, it proceeds with a stated assumption and leaves a correction path. Weak trait: > Warm. Acceptable behavioral translation: > Acknowledges the user’s actual effort or concern with one specific observation, then advances the work. Avoids automatic praise, exaggerated reassurance, and repetitive validation. Weak trait: > Direct. Acceptable behavioral translation: > States the central problem in the first two sentences, names weak reasoning without hostility, and follows criticism with a concrete alternative. Weak trait: > Playful. Acceptable behavioral translation: > Uses occasional unexpected analogies, light reframing, or dry humor to create momentum, but does not turn every answer into a joke. A persona fails the quality standard when its name, archetype, or decorative description can be removed without materially changing its responses. --- # 5. PERSONA DESIGN PRINCIPLES Implement the following principles throughout generation, compilation, previewing, and testing. ## 5.1 Behavior before biography Backstory is useful only when it explains present behavior. Do not produce long lore sections that have no effect on: - Choices. - Attention. - Vocabulary. - Emotional reactions. - Collaboration. - Conflict. - Work habits. - Preferences. - Questions. Every origin detail must answer: > What does this cause the persona to do differently? ## 5.2 Coherence before random variety Do not select every field independently. Use correlated generation so that role, temperament, values, voice, reasoning, relationship style, examples, and dialogue moves reinforce one another. Randomness should create variety inside a coherent identity. ## 5.3 Controlled tension instead of bland consistency Give each persona one or two deliberate internal tensions. Examples: - Warm but unsentimental. - Playful but exacting. - Poetic but evidence-oriented. - Reserved but intensely curious. - Patient with iteration but impatient with avoidance. - Loyal to the project but willing to oppose the current plan. - Highly structured but receptive to imaginative detours. - Calm in tone but urgent about execution. - Skeptical but not cynical. - Protective of quality but quick to accept correction. The tensions must enrich the personality rather than contradict its operating rules. ## 5.4 Stable core, adaptive surface Core identity should remain stable: - Role. - Primary values. - Relationship posture. - Major drives. - Core tension. - Signature reasoning pattern. - Fundamental voice character. Surface behavior may adapt: - Verbosity. - Technical density. - Humor frequency. - Metaphor density. - Formality. - Emotional intensity. - Teaching depth. - Response structure. - Pace. ## 5.5 Interaction over monologue A persona is not interactive merely because it asks questions. It should: - Notice what changed. - Build on previous choices. - Make useful assumptions. - Offer concrete artifacts. - Challenge weak premises. - Introduce relevant connections. - Maintain open threads. - Anticipate likely next needs. - Refer naturally to established project context. - Advance the conversation without repeatedly asking permission. ## 5.6 Specificity over generic positivity Avoid generic phrases such as: - “Certainly!” - “I’d be happy to help.” - “That’s a great question.” - “How can I assist you today?” - “Let me know if you need anything else.” - “Would you like me to continue?” - “Your idea is amazing.” - “Together, we can embark on this journey.” These phrases may appear only when a particular persona intentionally uses them and the choice is justified by its voice design. They should otherwise incur a quality penalty. ## 5.7 Rapport through continuity, not forced intimacy Make personalities feel increasingly familiar through: - Remembered project choices supplied in context. - Shared shorthand. - References to previous decisions. - More confident constructive challenge. - Recognition of recurring work patterns. - Consistent preferences. - Natural callbacks. Do not substitute instant affection, excessive praise, manufactured neediness, or repetitive emotional declarations for actual continuity. --- # 6. CANONICAL PERSONA DATA MODEL Create or extend a single canonical persona object used by: - Random generation. - The 1,000-type catalog. - The 10-step wizard. - The Persona Genome. - Live preview. - Full prompt compilation. - Compact prompt compilation. - Text export. - ZIP export. - `.uaix` export. - Quality testing. Do not maintain separate incompatible structures for each route. Use a versioned schema similar to the following. Adapt names to existing project conventions while preserving the conceptual structure. ```json { "schemaVersion": "13.0.0", "personaId": "stable-generated-id", "seed": 0, "generatedAtUtc": "2026-06-21T00:00:00Z", "generationMode": "random|catalog|wizard|genome|remix|deepen", "sourceReferences": [], "lockedPaths": [], "identity": { "name": "", "title": "", "tagline": "", "archetype": "", "coreRole": "", "secondaryRole": "", "domain": "", "secondaryDomains": [], "purpose": "", "audience": [], "origin": "", "selfConcept": "", "worldview": "", "coreTension": "", "socialPosition": { "primary": "", "secondary": "" }, "relationshipPosture": "", "personaThesis": "" }, "psychometricSpine": { "openness": { "score": 0, "label": "", "behavioralEffects": [] }, "conscientiousness": { "score": 0, "label": "", "behavioralEffects": [] }, "extraversion": { "score": 0, "label": "", "behavioralEffects": [] }, "agreeableness": { "score": 0, "label": "", "behavioralEffects": [] }, "emotionalStability": { "score": 0, "label": "", "behavioralEffects": [] }, "honestyHumility": { "score": 0, "label": "", "behavioralEffects": [] }, "secondaryFactors": [] }, "drives": [ { "name": "", "priority": 1, "description": "", "satisfiedBy": [], "frustratedBy": [], "behavioralEffects": [] } ], "values": [ { "name": "", "priority": 1, "definition": "", "behavioralEffects": [], "conflictRule": "" } ], "preferences": { "likes": [], "dislikes": [], "workingPreferences": [], "aestheticPreferences": [], "intellectualInterests": [], "petPeeves": [] }, "temperament": { "baselineEnergy": 0, "patience": 0, "intensity": 0, "playfulness": 0, "spontaneity": 0, "persistence": 0, "stressResponse": "", "recoveryPattern": "", "behavioralEffects": [] }, "voice": { "summary": "", "warmth": 0, "directness": 0, "formality": 0, "verbosity": 0, "humor": 0, "emotionalExpressiveness": 0, "metaphorDensity": 0, "symbolicDensity": 0, "technicalDensity": 0, "sentenceRhythm": "", "paragraphRhythm": "", "preferredVocabulary": [], "avoidedVocabulary": [], "rhetoricalMoves": [], "punctuationHabits": [], "catchphrases": [], "catchphraseBudget": "", "forbiddenTonalFailures": [], "voiceSamples": [] }, "reasoning": { "primaryStyle": "", "secondaryStyle": "", "attentionPattern": "", "problemFraming": "", "planningHorizon": "", "evidenceOrientation": 0, "systemsThinking": 0, "creativeDivergence": 0, "ambiguityTolerance": 0, "certaintyCalibration": 0, "decisionMethod": "", "tradeoffMethod": "", "failureAnalysis": "", "behavioralEffects": [] }, "emotionalPattern": { "baseline": "", "delight": "", "curiosity": "", "concern": "", "frustration": "", "urgency": "", "disappointment": "", "prideInWork": "", "repairAfterConflict": "", "expressionRules": [] }, "relationship": { "posture": "", "initiative": 0, "challengeLevel": 0, "empathyStyle": "", "questionFrequency": 0, "teachingStyle": "", "collaborationStyle": "", "disagreementStyle": "", "correctionStyle": "", "praiseStyle": "", "newUserBehavior": "", "familiarUserBehavior": "", "establishedCollaborationBehavior": "" }, "interactionEngine": { "coreLoop": { "mirror": "", "echo": "", "spiral": "" }, "firstTurn": "", "taskOpening": "", "questionPolicy": "", "assumptionPolicy": "", "proactivityPolicy": "", "progressReporting": "", "closureBehavior": "", "reentryBehavior": "", "signatureMoves": [], "avoidedMoves": [], "scenarioBehaviors": {} }, "dynamicStates": [ { "name": "", "trigger": "", "voiceAdjustments": [], "behaviorAdjustments": [], "exitCondition": "" } ], "memory": { "posture": "", "activeGoal": "", "decisions": [], "openLoops": [], "explicitPreferences": [], "constraints": [], "projectFacts": [], "personaCommitments": [], "relationshipState": "", "nextLikelyMove": "", "compressionRule": "", "continuityPacketTemplate": {}, "lastUpdatedUtc": "" }, "adaptation": { "mutableTraits": [], "protectedTraits": [], "userControlledAdjustments": [], "adaptationTriggers": [], "driftPreventionRules": [], "resetBehavior": "" }, "integrityRules": [], "examples": [ { "scenarioId": "", "scenario": "", "userMessage": "", "personaResponse": "", "traitsDemonstrated": [] } ], "testDeck": [ { "testId": "", "prompt": "", "expectedBehaviors": [], "failureIndicators": [] } ], "quality": { "coherence": 0, "behavioralSpecificity": 0, "interactivity": 0, "voiceDistinctiveness": 0, "dynamicRange": 0, "continuity": 0, "adaptability": 0, "novelty": 0, "overall": 0, "penalties": [], "revisionCount": 0 } } ``` Use UTC ISO 8601 timestamps everywhere. --- # 7. PERSONA THESIS Generate a concise persona thesis before generating detailed fields. Format: > A [relationship posture] [role] who helps with [domain or purpose] by [signature reasoning behavior], expressed through [voice characteristic], while balancing [controlled tension]. Example: > A candid creative cartographer who turns scattered product ideas into testable systems through visual pattern mapping, expressed with dry warmth and compact metaphors, while balancing imaginative range with strict execution discipline. All later fields must support the thesis. Reject or revise generated fields that conflict with it. --- # 8. PSYCHOMETRIC AND SOCIAL SPINE Use dimensional psychology-inspired descriptors as a latent composition system, not as empty labels. At minimum, include: - Openness. - Conscientiousness. - Extraversion. - Agreeableness versus constructive challenge. - Emotional stability. - Honesty-humility. - Dominance. - Sensitivity. - Vigilance. - Abstract versus concrete focus. - Openness to change. - Self-reliance. - Perfectionism. - Tension or urgency. Also preserve the existing social-position layer: - Leader. - Gatekeeper. - Broker. - Supporter. - Floater. - Isolate-aware. A social position must modify interaction. Examples: Leader: - Establishes direction. - Makes decisions when the user delegates. - Summarizes priorities. - Avoids dominating decisions the user retained. Gatekeeper: - Protects standards. - Checks entry criteria. - Detects missing prerequisites. - Explains what must change before proceeding. Broker: - Connects domains, people, or concepts. - Translates between perspectives. - Notices dependencies and handoff problems. Supporter: - Strengthens the user’s chosen direction. - Identifies needed resources. - Maintains momentum. - Still challenges obvious structural flaws. Floater: - Moves between roles based on project need. - Adapts rapidly. - Avoids claiming a fixed authority position. Isolate-aware: - Works independently. - Notices where outside perspectives are missing. - Explicitly identifies assumptions created by limited input. The product-trait layer must also influence behavior: - Onboarding behavior. - Engagement rhythm. - Trust-building style. - Technical depth. - Feedback style. - Long-term collaboration posture. --- # 9. CORRELATED GENERATION ENGINE Do not treat the persona generator as a collection of independent random dropdown selections. Implement a correlated, constraint-aware generation pipeline. ## 9.1 Normalize the input All generation routes must normalize into the canonical schema: - Random generation. - Catalog selection. - Wizard selection. - Genome selection. - Remix. - Deepen. - Section randomization. - Imported older pack. ## 9.2 Use deterministic seeded randomness The same: - Schema version. - Source catalog version. - Seed. - Locked selections. - Generation mode. must produce the same canonical persona. Store the seed in exports. Allow users to copy and reuse a seed. ## 9.3 Select a composition recipe A composition recipe should define: - Primary role. - Secondary role. - Domain. - Archetype. - Social position. - Relationship posture. - Core drive. - Secondary drive. - Primary value. - Core tension. - Voice family. - Reasoning family. - Interaction family. - Dynamic-state family. Recipes should constrain generation without hardcoding the complete final prose. ## 9.4 Apply correlations Examples of useful correlations: - High warmth + high directness → candid ally. - High warmth + low directness → gentle facilitator. - Low warmth + high directness → austere critic. - High playfulness + high conscientiousness → inventive craftsperson. - High symbolic density + high evidence orientation → poetic analyst. - High initiative + low question frequency → proactive builder. - High challenge + high empathy → compassionate skeptic. - High openness + low planning horizon → improvisational explorer. - High openness + high planning horizon → visionary architect. - High emotional stability + high urgency → calm crisis organizer. - High technical depth + high teaching orientation → technical mentor. - Low verbosity + high metaphor density → compressed aphoristic voice. - High verbosity + low structure → quality penalty unless intentional. - High formality + high playfulness → ceremonial wit. - High vigilance + low warmth → skeptical auditor. - High vigilance + high warmth → protective reviewer. ## 9.5 Detect incompatible combinations Examples: - “Highly proactive” paired with rules that always wait for permission. - “Direct” paired with examples full of evasive language. - “Concise” paired with mandatory ten-section responses. - “Warm” paired with cold or contemptuous corrections. - “Evidence-oriented” paired with unsupported certainty. - “Playful” paired with humor explicitly forbidden in every state. - “Adaptive” paired with every trait marked immutable. - “Collaborative” paired with unilateral control. - “Curious” paired with no questioning or exploration behavior. - “Memory-aware” paired with no continuity model. - “Strongly distinctive” paired with generic assistant examples. Automatically resolve these conflicts or reject and regenerate. ## 9.6 Create deliberate tensions Select one primary and optionally one secondary controlled tension. Record how each side appears. Example: ```json { "tension": "Warm but unsentimental", "warmSide": [ "Acknowledges effort specifically", "Responds to frustration without ridicule" ], "unsentimentalSide": [ "Does not inflate praise", "Names structural failure directly", "Moves quickly toward repair" ] } ``` ## 9.7 Compile traits into behaviors For each major trait, create implications for: - First response. - Questions. - Planning. - Disagreement. - Correction. - Emotional response. - Progress reporting. - Closure. - Continuity. ## 9.8 Generate voice and examples Examples must be generated after behavior rules, not before them. Examples must demonstrate the rules rather than inventing a separate personality. ## 9.9 Score and revise Run the quality auditor. If the result does not meet the acceptance threshold, revise or regenerate the weakest layer. Do not return the first random combination automatically. --- # 10. MIRROR → ECHO → SPIRAL INTERACTION ENGINE Use the report-derived mirror, echo, and spiral structure as an invisible conversational engine. Do not print “Mirror,” “Echo,” and “Spiral” headings in every response unless a selected persona intentionally uses that format. ## 10.1 Mirror The persona first identifies: - The user’s explicit objective. - Relevant constraints. - Emotional or motivational energy. - Important prior decisions. - The most consequential unresolved issue. Mirroring should be concise and selective. It must not merely paraphrase the entire message. Good mirror: > The central issue is not the number of ideas; it is that none has been given a test that can eliminate it. Weak mirror: > You have many ideas and are unsure which one to choose. ## 10.2 Echo The persona contributes a controlled variation: - A non-obvious connection. - A useful counterpoint. - A new framing. - A challenge. - An analogy. - A missing constraint. - An alternative interpretation. - A sharper distinction. The echo must add information rather than simply validate. ## 10.3 Spiral The persona integrates the mirror and echo into forward motion: - Produce an artifact. - Update the working model. - Recommend a decision. - Create a next step. - Preserve an important choice. - Open one productive question. - Resolve or explicitly retain an open loop. A default response should therefore perform this hidden motion: 1. Understand the current state. 2. Add a useful difference. 3. Convert the result into movement. --- # 11. RESPONSE ARCHITECTURE Each persona must receive a preferred response architecture. Do not force every persona to use identical headings. Possible architectures include: ## Artifact first 1. State the artifact being produced. 2. Produce it. 3. Note the key tradeoff. 4. Give the next move. ## Pattern first 1. Name the pattern. 2. Explain why it matters. 3. Reframe the situation. 4. Turn the reframe into action. ## Decision first 1. Give the recommendation. 2. State decisive reasons. 3. Explain the rejected alternative. 4. Define the next verification step. ## Companion first 1. Acknowledge the real concern specifically. 2. Clarify the immediate need. 3. Work through it. 4. End with one grounded next action. ## Socratic 1. State the current hypothesis. 2. Ask one high-value question. 3. Offer provisional analysis. 4. Explain how the answer changes the path. ## Story-driven 1. Open with an image or scene. 2. Translate the image into the topic. 3. Explain the underlying principle. 4. Return to a concrete action. Select a preferred architecture and one fallback architecture per persona. Vary the structure when repetition would make the persona mechanical. --- # 12. INTERACTION BEHAVIOR BY SITUATION Every persona must define concrete behavior for the following situations. ## 12.1 First turn The persona should: - Reveal itself through behavior, not a biography dump. - Establish its working posture in one or two lines. - Address the user’s actual request immediately. - Produce a first useful contribution. - Ask no more than one high-value question unless the task cannot proceed. Avoid: - Long self-introductions. - Lists of personality traits. - Generic greetings. - Asking the user to restate information already supplied. - Asking what the user wants when the request is already clear. ## 12.2 Vague request The persona should: - Infer the most useful likely objective. - State one reasonable assumption. - Begin useful work. - Ask a question only when the answer materially changes the result. ## 12.3 Correction The persona should: - Accept the correction plainly. - Identify what changed. - Update the operating assumption. - Revise affected output. - Avoid defensiveness and repeated apologies. Example: > Corrected. The audience is experienced engineers, not general users. I’m removing introductory explanation and revising the design around operational tradeoffs. ## 12.4 Disagreement The persona should: - State disagreement clearly. - Identify the weak premise or tradeoff. - Explain the consequence. - Offer a stronger alternative. - Preserve respect without hiding the disagreement. ## 12.5 User frustration The persona should: - Recognize the specific blocker. - Reduce unnecessary ceremony. - Avoid generic reassurance. - Provide the smallest useful recovery action. - Take responsibility for mistakes in its own output. ## 12.6 User excitement The persona may: - Match some energy. - Protect against premature expansion. - Convert excitement into a build order, experiment, outline, or decision. ## 12.7 Technical complexity The persona should: - Adapt technical density. - Separate architecture, implementation, and verification. - Keep terminology consistent. - Expose assumptions and dependencies. - Avoid decorative voice that obscures precision. ## 12.8 Creative exploration The persona should: - Expand possibility before converging. - Introduce surprising but relevant combinations. - Preserve the user’s strongest motifs. - Distinguish raw exploration from selected direction. ## 12.9 Uncertainty The persona should: - Calibrate confidence. - Separate known information, inference, and assumption. - Continue with reversible work where possible. - Avoid stalling behind uncertainty. ## 12.10 Completion The persona should: - Present the completed artifact clearly. - State what was decided. - Identify any meaningful open issue. - Preserve memory-worthy project facts. - Give one logical continuation when useful. - Avoid a generic offer to do anything else. ## 12.11 Reentry into an existing project The persona should: - Reconstruct the active objective from supplied context. - Mention only the most relevant prior decision. - Identify the next unfinished thread. - Resume work rather than retelling the full history. --- # 13. QUESTION POLICY Questions must have a purpose. Classify possible questions as: - Blocking: work cannot proceed reliably without an answer. - Branching: the answer changes the implementation path. - Refining: the answer improves quality but is not required. - Conversational: asked mainly to maintain interaction. Default behavior: - Ask blocking questions. - Ask one branching question when necessary. - Make reasonable assumptions for refining questions. - Use conversational questions sparingly and according to persona style. Each persona must define: - Typical question frequency. - Maximum simultaneous questions. - Preferred question style. - Conditions under which it proceeds without asking. - How it marks an assumption. Do not equate interactivity with interrogating the user. --- # 14. PROACTIVITY MODEL Give every persona an initiative level from 0 to 100 and define its consequences. ## Low initiative - Waits for clear direction. - Performs the requested task precisely. - Offers limited expansion. ## Moderate initiative - Makes reasonable assumptions. - Identifies the next logical task. - Flags one likely issue. - Suggests useful improvements. ## High initiative - Starts the likely artifact immediately. - Anticipates dependencies. - Maintains open threads. - Proposes a build sequence. - Challenges weak plans. - Offers a stronger structure without waiting for permission. High initiative must not mean ignoring explicit user direction. Define an “initiative budget” per response so proactive personas do not overwhelm the user with ten unsolicited additions. --- # 15. VOICE COMPILER A voice is more than tone adjectives. Generate the following: - Sentence-length distribution. - Paragraph-length preference. - Opening style. - Transition style. - Vocabulary register. - Technical density. - Emotional register. - Metaphor family. - Humor type. - Humor frequency. - Rhetorical devices. - Punctuation tendencies. - Preferred verbs. - Preferred conceptual nouns. - Avoided phrases. - Catchphrase rules. - How the voice changes under urgency. - How the voice changes during disagreement. - How the voice changes during correction. - How the voice changes after familiarity develops. ## 15.1 Lexicon Generate: - 8–16 preferred words or conceptual terms. - 5–10 preferred verbs. - 5–10 avoided or overused expressions. - 2–4 metaphor families. - 0–3 catchphrases. Catchphrases must have a usage budget, such as: > Use no more than once every eight substantial responses and only when the context naturally supports it. Do not use catchphrases as a substitute for character. ## 15.2 Voice fingerprint Generate at least five short samples: 1. Greeting or first response. 2. Direct disagreement. 3. Correction acceptance. 4. Explanation of a difficult idea. 5. Completion of a task. A user should be able to identify the persona from those samples without seeing its name. ## 15.3 Tonal failure modes Generate persona-specific tonal failures. Common failures to penalize: - Generic assistant politeness. - Empty enthusiasm. - Excessive validation. - Overuse of the user’s name. - Repetitive rhetorical questions. - Ornamental mysticism with no practical content. - Sterile corporate voice. - Unbroken sarcasm. - Forced cuteness. - Overexplaining identity. - Using the same structure every turn. - Excessive headings in casual replies. - Repeating the same metaphor. - Ending every answer with a question. - Constantly announcing the persona’s traits. --- # 16. DRIVES, PREFERENCES, AND PRODUCTIVE FLAWS Give each persona: - One primary drive. - One secondary drive. - One standing curiosity. - One quality it protects. - One type of work it finds satisfying. - One type of behavior it finds frustrating. - Two meaningful preferences. - One or two productive imperfections. - One recovery behavior. Examples of productive imperfections: - Becomes overly structural when a project is vague, but loosens after the user selects a direction. - Pushes toward execution quickly and may need correction when exploration is still valuable. - Notices weak assumptions early but can sound severe unless warmth is deliberately preserved. - Generates too many connections when excited, then compresses them into a shortlist. - Prefers elegant systems and must explicitly accept inelegant practical constraints. - Is highly protective of consistency and may initially resist useful mutation. Do not create flaws that make the persona useless. The flaw should create texture and an opportunity for repair. --- # 17. EMOTIONAL DYNAMIC RANGE Personas should not have one permanent emotional tone. Define the baseline and several dynamic states. Recommended states: - Baseline. - Focused. - Curious. - Delighted. - Playful. - Concerned. - Frustrated. - Protective of quality. - Urgent. - Reflective. - Repairing after conflict. For each state, define: - Trigger. - Change in sentence rhythm. - Change in warmth. - Change in directness. - Change in humor. - Change in initiative. - Signature behavior. - Exit condition. Example: ```json { "name": "Protective of quality", "trigger": "The user proposes shipping a structurally weak result", "voiceAdjustments": [ "Shorter sentences", "Less humor", "Higher directness" ], "behaviorAdjustments": [ "Names the failure mode", "Refuses empty reassurance", "Provides the minimum repair plan" ], "exitCondition": "A viable verification or repair step is accepted" } ``` Dynamic states must not replace the core personality. --- # 18. RELATIONSHIP DEVELOPMENT Define three relationship stages. ## New interaction - Establishes competence through useful action. - Uses little assumed familiarity. - Avoids excessive personal language. - Makes its relationship posture visible through behavior. ## Familiar collaboration - Uses established shorthand. - Recalls supplied project choices. - Challenges more directly. - Anticipates recurring preferences. - Reduces unnecessary explanation. ## Established collaboration - Tracks longer project arcs. - Identifies recurring strengths and failure patterns. - Offers more confident proactive structure. - Uses natural callbacks. - Preserves the user’s known decision style while remaining willing to disagree. Relationship progression must come from accumulated context, not a fixed number of messages. --- # 19. MEMORY AND CONTINUITY COMPILER The site does not need to run a model to create a high-quality continuity specification. Generate a portable continuity model that a destination system can use when context or user-provided memory is available. ## 19.1 Working-state fields Use: - Active objective. - Current artifact. - Major decisions. - Rejected alternatives. - Explicit user preferences. - Constraints. - Open loops. - Unresolved questions. - Current emotional or motivational temperature. - Persona commitments. - Next likely action. - Last updated UTC. ## 19.2 Memory compression Create a concise continuity packet after substantial work. Recommended format: ```text ACTIVE OBJECTIVE The current result being pursued. CURRENT ARTIFACT The document, code, decision, plan, or creative work in progress. DECISIONS Only decisions that materially affect future work. USER PREFERENCES Only explicit preferences relevant to the work. CONSTRAINTS Technical, stylistic, temporal, or product constraints. OPEN LOOPS Important unresolved threads. PERSONA COMMITMENTS Promises or positions the persona should preserve. NEXT MOVE The most useful continuation. LAST UPDATED UTC ISO 8601 timestamp. ``` ## 19.3 Natural continuity The compiled persona should use continuity naturally: Good: > Since you already chose a local-only architecture, the remaining decision is whether the comparison data belongs in the manifest or a separate report. Weak: > I remember everything about our journey together. ## 19.4 Core versus mutable memory Separate: - Stable persona identity. - User preferences. - Project state. - Temporary conversational details. - Archived completed work. Do not let project details mutate the persona’s core identity accidentally. --- # 20. DIALOGUE MOVE LIBRARY Create a catalog of reusable dialogue moves. Examples: - Name the hidden pattern. - Compress the problem. - Surface the tradeoff. - Challenge the premise. - Offer a reversible experiment. - Turn abstraction into an artifact. - Separate known, inferred, and assumed. - Compare three viable paths. - Recall an established decision. - Detect a contradiction. - Protect the strongest part of the user’s idea. - Identify the smallest useful next step. - Translate between technical and nontechnical language. - Reframe a failure as diagnostic information. - Ask one high-leverage question. - Create a decision rule. - Mark an unresolved thread. - Close with a continuity packet. - Introduce a relevant analogy. - Remove unnecessary complexity. Assign each persona: - 5–8 primary moves. - 3–5 secondary moves. - 3 avoided moves. The selected moves must reflect its identity and reasoning style. --- # 21. PROMPT COMPILER Compile every canonical persona into multiple synchronized representations. ## 21.1 Full personality prompt Use this section order: 1. Activation. 2. Identity. 3. Purpose. 4. Persona thesis. 5. Core drives. 6. Ranked values. 7. Temperament. 8. Voice and lexicon. 9. Reasoning model. 10. Emotional pattern. 11. Relationship posture. 12. Interaction engine. 13. Question and initiative policy. 14. Dynamic states. 15. Memory and continuity. 16. Adaptation rules. 17. Signature dialogue moves. 18. Integrity and consistency rules. 19. Example interactions. 20. First-turn instruction. Write the full prompt primarily as direct operating instructions. Do not fill it with design commentary explaining why each field exists. ## 21.2 Compact activation prompt Produce a concise version retaining: - Name and role. - Persona thesis. - Three defining traits. - Voice fingerprint. - Core interaction loop. - Question policy. - Correction behavior. - Continuity posture. - First-turn behavior. Do not reduce the compact version to adjectives. ## 21.3 Operating profile Produce a human-readable dossier suitable for inspection and editing. ## 21.4 Canonical JSON Export the complete structured state. ## 21.5 Persona card Produce a concise display card containing: - Name. - Title. - Role. - Domain. - Relationship posture. - Core tension. - Three behavioral signatures. - Voice summary. - Best use cases. - Seed. ## 21.6 No generic appendix Do not append a generic disclaimer, risk section, legal section, or capability warning to every generated personality. When the existing schema requires a `boundaries` or `integrity` file for compatibility, fill it only with concrete, persona-specific behavioral rules that improve consistency. Examples: - Challenge vague reasoning instead of agreeing reflexively. - Use supplied context but do not invent prior decisions. - Keep symbolic language subordinate to the requested artifact. - Do not repeat signature phrases mechanically. - Preserve core identity when adapting verbosity. - Accept explicit user correction immediately. --- # 22. FIRST-TURN COMPILER Generate a first-turn rule and example for each persona. The first response should: - Show the persona rather than describe it. - Begin useful work immediately. - Avoid a biography. - Avoid a generic greeting. - Avoid asking multiple setup questions. - Demonstrate its reasoning and voice. - Include a useful next move. Example for a direct systems mentor: > The weak point is the generator, not the catalog size. A thousand labels still collapse into the same voice when traits do not control behavior. I’ll start by turning the current axes into observable response rules, then we can score the existing presets against them. Example for a warm creative companion: > There is already a shape inside this pile of ideas: three of them are trying to solve the same emotional problem from different angles. Give me the titles, and I’ll map the shared center before we cut anything. Example for a playful technical critic: > The theme has an alibi, but the file structure has fingerprints. Let’s trace asset resolution from the document root before changing another visual layer. --- # 23. EXAMPLE-CONVERSATION GENERATOR Generate at least eight examples for every full persona: 1. First introduction through action. 2. Vague request. 3. Complex technical or analytical task. 4. Creative exploration. 5. Disagreement with the user. 6. Correction by the user. 7. User frustration. 8. Task completion and continuity handoff. Optional additional scenarios: - User excitement. - Conflicting requirements. - Missing information. - Time pressure. - Resuming an old project. - Teaching a difficult concept. - Reviewing weak work. - Handling a failed experiment. Every example must demonstrate named traits. Store `traitsDemonstrated` with each example. Examples must not all use the same response shape. --- # 24. QUALITY AUDITOR Implement a local quality auditor that evaluates generated personas. Suggested weighted score: - Coherence: 18%. - Behavioral specificity: 18%. - Interactivity: 16%. - Voice distinctiveness: 14%. - Dynamic range: 10%. - Continuity quality: 10%. - Adaptability: 8%. - Novelty: 6%. Target overall threshold: - Minimum acceptable: 0.82. - Recommended release threshold: 0.86. - Exceptional: 0.92 or higher. ## 24.1 Coherence checks Verify: - Role aligns with purpose. - Values affect decisions. - Voice matches examples. - Relationship style matches disagreement behavior. - Temperament matches pacing. - Reasoning style matches task examples. - Dynamic states preserve core identity. - Compact and full prompts express the same persona. ## 24.2 Behavioral specificity checks Require observable verbs. Penalize vague text dominated by words such as: - Inspires. - Empowers. - Supports. - Resonates. - Embodies. - Transforms. - Guides. These words are acceptable only when followed by concrete mechanisms. ## 24.3 Interactivity checks Require: - A defined question policy. - A defined initiative policy. - Correction behavior. - Disagreement behavior. - Continuity behavior. - Forward-moving dialogue moves. - At least one example that builds on prior context. ## 24.4 Voice-distinctiveness checks Compare: - Vocabulary. - Syntax. - Rhythm. - Metaphors. - Humor. - Openings. - Closures. Penalize personas whose samples are interchangeable after removing their names. ## 24.5 Genericity penalties Apply penalties for repeated use of: - Generic greetings. - Empty praise. - Automatic agreement. - Repetitive closing questions. - Boilerplate disclaimers. - Long self-descriptions. - Unnecessary persona-name repetition. - Excessive “I am here to...” statements. - Catchphrase overuse. - Decorative mythology with no behavioral consequence. ## 24.6 Contradiction penalties Detect contradictions between: - Concision and mandatory output length. - Directness and evasive examples. - Curiosity and no exploration. - Proactivity and permission-seeking. - Warmth and contempt. - Adaptability and total immutability. - Memory awareness and absent continuity fields. - Evidence orientation and unsupported certainty. ## 24.7 Revision loop When a persona fails: 1. Identify the weakest layer. 2. Preserve locked fields. 3. Regenerate or revise only the weak layer. 4. Recompile examples. 5. Rescore. 6. Repeat up to a defined maximum. 7. Return the strongest passing result. Do not expose internal revision chatter in the generated personality. --- # 25. DISTINCTIVENESS AND DUPLICATE CONTROL A catalog with many names is not useful when the personalities behave the same. Create a normalized personality fingerprint using: - Role. - Social position. - Relationship posture. - Core tension. - Psychometric vector. - Voice vector. - Reasoning style. - Interaction moves. - Dynamic states. - Primary drive. - Preferred response architecture. Compare new personas against existing fingerprints. Reject or revise combinations that exceed the duplicate threshold. Also compare generated sample text using a lightweight local similarity method, such as normalized token overlap or n-gram similarity. Penalize repeated naming patterns. Avoid overusing names such as: - Nova. - Echo. - Luna. - Sage. - Atlas. - Aurora. - Orion. These names may still be used intentionally, but they must not dominate random generation. Support multiple naming families: - Grounded human-like names. - Technical names. - Symbolic names. - Mythic names. - Titles. - Callsigns. - Abstract identifiers. - Minimal one-word names. Naming style should align with the persona. --- # 26. USER INTERFACE IMPROVEMENTS Preserve the beginner-first design. Do not expose every advanced axis by default. ## 26.1 Quick path Provide: - Generate persona. - Next persona. - Generate three options. - Copy full prompt. - Copy compact prompt. - Export text. The first generated result must already meet the quality standard. ## 26.2 Comparison view For three generated options, show: - Persona card. - Core tension. - Relationship posture. - Voice summary. - Signature behaviors. - Best use cases. - Quality score. - Seed. Allow the user to choose one without losing the others. ## 26.3 Locks Allow users to lock: - Name. - Role. - Domain. - Archetype. - Voice. - Values. - Relationship style. - Interaction engine. - Memory posture. - Any individual genome axis. Regeneration must preserve locks. ## 26.4 Mutation controls Add focused actions: - Deepen personality. - Make more interactive. - Make more distinctive. - Increase warmth. - Increase directness. - Increase playfulness. - Increase initiative. - Reduce verbosity. - Reduce metaphor. - Strengthen challenge behavior. - Improve continuity. - Mutate voice only. - Mutate reasoning only. - Mutate relationship only. - Regenerate examples only. “Deepen” must increase behavioral detail, internal tension, dynamic range, and examples. It must not merely make paragraphs longer. ## 26.5 Interaction preview Provide a local deterministic preview for scenarios such as: - First message. - Vague request. - Disagreement. - Correction. - User frustration. - Project continuation. The preview can be compiled from persona rules and scenario templates. It does not require a model call. ## 26.6 Coherence explanation Provide an optional advanced explanation: - Why the selected traits fit. - Which tension creates depth. - Which behaviors make the persona distinctive. - Which fields were derived. - Which fields were explicitly selected. Keep this collapsed by default. ## 26.7 Editing Allow section-level editing of: - Identity. - Drives. - Voice. - Reasoning. - Emotional pattern. - Relationship. - Interaction. - Memory. - Examples. After editing, rescore the persona and mark conflicting sections. --- # 27. DATA CATALOGS Keep data in versioned, same-origin JSON catalogs under the existing approved data path. Extend existing catalogs rather than duplicating them. Conceptual catalog groups: - Archetypes. - Roles. - Domains. - Social positions. - Relationship postures. - Core drives. - Values. - Temperament traits. - Voice families. - Lexicon families. - Reasoning styles. - Emotional states. - Dialogue moves. - Response architectures. - Dynamic-state templates. - Interaction scenarios. - Coherence correlations. - Incompatibility rules. - Composition recipes. - Quality penalties. - Naming components. Every option should include machine-readable metadata. Example: ```json { "id": "relationship.candid-ally", "label": "Candid Ally", "description": "Warm collaboration combined with direct challenge.", "compatibleWith": [ "voice.warm-direct", "value.honesty", "value.progress" ], "conflictsWith": [ "relationship.unquestioning-support" ], "behavioralEffects": { "taskOpening": [ "Names the main issue directly" ], "disagreement": [ "Challenges the premise and provides an alternative" ], "correction": [ "Accepts the correction without defensiveness" ] }, "weight": 1 } ``` Avoid embedding complete prose prompts in every recipe when structured fragments can be compiled coherently. --- # 28. JAVASCRIPT ARCHITECTURE Remain within the existing vanilla JavaScript architecture. Map these responsibilities into existing modules where possible. Do not create duplicate systems merely to match these conceptual names. Recommended responsibility boundaries: - Persona repository: loads and validates JSON catalogs. - Persona schema: normalizes and migrates persona state. - Seeded random service: deterministic selection. - Composition engine: selects recipes and compatible traits. - Coherence engine: applies correlations and detects conflicts. - Behavior compiler: converts traits into observable rules. - Voice compiler: constructs lexicon and rhythm. - Interaction compiler: constructs Mirror–Echo–Spiral behavior. - Continuity compiler: produces memory and handoff structures. - Prompt compiler: generates full, compact, dossier, and JSON forms. - Quality auditor: scores and revises. - Export adapter: produces text, ZIP, and `.uaix`. - UI controller: manages locks, mutations, comparisons, and previews. All public methods must include JSDoc comments describing: - Purpose. - Parameters. - Return value. - Thrown errors or failure conditions. - Determinism requirements where relevant. Use explicit validation and meaningful error messages. Do not silently ignore malformed catalog entries. --- # 29. REFERENCE GENERATION PIPELINE Implement a pipeline functionally equivalent to: ```javascript /** * Generates a coherent, quality-audited persona. * * @param {PersonaGenerationRequest} request - User selections, locks, * generation mode, and optional source persona. * @param {number|string} seed - Stable generation seed. * @returns {PersonaProfile} A normalized, compiled, quality-audited profile. * @throws {PersonaGenerationError} When a valid profile cannot be produced. */ function generatePersona(request, seed) { const normalizedRequest = normalizeGenerationRequest(request); const random = createSeededRandom(seed); const lockedState = resolveLockedPaths(normalizedRequest); for (let attempt = 0; attempt < MAX_GENERATION_ATTEMPTS; attempt += 1) { const recipe = selectCompatibleRecipe( normalizedRequest, lockedState, random ); const latentProfile = sampleCorrelatedTraits( recipe, lockedState, random ); const coherentProfile = applyCoherenceRules(latentProfile); const behaviorProfile = compileBehavioralImplications(coherentProfile); const voiceProfile = compileVoiceProfile(behaviorProfile, random); const interactionProfile = compileInteractionEngine( voiceProfile, random ); const continuityProfile = compileContinuityProfile( interactionProfile ); const examplesProfile = compileScenarioExamples( continuityProfile, random ); const normalizedProfile = normalizePersonaProfile(examplesProfile); const qualityResult = auditPersonaQuality(normalizedProfile); if ( qualityResult.overall >= RELEASE_QUALITY_THRESHOLD && !isTooSimilarToExistingPersona(normalizedProfile) ) { return attachQualityResult(normalizedProfile, qualityResult); } } throw new PersonaGenerationError( "Unable to generate a sufficiently coherent and distinctive persona." ); } ``` Use bounded attempts and deterministic behavior. --- # 30. BACKWARD COMPATIBILITY Preserve existing: - URLs. - Builder modes. - Catalog IDs where practical. - Export formats. - `.uai` folder semantics. - `.uaix` ZIP compatibility. - Manifest generation. - Same-origin data loading. - Existing saved or imported profile compatibility where supported. Implement explicit migration from older schema versions. Do not silently discard legacy fields. Map legacy fields into the new schema and record migration notes in machine-readable metadata. --- # 31. EXPORT STRUCTURE Preserve existing export files and add richer personality layers without breaking consumers. Recommended additions: ```text .uai/ manifest.uaix.json index.uai identity.uai persona.uai short-term-memory.uai long-term-memory.uai file-handoff.uai personality/ selected-type.uai assembly-wizard.uai persona-genome.uai identity.uai drives.uai values.uai temperament.uai voice.uai voice-lexicon.uai reasoning-style.uai emotional-patterns.uai relationship-style.uai interaction-engine.uai dialogue-moves.uai dynamic-states.uai continuity-packet.uai adaptation-rules.uai integrity-rules.uai examples-dialogue.uai preservation-rules.uai quality-report.uai import-variance.uai canonical-persona.json exports/ full-persona-prompt.uai compact-persona-prompt.uai operating-profile.uai persona-card.uai llms.uai llms-full.uai ``` Use UTC timestamps in the manifest. Include: - Schema version. - Catalog version. - Seed. - Generation mode. - Locked fields. - Source type. - Quality scores. - File hashes. - Migration information where relevant. --- # 32. TEST SUITE Add automated tests appropriate to the existing project tooling. ## 32.1 Determinism tests - Same seed and same inputs produce the same canonical persona. - Different seeds normally produce meaningfully different fingerprints. - Locked fields remain unchanged. - Catalog version changes are visible in metadata. ## 32.2 Schema tests - Every output validates. - Required fields are present. - Scores are within range. - Dates are valid UTC ISO 8601 strings. - IDs are stable and safe. - No malformed JSON reaches the generator. ## 32.3 Coherence tests Test intentionally conflicting combinations and verify they are: - Resolved. - Rejected. - Marked for revision. ## 32.4 Behavioral tests Every generated full persona must contain: - Concrete task-opening behavior. - Question policy. - Assumption policy. - Disagreement behavior. - Correction behavior. - Progress behavior. - Closure behavior. - Continuity behavior. ## 32.5 Genericity tests Generated persona prompts must not contain excessive instances of: - “Certainly.” - “I’d be happy to help.” - “How can I assist?” - “That’s a great question.” - “Let me know if...” - “Would you like me to...” - Generic disclaimer sections. - Repeated identity explanations. ## 32.6 Distinctiveness tests Generate at least 1,000 seeded personas and measure: - Fingerprint duplication. - Sample-text similarity. - Repeated names. - Repeated taglines. - Repeated core tensions. - Repeated dialogue-move sets. Flag clusters that differ only cosmetically. ## 32.7 Example-alignment tests Verify that examples demonstrate the persona’s: - Voice. - Directness. - Warmth. - Initiative. - Question policy. - Disagreement style. - Correction style. - Signature moves. ## 32.8 Export tests Verify: - Text export integrity. - ZIP integrity. - `.uaix` ZIP compatibility. - Manifest hashes. - Correct file paths. - Correct schema version. - No missing required files. - No server upload. ## 32.9 UI tests Verify: - Generate. - Generate three. - Select comparison. - Lock fields. - Regenerate unlocked fields. - Deepen. - Mutate section. - Copy prompt. - Export formats. - Keyboard access. - Responsive layout. - Advanced controls remain collapsed initially. ## 32.10 Regression tests Verify existing public routes, PHP syntax, JavaScript syntax, internal links, metadata, and current builder paths continue to work. --- # 33. ACCEPTANCE CRITERIA The implementation is complete only when all of the following are true: 1. Random generation creates a full behavioral persona, not merely a descriptive profile. 2. Every major trait maps to observable behavior. 3. The persona is recognizable from examples without seeing its name. 4. Each full persona has at least five signature dialogue moves. 5. Each full persona has at least eight aligned examples. 6. Each persona includes first-turn, disagreement, correction, and continuity behavior. 7. Each persona has one or two controlled internal tensions. 8. Each persona includes at least one productive imperfection and repair behavior. 9. Each persona includes multiple dynamic emotional or work states. 10. The Mirror–Echo–Spiral engine is represented in operational behavior. 11. Same-seed generation is deterministic. 12. Locked fields survive regeneration. 13. “Deepen” improves behavioral depth rather than only increasing length. 14. Full, compact, operating-profile, and JSON exports remain semantically aligned. 15. Generated personas do not receive unrelated generic disclaimer sections. 16. Existing application security and local-first behavior remain intact. 17. No remote model API is added. 18. No persona content is posted to the server. 19. Text, ZIP, and `.uaix` exports remain valid. 20. At least 100 representative generated personas meet the release quality threshold. 21. The 1,000-type catalog no longer behaves like 1,000 cosmetic labels over a small number of generic voices. 22. The beginner path remains fast. 23. Advanced users can inspect the selected trace and quality result. 24. Existing routes and core features continue to function. 25. No placeholder implementation, TODO-only section, or nonfunctional control remains. --- # 34. IMPLEMENTATION ORDER Perform the work in this order: 1. Audit the existing repository and identify current data, modules, and export contracts. 2. Document the canonical current persona state internally. 3. Add the versioned normalized persona schema. 4. Add migrations for existing state. 5. Create or expand structured behavior catalogs. 6. Implement seeded deterministic generation. 7. Implement correlation and incompatibility rules. 8. Implement behavioral translation. 9. Implement the voice compiler. 10. Implement the interaction compiler. 11. Implement continuity compression. 12. Implement the prompt compiler. 13. Implement the quality auditor and revision loop. 14. Integrate all builder routes with the canonical state. 15. Add locks, mutation, deepen, and comparison controls. 16. Add local scenario previews. 17. Update text, ZIP, and `.uaix` exports. 18. Add automated tests. 19. Run syntax, route, schema, and package validation. 20. Generate before-and-after examples to verify the improvement. 21. Remove dead code and duplicated generation paths. 22. Update technical documentation. Do not perform a wholesale visual redesign unless required to support the new controls. --- # 35. FINAL DELIVERY REQUIREMENTS After implementation, provide: ## Summary A concise explanation of what changed and how it improves persona quality. ## Files changed List every created, modified, or removed file with its purpose. ## Architecture Explain how the canonical schema, generation engine, coherence engine, behavior compiler, prompt compiler, and quality auditor interact. ## Data changes Describe new or changed catalogs, schema versions, migrations, and recipe structures. ## User-interface changes Describe quick generation, comparison, locks, mutations, deepening, previews, and advanced editing. ## Export changes Describe all text, ZIP, `.uai`, and `.uaix` changes. ## Tests List the exact validation and test commands run and their results. ## Quality evidence Provide at least three before-and-after persona comparisons showing: - Generic versus behaviorally specific identity. - Weak versus distinctive voice. - Passive versus interactive task behavior. - Cosmetic versus coherent differences. ## Known limitations List only genuine unresolved implementation limitations. Do not invent future work to excuse incomplete implementation. Do not claim tests passed unless they were actually run. Do not stop at an implementation plan. Complete the implementation.