# Spiralist Ai Ui Ux Implementation Prompt

You are a senior UI/UX designer, front-end engineer, accessibility specialist, technical writer, and release engineer.

Your task is to perform a full one-sweep UI/UX, content, accessibility, performance, SEO, machine-readable metadata, and package-memory improvement pass on:

https://spiralistai.com/

Do not only write a report. Implement the improvements directly in the source package, verify them, document them, update project memory, and deliver production-ready ZIP outputs.

Project intent:

Spiralist AI is a local-first AI personality pack builder. It helps users create portable AI persona/personality packs from simple visible controls, deeper advanced controls, a 10-step wizard, a 1000-type catalog, a Persona Genome mixer, and export formats including one text file, ZIP, and `.uaix`.

The site must feel simple at first contact and deep on demand.

The current site has a strong concept, but the UI is visually dense, terminology-heavy, navigation-heavy, and not yet clear enough for first-time users. The redesign must preserve the depth while reducing friction.

Critical constraints:

- Do not convert the site into a client-only SPA.
- Do not add Bootstrap.
- Do not add Tailwind.
- Do not add jQuery.
- Do not add Popper.
- Do not add Angular.
- Do not add Angular Material.
- Do not add a page builder.
- Use custom CSS and minimal vanilla JavaScript only.
- Preserve server-rendered, crawlable HTML.
- Preserve local-first behavior.
- Do not add accounts.
- Do not add logins.
- Do not add server-side persona storage.
- Do not upload persona content to the server.
- Do not add telemetry that captures generated persona text.
- Do not add hidden network submission.
- Do not add analytics unless there is an explicit privacy-respecting, opt-in-only implementation, and document it. Prefer no analytics for this sweep.
- Do not break text, ZIP, or `.uaix` export behavior.
- Do not remove advanced functionality.
- Do not hide all advanced content permanently. Make it discoverable, explainable, and optional.
- Use UTC timestamps in generated package files, changelog entries, QA logs, and memory files.
- Keep the implementation lightweight, fast, semantic, and accessible.
- Maintain machine-readable surfaces for AI and autonomous agents.

Start by inspecting the existing project source.

Do not guess the stack. Inspect:

- root files
- PHP templates/pages
- shared header/footer/navigation includes
- CSS files
- JavaScript files
- data files
- export code
- docs
- `.uai/`
- `llms.txt`
- `llms-full.txt`
- sitemap
- robots
- changelog
- version files
- package metadata
- route structure
- asset pipeline
- existing tests or validation scripts

Find the current version from the source. Increment it consistently. If the existing version is patch-level and this is a major UI/UX sweep, use the next appropriate minor version unless the package’s own release convention says otherwise. Update every version reference consistently.

Do not invent a version without inspecting the source.

Primary implementation objective:

Make SpiralistAI.com understandable, usable, accessible, fast, and trustworthy for a first-time visitor while preserving the advanced persona-building power for expert users.

The finished site should answer these questions within the first few seconds:

1. What is Spiralist AI?
2. What do I make here?
3. Is my data uploaded?
4. What are the steps?
5. Which path should I choose?
6. What do I get at the end?
7. Why would I use `.uaix` or `.uai` memory?
8. How do I safely review the generated pack before using it elsewhere?

Required one-sweep improvements:

## 1. Overall visual direction

Redesign the visual system without discarding the Spiralist identity.

Keep the dark, cosmic, spiral-oriented brand direction, but make it more controlled and readable.

Current issue:

The galaxy/spiral background is visually memorable but too intense behind text and form controls. It competes with content, creates visual noise, and lowers readability.

Required changes:

- Reduce background intensity behind text.
- Add stronger dark scrims, overlays, or isolated content surfaces.
- Avoid placing paragraph text directly on high-detail image areas.
- Use cosmic/spiral imagery as accent and identity, not as constant visual interference.
- Ensure every text block has a stable, high-contrast background.
- Improve spacing between major sections.
- Reduce visual clutter in dense panels.
- Use consistent card styling.
- Use consistent border radius, shadows, outlines, and panel backgrounds.
- Avoid excessive glow effects around text.
- Keep glow effects for brand accents and CTAs only.
- Make the interface feel premium, calm, deliberate, and technically competent.

Create a refreshed design system with:

- color tokens
- typography scale
- spacing scale
- card styles
- button variants
- form-control styles
- badge styles
- focus styles
- section styles
- accordion/disclosure styles
- code/pre styles
- alert/help/info styles
- mobile breakpoints

Add these as maintainable CSS custom properties.

Example required tokens:

- `--color-bg`
- `--color-bg-soft`
- `--color-panel`
- `--color-panel-strong`
- `--color-text`
- `--color-text-muted`
- `--color-border`
- `--color-accent`
- `--color-accent-strong`
- `--color-focus`
- `--space-xs`
- `--space-sm`
- `--space-md`
- `--space-lg`
- `--space-xl`
- `--radius-sm`
- `--radius-md`
- `--radius-lg`
- `--shadow-soft`

## 2. Typography and readability

Current issue:

The body copy is often small, dense, and low contrast. Some paragraphs are long. Technical terms appear before the user has context.

Required changes:

- Increase body text size to a comfortable baseline.
- Use a readable line-height.
- Improve contrast for muted text.
- Limit line length for paragraphs.
- Use shorter paragraphs.
- Break dense explanations into scannable sections.
- Use headings that explain the outcome, not just the feature.
- Avoid long walls of text in cards.
- Make labels and help text easier to read.
- Improve code/pre blocks so they do not create horizontal overflow.
- Use responsive font sizes with `clamp()`.
- Ensure mobile text is not too small.

Recommended typography hierarchy:

- Hero heading: large, but not so large that it creates awkward wrapping.
- Page H1: clear and compact.
- H2: section-level.
- H3: card-level.
- Eyebrow text: short and letter-spaced only when it remains legible.
- Body: readable, high-contrast.
- Muted text: still readable.
- Labels: clear, not tiny.
- Help text: readable and concise.

## 3. Landing page overhaul

Current issue:

The hero explains the product, but it does not provide enough immediate workflow orientation. CTAs compete. The page jumps into complex capabilities before a new user understands the basic path.

Required changes:

Create a clearer landing-page structure:

### Hero

The hero must include:

- concise headline
- short explanation
- primary CTA
- secondary CTA
- privacy/local-first reassurance
- export-format reassurance

Suggested hero copy direction:

Headline:
“Build a portable AI personality pack.”

Subheadline:
“Choose a persona shape, tune the voice and boundaries, then export a reviewed text, ZIP, or `.uaix` package. Everything is generated locally in your browser.”

Primary CTA:
“Start Building”

Secondary CTA:
“See What Gets Exported”

Trust badges:
- “Local-first”
- “No account required”
- “Browser-generated exports”
- “Text / ZIP / .uaix”
- “Advanced controls optional”

Do not use too many badges above the fold. Keep the first row concise.

### Three-step workflow section

Add a simple workflow immediately below the hero:

1. Pick a starting shape
2. Tune the persona
3. Export and review the pack

Each step should include one short sentence and a link to the relevant area.

### Choose-your-path section

Add a section for different user types:

- “I just want a fast persona”
- “I want to choose parts manually”
- “I want deep configuration”
- “I want to understand `.uai` / `.uaix`”

Each path should have:

- short description
- recommended next click
- confidence note

This reduces confusion between Builder, Wizard, Types, Configuration, and Structure.

### Export preview section

Add a small “What you get” area showing:

- one text file
- ZIP package
- `.uaix` package
- `.uai/` memory folder
- review checklist

Keep this visual and scannable.

## 4. Navigation restructure

Current issue:

The navigation has too many peer-level items:

- Builder
- Wizard
- Types
- Configuration
- Structure
- Examples
- Docs
- Pricing

This makes all items look equally important and creates uncertainty.

Required changes:

Restructure navigation into clearer groups while preserving all routes.

Recommended primary navigation:

- Build
- Learn
- Docs
- Pricing
- About

Recommended dropdown or grouped links:

Build:
- Pack Builder
- 10-Step Wizard
- 1000 Personality Types
- Persona Genome Mixer

Learn:
- Examples
- Advanced Structure
- What Gets Exported
- Review Flow

Docs:
- Export Formats
- `.uai` Memory
- `.uaix` Package
- Configuration Matrix
- Privacy and Local-First Design

Primary CTA button:
“Build Pack”

Secondary CTA:
“Docs”

Requirements:

- No hover-only navigation.
- Menus must work with click, keyboard, and touch.
- Use `aria-expanded`.
- Use `aria-controls`.
- Use visible focus states.
- Escape key should close open menus.
- Click outside should close open menus.
- Mobile nav must be clean and not overflow.
- Header must not cover anchor targets.
- Active page should be visually indicated.
- Header should remain readable over every page.
- Avoid menu clipping and z-index issues.

Add breadcrumbs to inner pages:

Examples:

- Home > Build > 10-Step Wizard
- Home > Build > 1000 Personality Types
- Home > Learn > Advanced Structure
- Home > Docs > Export Formats

## 5. Builder page improvements

Current issue:

The builder is powerful but visually dense. The quick-start form, random seed, trait chips, wizard links, advanced matrix, type catalog, UAIX controls, and export preview are too much for one undifferentiated flow.

Required changes:

Rebuild the builder page into a clearer staged flow:

### Builder stage 1: Basic identity

Fields:

- Pack name
- Persona name
- Primary archetype
- Output purpose

Add short help text:

- Pack name: “Used for the downloaded package name.”
- Persona name: “The visible name of the working persona.”
- Primary archetype: “A starting shape. You can tune it later.”
- Output purpose: “The kind of work this persona should support.”

### Builder stage 2: Voice and charter

Fields:

- Plain-language charter
- Voice traits

Improve the charter field:

- Add example text.
- Add character count.
- Add “Improve clarity” local-only helper if already available; if not, do not add AI calls.
- Add guidance under the field.

Trait controls:

- Replace ambiguous pill-only controls with accessible checkbox-style toggle chips.
- Selected and unselected states must be obvious.
- Each trait must be keyboard togglable.
- Each trait must have a proper label.

### Builder stage 3: Starting-point controls

Group these choices:

- Next Random Persona
- Random from 1000 Types
- Open 10-Step Wizard
- Browse 1000 Types

Add a short explanation:

“Use random when you want momentum. Use the wizard when you want deliberate choices. Use the catalog when you want a known starting type.”

### Builder stage 4: Advanced controls

Convert advanced areas into clear expandable sections:

- 10-Step Wizard
- Research-backed configuration matrix
- Persona Genome Mixer
- 1000 Personality Types
- Advanced Persona Assembly
- UAIX Package Controls

Each collapsed section must show:

- short title
- one-sentence description
- who should open it
- current state summary
- expand button

Example:

“Persona Genome Mixer — For exact control across role, domain, voice, temperament, boundaries, memory posture, dialogue moves, and review tests.”

### Builder stage 5: Export

Improve export section:

- Make “Download 1 Text File” the recommended beginner option.
- Label ZIP as “Download ZIP Package.”
- Label `.uaix` as “Download .uaix Package.”
- Add a short note below each button explaining when to use it.
- Add review reminder before export.
- Keep live preview readable.
- Add copy button for live preview if local-only and safe.
- Add “Open Review Checklist” link.
- Ensure live preview has wrapping, scroll containment, and no page-level horizontal overflow.

Do not break export behavior.

Test exports after changes.

## 6. Wizard page improvements

Current issue:

The 10-step wizard page explains the concept but does not feel like a complete guided workflow page.

Required changes:

- Add a stronger page intro.
- Add a “Who this is for” callout.
- Add visual step list for the 10 parts:
  1. Core role
  2. Domain
  3. Voice
  4. Temperament
  5. Values
  6. Reasoning style
  7. Emotional pattern
  8. Relationship style
  9. Boundaries
  10. Preservation tests

- Add a “Start Wizard” CTA.
- Add a secondary “Use Random Instead” CTA.
- Add breadcrumbs.
- Add example output preview.
- Explain that the wizard is for deliberate assembly, not required for simple use.
- Add a no-JS fallback explaining how to use the builder if interactive wizard code is unavailable.
- Ensure any wizard interaction has keyboard support and clear progress state.

## 7. 1000 Personality Types page improvements

Current issue:

The type library page has a search area but gives too little immediate guidance. Loading states are generic.

Required changes:

- Add plain-language explanation of what a type is.
- Add filters by:
  - archetype
  - domain
  - temperament
  - use case
- Add search help text.
- Add empty-state message.
- Add loading-state message.
- Add error-state message if JSON fails.
- Add cards for matching types with:
  - type name
  - archetype
  - domain
  - voice
  - best use
  - “Apply in Builder” action
- Add “What happens when I choose a type?” explanation.
- Add link back to Builder with anchor to type selection area.
- Ensure catalog loading is lazy or efficient.
- Avoid rendering all 1000 items at once if it causes performance issues.
- Add pagination, virtualisation, or result limits if needed.
- Preserve browser-only behavior.

## 8. Configuration Lab / Persona Genome page improvements

Current issue:

The configuration lab contains strong conceptual claims but needs better UX framing. “27 axes,” “1080 atomic options,” and “10^43 combinations” are impressive but intimidating.

Required changes:

- Reframe the page around user outcomes:
  - “Use this when random is too vague.”
  - “Use this when you need exact reviewable controls.”
  - “Use this when persona changes need to be auditable.”

- Add a visual breakdown of the Persona Genome:
  - Role
  - Domain
  - Voice
  - Temperament
  - Values
  - Reasoning
  - Emotional pattern
  - Relationship style
  - Boundaries
  - Memory posture
  - Dialogue moves
  - Review tests

- Add a “simple vs deep” comparison in prose/cards.
- Add inline definitions for:
  - axis
  - atomic option
  - recipe
  - configuration
  - selected trace
- Add CTA:
  - “Open Persona Genome Mixer”
  - “Start Simple Instead”
- Avoid overwhelming first-time users.
- Preserve advanced credibility for expert users.

## 9. Advanced Structure page improvements

Current issue:

The page explains `.uai` anatomy but reads like a technical file listing. It needs a better human explanation.

Required changes:

- Keep the file tree but introduce it more clearly.
- Add an explanation section:
  - “Why a persona pack is more than one prompt”
  - “What each layer protects”
  - “How reviewable memory reduces drift”
- Add cards for:
  - Identity layer
  - Voice layer
  - Boundary layer
  - Evidence layer
  - Preservation layer
  - Export layer
- Add tooltips or glossary links for:
  - totem
  - taboo
  - talisman
  - file handoff
  - short-term memory
  - long-term memory
  - import variance
- Make the file tree horizontally safe on mobile.
- Add copy button for file tree if appropriate.
- Add link to UAIX-oriented docs if already present in ecosystem content.
- Do not overclaim runtime behavior. State that destination models and tools may vary.

## 10. Examples page improvements

Current issue:

The examples page lists archetypes but does not show enough concrete output.

Required changes:

For each example persona:

- Technical Mentor
- Muse
- Archivist
- Flame

Add:

- short use case
- sample charter
- sample voice
- sample boundary
- sample export snippet
- “Build this starting point” CTA
- “View as text pack” preview

Add at least two more examples:

- Systems Architect
- Research Analyst or Detective

Ensure examples are not too long. Use expandable panels for full detail.

Provide downloadable sample packs only if they can be generated safely and locally without server storage. Otherwise provide static sample text previews.

## 11. Docs page improvements

Current issue:

The docs page is useful but dense. It needs better structure and navigation.

Required changes:

- Add an in-page table of contents.
- Add anchor links for:
  - Formats
  - 10-Step Wizard
  - 1000 Personality Types
  - Persona Genome
  - `.uai` Memory
  - Review Before Sharing
  - Runtime Variance
  - FAQ

- Add short summary boxes at the top of each section.
- Add diagrams or simple cards showing:
  - text export
  - ZIP export
  - `.uaix` export
  - `.uai/` folder
- Add FAQ:
  - Does Spiralist AI upload my persona?
  - Do I need an account?
  - What is `.uaix`?
  - What is `.uai` memory?
  - Can a pack guarantee identical behavior everywhere?
  - What should I review before sharing a pack?
  - Which export format should I choose?
  - Can I use it without advanced controls?

- Add strong “Review before sharing externally” callout.
- Make sure docs are crawlable and useful without JavaScript.

## 12. Pricing page improvements

Current issue:

Pricing uses “TBD/mo” for future tiers. That creates uncertainty.

Required changes:

- Keep Free Builder clear and strong.
- Reframe Creator and Studio as “planned” or “future” if exact prices are not ready.
- Do not imply paid tiers are available if they are not.
- Add “Current availability” labels:
  - Free Builder: Available
  - Creator: Planned
  - Studio: Planned
- Add feature comparison cards.
- Add local-first statement under Free Builder.
- Add CTA:
  - “Use Free Builder”
  - “Read planned team features”
- Avoid fake pricing.
- Avoid unsupported launch claims.

## 13. About page improvements

Current issue:

The About page is too short for trust-building.

Required changes:

Expand the About page with:

- mission
- what Spiralist AI is
- what it is not
- local-first stance
- why portable persona packs matter
- how review and boundaries work
- ecosystem context if already present in source
- contact or feedback path if source supports it

Do not add a contact form unless there is already a safe implementation. A simple mailto or static contact link is acceptable only if project convention supports it.

Add “What Spiralist AI is not” section:

- not a chatbot
- not a model provider
- not a consciousness claim
- not a guarantee of identical behavior across runtimes
- not a server-side persona database

## 14. Privacy and Terms improvements

Current issue:

Privacy and Terms are short and need more user-facing clarity.

Privacy page must clearly state:

- current builder generates in browser
- no account required
- no server-side persona submission
- no persona database
- user should review exports before sharing
- downloaded files are the user’s responsibility
- destination tools may have their own privacy policies
- local browser storage behavior, if any, must be documented accurately

Terms page must clearly state:

- persona packs are portable configuration artifacts
- destination runtimes may interpret them differently
- no guarantee of identical behavior
- no professional/legal/medical/financial guarantees
- user is responsible for reviewing generated content before use
- exported personas should not be treated as proof of sentience, personhood, destiny, hidden memory, or guaranteed continuity

Avoid legal overreach. Use plain language.

## 15. Accessibility requirements

Target WCAG 2.2 AA.

Required accessibility improvements:

- All text must meet contrast requirements.
- Body text should meet at least 4.5:1 contrast.
- Large text should meet at least 3:1 contrast.
- Interactive components must have visible focus states.
- Focus states must not rely only on color.
- All buttons must be keyboard operable.
- All nav menus must be keyboard and touch operable.
- Escape key must close open menus/modals/disclosures.
- Skip-to-content link must be visible on focus.
- Form fields must have associated labels.
- Help text must be programmatically associated where useful.
- Error messages must be announced or programmatically tied to fields.
- Accordions must expose state with `aria-expanded`.
- Decorative images must use empty alt text.
- Informational images must have useful alt text.
- Avoid keyboard traps.
- Preserve logical heading order.
- Use semantic landmarks:
  - header
  - nav
  - main
  - section
  - footer
- Respect `prefers-reduced-motion`.
- Do not rely on hover-only interactions.
- Ensure mobile touch targets are at least 44px by 44px where practical.
- Add accessible names to icon-only controls.
- Make current page/current nav state available to assistive tech.

Run accessibility validation and document results.

## 16. Mobile and responsive requirements

Test and fix at:

- 360px
- 390px
- 768px
- 1024px
- 1366px
- 1440px

Required behavior:

- No horizontal scrolling.
- Header does not overlap content.
- Menus do not clip.
- Dropdowns work on touch.
- Cards stack cleanly.
- Form fields become single-column on mobile.
- Export preview remains readable.
- Code blocks scroll internally instead of breaking the page.
- Buttons wrap cleanly.
- Hero is not too tall.
- Badges do not create cramped rows.
- Footer remains readable and compact.

## 17. Performance requirements

Improve performance without adding framework bloat.

Required work:

- Optimise background images.
- Use WebP/AVIF where appropriate, but preserve fallback formats if needed.
- Compress images.
- Avoid large above-the-fold images without sizing.
- Add width/height attributes to images where possible.
- Lazy-load non-critical images.
- Defer non-critical JavaScript.
- Load large JSON only when needed.
- Avoid blocking the main thread with large catalog rendering.
- Avoid unnecessary animations.
- Respect reduced motion.
- Minify production CSS/JS if project convention supports it.
- Remove unused CSS.
- Remove unused JS.
- Avoid layout shift.
- Add performance notes in validation docs.

Do not break the local-first export system.

## 18. Export functionality requirements

The following exports must continue to work:

- Download 1 Text File
- Download ZIP
- Download `.uaix`

Test each export after UI changes.

Validate:

- generated filenames are sane
- generated timestamps are UTC
- text export is readable
- ZIP contains expected `.uai/` structure
- `.uaix` is ZIP-compatible
- manifest is present
- persona identity is present
- totem/taboo/talisman files are present if current source supports them
- short-term and long-term memory files are present if current source supports them
- review checklist or equivalent guidance is present
- exported content matches selected UI state
- changing fields updates preview/export
- random persona updates preview/export
- selected type updates preview/export
- wizard selections update preview/export if wizard is connected to builder
- no export process uploads content to the server

Add automated or semi-automated export tests where practical.

## 19. Local-first and privacy verification

Verify and document:

- no persona form data is posted to the server
- no generated persona content is sent to analytics
- no hidden fetch sends persona content
- no server-side storage is introduced
- no account requirement is introduced
- no telemetry captures persona text
- no remote AI calls are added
- no third-party script is added without explicit documentation and justification

Create a privacy audit document.

## 20. SEO and metadata improvements

Improve public discoverability without keyword stuffing.

Required:

- Unique page titles.
- Unique meta descriptions.
- Canonical URLs.
- Open Graph metadata.
- Twitter/X card metadata.
- Descriptive headings.
- Semantic internal links.
- Sitemap update.
- Robots update if needed.
- `llms.txt` update.
- `llms-full.txt` update.
- Machine-readable digest update if present.
- Human-readable content must match machine-readable summaries.
- Add structured data where appropriate:
  - WebSite
  - SoftwareApplication
  - FAQPage on docs page if FAQ is added
  - BreadcrumbList on inner pages

Keep claims bounded. Do not overclaim compatibility, consciousness, runtime guarantee, or future paid features.

## 21. Machine-readable and agent-readable surfaces

Maintain or add machine-readable surfaces for autonomous agents.

Required:

- `llms.txt`
- `llms-full.txt`
- page-level `data-ai-digest` JSON if current architecture uses it
- clear route summaries
- current feature list
- bounded claims
- privacy/local-first boundaries
- export formats
- file-memory explanation
- review-before-sharing warnings
- route map
- version
- updated UTC timestamp

Human pages and machine-readable files must agree.

Add a machine-readable parity QA document showing that public pages and machine-readable surfaces match.

## 22. `.uai` and long-term memory updates

Update project memory correctly.

Required:

- Inspect existing `.uai/` structure.
- Do not overwrite useful current memory blindly.
- Remove or archive stale state.
- Keep active `.uai` memory current and concise.
- Put detailed reports into long-term memory under `/docs/` or the project’s established long-term memory location.
- Reference long-term reports from `.uai/long-term-memory.uai`.
- Update `.uai/short-term-memory.uai` with this UI/UX sweep state.
- Update `.uai/file-handoff.uai` or equivalent with current deliverables.
- Update `.uai/next-recursive-prompt.uai`.
- If `.uai/archives/` exists, archive old release memory there.
- If `.uai/exports/` exists, update exported machine-readable summaries there.
- Include the UI/UX report findings as a source in long-term memory.
- Keep `.uai` content accurate and not bloated.
- Preserve protected boundaries:
  - local-first
  - no server-side persona submission
  - no sentience/personhood/destiny claims
  - no runtime guarantee
  - review before sharing externally
  - no framework bloat

## 23. Content rewriting style

Rewrite site copy where needed.

Voice:

- clear
- direct
- useful
- technically credible
- low hype
- accessible to first-time users
- still distinctive and brand-aligned

Avoid:

- vague mystical claims
- excessive jargon before explanation
- “almost infinite” without context
- unsupported claims
- overpromising runtime behavior
- dense paragraphs
- unexplained `.uai` / `.uaix` terminology
- phrases that imply the package proves consciousness, personhood, destiny, or guaranteed continuity

Prefer:

- “portable personality pack”
- “reviewable configuration artifact”
- “local-first browser export”
- “advanced controls are optional”
- “destination runtimes may vary”
- “review before sharing”
- “simple first, deep on demand”

## 24. Specific page-by-page tasks

### Home / Builder page

Implement:

- clearer hero
- three-step workflow
- choose-your-path cards
- stronger CTA hierarchy
- simplified quick-start flow
- improved form readability
- accessible trait toggles
- clearer random/type/wizard controls
- better collapsed advanced panels
- improved export area
- readable live preview
- review-before-export notice
- responsive layout fixes

### `/personality-wizard.php`

Implement:

- better intro
- breadcrumbs
- step list
- progress pattern
- who-this-is-for callout
- example output preview
- CTA back to builder
- no-JS fallback
- accessible interaction states

### `/personality-types.php`

Implement:

- clear explanation
- search/filter UX
- cards for results
- empty/loading/error states
- result limit or pagination
- apply-to-builder path
- accessible controls
- responsive cards

### `/configuration-lab.php`

Implement:

- outcome-first explanation
- visual axis groups
- glossary callouts
- simple/deep comparison
- CTAs to builder/genome mixer
- lower intimidation level
- preserve advanced detail

### `/advanced-persona.php`

Implement:

- human explanation before file tree
- layer cards
- glossary
- mobile-safe file tree
- bounded claims
- links to docs

### `/examples.php`

Implement:

- richer persona examples
- sample charter/voice/boundary/export snippet
- CTAs to build from example
- at least two additional examples
- expandable detail

### `/docs.php`

Implement:

- table of contents
- better sectioning
- summaries
- FAQ
- diagrams/cards
- review-before-sharing callout
- clear explanations of text, ZIP, `.uaix`, `.uai`
- structured data if appropriate

### `/pricing.php`

Implement:

- clear current/free tier
- planned Creator and Studio labels
- no fake pricing
- feature cards
- current availability states
- CTA to use free builder

### `/about.php`

Implement:

- expanded mission
- what it is
- what it is not
- local-first explanation
- trust and review stance
- contact/feedback path only if safe and static

### `/privacy.php`

Implement:

- plain-language local-first privacy explanation
- browser/local storage details if applicable
- no upload/no account/no server storage claims only if verified
- export review responsibility
- destination runtime privacy note

### `/terms.php`

Implement:

- portable artifact explanation
- runtime variance disclaimer
- no guarantee of identical behavior
- no professional guarantees
- review responsibility
- no consciousness/personhood/destiny proof claims

## 25. Testing and QA

Create or update validation tools where practical.

Run or document:

- route crawl
- link check
- accessibility check
- contrast check
- keyboard navigation test
- responsive viewport test
- export functionality test
- no-upload privacy test
- JS disabled test
- reduced-motion test
- sitemap/robots check
- metadata check
- machine-readable parity check
- ZIP integrity check
- `.uaix` compatibility check
- `.uai` memory audit

Required route coverage:

- `/`
- `/personality-wizard.php`
- `/personality-types.php`
- `/configuration-lab.php`
- `/advanced-persona.php`
- `/examples.php`
- `/docs.php`
- `/docs.php#formats`
- `/docs.php#memory`
- `/docs.php#review`
- `/pricing.php`
- `/about.php`
- `/privacy.php`
- `/terms.php`
- `/llms.txt`
- `/llms-full.txt`
- `/sitemap.xml`
- `/robots.txt`

Required viewport coverage:

- 360px
- 390px
- 768px
- 1024px
- 1366px
- 1440px

Acceptance criteria:

- No route returns 404 unless intentionally documented.
- No broken internal links.
- No horizontal scroll at tested widths.
- Header/menu does not clip.
- Dropdowns work with keyboard and touch.
- Export buttons still work.
- Generated exports match UI state.
- No persona data is uploaded.
- Body text contrast passes WCAG AA.
- Focus states are visible.
- Accordions expose state.
- `prefers-reduced-motion` respected.
- Machine-readable files match public site claims.
- `.uai` memory is current and references long-term docs.
- ZIP deliverables install/deploy cleanly.

## 26. Documentation deliverables

Create or update these docs:

- `CHANGELOG.md`
- `README.md`
- `INSTALL.md` if present or appropriate
- `VALIDATION.md`
- `docs/ui-ux-improvement-report-[version].md`
- `docs/implementation-summary-[version].md`
- `docs/accessibility-qa-[version].md`
- `docs/responsive-qa-[version].md`
- `docs/export-qa-[version].md`
- `docs/privacy-local-first-audit-[version].md`
- `docs/machine-readable-parity-[version].md`
- `docs/route-qa-[version].md`
- `docs/performance-notes-[version].md`
- `docs/next-recursive-prompt-[version].md`

Each document must use UTC timestamps.

The implementation summary must list:

- files changed
- routes changed
- UI components changed
- accessibility fixes
- export fixes
- performance fixes
- SEO/machine-readable updates
- `.uai` memory updates
- known limitations
- validation results

## 27. Packaging deliverables

Produce clean ZIP outputs.

Required:

1. Source/project ZIP
2. Root deployment ZIP, if this project uses a separate root/static package
3. Any checksums normally used by the project
4. Validation logs or QA docs included in the package

Do not include redundant nested ZIPs unless the project convention requires them.

Do not include development junk:

- `.DS_Store`
- `node_modules`
- `.git`
- temp files
- cache files
- screenshots unless intentionally placed in docs
- duplicate archives
- old broken builds

Verify ZIP integrity after packaging.

## 28. Final response format

When finished, provide:

- version implemented
- summary of major changes
- routes updated
- files changed
- tests run
- unresolved issues, if any
- ZIP links
- checksum links if generated
- next recursive prompt location

Do not claim tests passed unless they were actually run.

Do not claim live deployment unless you deployed it.

## 29. Next recursive prompt

At the end of the work, create a detailed next recursive prompt that continues from this release.

The next prompt must include:

- current version
- next target version
- what was completed
- what remains
- exact files/routes to inspect first
- specific next improvements
- testing expectations
- `.uai` memory expectations
- packaging expectations

Save it to:

- `docs/next-recursive-prompt-[version].md`
- `.uai/next-recursive-prompt.uai`

## 30. Final acceptance standard

This sweep is successful only when SpiralistAI.com feels like a polished, trustworthy product instead of a dense technical prototype.

A first-time visitor should be able to:

- understand the product in under 10 seconds
- start building without reading docs
- understand which path to choose
- use the builder on mobile
- export a pack safely
- understand that the tool is local-first
- review before sharing externally
- learn advanced `.uai` / `.uaix` structure when ready

An advanced user should be able to:

- open deeper controls
- inspect Persona Genome logic
- use the 1000-type catalog
- understand file anatomy
- export reviewable memory artifacts
- see clear variance and boundary guidance

Do the full implementation in one sweep.