cfsa-antigravity 3.0.2 → 3.1.0

package/template/.codex/skills/prd-templates/references/design-system-decisions.md

@@ -0,0 +1,198 @@
+# Design System Decision Options & Output Template
+
+Reference material for the `/create-prd-design-system` workflow. Contains option menus for all seven decisions and the canonical output template for `.memory/wiki/specs/design-system.md`.
+
+---
+
+## Navigation Paradigm Options
+
+### Web surfaces
+
+- **Sidebar + topnav** — Collapsible sidebar for section nav, top bar for global actions. Good for complex apps with deep IA; competes with content width on small screens.
+- **Tab bar (app-style)** — Horizontal tab bar, web app feels like a native app. Limited to 5–7 top-level destinations; unfamiliar on traditional websites.
+- **Full-page transitions** — Each section is a full-page view with navigation between pages. Poor for frequent cross-section navigation; high cognitive load for data-heavy apps.
+- **Command palette primary** — Keyboard-first navigation with minimal visible chrome. High power-user efficiency; steep learning curve, requires discoverability affordances.
+- **Minimal/none** — No persistent navigation; content-first with contextual links. Clean and focused; users may feel lost without orientation cues.
+
+### Mobile surfaces
+
+- **Bottom tab bar** — iOS/Android standard, 3–5 tabs at screen bottom. Limited to 5 top-level destinations; thumb-friendly.
+- **Drawer + top header** — Slide-out drawer with a persistent top header bar. Supports many sections; discoverability issues — out of sight, out of mind.
+- **Stack navigation only** — Linear forward/back navigation with no persistent tabs. No quick access to unrelated sections; relies on back button.
+- **Tab bar + stack hybrid** — Bottom tabs for top-level sections, stack navigation within each tab. Combines discoverability with depth; tab count still limited.
+
+### Desktop (native) surfaces
+
+- **Menu bar + sidebar** — OS-native menu bar with sidebar panel. Platform-specific conventions differ (macOS vs Windows vs Linux).
+- **Ribbon (Office-style)** — Grouped toolbar with tabbed ribbon. Heavy initial learning curve; takes vertical space.
+- **Panel system** — Draggable/dockable panels with customizable layout. Window management complexity; steep learning curve.
+- **Sidebar only** — Vertical sidebar as sole navigation element. No menu bar discoverability for infrequent actions.
+
+---
+
+## Page Archetype Options
+
+| Archetype | Description | Typical Layout Zones |
+|-----------|-------------|---------------------|
+| **Dashboard** | Data overview with cards/charts | Nav zone · Summary strip · Grid/card zone · Detail panel |
+| **List → Detail** | Browse items, select to view/edit | Nav zone · Filter bar · List zone · Detail zone |
+| **Form** | Multi-step or single-page data entry | Nav zone · Form zone · Action bar |
+| **Content/Article** | Long-form reading with optional sidebar | Nav zone · Content zone · Sidebar/TOC zone |
+| **Settings** | Tabbed or sectioned preference panels | Nav zone · Section nav · Settings zone |
+| **Empty/Onboarding** | First-run or zero-data state | Nav zone · Illustration zone · CTA zone |
+| **Auth** | Login/signup/password-reset | Centered card zone · Background zone |
+| **Error** | 404/500/offline states | Nav zone · Error illustration zone · Recovery CTA |
+
+### Example wireframe (Dashboard archetype)
+
+```
+┌─────────────────────────────────────┐
+│              Nav Zone               │
+├────────┬────────────────────────────┤
+│        │       Summary Strip        │
+│  Side  ├────────────────────────────┤
+│  bar   │                            │
+│  Zone  │       Content Zone         │
+│        │                            │
+├────────┴────────────────────────────┤
+│            Action Bar               │
+└─────────────────────────────────────┘
+```
+
+---
+
+## Global Component Categories
+
+- **Navigation components** — derived from the navigation paradigm (e.g., TopNav, Sidebar, BottomTabBar, Breadcrumb)
+- **Layout components** — derived from archetypes (e.g., PageShell, ContentArea, Sidebar, ActionBar)
+- **Feedback components** — Loading skeleton, Toast, ErrorBoundary, EmptyState
+- **Form primitives** — Input, Select, Checkbox, Radio, TextArea, DatePicker, FileUpload
+- **Data display** — Table, Card, Badge, Avatar, Stat, Chart container
+- **Overlay components** — Modal, Drawer, Popover, Tooltip, ContextMenu
+- **Action components** — Button, IconButton, Link, Dropdown menu
+
+---
+
+## Motion Language Options
+
+| Level | Description | Typical Durations | Use When |
+|-------|-------------|-------------------|----------|
+| **Instant** | No transitions — all state changes are immediate | 0ms | Performance-critical tools, terminal UIs, accessibility-first products |
+| **Subtle** | Micro-transitions only — fades and opacity shifts | 100–150ms ease-out | Productivity tools, data-dense dashboards, professional/enterprise apps |
+| **Balanced** | Purposeful transitions for navigation and state changes | 150–300ms ease-in-out | Most consumer apps, SaaS products, general-purpose UIs |
+| **Rich** | Expressive animations — page transitions, element choreography, spring physics | 200–500ms spring/cubic-bezier | Marketing sites, creative tools, consumer apps where delight matters |
+
+> **Mandatory regardless of level**: All motion must respect `prefers-reduced-motion: reduce`. When reduced motion is active, all animations collapse to instant (0ms) or opacity-only transitions (≤100ms).
+
+---
+
+## Data Density Options
+
+| Philosophy | Description | Best For | Characteristics |
+|------------|-------------|----------|-----------------|
+| **Compact** | Maximum information per viewport — tight spacing, smaller text, dense tables | Data-heavy dashboards, admin panels, developer tools | 12–14px body text, 4–8px element spacing, minimal whitespace |
+| **Spacious** | Generous whitespace, larger text, breathing room between elements | Consumer apps, marketing, content-focused products | 16–18px body text, 16–24px element spacing, generous padding |
+| **Hybrid** | Context-dependent — compact for data tables/lists, spacious for forms/content | Apps mixing data overview with detail editing | Defined rules for when each density applies |
+
+If **Hybrid** is selected, ask the user to define the density rules:
+- Which archetypes get compact density?
+- Which archetypes get spacious density?
+- What is the transition behavior between densities?
+
+---
+
+## Global State Design Language Options
+
+### Loading states
+
+| Option | Description | Best For |
+|--------|-------------|----------|
+| **Skeleton screens** | Grey placeholder shapes matching the expected layout | Content-heavy pages where layout stability matters |
+| **Spinner/shimmer** | Centered spinner or shimmer overlay | Simple actions, modals, inline operations |
+| **Progressive** | Skeleton for page-level, spinner for component-level operations | Complex apps with mixed loading contexts |
+
+### Error states
+
+- **Inline** — Error message appears near the failed element (forms, field validation)
+- **Toast** — Transient notification for non-blocking errors (network retry, background sync)
+- **Full-page** — Dedicated error page (404, 500, offline)
+- **Error boundary** — Component-level fallback UI (prevents cascade, isolates failure)
+
+### Empty states
+
+- **Illustration + copy** — Custom illustration with descriptive text and CTA
+- **Minimal** — Text-only with action link
+- **Contextual** — Different empty states per archetype (empty dashboard vs. empty list)
+
+**Copy tone**: Helpful / Playful / Neutral — must align with the confirmed design direction.
+
+---
+
+## design-system.md Output Template
+
+The final `.memory/wiki/specs/design-system.md` must have this exact structure:
+
+```markdown
+# Design System
+
+> **Confirmed Design Direction**: [confirmed direction from brand-guidelines]
+> **Date**: [YYYY-MM-DD]
+> **Status**: Locked
+
+## Navigation Paradigm
+[Confirmed paradigm with rationale]
+[Surface-specific notes if multi-surface project]
+
+## Layout Grid
+
+| Breakpoint | Columns | Gutter | Max Width |
+|------------|---------|--------|-----------|
+| Mobile (≤768px) | [confirmed] | [confirmed] | [confirmed] |
+| Tablet (769–1024px) | [confirmed] | [confirmed] | [confirmed] |
+| Desktop (≥1025px) | [confirmed] | [confirmed] | [confirmed] |
+
+**Grid type**: [confirmed]
+
+## Page Archetypes
+
+### [Archetype Name]
+**Layout zones**: [nav] | [content] | [sidebar] | [action]
+[Optional: ASCII wireframe for additional clarity]
+
+[repeat for each confirmed archetype]
+
+## Global Component Inventory
+- `<ComponentName>` — [what it does / what it renders]
+- `<ComponentName>` — [what it does / what it renders]
+[repeat for each confirmed global component]
+
+## Motion Language
+**Style**: [confirmed style — Instant / Subtle / Balanced / Rich]
+**Default duration**: [confirmed duration range]
+**Default easing**: [confirmed easing function]
+**Interaction transitions**: [confirmed interaction transition behavior]
+**Reduced-motion policy**: All animations disabled when `prefers-reduced-motion: reduce` is active.
+
+## Data Density Philosophy
+**Default density**: [confirmed density — Compact / Spacious / Hybrid]
+**Rules**: [when each density applies — per archetype if hybrid]
+
+## Global State Design Language
+
+### Loading States
+- **Skeleton screens**: use when [confirmed rule]
+- **Spinner/shimmer**: use when [confirmed rule]
+- **Progressive**: use when [confirmed rule]
+
+### Error States
+- **Inline errors**: use when [confirmed rule — e.g., form field validation]
+- **Toast errors**: use when [confirmed rule — e.g., non-blocking network errors]
+- **Full-page errors**: use when [confirmed rule — e.g., 404, 500, offline]
+- **Error boundaries**: use when [confirmed rule — e.g., component-level isolation]
+
+### Empty States
+**Illustration style**: [confirmed style]
+**Copy tone**: [confirmed tone — must align with confirmed design direction]
+**CTA**: Every empty state MUST include a primary call-to-action that guides the user toward populating the view.
+[Per-archetype empty state rules if contextual]
+```

package/template/.codex/skills/prd-templates/references/design-system-prerequisite-check.md

@@ -0,0 +1,18 @@
+# Design System Prerequisite Check
+
+Run this check before writing any FE spec.
+
+## Procedure
+
+1. Check whether `.memory/wiki/specs/design-system.md` exists.
+2. If it does not exist → **stop** and tell the user: _"The design system has not been established yet. Run `/create-prd-design-system` to lock navigation paradigm, layout grid, page archetypes, and global state design language before writing FE specs."_
+3. If it exists → read and extract all seven decision areas: Navigation Paradigm, Layout Grid, Page Archetypes, Global Component Inventory, Motion Language, Data Density Philosophy, and Global State Design Language.
+4. The extracted decisions are **requirements** for this FE spec — any violation is a rubric failure under Dimension 11 (Design System Consistency).
+
+## Fail-Fast Validation Checks
+
+Verify the following before proceeding. If any check fails, classification must **stop** and instruct the user to run `/create-prd-design-system` to resolve drift before continuing:
+
+- **Page archetype match**: At least one page archetype from `design-system.md` applies to the feature being classified. If no archetype matches, the design system is incomplete for this feature.
+- **Global component / navigation compliance**: The navigation paradigm and Global Component Inventory sections are populated (not empty or placeholder). Every navigation element the FE spec will use must exist in the inventory — re-inventing global components is a rubric failure.
+- **Global state design language compliance**: The Loading States, Error States, and Empty States sub-sections are populated with confirmed approaches. The FE spec must use these confirmed patterns — inventing loading/error/empty state patterns outside the design language is a rubric failure.

package/template/.codex/skills/prd-templates/references/domain-exhaustion-criteria.md

@@ -0,0 +1,37 @@
+# Domain Exhaustion Criteria
+
+Final validation gate before vision compilation. All criteria must pass.
+
+| Check | Criteria | Action if Fail |
+|-------|----------|----------------|
+| All leaf nodes ≥ `[DEEP]` | Every feature file in the tree is `[DEEP]` or `[EXHAUSTED]` | Drill remaining feature files |
+| Status propagation correct | Parent nodes reflect their children's status | Update parent indexes |
+| All Must Have features ≥ Level 2 | Every Must Have has sub-features AND edge cases AND Role Lens | Deep Think + drill |
+| Deep Think zero hypotheses | Final Deep Think pass across ALL leaf nodes yields no new hypotheses | Present any new hypotheses, drill if confirmed |
+| All CX files clean | No Medium/Low confidence entries remain at any level — all are High or rejected | Run synthesis questions on pending pairs |
+| Role Lens complete | Every feature file has a populated Role Lens table | Fill missing Role Lens entries |
+| User confirmation | User explicitly confirms "nothing else" for each domain | Ask for each under-explored domain |
+
+## Execution Procedure
+
+1. Walk the fractal tree. For each leaf node below `[DEEP]`:
+   - "Feature [X] in [domain] is still at [status]. Drill deeper or intentionally minimal?"
+   - If "drill" → return to `/ideate-discover`
+   - If "intentionally minimal" → note in feature file and proceed
+
+2. Run **final Deep Think pass**: For each `[DEEP]` leaf node, apply the four Deep Think questions. Present any new hypotheses.
+   - If confirmed → drill, update feature files
+   - If zero hypotheses → mark `[EXHAUSTED]`, propagate status upward
+
+3. Walk ALL CX files at every level. Resolve any Medium/Low confidence entries.
+
+4. Verify all feature files have populated Role Lens tables.
+
+5. Update `ideation-index.md` progress summary with final counts (total leaf nodes, exhausted count, CX entries confirmed).
+
+## Proportionality Check
+
+- **Rich inputs**: Total domain file content (all files combined) should be at least 30% of the original source document's line count. If short, identify what was lost.
+- **All inputs**: Each domain with `[DEEP]` or `[EXHAUSTED]` status should have at least 3 sub-areas drilled with edge cases.
+
+If proportionality fails, return to `/ideate-discover` for the under-explored areas.

package/template/.codex/skills/prd-templates/references/engagement-tier-protocol.md

@@ -0,0 +1,58 @@
+# Engagement Tier Protocol
+
+**Purpose**: Single source of truth for engagement tier definitions and behavior. Workflows reference this instead of inlining tier blocks.
+
+---
+
+## Tier Definitions
+
+| Tier | When | User Experience |
+|------|------|-----------------|
+| **Auto** | 6+ well-constrained axes, experienced user, clear preferences | Agent uses Deep Think reasoning per axis, presents all decisions for batch review at shard end |
+| **Hybrid** | 3-5 axes, some need discussion, some are obvious | Group related decisions, present key choices, auto-confirm obvious ones |
+| **Interactive** | ≤2 axes, novel/uncertain domain, user requests it | Full interview — one decision at a time with options and trade-offs |
+
+## Tier Selection
+
+Read the user's context:
+1. Count the number of decision axes in the current step
+2. Assess user's familiarity (prior conversations, explicit preferences, technical depth)
+3. Default to **Interactive** if uncertain
+
+Present the proposed tier: "I'll approach this as [tier] — [brief rationale]. Want a different level of involvement?"
+
+**HARD GATE**: Wait for user acknowledgment before proceeding. If the user requests a different tier, switch.
+
+## Behavior by Tier
+
+### Auto Tier
+1. For each decision: apply Deep Think reasoning (consider constraints, project goals, prior decisions)
+2. Write the decision with `[AUTO-CONFIRMED — reasoning: ...]` annotation
+3. At shard end: present ALL auto-confirmed decisions in a summary table
+4. User reviews batch — any rejection triggers Interactive re-presentation for that decision
+5. Remove `[AUTO-CONFIRMED]` annotations after batch approval
+
+### Hybrid Tier
+1. Group related decisions (e.g., all auth decisions together)
+2. For obvious decisions: present with recommendation, apply if user says "looks good"
+3. For debatable decisions: present options with trade-offs, wait for selection
+4. Follow the decision-confirmation-protocol for each group
+
+### Interactive Tier
+1. Present one decision at a time
+2. Include 2-3 options with trade-offs and your recommendation
+3. Wait for explicit selection
+4. Follow the decision-confirmation-protocol for each decision
+
+## Gate Classification
+
+Not all decisions follow the engagement tier. Some are always user-facing regardless of tier:
+
+| Gate Type | Always Interactive? | Examples |
+|-----------|-------------------|----------|
+| **Product** | Yes — user always decides | Feature scope, UX philosophy, pricing |
+| **Architecture** | Yes — present options | Database choice, framework, hosting |
+| **Structural** | No — tier-aware | File naming, directory organization |
+| **Implementation** | No — agent decides | Import ordering, variable naming |
+
+See `.codex/rules/decision-classification.md` for the full classification.

package/template/.codex/skills/prd-templates/references/engineering-standards-template.md

@@ -0,0 +1,126 @@
+# Engineering Standards Template
+
+Use this template when creating `.memory/wiki/specs/ENGINEERING-STANDARDS.md`. Fill in concrete values based on tech stack decisions — **no TBDs allowed**.
+
+```markdown
+# [Project Name] — Engineering Standards
+
+> **Architecture**: [link to architecture-design.md]
+> **Date**: YYYY-MM-DD
+> **Status**: Draft | Review | Approved
+
+## Test Coverage
+- Minimum unit test coverage: [e.g., 80%]
+- Integration test requirement: [e.g., every API endpoint]
+- E2E test requirement: [e.g., every critical user flow]
+- Coverage tool: [e.g., vitest coverage-v8]
+
+## Linting & Formatting
+- Linter: [e.g., ESLint with strict config]
+- Formatter: [e.g., Prettier]
+- Type checker: [e.g., TypeScript strict mode]
+- Pre-commit hooks: [yes/no, tool]
+
+## Performance Budgets
+
+> **Baseline**: Budgets target [device tier] on [network condition]. Every threshold must have a named enforcement tool — a threshold without an enforcement tool is incomplete.
+
+### Web Vitals per page type (web/desktop surfaces only)
+
+| Page Type | LCP target | INP target | CLS target | Enforcement Tool |
+|-----------|-----------|-----------|-----------|-----------------|
+| [e.g., Landing] | [e.g., ≤ 2.0 s] | [e.g., ≤ 150 ms] | [e.g., ≤ 0.05] | [e.g., Lighthouse CI] |
+| [e.g., Dashboard] | [e.g., ≤ 2.5 s] | [e.g., ≤ 200 ms] | [e.g., ≤ 0.1] | [e.g., Lighthouse CI] |
+| [e.g., Detail/Form] | [e.g., ≤ 2.0 s] | [e.g., ≤ 100 ms] | [e.g., ≤ 0.05] | [e.g., Lighthouse CI] |
+
+### JS Bundle Size per page type (web/desktop surfaces only)
+
+| Page Type | Initial JS (gzipped) | Total JS (gzipped) | Enforcement Tool |
+|-----------|---------------------|-------------------|-----------------|
+| [e.g., Landing] | [e.g., ≤ 80 KB] | [e.g., ≤ 150 KB] | [e.g., size-limit] |
+| [e.g., Dashboard] | [e.g., ≤ 150 KB] | [e.g., ≤ 300 KB] | [e.g., size-limit] |
+
+### API Response Time per tier
+
+| Tier | Description | p50 | p95 | p99 | Enforcement Tool |
+|------|------------|-----|-----|-----|-----------------|
+| Tier 1 — Cached read | [e.g., Response from cache] | [e.g., ≤ 10 ms] | [e.g., ≤ 30 ms] | [e.g., ≤ 50 ms] | [e.g., k6] |
+| Tier 2 — Uncached read | [e.g., Single-entity DB fetch] | [e.g., ≤ 30 ms] | [e.g., ≤ 80 ms] | [e.g., ≤ 150 ms] | [e.g., k6] |
+| Tier 3 — Write | [e.g., Create, update, delete] | [e.g., ≤ 80 ms] | [e.g., ≤ 200 ms] | [e.g., ≤ 400 ms] | [e.g., k6] |
+| Tier 4 — Background | [e.g., Async jobs, external calls] | [Best-effort] | [e.g., ≤ 1000 ms] | [e.g., ≤ 3000 ms] | [e.g., k6] |
+
+### DB Query Time per tier
+
+| Tier | Description | p50 | p95 | Enforcement Tool |
+|------|------------|-----|-----|-----------------|
+| Tier 1 — Indexed point lookup | [e.g., PK or unique-index fetch] | [e.g., ≤ 5 ms] | [e.g., ≤ 15 ms] | [e.g., pgbench] |
+| Tier 2 — Indexed range scan | [e.g., Range or list on indexed column] | [e.g., ≤ 15 ms] | [e.g., ≤ 50 ms] | [e.g., pgbench] |
+| Tier 3 — Aggregation | [e.g., COUNT, SUM, GROUP BY] | [e.g., ≤ 50 ms] | [e.g., ≤ 150 ms] | [e.g., pgbench] |
+| Tier 4 — Full-text / vector / analytical | [e.g., Search, similarity, reports] | [e.g., ≤ 100 ms] | [e.g., ≤ 300 ms] | [e.g., pgbench] |
+
+### Desktop surfaces (if applicable)
+
+| Metric | Threshold | Enforcement Tool |
+|--------|----------|-----------------|
+| Cold start | [e.g., ≤ 2 s] | [e.g., platform profiler] |
+| Memory (idle) | [e.g., ≤ 200 MB] | [e.g., platform profiler] |
+| Memory (active) | [e.g., ≤ 500 MB] | [e.g., platform profiler] |
+| Installer size | [e.g., ≤ 100 MB] | [e.g., CI size check] |
+
+### Mobile surfaces (if applicable)
+
+| Metric | Threshold | Enforcement Tool |
+|--------|----------|-----------------|
+| Cold launch | [e.g., ≤ 1.5 s] | [e.g., platform profiler] |
+| Warm launch | [e.g., ≤ 0.5 s] | [e.g., platform profiler] |
+| Battery drain (active) | [e.g., ≤ 5 %/hr] | [e.g., platform profiler] |
+| Download size | [e.g., ≤ 50 MB] | [e.g., CI size check] |
+
+### CLI surfaces (if applicable)
+
+| Metric | Threshold | Enforcement Tool |
+|--------|----------|-----------------|
+| Execution time | [e.g., ≤ 500 ms for common operations] | [e.g., hyperfine] |
+| Binary size | [e.g., ≤ 20 MB] | [e.g., CI size check] |
+| Startup latency | [e.g., ≤ 100 ms] | [e.g., hyperfine] |
+
+### CI Enforcement
+
+| Budget Category | Enforcement Tool | Fail Condition | Fail vs. Warn |
+|----------------|-----------------|----------------|---------------|
+| Web Vitals | [e.g., Lighthouse CI] | [e.g., Score below threshold] | [Fail] |
+| Bundle size | [e.g., size-limit] | [e.g., Exceeds per-page-type cap] | [Fail] |
+| API response time | [e.g., k6] | [e.g., p95 exceeds tier target] | [Warn / Fail after baseline] |
+| DB query time | [e.g., pgbench] | [e.g., p95 exceeds tier target] | [Warn / Fail after baseline] |
+| Desktop/mobile | [e.g., platform profiler] | [e.g., Any metric exceeds threshold] | [Warn] |
+
+## Accessibility
+- WCAG level: [e.g., 2.1 AA] (web/mobile)
+- Screen reader testing: [required/optional]
+- Keyboard navigation: [all interactive elements]
+- Platform accessibility APIs: [e.g., UIAccessibility for iOS, AccessibilityNodeInfo for Android]
+
+## Security
+- Dependency audit: [e.g., npm audit on every CI run]
+- Dependency audit enforcement: [e.g., Fail on HIGH/CRITICAL, Warn on MODERATE]
+- Secret scanning: [tool/approach]
+- CSP policy: [strict/relaxed + details] (web surfaces)
+- Code signing: [signing certificate strategy] (desktop/mobile surfaces)
+- Security testing tool: [e.g., OWASP ZAP for web, MobSF for mobile, or none] (surface-specific dynamic security scan)
+
+## Code Quality
+- Max file length: [e.g., 300 lines]
+- Max function length: [e.g., 50 lines]
+- Max cyclomatic complexity: [e.g., 10]
+- Required documentation: [public APIs / all exports / none]
+
+## CI/CD Gates
+- Tests must pass: [yes]
+- Lint must pass: [yes]
+- Type-check must pass: [yes]
+- Build must succeed: [yes]
+- Coverage threshold met: [yes]
+
+## Validation Command
+[The single command that enforces all of the above]
+```

package/template/.codex/skills/prd-templates/references/evolution-layer-guidance.md

@@ -0,0 +1,91 @@
+# Evolution Layer Guidance
+
+Reference for `/evolve-feature-classify` Step 4 and `/evolve-feature-cascade` Step 1 — specifies what to write at each pipeline layer when evolving a feature.
+
+## Entry Point Writing Depth
+
+### Ideation Layer (`.memory/wiki/specs/ideation/`)
+
+1. **Placement**: Read `ideation-index.md` Structure Map. Identify the domain folder. Create new domain if needed.
+2. **Classification Gate**: Apply Node Classification Gate from `.codex/skills/idea-extraction/SKILL.md` — leaf feature or sub-domain folder.
+3. **Write**: Use `.codex/skills/prd-templates/references/fractal-feature-template.md`. Include:
+   - Feature description (what and why)
+   - Affected personas
+   - Success criteria
+   - Constraints
+   - Role Lens — which personas interact and how
+4. **Update parent index**: Add to parent domain's `*-index.md` children table
+5. **Update CX files**: If cross-domain interactions exist, update parent `*-cx.md` and/or `ideation-cx.md`
+6. **Update `ideation-index.md`**: Add to MoSCoW Summary at appropriate priority
+
+### Architecture Layer (`architecture-design.md`)
+
+- Technical constraint description
+- Affected components
+- Non-functional requirements (performance, scalability, compliance)
+- Integration points
+
+### IA Layer (specific IA shard)
+
+- Domain interactions (new/modified user flows)
+- Contracts (new/modified API contracts)
+- Data models (new entities, fields, relationships)
+- Access control (RBAC implications)
+
+### BE Layer (BE spec)
+
+- New API endpoints
+- Updated schemas
+- Middleware requirements
+- Validation rules
+
+### FE Layer (FE spec)
+
+- New components
+- State management updates
+- New routes
+- Accessibility requirements
+
+### Phase Plan
+
+- New slices or updated slice acceptance criteria
+
+## Cascade Layer Guidance
+
+When cascading through downstream layers in `/evolve-feature-cascade`:
+
+| Layer | What to Add |
+|-------|------------|
+| Architecture | New components, system diagram references, NFRs, integration points |
+| IA | New domain interactions, updated contracts, data model changes, access control updates |
+| BE | New API endpoints, updated schemas, middleware requirements, validation rules |
+| FE | New components, state management updates, new routes, accessibility requirements |
+| Phase plan | New slices or updated slice acceptance criteria |
+
+## Impact Assessment Format
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Implementation Impact
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+In-progress slices affected:              [list or "none"]
+Completed slices that may need revisiting: [list or "none"]
+New slices needed:                        [list or "none"]
+Phase plan update required:               [yes/no]
+
+Recommended action: [specific next step]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+## Completion Summary Format
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Feature Evolution Complete
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Entry point:       [document]
+Layers updated:    [list]
+New content:       [summary]
+Implementation:    [impact summary]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```

package/template/.codex/skills/prd-templates/references/expansion-modes.md

@@ -0,0 +1,27 @@
+# Expansion Mode Options
+
+Present these options after engagement tier selection. All input types see the same options.
+
+| # | Mode | When to Recommend | Description |
+|---|------|-------------------|-------------|
+| 1 | **Full exploration** | 3+ domains | Breadth-before-depth with Deep Think |
+| 2 | **Process as-is** | Thin input where user is confident | Proceed with what's captured |
+| 3 | **Expand vertically** | Domains exist but are shallow | Drill deeper into existing features |
+| 4 | **Expand horizontally** | Domains are deep but coverage gaps exist | Add new domains |
+| 5 | **Cross-cutting concerns** | Domains mapped but interactions unexplored | Map feature interactions |
+| 6 | **Combination** | User has specific priorities | User specifies dimensions and order |
+| 7 | **Audit ambiguity first** | Unclear whether depth or breadth is needed | Inline ambiguity check before deciding |
+
+## Default Recommendations
+
+| Input Type | Default |
+|---|---|
+| Rich document (≥3 domains) | Full exploration |
+| Rich document (<3 domains) | Expand vertically |
+| Thin document | Full exploration |
+| Verbal / one-liner | Full exploration |
+| Re-run (continue) | Audit ambiguity first |
+
+## Recording
+
+Write the selected mode to `ideation-index.md` under `## Expansion Mode` immediately after user selection.

package/template/.codex/skills/prd-templates/references/fe-classification-procedures.md

@@ -0,0 +1,47 @@
+# FE Classification — Accessibility & Conditional Rendering Procedures
+
+Procedures used during `/write-fe-spec-classify` Step 4c to build accessibility inventories and conditional rendering matrices.
+
+---
+
+## Accessibility Extraction Gate
+
+Build an accessibility inventory table for every interactive component or interaction in this feature:
+
+| Component/Interaction | WCAG Req | Keyboard Nav | Screen Reader | IA Source |
+|-----------------------|----------|-------------|--------------|-----------|
+| [component name] | [WCAG level + criterion] | [key bindings + focus order] | [aria-label / role / live region] | [IA shard § section] |
+| [interaction name] | [WCAG level + criterion] | [key bindings + focus order] | [aria-label / role / live region] | [IA shard § section] |
+
+**Thin a11y coverage flag**: If an interactive feature has **< 3 accessibility specifications** in the IA shard (fewer than 3 rows in the inventory table for a feature with interactive elements), flag it:
+
+> ⚠️ **Thin accessibility coverage** for [feature name]: only [N] a11y specs found in IA shard. Options:
+> 1. Resolve now — add missing WCAG requirements to the IA shard before proceeding
+> 2. Accept thin coverage — proceed with what exists and flag as tech debt
+
+**Wait for the user's choice before proceeding.**
+
+**Carry-forward instruction**: The accessibility inventory table becomes inline annotations in the `## Component Inventory` section during `/write-fe-spec-write`. Each component's specification must include its WCAG requirements, keyboard navigation, and screen reader behavior directly — not as a separate accessibility section.
+
+---
+
+## Conditional Rendering Enumeration (Step 4c.5)
+
+Read the IA shard's `## Access Control` section. Build a **role × feature rendering matrix** for every feature-level component or interaction:
+
+| Feature/Component | Free | Paid | Creator | Guardian | Junior | Business | Staff | Admin |
+|-------------------|------|------|---------|----------|--------|----------|-------|-------|
+| [component name] | [hidden/locked/read-only/full] | [hidden/locked/read-only/full] | [hidden/locked/read-only/full] | [hidden/locked/read-only/full] | [hidden/locked/read-only/full] | [hidden/locked/read-only/full] | [hidden/locked/read-only/full] | [hidden/locked/read-only/full] |
+
+**Values**: `hidden` (not rendered), `locked` (visible but disabled with upgrade prompt), `read-only` (visible, non-interactive), `full` (full access).
+
+**Variant mapping**: Every non-trivial cell (any value other than `full` for the majority role) becomes a **named variant** in the component's `variants` spec in the FE spec. For example, if `Creator` gets `read-only` access to a component while `Paid` gets `full`, the component spec must include a `readOnlyCreator` variant (or equivalent named variant).
+
+**Unspecified role × feature combinations**: If the IA shard's `## Access Control` does not specify the rendering state for a particular role × feature combination, flag it explicitly:
+
+> ⚠️ **Unspecified role × feature combination**: [component] × [role] is not defined in the IA shard's access control.
+> Options:
+> 1. Define it now — specify the rendering state
+> 2. Apply closest-tier default — inherit from the nearest tier (e.g., Free inherits from the most restrictive, Admin inherits `full`)
+
+**Do not assume.** Every cell must be explicitly defined or explicitly defaulted with user confirmation.