cfsa-antigravity 2.0.0 → 2.2.0

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

@@ -23,6 +23,23 @@ 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 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 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 |
+|---|---|
+| ≤6 | ✅ No concern — proceed to skeleton validation |
+| 7–9 | ⚠️ **Pre-flag for split review** — note in the shard skeleton: `> ⚠️ Ideation source has [N] sub-areas — likely split candidate. Review at calibration gate.` |
+| ≥10 | 🚩 **Proactive split proposal** — present a split proposal to the user NOW, before the calibration gate. Use the same split format as Step 12. If the user approves, create the split shards immediately and update the decomposition plan. |
+
+> **Why proactive?** The reactive calibration gate (Step 12) catches overloaded shards, but only after skeletons are fully seeded. By reading ideation sub-area counts first, we avoid creating a massive skeleton only to immediately split it. For multi-product projects where a single surface domain (e.g., "Operations" in a desktop shop app) might have 15+ sub-areas, this saves significant rework.
+
 ## 10. Identify deep dive candidates
 
 Read .agent/skills/architecture-mapping/SKILL.md and follow its methodology.
@@ -61,7 +78,7 @@ Read .agent/skills/architecture-mapping/SKILL.md and follow its methodology for
 
 - **Must Have coverage gate**: Read `docs/plans/ideation/ideation-index.md` and extract every feature listed under "Must Have" in the MoSCoW Summary. For each Must Have feature, verify it appears in at least one shard's Features section. If any Must Have feature is not covered by any shard → **STOP**: "The following Must Have features from ideation-index.md are not covered by any shard: [list]. Add them to the appropriate shards before proceeding."
 
-- **Shard load calibration gate**: After the Must Have coverage gate passes, count the sub-features in each shard's `## Features` section using the **bullet/named-item rule**: count every bullet point or named item under `## Features`, **excluding** group headers (lines that introduce a group of sub-features but are not themselves a concrete capability). Compare against the following thresholds:
+- **Shard load calibration gate**: After the Must Have coverage gate passes, count the sub-features in each shard's `## Features` section using the **bullet/named-item rule**: count every bullet point or named item under `## Features`, **excluding** group headers (lines that introduce a group of sub-features but are not themselves a concrete capability). If Step 9.5 pre-flagged any shards, they should be reviewed first. Compare against the following thresholds:
 
   | Sub-feature Count | 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-contract.md

@@ -1,5 +1,5 @@
 ---
-description: Safely evolve a Zod schema — identify all consumers, write migration tests, update across all four surfaces
+description: Safely evolve a {{CONTRACT_LIBRARY}} schema — identify all consumers, write migration tests, update across all four surfaces
 pipeline:
   position: utility
   stage: maintenance
@@ -11,7 +11,7 @@ pipeline:
 
 # Evolve Contract
 
-Safely modify a Zod schema without breaking existing consumers.
+Safely modify a {{CONTRACT_LIBRARY}} schema without breaking existing consumers.
 
 **Input**: The contract to change and the desired modification
 **Output**: Updated contract, migration tests, and all consumers updated
@@ -44,9 +44,9 @@ Read these skills for safe schema migration:
 
 ## 1. Identify the contract
 
-Read .agent/skills/{{LANGUAGE_SKILL}}/SKILL.md and follow its language conventions.
+Determine which surface this contract belongs to (from the file path or calling context). Load the Languages skill(s) from that surface's row per the skill loading protocol (`.agent/skills/prd-templates/references/skill-loading-protocol.md`).
 
-Determine which Zod schema needs to change and what the change is:
+Determine which {{CONTRACT_LIBRARY}} schema needs to change and what the change is:
 - **Additive** (new optional field) — Low risk
 - **Narrowing** (tighter validation) — Medium risk
 - **Breaking** (rename, remove, type change) — High risk
@@ -77,32 +77,32 @@ If a new API version is needed, document the versioning approach (URL prefix, he
 
 Read .agent/skills/tdd-workflow/SKILL.md and follow its Red→Green→Refactor cycle for contract evolution.
 
-Read .agent/skills/{{UNIT_TESTING_SKILL}}/SKILL.md and follow its test writing conventions.
+Load the Unit Tests skill(s) from this contract's surface row per the skill loading protocol.
 
 Before changing anything, write tests that validate:
 - Existing data still passes the new schema (backward compatibility)
 - New data shape is accepted
 - Invalid data is rejected
 
-Run `{{TEST_COMMAND}}` — tests should FAIL until the schema is updated.
+Run the Test Cmd from this contract's surface row in the surface stack map (see `.agent/instructions/tech-stack.md`) — tests should FAIL until the schema is updated.
 
 ## 4. Update the contract
 
-Read .agent/skills/{{LANGUAGE_SKILL}}/SKILL.md and follow its language conventions.
+Load the Languages skill(s) from this contract's surface row per the skill loading protocol.
 
-Modify the Zod schema. For breaking changes:
+Modify the {{CONTRACT_LIBRARY}} schema. For breaking changes:
 - Consider versioning (v1 → v2)
 - Add runtime migration helpers if needed
 
 ## 4.5. New dependency check
 
-If the contract change introduces a dependency not currently in the skill set — for example, a new Zod plugin, a Pydantic extension, a binary serialization library, or a new validation pattern — read `.agent/workflows/bootstrap-agents.md` and invoke `/bootstrap-agents NEW_DEPENDENCY=[package]` before updating consumers in Step 5.
+If the contract change introduces a dependency not currently in the skill set — for example, a new validation library plugin, a schema extension, a binary serialization library, or a new validation pattern — read `.agent/workflows/bootstrap-agents.md` and invoke `/bootstrap-agents NEW_DEPENDENCY=[package]` before updating consumers in Step 5.
 
 Confirm the matching skill is installed (or no new dependency was introduced) before proceeding to Step 5.
 
 ## 5. Update all consumers
 
-Read .agent/skills/{{LANGUAGE_SKILL}}/SKILL.md and follow its language conventions.
+Load the Languages skill(s) from this contract's surface row per the skill loading protocol.
 
 For each consumer found in Step 2:
 - Update the code to use the new schema shape
@@ -110,7 +110,7 @@ For each consumer found in Step 2:
 
 ## 6. Validate
 
-Run `{{VALIDATION_COMMAND}}` (see `.agent/instructions/commands.md` for the configured validation command).
+Run the Validation Cmd from this contract's surface row in the surface stack map (see `.agent/instructions/tech-stack.md` and `.agent/instructions/commands.md`).
 
 All must pass.
 

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,176 +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` section from `docs/plans/ideation/ideation-index.md` and route accordingly. All findings are written to the appropriate files in `docs/plans/ideation/` in real time — not held in context.
+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
-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 in `domains/` using the `ideation-domain-template.md`
-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
-6. **Gate**: Present complete domain map to user. Get confirmation before Level 1.
+1. Read `ideation-index.md` for currently identified domains and structural classification
+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?** → Create domain file, 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?** → Create domain file, 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.
-
-### As-is Mode
+Read all CX files + feature files' cross-cut notes. Identify interaction points. Run synthesis questions on unresolved pairs. Document in appropriate CX files.
 
-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.
+### Combination / As-is Mode
 
-> **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?
-
-**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]."
+Read `.agent/skills/brainstorming/SKILL.md`.
 
-Write the MoSCoW matrix to `ideation-index.md` under the MoSCoW Summary section. Each feature links to its domain file.
+For each persona, brainstorm features across all 4 MoSCoW tiers. **Deep Think** for missing Must Haves.
 
-> **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.