cfsa-antigravity 2.1.0 → 2.2.1

package/template/.agent/skills/spec-writing/SKILL.md

@@ -21,7 +21,7 @@ Write one section at a time in document order. Before writing section N+1, re-re
 
 - For BE specs, the upstream source is the IA shard
 - For FE specs, the upstream source is the BE spec
-- For IA shards, the upstream sources are `ideation-index.md` (+ domain files) and `architecture-design.md`
+- For IA shards, the upstream sources are `ideation-index.md` (+ the relevant domain folder's `*-index.md`, `*-cx.md`, and feature files) and `architecture-design.md`
 
 **Hard rules:**
 

package/template/.agent/workflows/create-prd-architecture.md

@@ -50,10 +50,15 @@ Design the high-level system. Each sub-item requires full exploration, not a sum
    Load the Hosting skill(s) from the cross-cutting section per the skill loading protocol (`.agent/skills/prd-templates/references/skill-loading-protocol.md`).
    Read .agent/skills/technical-writer/SKILL.md and follow its methodology.
 4. **API surface** — REST? GraphQL? RPC? Versioning strategy? Error format? Pagination? Rate limit headers?
+5. **Deployment strategy** — Rolling? Blue-green? Canary? Read `.agent/skills/deployment-procedures/SKILL.md` Section 6 for the strategy options and selection matrix. Ask:
+   - "Which zero-downtime deployment strategy fits your risk profile? Rolling (standard), Blue-Green (easy rollback), or Canary (validate with real traffic)?"
+   - "Do you want feature flags for controlled rollout of risky features? If yes, which provider (or build your own)?"
+   - "What is your rollback trigger? Error rate spike above N%? Latency threshold? Manual decision?"
+   Write the confirmed strategy to `docs/plans/architecture-draft.md` under `## Deployment Strategy`.
 
 For multi-surface projects, additionally define:
-5. **Surface interconnection** — How do surfaces communicate? What is the source of truth for shared data? What happens when a surface is offline?
-6. **Shared domain boundary** — Which entities/models are shared across surfaces vs surface-specific?
+6. **Surface interconnection** — How do surfaces communicate? What is the source of truth for shared data? What happens when a surface is offline?
+7. **Shared domain boundary** — Which entities/models are shared across surfaces vs surface-specific?
 
 For each component, also define:
 - What it owns (data, logic, auth decisions)

package/template/.agent/workflows/create-prd-stack.md

@@ -27,7 +27,7 @@ Build the decision constraints map from the ideation output, then walk through e
 
 Before any tech stack decision, read `docs/plans/ideation/meta/constraints.md` to build the **decision constraints map**.
 
-Also read `docs/plans/ideation/ideation-index.md` — specifically the `## Structural Classification` section. This is the **authoritative source** for the project's surface list and project shape (single-surface, multi-surface-shared, or multi-product). Use this to determine which decision axes apply and whether tech stack decisions need to be made per-surface.
+Also read `docs/plans/ideation/ideation-index.md` — specifically the `## Structural Classification` section. This is the **authoritative source** for the project's surface list and project shape (`single-surface`, `multi-surface-shared`, `multi-product-hub`, or `multi-product-peer`). Use this to determine which decision axes apply and whether tech stack decisions need to be made per-surface.
 
 Build the constraints map:
 

package/template/.agent/workflows/create-prd.md

@@ -35,11 +35,12 @@ Read `docs/plans/ideation/ideation-index.md`.
 
 If the file doesn't exist, tell the user to run `/ideate` first. Do not proceed without approved ideation output.
 
-Use the **Document Map** in `ideation-index.md` to locate specific files:
+Use the **Structure Map** in `ideation-index.md` to locate specific files:
 - Constraints + surface classification → `meta/constraints.md`
 - Personas → `meta/personas.md`
-- Domain details → individual domain files in `domains/`
-- Cross-cutting concerns → `cross-cuts/cross-cut-ledger.md`
+- Domain details → fractal tree under `domains/` (or `surfaces/` for multi-product). Each domain is a **folder** containing `*-index.md` (children + Role Matrix), `*-cx.md` (cross-cuts), and child feature `.md` files. Walk the tree to the depth needed.
+- Cross-cutting concerns → `ideation-cx.md` (global cross-surface) + per-domain `*-cx.md` files within the fractal tree
+- Role coverage → Role Matrix in each domain index, Role Lens in each feature file (use for RBAC planning in security shard)
 
 Pay special attention to the **Project Surfaces** section in `meta/constraints.md` — it determines which tech stack axes apply.
 

package/template/.agent/workflows/decompose-architecture-structure.md

@@ -51,9 +51,9 @@ The `00-infrastructure` skeleton must contain these five items:
 
 Read `.agent/skills/prd-templates/references/decomposition-templates.md` for the **Shard Skeleton** template. For each shard, create a skeleton file at `docs/plans/ia/[NN-domain-name].md` using the template.
 
-Read .agent/skills/prd-templates/SKILL.md and follow its Shard Seeding Procedure for Level-1 sub-feature extraction. The procedure reads `ideation-index.md` to find the correct domain file path — files may be in `domains/` or `surfaces/{name}/` depending on the structural classification.
+Read `.agent/skills/prd-templates/SKILL.md` and follow its Shard Seeding Procedure for Level-1 sub-feature extraction. The procedure reads `ideation-index.md` to find the correct domain path — the ideation folder uses a fractal structure where each domain is a folder (with `{slug}-index.md`, `{slug}-cx.md`, and child features/sub-domains) rather than a flat file. For multi-product projects, domains may be in `surfaces/{name}/` (surface-exclusive or hub-owned) or `shared/` (peer mode).
 
-Fallback for domains not covered in the ideation domain files is defined in the skill's Shard Seeding Procedure.
+Fallback for domains not covered in the ideation domain folders is defined in the skill's Shard Seeding Procedure.
 
 ## 6. Create IA index
 

package/template/.agent/workflows/decompose-architecture-validate.md

@@ -25,11 +25,11 @@ Identify deep dive candidates, annotate shard document types, validate the depen
 
 ## 9.5. Proactive shard load pre-check (ideation signal)
 
-Before identifying deep dives, read the ideation domain files that fed each shard. The sub-area count from ideation is a **leading indicator** of shard complexity.
+Before identifying deep dives, read the ideation domain folders that fed each shard. The sub-area count from ideation is a **leading indicator** of shard complexity.
 
 For each shard skeleton:
-1. Read the corresponding ideation domain file (use the path from `ideation-index.md` Domain Documents table — may be in `domains/` or `surfaces/{name}/`)
-2. Count the sub-areas listed in the domain file's `## Sub-Areas` or breadth map section
+1. Read the corresponding ideation domain folder (use the path from `ideation-index.md` Structure Map — may be under `domains/` or `surfaces/{name}/`). Read the folder's `*-index.md` for the children table.
+2. Count the child feature files and sub-domain folders listed in the domain index
 3. Compare against the shard load thresholds:
 
 | Ideation Sub-Areas | Pre-Check Action |

package/template/.agent/workflows/decompose-architecture.md

@@ -29,7 +29,7 @@ If no architecture design exists, tell the user to run `/create-prd` first. Do n
 
 Also check the document's `**Status**:` field. If the status is `Draft` or `Review` → **STOP**: "The architecture design is not yet approved (current status: [status]). Get explicit approval from the user and update the status to `Approved` before decomposing."
 
-Also read `docs/plans/ideation/ideation-index.md` for the domain map, and load specific domain files as needed for context.
+Also read `docs/plans/ideation/ideation-index.md` for the fractal domain map and structural classification. The ideation folder uses a fractal structure — read domain indexes (not flat files) to understand depth, child counts, and cross-cut density.
 
 > **Design system prerequisite (web/mobile/desktop projects)**: Read `.agent/instructions/tech-stack.md` and locate the `SURFACES` value. If surfaces include `web`, `mobile`, or `desktop`, verify that `docs/plans/design-system.md` exists and is not empty.
 >
@@ -53,13 +53,28 @@ Read .agent/skills/architecture-mapping/SKILL.md and follow its methodology.
 
 Analyze the architecture design and identify natural domain boundaries. Each boundary becomes a numbered IA shard.
 
-**Heuristics for finding boundaries:**
+**Fractal tree analysis for shard boundaries:**
+
+The ideation folder uses a fractal structure. Walk the tree to inform shard granularity:
+
+| Signal | What It Means for Sharding |
+|--------|---------------------------|
+| Deep fractal tree (3+ levels) | Domain is complex enough for its own shard |
+| Many children (5+ features) | Consider splitting into multiple shards |
+| Dense CX file (5+ cross-cuts) | This domain has high coupling — keep it together in one shard, or isolate carefully |
+| Rich Role Matrix (3+ roles with access) | Shard needs multi-role IA spec coverage |
+| Hub-and-spoke shared domains | Shared domains often become `00-*` cross-cutting shards |
+| Leaf features marked `[EXHAUSTED]` | Most confident for shard scoping — behavior is fully defined |
+
+**Standard heuristics also apply:**
 - Features that share the same data models belong together
 - Features that can be developed/deployed independently are candidates for separation
 - Features that share the same access control model may belong together
 - Cross-cutting concerns (auth, API conventions, error handling) become `00-*` shards
 
-Read .agent/skills/architecture-mapping/SKILL.md and follow its Domain Boundary Protocol. Build the domain inventory record, apply all three split trigger rules, and produce the domain boundary table. Present split candidates to the user before locking any boundary.
+Read `.agent/skills/architecture-mapping/SKILL.md` and follow its Domain Boundary Protocol. Build the domain inventory record, apply all three split trigger rules, and produce the domain boundary table. Present split candidates to the user before locking any boundary.
+
+> **Important**: Ideation does NOT prescribe shard boundaries. It provides the raw data (depth, features, cross-cuts, roles). This workflow makes the shard boundary decisions based on architectural analysis.
 
 Present the proposed domain decomposition to the user for validation.
 

package/template/.agent/workflows/evolve-feature-classify.md

@@ -54,7 +54,7 @@ Based on the classification, determine where the new content enters the pipeline
 
 | Classification | Entry Point Document | Rationale |
 |---------------|---------------------|-----------|
-| **[1] New feature** | `docs/plans/ideation/ideation-index.md` + relevant domain file | New features start at the ideation layer — they affect everything downstream |
+| **[1] New feature** | `docs/plans/ideation/ideation-index.md` + fractal tree placement (see Step 4) | New features start at the ideation layer — placed in the correct domain folder via Classification Gate |
 | **[2] New requirement** | The IA shard that owns the affected domain | Requirements on existing features enter at the domain interaction level |
 | **[3] New technical constraint** | `docs/plans/[dated]-architecture-design.md` | Technical constraints affect the architecture and everything below it |
 | **[4] Scope correction** | Ask the user which document contains the misunderstanding | Corrections enter wherever the original misunderstanding lives |
@@ -69,11 +69,19 @@ Read .agent/skills/technical-writer/SKILL.md and follow its clarity standards fo
 
 This is a real spec-writing step — not a placeholder. Write the new content at the appropriate depth for the entry point layer:
 
-**If entry point is ideation layer** (`docs/plans/ideation/ideation-index.md`):
-- Feature description (what it does, why it matters)
-- Affected personas (who uses this)
-- Success criteria (how we know it works)
-- Constraints (what limits apply)
+**If entry point is ideation layer** (`docs/plans/ideation/`):
+
+1. **Placement**: Read `ideation-index.md` Structure Map. Identify the domain folder where this feature belongs. If no suitable domain exists, create one.
+2. **Classification Gate**: Apply the Node Classification Gate from `.agent/skills/idea-extraction/SKILL.md` — determine if the feature is a leaf feature file or complex enough to warrant a sub-domain folder.
+3. **Write the feature**: Use `.agent/skills/prd-templates/references/fractal-feature-template.md` as the template. Include:
+   - Feature description (what it does, why it matters)
+   - Affected personas (who uses this)
+   - Success criteria (how we know it works)
+   - Constraints (what limits apply)
+   - **Role Lens** — which personas interact with this feature and how
+4. **Update parent index**: Add the new feature to the parent domain's `*-index.md` children table
+5. **Update CX files**: If the feature has cross-domain interactions, update the parent domain's `*-cx.md` and/or `ideation-cx.md` (global)
+6. **Update `ideation-index.md`**: Add the feature to the MoSCoW Summary at the appropriate priority level
 
 **If entry point is architecture layer** (`architecture-design.md`):
 - Technical constraint description

package/template/.agent/workflows/ideate-discover.md

@@ -1,5 +1,5 @@
 ---
-description: Recursive breadth-before-depth domain exploration with Deep Think protocol for the ideate workflow
+description: Recursive breadth-before-depth domain exploration with Deep Think protocol and fractal structure for the ideate workflow
 parent: ideate
 shard: discover
 standalone: true
@@ -17,180 +17,141 @@ pipeline:
 
 # Ideate — Discover
 
-Explore domains through recursive breadth-before-depth with the Deep Think protocol. Write directly to domain files — no monolithic intermediary.
+Explore domains through recursive breadth-before-depth with the Deep Think protocol. Write to the fractal folder structure — every node gets an index, CX file, and children.
 
-**Prerequisite**: If invoked standalone, verify `docs/plans/ideation/ideation-index.md` exists with at least the folder structure seeded. If not, prompt the user to run `/ideate-extract` first.
+**Prerequisite**: If invoked standalone, verify `docs/plans/ideation/ideation-index.md` exists with the fractal folder structure seeded. If not, prompt the user to run `/ideate-extract` first.
 
 ---
 
 ## 3. Domain Exploration — Recursive Model
 
-Read `.agent/skills/idea-extraction/SKILL.md` and follow its Recursive Domain Exhaustion Protocol and Deep Think Protocol.
+Read `.agent/skills/idea-extraction/SKILL.md` — follow the Recursive Domain Exhaustion Protocol, Deep Think Protocol, Node Classification Gate, and Reactive Depth Protocol.
 
-Read the `## Expansion Mode` and `## Structural Classification` sections from `docs/plans/ideation/ideation-index.md`. The expansion mode shapes exploration behavior. The structural classification determines where domain files are created.
-
-> **Multi-product projects:** When creating domain files, always check whether the domain belongs to a specific surface or is shared. Use `surfaces/{name}/` for surface-exclusive domains and `domains/` for shared/cross-cutting domains. Ask the user if placement is unclear.
+Read `## Expansion Mode` and `## Structural Classification` from `docs/plans/ideation/ideation-index.md`.
 
 ### Full Mode (recommended for 3+ domains)
 
 #### Level 0 — Global Domain Map
 
 1. Read `ideation-index.md` for currently identified domains and structural classification
-2. Apply the idea-extraction skill's Deep Think Protocol:
-   - "Based on this product type and industry, what domains would I expect to see that haven't been mentioned?"
-   - Present hypotheses to user for confirmation or rejection
-3. For each confirmed domain, create a domain file:
-   - **Single-surface**: Create in `domains/` using the `ideation-domain-template.md`
-   - **Multi-product**: Determine placement first — "Does this belong to a specific surface, or is it shared?" Create in `surfaces/{name}/` or `domains/` accordingly.
-4. Note preliminary cross-cuts: "Domain A might touch Domain B because [reason]" → add to `cross-cuts/cross-cut-ledger.md` as **Level 0** entries
-5. Update `ideation-index.md` with the complete domain map (paths reflect actual folder locations)
-6. **Gate**: Present complete domain map to user. Get confirmation before Level 1.
+2. Apply Deep Think: "What domains would I expect for this product type?"
+3. For each confirmed domain, run the **Node Classification Gate** (from skill):
+   - Determine placement (surface folder, hub, shared, or top-level)
+   - Create domain folder: `{NN}-{slug}/` + `{slug}-index.md` + `{slug}-cx.md`
+4. Note preliminary cross-cuts:
+   - In the relevant parent's CX file (surface CX or global CX)
+   - In `ideation-cx.md` if cross-surface
+5. Update `ideation-index.md` structure map with paths
+6. **Gate**: Present domain map. User confirms before Level 1.
 
 #### Level 1 — Domain Breadth Sweep
 
 For each domain (dependency order — foundational first):
 
 1. List all sub-areas/capabilities within the domain
-2. **Deep Think**: "Based on this domain in this industry, what sub-areas would an expert expect that haven't been mentioned?" Present hypotheses.
-3. Write the breadth map to the domain file. Mark each sub-area as `[SURFACE]`.
-4. Note cross-cuts at sub-area level → add to ledger as **Level 1** entries
-5. **NEW DOMAINS DISCOVERED?** → Classify placement (surface-specific or shared), create domain file in the correct folder, update index, loop back to Level 0 for the new domain. Do NOT proceed until domain map is stable.
-6. Mark domain status as `[BREADTH]` in the index
-7. **Gate**: Pause after EACH domain's breadth map. "Here's what I mapped for [Domain]. Anything missing?" Then after ALL domains: "All domains are at BREADTH. Ready to drill?"
+2. **Deep Think**: "What sub-areas would an expert expect?"
+3. Run **Node Classification Gate** for each:
+   - 2+ interacting capabilities → **sub-domain** (create folder + index + CX)
+   - Single capability → **feature** (create `.md` file from `fractal-feature-template.md`)
+4. Update domain index (Children table + **Role Matrix**)
+5. Note cross-cuts in the domain's CX file
+6. **NEW DOMAINS DISCOVERED?** → Classify, create, update index, loop to Level 0
+7. Mark domain status as `[BREADTH]`
+8. **Gate**: Pause after EACH domain. "Here's what I mapped for [Domain]. Missing anything?" After ALL: "All domains at BREADTH. Ready to drill?"
 
 #### Level 2+ — Vertical Drilling
 
-For each domain (dependency order), for each sub-area:
-
-1. Apply the idea-extraction skill's Exhaustion Questions (entity, feature, user, integration)
-2. **Deep Think** per sub-area:
-   - "Based on this feature in this product, what edge cases, interactions, and failure modes would a production system need?"
-   - "Based on cross-domain knowledge already captured, does this sub-area need something because of how it connects to other domains?"
-   - Present hypotheses to user
-3. Write drill results to the domain file under the appropriate sub-area section
-4. Record Deep Think outcomes in the domain file's Deep Think Annotations table
-5. Cross-cuts with evidence → add to ledger as **Level 2+** entries with specific evidence
-6. **NEW SUB-AREAS DISCOVERED?** → Add to domain file breadth map as `[SURFACE]`, complete breadth mapping first, THEN drill
-7. **NEW DOMAINS DISCOVERED?** → Classify placement (surface-specific or shared), create domain file in the correct folder, update index, loop back to Level 0
-8. When Deep Think yields zero new hypotheses AND user confirms → mark sub-area `[EXHAUSTED]`
-9. When all sub-areas are `[DEEP]` or `[EXHAUSTED]` → mark domain `[DEEP]` or `[EXHAUSTED]` in index
-10. **Gate**: Pause after each domain is drilled. "Here's what I captured for [Domain]. Anything missing?"
+For each domain (dependency order), for each child:
+
+1. Apply Exhaustion Questions (entity, feature, user, integration)
+2. **Deep Think** per child — edge cases, interactions, failure modes
+3. For **feature files**: fill all sections (Behavior, Edge Cases, States, **Role Lens**)
+4. For **sub-domains**: drill their child features recursively
+5. Record Deep Think outcomes in each feature file's Deep Think Annotations table
+6. Cross-cuts with evidence → add to parent's CX file with synthesis questions
+7. **Feature reveals 2+ interacting capabilities?** → Run **Promotion Protocol** (convert .md to folder)
+8. **NEW DOMAINS DISCOVERED?** → Loop to Level 0
+9. When Deep Think yields zero hypotheses AND user confirms → mark `[EXHAUSTED]`
+10. Status propagation: all children `[EXHAUSTED]` → node is `[EXHAUSTED]`
+11. **Gate**: Pause after each domain is drilled.
 
 #### Cross-Cut Synthesis (Continuous)
 
-Cross-cuts are NOT a separate pass. They are identified and synthesized continuously. However, after all domains reach `[DEEP]`, do a final review:
+Cross-cuts are identified continuously, but after all domains reach `[DEEP]`, do a final review:
 
-1. Read `cross-cuts/cross-cut-ledger.md` for all accumulated entries
-2. For any pairs still at `pending` status, ask the five synthesis questions:
-   - Shared state conflict — who owns the entity? merge strategy?
-   - Trigger chain — does A trigger B? rollback if B fails? sync/async?
-   - Permission intersection — does permission in A affect B?
-   - Notification fan-out — does event in A notify actors in B?
-   - State transition conflict — can A and B race? consistency impact?
-3. Document confirmed interactions with outcomes in the ledger
-4. Discard rejected pairs with a one-line reason
-5. Check for **second-order cross-cuts**: "Now that we've confirmed these interactions, do any of the CONFIRMED pairs themselves cross-cut each other?"
+1. Read ALL CX files at every level (global, surface, domain, sub-domain)
+2. For any entries at Medium/Low confidence, ask the five synthesis questions (per `fractal-cx-template.md`)
+3. Document confirmed interactions with role scoping
+4. Record rejected pairs with reasoning
+5. Check second-order cross-cuts: "Do any CONFIRMED pairs cross-cut each other?"
 
 ### Vertical Mode
 
-Focus on existing domains. Identify shallowest sub-areas. Drive to Level 2+ depth with Deep Think active. Cross-cut watch active — surface candidates in ledger. Do not introduce new domains unless user requests.
+Identify shallowest leaf nodes. Drive to `[DEEP]`/`[EXHAUSTED]` with Deep Think. Fill Role Lens in all feature files. Cross-cut watch active — log to appropriate CX files. Do not introduce new domains unless user requests.
 
 ### Horizontal Mode
 
-Audit for missing domains with Deep Think. Present gap list. Create domain files for confirmed new domains with Level 1 exploration. Cross-cut watch active for new domains vs existing. Offer to continue with vertical drilling after.
+Audit for missing domains with Deep Think. Create domain folders (with Classification Gate) for confirmed new domains. Level 1 breadth sweep on each. Offer vertical drilling after.
 
 ### Cross-cutting Mode (standalone)
 
-Read all domain files, identify interaction points. For each significant pair, ask the five synthesis questions. Document confirmed interactions in ledger. Note: works best after vertical drilling.
-
-### Combination Mode
-
-User specifies sequence. Apply each mode in order. Cross-cut detection always active.
+Read all CX files + feature files' cross-cut notes. Identify interaction points. Run synthesis questions on unresolved pairs. Document in appropriate CX files.
 
-### As-is Mode
+### Combination / As-is Mode
 
-Skip active expansion. Proceed to exhaustion check. Cross-cut watch still active — scan domain files for obvious interaction points and surface candidates in ledger before proceeding.
-
-> **Mid-session mode switching**: If you want to change expansion direction, update the `Expansion Mode` in `ideation-index.md` and re-run `/ideate-discover`.
+Combination: user specifies sequence. As-is: skip expansion, run exhaustion check, but still scan for obvious CX candidates.
 
 ---
 
 ## 4. Problem exploration
 
-Read `.agent/skills/brainstorming/SKILL.md` and follow its structured facilitation methodology.
-
-Using the idea-extraction skill's approach for the selected mode, explore:
-
-1. **What problem are we solving?** — Get the user to articulate the core pain point in one sentence. If they can't, help them sharpen it. Write to `meta/problem-statement.md`.
-2. **Who has this problem?** — Identify 2-4 distinct user personas with different needs. For each persona, explore all 6 required fields. Write to `meta/personas.md`.
-3. **How are they solving it today?** — Understand the competitive landscape and current workarounds. Write to `meta/competitive-landscape.md`.
-4. **Why now?** — What has changed that makes this solvable/valuable now. Write to `meta/problem-statement.md` under the "Why Now" section.
+Read `.agent/skills/brainstorming/SKILL.md` and follow its methodology.
 
-After each answer, summarize what you've captured and ask the user to confirm before moving on.
+1. **What problem are we solving?** → Write to `meta/problem-statement.md`
+2. **Who has this problem?** → Write to `meta/personas.md`
+3. **How are they solving it today?** → Write to `meta/competitive-landscape.md`
+4. **Why now?** → Write to `meta/problem-statement.md` under "Why Now"
 
-**Persona completeness gate (Ideation Rubric Dimension 2):** For each persona, verify all 6 fields are explicitly present before moving on:
-1. **Name + specific role** — not "a user" or "customers"; a named role with context
-2. **Specific pain point** — one sentence naming the exact friction
-3. **Current workaround** — how they solve this today: the specific tool, process, or coping mechanism
-4. **Success criteria** — what "solved" concretely looks like for this persona; measurable if possible
-5. **Switching trigger** — what would make them switch from their current approach
-6. **At least one edge case or constraint unique to this persona**
+**Persona completeness gate (Ideation Rubric Dimension 2):** For each persona, verify all 6 fields:
+1. Name + specific role
+2. Specific pain point
+3. Current workaround
+4. Success criteria
+5. Switching trigger
+6. At least one edge case or constraint unique to this persona
 
-If any field is absent → probe for it before proceeding. Do not move to feature collection until all personas have all 6 fields. Reference: `.agent/skills/pipeline-rubrics/references/ideation-rubric.md` Dimension 2.
+If any field absent → probe before proceeding. Reference: `.agent/skills/pipeline-rubrics/references/ideation-rubric.md` Dimension 2.
 
 ---
 
 ## 5. Feature inventory — deep exploration
 
-This is where most ideation workflows fail. They collect a feature list and move on. This workflow explores each feature using the recursive model and Deep Think.
-
 ### 5a. Feature collection (MoSCoW)
 
-Read `.agent/skills/brainstorming/SKILL.md` and follow its methodology.
-
-For each persona identified in Step 4, brainstorm features:
-
-1. **Must-have features** — What features are launch-blocking?
-2. **Should-have features** — What features are expected but not day-one critical?
-3. **Could-have features** — What features would delight but can be deferred?
-4. **Won't-have (now)** — What is explicitly out of scope?
+Read `.agent/skills/brainstorming/SKILL.md`.
 
-**Deep Think**: "Based on the personas and problem statement, what features would I expect to see in the Must Have list that haven't been mentioned? For example, in similar products, [examples]."
+For each persona, brainstorm features across all 4 MoSCoW tiers. **Deep Think** for missing Must Haves.
 
-Write the MoSCoW matrix to `ideation-index.md` under the MoSCoW Summary section. Each feature links to its domain file.
-
-> **Note:** Deferred ≠ lower quality. Every feature that makes the cut will be built to production standard.
+Write MoSCoW matrix to `ideation-index.md`. Each feature references its **fractal path** (e.g., `web/01.02.03`) and links to its feature file.
 
 ### 5b. Feature deepening — Must Haves
 
-For each **Must Have** feature, use the recursive model:
-
-1. **Level 1: Sub-features.** What are the component parts of this feature?
-   - "User authentication" → signup, login, password reset, profile management, account deletion, session management, OAuth providers
-
-2. **Level 2: Edge cases and failure modes.** For each sub-feature:
-   - What happens on failure? What error does the user see?
-   - What happens on partial failure? (network drops mid-operation)
-   - What permissions are required?
-   - What are the states? (loading, empty, populated, error)
-
-3. **Level 3 (complex features): Interactions and conflicts.**
-   - How does this feature interact with other Must Haves?
-   - What if two features trigger simultaneously?
-   - Are there any conflicts between features?
+For each Must Have feature, use the recursive model:
 
-**Deep Think at each level**: "Based on this feature in production systems, what am I missing? What breaks in the real world?"
+1. **Level 1: Sub-features.** Component parts. Run Classification Gate — sub-domain or feature?
+2. **Level 2: Edge cases and failure modes.** Fill feature file sections: Behavior (happy path, edge cases, states), **Role Lens**.
+3. **Level 3 (complex features): Interactions.** Cross-cuts with evidence → parent CX file.
 
-Write all drilling results to the appropriate domain files.
+**Deep Think at each level.** Write results to feature files using `fractal-feature-template.md`.
 
 ### 5c. Feature deepening — Should Haves (lighter touch)
 
-For Should Have features, explore Level 1 (sub-features) only with Deep Think. Note that these will get full Level 2-3 treatment in `/create-prd` when they enter scope.
+Level 1 (sub-features) only with Deep Think. Full treatment deferred to `/create-prd`.
 
 ---
 
 ### Propose next step
 
-Once the feature inventory is complete and the user has confirmed the MoSCoW matrix, proceed to `/ideate-validate` to check exhaustion, explore constraints, and compile the vision summary.
+Proceed to `/ideate-validate` for exhaustion check, constraint exploration, and vision compilation.
 
-> If this shard was invoked standalone (not from `/ideate`), surface this via `notify_user`. If invoked by the parent `/ideate`, this is a natural handoff — the parent orchestrates the transition.
+> If standalone, surface via `notify_user`. If from parent `/ideate`, natural handoff.