cfsa-antigravity 2.7.0 → 2.8.0

package/template/.agent/workflows/evolve-contract.md

@@ -61,6 +61,11 @@ Document all consumers:
 - Test files
 - Other contracts that reference this one
 
+**Zero-consumer path**: If no consumers are found (only the schema definition itself):
+- Confirm with user: "Contract [name] has zero consumers. It can be modified directly without migration safeguards. Proceed with simple edit?"
+- If confirmed → skip Steps 3-5, apply the schema change directly, run validation (Step 6), then proceed to Step 6.5.
+- If user declines → proceed normally (the contract may have planned but not-yet-implemented consumers).
+
 ### 2.5. API versioning check (conditional)
 
 If any consumer is a **public-facing API endpoint** (i.e., called by external clients, not just internal frontend):
@@ -96,9 +101,9 @@ Modify the {{CONTRACT_LIBRARY}} schema. For breaking changes:
 
 ## 4.5. New dependency check
 
-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.
+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. **HARD GATE**: Follow the bootstrap verification protocol (`.agent/skills/prd-templates/references/bootstrap-verification-protocol.md`).
 
-Confirm the matching skill is installed (or no new dependency was introduced) before proceeding to Step 5.
+If no new dependency was introduced, proceed directly to Step 5.
 
 ## 5. Update all consumers
 

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

@@ -17,32 +17,32 @@ pipeline:
 
 Cascade the new content from the entry point through all downstream layers with existing content, assess implementation impact, run a consistency check, and write the evolution record.
 
-> **Prerequisite**: The entry point document must already contain the new content (written by `/evolve-feature-classify` Step 4). The cascade scope must be determined (Step 5 output).
+> **Prerequisite**: Entry point document must contain the new content (from `/evolve-feature-classify` Step 4). Cascade scope must be determined (Step 5 output).
+
+**Locked decision conflict check**: Before cascading, scan the new content against locked decisions in upstream layers:
+1. Read the architecture design document (`docs/plans/*-architecture-design.md`) for locked constraints
+2. Compare each element of the new feature against: tech stack decisions, data placement strategy, security model, performance budgets
+3. **If conflict detected** → **STOP**: "New feature '[name]' conflicts with locked decision: [decision]. Options: (1) Modify the feature to work within the constraint, (2) Use `/propagate-decision` to change the locked decision first, then re-run `/evolve-feature`."
+4. **If no conflicts** → proceed to Step 1.
 
 ---
 
 ## 1. Cascade through each downstream layer
 
-Read .agent/skills/technical-writer/SKILL.md and apply its writing standards to all spec additions and the evolution record.
-
-For each downstream layer with existing content (in order: architecture → IA → BE → FE → phase plan):
+Read `.agent/skills/technical-writer/SKILL.md` for writing standards.
 
-1. **Read existing documents** in the layer
-2. **Determine what the new feature means for this layer** — what sections need additions, what contracts change, what new components are needed
-3. **Write the additions** — new sections, new entries in existing tables, new acceptance criteria, new contracts. Write at the same depth and quality as the existing content in the layer.
-4. **Present additions to user** — show exactly what was added and where
+Read `.agent/skills/prd-templates/references/evolution-layer-guidance.md` → **Cascade Layer Guidance** table.
 
-**STOP at each layer** — do not cascade to the next layer until the user approves the current layer's additions.
+For each downstream layer with existing content (in order: architecture → IA → BE → FE → phase plan):
 
-Layer-specific guidance:
+1. Read existing documents in the layer
+2. Determine what the new feature means for this layer — consult the guidance table for what to add
+3. Write the additions at the same depth and quality as existing content
+4. Present additions to user
 
-- **Architecture layer**: Add new components, update system diagrams references, add NFRs, update integration points
-- **IA layer**: Add new domain interactions, update contracts, add data model changes, update access control
-- **BE layer**: Add new API endpoints, update schemas, add middleware requirements, update validation rules
-- **FE layer**: Add new components, update state management, add new routes, update accessibility requirements
-- **Phase plan**: Add new slices or update existing slice acceptance criteria (see Step 2)
+**STOP at each layer** — do not cascade to next until user approves.
 
-> After writing additions to any spec document in this step, append a row to that spec's `## Changelog` table recording: today's date, `'Evolution: [brief description of what was added]'`, this workflow (`/evolve-feature-cascade`), and the sections of the spec that were updated. If the spec does not yet have a `## Changelog` section, add one following the template in `.agent/skills/prd-templates/references/be-spec-template.md` (for BE specs) or the equivalent FE/IA template before appending the row.
+> After writing to any spec document, append a `## Changelog` row: date, `'Evolution: [description]'`, workflow, updated sections. If no `## Changelog` exists, add one from the template in `.agent/skills/prd-templates/references/be-spec-template.md`.
 
 ---
 
@@ -50,91 +50,47 @@ Layer-specific guidance:
 
 If `docs/plans/phases/` exists and contains phase plans:
 
-1. **Check in-progress slices** — do any currently in-progress slices need their acceptance criteria updated? List the affected criteria.
-2. **Check completed slices** — do any completed slices that may need revisiting? (This is a red flag — document it clearly with regression risk assessment)
-3. **Determine if new slices are needed** — does the new feature require new implementation slices in the current phase? If yes, draft the slice names and acceptance criteria.
-4. **Determine if phase plan update is required** — does the scope require changes to the phase plan structure?
-
-Present the impact assessment:
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-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]
+1. Check in-progress slices for affected acceptance criteria
+2. Check completed slices that may need revisiting (flag regression risk)
+3. Determine if new slices are needed
+4. Determine if phase plan update is required
 
-Recommended action: [specific next step]
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
+Read `.agent/skills/prd-templates/references/evolution-layer-guidance.md` → **Impact Assessment Format** and use it to present.
 
-If no phase plans exist, skip this step and note: "No phase plans exist yet — implementation impact will be assessed during `/plan-phase`."
+If no phase plans exist: "No phase plans yet — impact assessed during `/plan-phase`."
 
 ---
 
 ## 3. Run consistency check
 
-Read .agent/skills/resolve-ambiguity/SKILL.md and follow its methodology.
+Read `.agent/skills/resolve-ambiguity/SKILL.md` and follow its methodology.
 
-For every document that received additions in Step 1:
+For every document that received additions:
+1. Re-read full document — verify additions integrate correctly
+2. Check for internal contradictions
+3. Check cross-references between changed documents
+4. Check against locked decisions
 
-1. **Re-read the full document** — verify the additions integrate correctly with existing content
-2. **Check for internal contradictions** — do the additions conflict with anything else in the same document?
-3. **Check cross-references between changed documents** — if multiple documents were updated, verify they are consistent with each other
-4. **Check against locked decisions** — do the additions contradict any locked architectural decisions?
-
-Report any issues found. **Do not auto-fix** — present them to the user for review.
+Report issues. **Do not auto-fix** — present to user.
 
 ---
 
 ## 4. Write evolution record
 
-Write `docs/audits/evolve-feature-[name]-[date].md` recording:
-
-- **Feature name** — short identifier for the evolution
-- **Change type** — classification from Step 2 of `/evolve-feature-classify`
-- **Entry point** — which document received the initial content
-- **New content written** — summary of what was added at the entry point
-- **Layers updated** — list of downstream layers that received additions
-- **Per-layer additions** — what was added at each layer (summary, not full content)
-- **Implementation impact** — assessment from Step 2 (if applicable)
-- **Consistency check results** — pass/fail with details
-- **Timestamp** of the evolution run
+Write `docs/audits/evolve-feature-[name]-[date].md` recording: feature name, change type, entry point, new content summary, layers updated, per-layer additions, implementation impact, consistency check results, timestamp.
 
 ---
 
 ## 4.5. Bootstrap gate — new dependency check
 
-Before closing the cascade, scan every document that was updated in Step 1 for any technology, library, or service referenced in the new content that does not have a corresponding installed skill directory in `.agent/skills/`.
-
-For each missing skill:
-1. Identify the technology (e.g., WebSocket, S3 storage, Stripe, Redis)
-2. Read `.agent/workflows/bootstrap-agents.md` and invoke `/bootstrap-agents NEW_DEPENDENCY=[technology]`
-3. Confirm the matching skill is installed before proceeding to Step 5
+Scan updated documents for technologies without corresponding skill directories.
 
-If no new unregistered technologies were introduced, skip and proceed to Step 5.
+For each missing skill: read `.agent/workflows/bootstrap-agents.md` and invoke. **HARD GATE**: follow bootstrap verification protocol (`.agent/skills/prd-templates/references/bootstrap-verification-protocol.md`).
 
 ---
 
 ## 5. Propose next steps
 
-Display the completion summary:
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Feature Evolution Complete
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Entry point:       [document]
-Layers updated:    [list]
-New content:       [summary]
-Implementation:    [impact summary]
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-❗ **Mandatory next step — do not skip**: The evolution just added or modified content across [N] layers. Evolution bypasses the normal deepening phase — the audit is the quality gate that replaces it.
-
-Run `/audit-ambiguity` on the affected layers before any implementation work touches these documents. The affected layers are: [list the layers that were updated during the cascade — populated from Step 1's output].
+Read `.agent/skills/prd-templates/references/evolution-layer-guidance.md` → **Completion Summary Format** and present.
 
-This is not optional. Under-specified evolution content is the single most common source of spec drift. The audit catches what the inline micro check may have missed at a cross-document level.
-```
+❗ **Mandatory next step**: Run `/audit-ambiguity` on affected layers before any implementation work. List the layers updated during Step 1.

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

@@ -17,7 +17,7 @@ pipeline:
 
 Capture the user's new feature, requirement, or constraint. Classify it, identify the correct entry point document, write the new content at proper spec depth, and determine which downstream layers need updating.
 
-> **Prerequisite**: At least `docs/plans/ideation/ideation-index.md` must exist. If the pipeline hasn't started, run `/ideate` first — there's nothing to evolve yet.
+> **Prerequisite**: `docs/plans/ideation/ideation-index.md` must exist. If not → **STOP**: run `/ideate` first.
 
 ---
 
@@ -25,100 +25,66 @@ Capture the user's new feature, requirement, or constraint. Classify it, identif
 
 Ask the user to describe what they want to add. Accept free-form input or `@file`.
 
-If the user provides an `@file` reference, read the file and extract the key additions. If free-form, engage briefly to ensure the addition is clear — but this is NOT a full `/ideate` interview. The goal is to understand what's being added, not to explore the entire problem space.
+If `@file` → read and extract key additions. If free-form → brief clarifying questions only (NOT a full `/ideate` interview).
 
 ---
 
 ## 2. Classify the change
 
-Read .agent/skills/brainstorming/SKILL.md and follow its methodology.
+Read `.agent/skills/brainstorming/SKILL.md` and follow its methodology.
 
 Present the classification menu:
 
 ```
 What type of change is this?
 
-[1] New feature — an entirely new capability that doesn't exist in the current specs
-[2] New requirement on an existing feature — additional constraint, behavior, or acceptance criteria for something already specified
-[3] New technical constraint — a non-functional requirement that affects architecture (performance, compliance, infrastructure)
-[4] Scope correction — something was misunderstood or underspecified in existing specs and needs to be fixed
+[1] New feature — entirely new capability
+[2] New requirement on existing feature — additional constraint/behavior/criteria
+[3] New technical constraint — non-functional requirement affecting architecture
+[4] Scope correction — misunderstanding or underspecification that needs fixing
 ```
 
-**Do not proceed until the user selects.**
+**STOP** — do not proceed until the user selects.
 
 ---
 
 ## 3. Identify the entry point document
 
-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` + 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 |
-
-For classification [2], identify which IA shard owns the affected domain by reading `docs/plans/ia/index.md` and matching the feature to a domain.
+| Classification | Entry Point Document |
+|---------------|---------------------|
+| **[1] New feature** | `docs/plans/ideation/ideation-index.md` + fractal tree placement (Step 4) |
+| **[2] New requirement** | The IA shard that owns the affected domain (read `docs/plans/ia/index.md` to find it) |
+| **[3] New technical constraint** | `docs/plans/[dated]-architecture-design.md` |
+| **[4] Scope correction** | Ask the user which document contains the misunderstanding |
 
 ---
 
 ## 4. Write new content at the entry point
 
-Read .agent/skills/technical-writer/SKILL.md and follow its clarity standards for all new spec content.
-
-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/`):
+Read `.agent/skills/technical-writer/SKILL.md` for clarity standards.
 
-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
+Read `.agent/skills/prd-templates/references/evolution-layer-guidance.md` → **Entry Point Writing Depth** section for the entry point layer. Follow its writing checklist for the identified layer.
 
-**If entry point is architecture layer** (`architecture-design.md`):
-- Technical constraint description
-- Affected components (which parts of the system this touches)
-- Non-functional requirements (performance, scalability, compliance)
-- Integration points (how this relates to existing architecture decisions)
-
-**If entry point is IA layer** (specific IA shard):
-- Domain interactions (new user flows or modifications to existing flows)
-- Contracts (new or modified API contracts)
-- Data models (new entities, fields, or relationships)
-- Access control (RBAC implications)
-
-**Inline ambiguity check**: Before presenting this content to the user for approval, apply the Micro Ambiguity Check from `.agent/skills/session-continuity/SKILL.md` (Ambiguity Gates section). Walk each individual element of the new content and ask: "Would an implementer need to guess about this?" For every element where the answer is yes — fix it now. Add the missing detail, type, behavior, or constraint. Only present the content to the user once it passes the micro check.
+**Inline ambiguity check**: Before presenting to user, apply Micro Ambiguity Check from `.agent/skills/session-continuity/SKILL.md` — walk each element, fix any gaps where an implementer would need to guess.
 
 Present the written content to the user.
 
-**STOP — do not proceed until the user approves the new content.**
+**STOP** — do not proceed until the user approves.
 
 ---
 
 ## 5. Determine cascade scope
 
-Based on the entry point, determine which downstream layers have existing content that needs updating:
-
 | Entry Point | Cascade Layers (in order) |
 |-------------|---------------------------|
 | Vision | Architecture → IA → BE → FE → Phase plan |
 | Architecture | IA → BE → FE → Phase plan |
-| IA shard | BE spec for that shard → FE spec for that shard → Phase plan |
+| IA shard | BE spec → FE spec → Phase plan |
 | BE spec | FE → Phase plan |
-| Scope correction | Depends on the document — all layers below the corrected document |
-
-**Important**: When the entry point is an IA shard, the downstream cascade remains scoped to the affected domain shard's corresponding BE and FE specs. Do not cascade into unrelated domain shards unless the user explicitly broadens scope.
+| Scope correction | All layers below the corrected document |
 
-For each downstream layer, check whether content exists (using the same file checks as `/remediate-pipeline-assess` Step 1). Only layers with existing content need updating — layers that haven't been started yet will naturally incorporate the new content when they are written.
+Check each downstream layer for existing content. Only layers with existing content need updating.
 
 Report: "These layers have existing content that will need updating: [list]."
 
-If no downstream layers have content, report: "No downstream layers have existing content — the new content will be incorporated when those layers are written. Evolution complete."
+If no downstream layers have content: "No downstream layers have existing content — incorporated when written. Evolution complete."

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

@@ -17,102 +17,48 @@ pipeline:
 
 # Ideate — Discover
 
-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.
+Explore domains through recursive breadth-before-depth with the Deep Think protocol. Write to the fractal folder structure.
 
-**Prerequisite**: If invoked standalone, verify `docs/plans/ideation/ideation-index.md` exists with the fractal folder structure seeded. If this file does not exist → **STOP**: "Extraction output missing — the fractal folder structure has not been seeded. Run `/ideate-extract` first before proceeding to discovery." Do not proceed without this output.
+**Prerequisite**: If invoked standalone, verify `docs/plans/ideation/ideation-index.md` exists with the fractal folder structure seeded. If missing → **STOP**: "Run `/ideate-extract` first."
 
 ---
 
-## 3. Domain Exploration — Recursive Model
+## 2.4. Mid-shard resumption check
 
-Read `.agent/skills/idea-extraction/SKILL.md` — follow the Recursive Domain Exhaustion Protocol, Deep Think Protocol, Node Classification Gate, and Reactive Depth Protocol.
+Scan `docs/plans/ideation/` for existing domain folders and feature files.
 
-Read `## Expansion Mode` and `## Structural Classification` from `docs/plans/ideation/ideation-index.md`.
+- **If 0 domain folders exist** → fresh exploration. Proceed to Step 2.5.
+- **If domain folders exist but ideation-index.md `## Domain Map` is incomplete** (some domains listed but not all have `[DEEP]`/`[EXHAUSTED]`) → this is a resumed session. Log: "Resuming exploration. [N] of [M] domains already explored." Skip already-completed domains and continue from the first incomplete one.
+- **If all domains are marked `[DEEP]` or `[EXHAUSTED]`** → exploration is complete. Skip to Step 4 (problem exploration) if not yet done, otherwise skip to `/ideate-validate`.
 
 ## 2.5. Read Engagement Tier
 
-Read `## Engagement Tier` from `docs/plans/ideation/ideation-index.md`. Apply gate behavior rules for this session:
-
-| Tier | Structural gates (domain maps, classification, sub-domain structure) | Product gates (personas, MoSCoW, feature scope, competitive positioning) |
-|------|----------------------------------------------------------------------|-------------------------------------------------------------------------|
-| 🤖 **Auto** | Auto-confirm: apply Deep Think, write reasoning to feature files, proceed | Auto-confirm: apply Deep Think, write reasoning to feature files, proceed |
-| 🤝 **Hybrid** | Auto-confirm: apply Deep Think, write reasoning to feature files, proceed | **Pause for user**: present findings, wait for explicit confirmation |
-| 💬 **Interactive** | **Pause for user**: present findings, wait for explicit confirmation | **Pause for user**: present findings, wait for explicit confirmation |
-
-> [!IMPORTANT]
-> **Auto-confirmed gates must still write.** When a gate is auto-confirmed, the agent writes the Deep Think reasoning and decision to the relevant file immediately — just as if the user had confirmed it. The file trail must be identical regardless of tier. This ensures the Auto tier review checkpoint in `ideate-validate` has full traceability.
-
-### 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 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** *(structural)*: Present domain map. **Interactive/Hybrid**: User confirms before Level 1. **Auto**: Auto-confirm with Deep Think reasoning written to `ideation-index.md`.
-
-#### Level 1 — Domain Breadth Sweep
+Read `## Engagement Tier` from `docs/plans/ideation/ideation-index.md`.
 
-For each domain (dependency order — foundational first):
+- **If the section exists** → apply the specified tier.
+- **If the section is missing** → default to **Hybrid** tier. Warn: "Engagement tier not found in ideation-index.md. Defaulting to Hybrid. Override now or continue?"
+- **If the value is not one of Auto/Hybrid/Interactive** → **STOP**: "Invalid engagement tier '[value]' in ideation-index.md. Expected: Auto, Hybrid, or Interactive."
 
-1. List all sub-areas/capabilities within the domain
-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** *(structural)*: Pause after EACH domain. **Interactive/Hybrid**: "Here's what I mapped for [Domain]. Missing anything?" After ALL: "All domains at BREADTH. Ready to drill?" **Auto**: Auto-confirm with Deep Think reasoning written to domain index.
+Read `.agent/skills/prd-templates/references/engagement-tier-protocol.md` — apply the tier's gate behavior for structural gates and product gates throughout this shard.
 
-#### Level 2+ — Vertical Drilling
-
-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 (or auto-confirms for Auto tier) → mark `[EXHAUSTED]`
-10. Status propagation: all children `[EXHAUSTED]` → node is `[EXHAUSTED]`
-11. **Gate** *(product)*: Pause after each domain is drilled. **Interactive**: Full review. **Hybrid**: Pause for review. **Auto**: Auto-confirm with Deep Think reasoning written to domain index.
-
-#### Cross-Cut Synthesis (Continuous)
-
-Cross-cuts are identified continuously, but after all domains reach `[DEEP]`, do a final review:
-
-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
-
-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
+> [!IMPORTANT]
+> **Auto-confirmed gates must still write.** When a gate is auto-confirmed, the agent writes the Deep Think reasoning and decision to the relevant file immediately. The file trail must be identical regardless of tier.
 
-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.
+## 3. Domain Exploration — Recursive Model
 
-### Cross-cutting Mode (standalone)
+Read `.agent/skills/idea-extraction/SKILL.md` — follow the **Recursive Domain Exhaustion Protocol**, **Deep Think Protocol**, **Node Classification Gate**, and **Reactive Depth Protocol**.
 
-Read all CX files + feature files' cross-cut notes. Identify interaction points. Run synthesis questions on unresolved pairs. Document in appropriate CX files.
+Read `## Expansion Mode` and `## Structural Classification` from `docs/plans/ideation/ideation-index.md`.
 
-### Combination / As-is Mode
+Route to the correct exploration mode based on what was selected in `ideate-extract` Step 1.6.5:
 
-Combination: user specifies sequence. As-is: skip expansion, run exhaustion check, but still scan for obvious CX candidates.
+- **Full exploration** → Run Level 0 → Level 1 → Level 2+ as defined in `idea-extraction/SKILL.md` → `## Recursive Domain Exhaustion Protocol`. Apply tier-appropriate gate behavior at each level.
+- **Vertical** → Identify shallowest leaf nodes. Drive to `[DEEP]`/`[EXHAUSTED]` with Deep Think. Do not introduce new domains unless user requests.
+- **Horizontal** → Audit for missing domains with Deep Think. Create domain folders (with Classification Gate). Level 1 breadth sweep on each. Offer vertical drilling after.
+- **Cross-cutting** → Read all CX files + feature files. Identify interaction points. Run synthesis questions on unresolved pairs.
+- **Combination** → User specifies sequence.
+- **As-is** → Skip expansion, run exhaustion check, but still scan for obvious CX candidates.
+- **Audit ambiguity first** → Run inline ambiguity check, then select expansion mode based on results.
 
 ---
 
@@ -125,15 +71,7 @@ Read `.agent/skills/brainstorming/SKILL.md` and follow its methodology.
 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:
-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 absent → probe before proceeding. Reference: `.agent/skills/pipeline-rubrics/references/ideation-rubric.md` Dimension 2.
+**Persona completeness gate**: Read `.agent/skills/prd-templates/references/persona-completeness-gate.md`. Verify all 6 fields for every persona. If any field absent → probe before proceeding.
 
 ---
 
@@ -141,30 +79,81 @@ If any field absent → probe before proceeding. Reference: `.agent/skills/pipel
 
 ### 5a. Feature collection (MoSCoW)
 
-Read `.agent/skills/brainstorming/SKILL.md`.
+Read `.agent/skills/brainstorming/SKILL.md`. For each persona, brainstorm features across all 4 MoSCoW tiers. **Deep Think** for missing Must Haves.
 
-For each persona, brainstorm features across all 4 MoSCoW tiers. **Deep Think** for missing Must Haves.
+Write MoSCoW matrix to `ideation-index.md`. Each feature references its fractal path and links to its feature file.
 
-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.
+**0 Must Haves guard**: If the MoSCoW matrix contains 0 Must Have features → **STOP**: "No Must Have features identified. This indicates the problem statement or personas need refinement. Return to Step 4 and re-examine 'What problem are we solving?' with deeper probing before continuing."
 
-### 5b. Feature deepening — Must Haves
+### 5a.5. Adjacent Feature Analysis (gap surfacing)
+
+After the MoSCoW matrix is populated, reason about what's **conspicuously absent** given everything known about the product:
 
-For each Must Have feature, use the recursive model:
+1. **Domain reasoning**: Given the product type (e.g., e-commerce, SaaS, marketplace), enumerate the standard feature categories expected in this space. Compare against the MoSCoW matrix. List any standard categories with zero features.
+2. **Persona reasoning**: For each persona, ask: "What does this persona need to accomplish their goal that isn't covered by any feature?" List unmet persona needs.
+3. **Workflow reasoning**: Trace each persona's end-to-end workflow. Identify any step where the user would need to leave the product to accomplish something — each gap is a potential missing feature.
+4. **Competitive reasoning**: Read `meta/competitive-landscape.md`. For each competitor capability listed, verify a corresponding feature exists. List competitive gaps.
 
-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.
+**Present findings as suggestions, not mandates**:
 
-**Deep Think at each level.** Write results to feature files using `fractal-feature-template.md`.
+> 🔍 **Features you might not have thought of:**
+>
+> Based on [product type] and your personas:
+> - [Feature A] — [why it fits: persona X needs this for workflow step Y]
+> - [Feature B] — [why it fits: standard in this space, competitors X and Y have it]
+> - [Feature C] — [why it fits: gap in persona Z's end-to-end workflow]
+>
+> Want to add any of these? They'd enter the MoSCoW matrix for prioritization.
+
+**STOP** — wait for user response. For each accepted feature:
+1. Add to the MoSCoW matrix at the user's chosen priority
+2. Create a feature file in the appropriate domain folder
+3. Continue to Step 5b with the expanded feature set
+
+For rejected features: note in `ideation-index.md` under a `## Considered & Rejected` section with the reason, so future sessions don't re-suggest them.
+
+### 5b. Feature deepening — Must Haves
+
+For each Must Have feature, use the recursive model from `idea-extraction/SKILL.md`:
+1. **Level 1**: Sub-features. Run Classification Gate — sub-domain or feature?
+2. **Level 2**: Edge cases and failure modes. Fill feature file sections per `fractal-feature-template.md`.
+3. **Level 3** (complex features): Cross-cuts with evidence → parent CX file.
+
+**Deep Think at each level.** Write results to feature files.
 
 ### 5c. Feature deepening — Should Haves (lighter touch)
 
 Level 1 (sub-features) only with Deep Think. Full treatment deferred to `/create-prd`.
 
+### 5d. Cross-Cut Synthesis Sweep (mandatory)
+
+After all features are deepened, systematically identify emergent capabilities that arise when features **combine**:
+
+1. **Build a feature interaction matrix**: List all Must Have and Should Have features on both axes. For each pair, ask: "When a user has both of these, does something new become possible that neither feature provides alone?"
+2. **Identify emergent capabilities**: For each interesting pair (or triplet), describe the emergent capability.
+   - Example: Feature "AI diagnostics" + Feature "Supplier catalog" → emergent: "AI-recommended parts ordering" — the diagnostic identifies the failed part AND the catalog knows who sells it, enabling one-click ordering.
+3. **Classify each emergent capability**:
+   - **Already captured** → a feature or sub-feature already covers this. Note the link.
+   - **New cross-cut** → write to the parent domain's CX file. Flag for user review.
+   - **New feature entirely** → present to user for MoSCoW placement.
+4. **Present all findings**:
+
+> 🔗 **Cross-cutting opportunities discovered:**
+>
+> | Features Combined | Emergent Capability | Status |
+> |---|---|---|
+> | [A] + [B] | [What becomes possible] | New cross-cut / New feature / Already captured |
+>
+> These emerged from how your features interact — they're capabilities you get "for free" if you build them with this interaction in mind.
+
+**STOP** — wait for user response. Write accepted cross-cuts to CX files immediately. Add accepted new features to MoSCoW matrix.
+
+> **Minimum coverage**: The sweep must evaluate at least every Must Have × Must Have pair and every Must Have × Should Have pair. Should Have × Should Have pairs are optional but recommended for complex products.
+
 ---
 
-### Propose next step
+### Next step
 
-Proceed to `/ideate-validate` for exhaustion check, constraint exploration, and vision compilation.
+**STOP** — do NOT proceed to any other workflow. The only valid next step is `/ideate-validate`.
 
-> If standalone, surface via `notify_user`. If from parent `/ideate`, natural handoff.
+> If invoked standalone, surface this via `notify_user` and wait for user confirmation before running `/ideate-validate`.