cfsa-antigravity 2.7.0 → 2.9.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cfsa-antigravity",
-  "version": "2.7.0",
+  "version": "2.9.0",
   "description": "CFSA Pipeline — Constraint-First Specification Architecture for AI agents. Production-grade from line one.",
   "scripts": {
     "changeset": "changeset",

package/template/.agent/kit-sync.md

@@ -1,6 +1,6 @@
 # Kit Sync State
 
 upstream: https://github.com/RepairYourTech/cfsa-antigravity
-last_synced_commit: b0f13b49de8b5d929395c6974898ae091a6cf252
-last_synced_at: 2026-03-17T01:44:25Z
-kit_version: 2.7.0
+last_synced_commit: 9f4ba4f09f8234f0e81f568f66f6394148c0e383
+last_synced_at: 2026-03-17T05:20:16Z
+kit_version: 2.9.0

package/template/.agent/skills/idea-extraction/SKILL.md

@@ -124,9 +124,10 @@ When processing a document, scan for these signals before creating any domain fi
 
 When hub-and-spoke is identified:
 
-- **The hub surface owns shared domains.** Device History, Payments, Certification — these live INSIDE the hub surface's domain tree, not in a separate `shared/` folder.
+- **The hub surface owns shared API/data domains.** Device History, Payments, Certification — these live INSIDE the hub surface's domain tree, not in a separate `shared/` folder.
 - **Spoke surfaces reference hub domains via CX.** Desktop's CX files say "Feature X consumes web/domain/feature via API."
-- **The hub surface tends to be the largest.** This is expected and correct.
+- **Spoke surfaces own their operational domains.** A domain belongs on the surface where it is **primarily experienced and operated**, not where the data lives. POS is a desktop domain even though it calls the hub's Stripe API. Inventory is a desktop domain even though it syncs to the hub's database.
+- **Proportionality check**: The hub may have more domains than any single spoke, but spokes must reflect the FULL experience their users have. If a spoke user's daily workflow involves 10+ distinct capabilities, 2-3 domains is a red flag — re-examine whether concepts were incorrectly collapsed into the hub.
 
 ### Peer Mode Implications
 
@@ -159,19 +160,35 @@ Does it belong to an EXISTING domain or sub-domain?
      │            │
      │           NO ──► It's a FEATURE ──► create .md file inside existing parent
      │
-    NO ──► Is it surface-exclusive?
+    NO ──► (Surface Placement — two questions, not one)
               │
-             YES ──► It's a new DOMAIN ──► create domain folder in the correct surface
+              Q1: "Where is this PRIMARILY experienced/operated?"
+              │    (Which surface's user interacts with this most?)
               │
-             NO ──► Is there a hub surface that owns this kind of logic?
-                       │
-                      YES ──► It lives in the HUB surface ──► create domain in hub + CX from spokes
-                       │
-                      NO ──► It's a shared domain ──► create in shared/
+              Q2: "Which hub APIs does it consume?"
+              │    (What data/services does it call from the hub?)
+              │
+              ├── Primarily experienced on a SPOKE surface
+              │     ──► It's a SPOKE DOMAIN ──► create in that spoke surface
+              │     ──► Log hub API dependencies in CX (Q2 answer)
+              │
+              ├── Primarily experienced on the HUB surface
+              │     ──► It's a HUB DOMAIN ──► create in hub surface
+              │
+              ├── No primary surface (pure API/data layer, no direct user interaction)
+              │     ──► It's a HUB DOMAIN (infrastructure) ──► create in hub
+              │
+              └── Equally used across multiple surfaces (rare)
+                    ──► It's a shared domain ──► create in shared/ (peer) or hub (hub-and-spoke)
 
 **WHEN UNCERTAIN: Ask the user.** Never assume placement.
 ```
 
+> **Key principle**: A domain belongs where it is PRIMARILY USED, not where the data lives.
+> POS is a desktop domain even though payments go through the hub's Stripe API.
+> Inventory is a desktop domain even though stock data is in the hub's database.
+> The hub API dependency is logged as a CX reference, not as a classification signal.
+
 ### Sub-Domain vs Feature Test
 
 The key question: **"Does this thing have its own internal features that interact with each other?"**
@@ -187,7 +204,8 @@ The key question: **"Does this thing have its own internal features that interac
 
 | ❌ Wrong | ✅ Right |
 |----------|---------|
-| Creating "Supplier Integration" as a new domain | Recognizing it's a feature within AI Assistant, cross-cutting to web's Supplier Accounts |
+| Creating "Print Receipt" as a new domain | Recognizing it's a feature within POS/Payments |
+| Classifying POS as a hub domain because it calls Stripe | Classifying POS as a desktop domain because the shop tech primarily operates it there |
 | Creating a domain for every feature mentioned | Grouping related features under their parent domain/sub-domain |
 | Pre-creating 4 levels of empty folders | Creating depth reactively as complexity is discovered |
 | Putting a shared domain in `shared/` when hub-and-spoke is active | Putting it inside the hub surface, with CX references from spokes |
@@ -196,6 +214,7 @@ The key question: **"Does this thing have its own internal features that interac
 | Collapsing a rich multi-system area into a single domain | Recognizing 2+ interacting capabilities = sub-domain or promoted domain |
 | Creating "Data Architecture" or "Tech Stack" as product domains | Noting architectural concerns for `/create-prd` — they are not product domains |
 | Creating folders before presenting the classification to the user | Always presenting the classification table and getting user confirmation first |
+| Classifying everything that touches the hub API as a hub domain | Using the "primarily experienced" test — hub API usage = CX, not classification |
 
 ---
 
@@ -283,6 +302,12 @@ Before starting, classify what the user has provided and select the right mode.
 > and document structure tell you where to LOOK for concepts. They do NOT tell you what those
 > concepts ARE (domain, sub-domain, feature, cross-cut, or not-a-product-domain). The Node
 > Classification Gate determines what each concept is. NEVER mirror source headings as domains.
+>
+> **Document surface signals ARE classification input.** When a concept appears WITHIN a
+> surface-specific section of the document (e.g., "Shop Software", "Mobile App", "Desktop"),
+> that is a strong signal for surface placement. The section heading doesn't dictate the
+> domain NAME, but it DOES inform which surface the concept is primarily experienced on.
+> Use this as input to the "primarily experienced" question in the classification gate.
 
 **Process — Phase 1: Interview the Document** (silent — no user interaction)
 
@@ -293,22 +318,25 @@ Before starting, classify what the user has provided and select the right mode.
    - Source location (line numbers or section reference — this is the citation)
    - What the document says about it (summary of the content)
    - How many distinct interacting capabilities it contains (the sub-domain test)
-   - Whether it is surface-exclusive, shared, or cross-cutting
+   - Which surface section of the document it appeared in (if any) — this is a surface placement signal
+   - Whether it is cross-cutting (affects multiple domains regardless of surface)
    Do NOT use source document headings as concept names unless they happen to be accurate after classification. The concept name must reflect what the thing actually IS after gate analysis.
 4. **BLOCKING GATE — Classify every concept.** Run the Node Classification Gate on EACH extracted concept individually. For each concept, answer the gate questions explicitly:
    - "Does it belong to an EXISTING domain?" → if YES, it's a sub-domain or feature of that domain
    - "Does it have 2+ distinct capabilities that interact with each other?" → if YES, it's a sub-domain (folder); if NO, it's a feature (file)
-   - "Is it surface-exclusive?" → determines placement
+   - "Where is this PRIMARILY experienced/operated?" → determines surface placement
+   - "Which hub APIs does it consume?" → logged as CX, NOT as classification signal
    - "Is it an architectural concern, not a product domain?" → note for `/create-prd`, do NOT create a domain
    - "Is it a cross-cutting concern?" → log in CX files, do NOT create a domain
    Produce a **classification table**:
 
-   | Concept | Source Location | Gate Result | Reasoning |
-   |---------|----------------|-------------|----------|
-   | Inventory System | lines 982–1017 | Sub-domain of Shop Software | 4+ interacting capabilities (purgatory model, alerts, visibility, pre-auth billing) |
-   | In-Platform Messaging | lines 759–788 | Feature of Consumer Platform | Single capability with role-based routing, no internal sub-features |
-   | Data Architecture | lines 1261–1282 | NOT a product domain | Architectural concern — database selection, sync strategy → note for /create-prd |
-   | Analytics & Insights | lines 730–758 | Cross-cutting concern | Three tiers serving all domains, no exclusive features of its own |
+   | Concept | Source Location | Gate Result | Primary Surface | Also Used On | Reasoning |
+   |---------|----------------|-------------|----------------|-------------|----------|
+   | Inventory System | lines 982–1017 (§Shop Software) | Sub-domain of Shop Operations | Desktop | Web (read-only dashboard) | 4+ interacting capabilities, primarily operated by shop tech at the counter |
+   | POS / Payments | lines 1018–1050 (§Shop Software) | Domain in Desktop | Desktop | Hub (Stripe API) | Shop tech runs transactions at register; hub provides payment processing API |
+   | In-Platform Messaging | lines 759–788 | Feature of Consumer Platform | Web | Mobile | Single capability with role-based routing, no internal sub-features |
+   | Data Architecture | lines 1261–1282 | NOT a product domain | — | — | Architectural concern — database selection, sync strategy → note for /create-prd |
+   | Analytics & Insights | lines 730–758 | Cross-cutting concern | — | All surfaces | Three tiers serving all domains, no exclusive features of its own |
 
 5. **BLOCKING GATE — Build proposed domain map.** From the classification table, group concepts into a proposed domain hierarchy:
    - Only concepts classified as **domain** become domain folders
@@ -316,6 +344,21 @@ Before starting, classify what the user has provided and select the right mode.
    - Concepts classified as **feature** become leaf files inside their parent
    - Concepts classified as **cross-cut** go in the appropriate CX files
    - Concepts classified as **not-a-product-domain** are noted in `meta/constraints.md` for `/create-prd`
+
+5.5. **BLOCKING GATE — Surface Distribution Audit.** Before presenting to the user, verify the classification didn't starve any spoke:
+
+   For each spoke surface:
+   1. List all concepts the document describes within that surface's sections
+   2. Count how many were classified as spoke domains vs. hub domains
+   3. For each hub-classified concept that appeared in a spoke section: **re-run the "primarily experienced" test**. If the concept is primarily operated on the spoke, reclassify it as a spoke domain with hub CX
+   4. **Red flag**: If a spoke has fewer than 5 domains AND the document dedicates 100+ lines to that spoke → the classification is likely wrong. Re-examine every concept from that spoke section
+
+5.6. **Spoke Persona Walk-Through.** For each spoke surface, identify its primary persona(s) and mentally walk through their daily workflow:
+   - "If I'm a [persona] sitting at the [surface], what are ALL the things I do in a typical day?"
+   - Enumerate every distinct workflow: each workflow with 2+ interacting capabilities is a candidate spoke domain
+   - Cross-reference against the classification table: any daily workflow capability that was classified as hub is suspect
+   - Reclassify as needed — the walk-through is the final validation before presenting to user
+
 6. **Identify gaps** — interview questions the document doesn't answer. These become Phase 2 interview questions.
 
 **Process — Phase 2: Present and Interview the User**

package/template/.agent/skills/prd-templates/references/architecture-completeness-checklist.md

@@ -0,0 +1,28 @@
+# Architecture Completeness Checklist
+
+Apply after the architecture rubric self-check. All items must pass.
+
+## Feature Coverage
+- [ ] Every "Must Have" feature from `ideation-index.md` MoSCoW list has a home in the architecture
+
+## Security Coverage
+- [ ] Security model addresses all compliance constraints from `ideation/meta/constraints.md`
+- [ ] Compliance-heavy domains have their own top-level sections (not buried as sub-bullets)
+
+## Stack Coverage
+- [ ] All relevant skills installed for chosen stack
+
+## Standards Coverage
+- [ ] Validation command in Engineering Standards matches `AGENTS.md` validation command
+
+## Multi-Surface (if applicable)
+- [ ] Sync strategy defined
+- [ ] Data ownership clear
+- [ ] Conflict resolution specified
+
+## Cross-Platform (if applicable)
+- [ ] Platform-specific considerations documented for each target OS
+
+## Design System
+- [ ] Design system document exists at `docs/plans/design-system.md`
+- [ ] All seven decision areas are filled (no placeholders)

package/template/.agent/skills/prd-templates/references/be-spec-classification.md

@@ -0,0 +1,41 @@
+# BE Spec Classification Guide
+
+Use when classifying an IA shard during `/write-be-spec-classify` Step 2.
+
+## Classification Types
+
+| Classification | Description | BE Spec Output | Detection Criteria |
+|---------------|-------------|----------------|-------------------|
+| **Feature domain** | Defines user interactions, data models, and API-facing behavior for a single cohesive domain | 1 BE spec | Has data model + user flows + access model that imply API endpoints |
+| **Multi-domain** | Covers multiple distinct backend sub-systems with independent APIs | N BE specs (split along sub-feature boundaries) | Section headers map to independent API surfaces; data models don't overlap; could be developed by different teams |
+| **Cross-cutting** | Defines shared patterns consumed by all feature specs (auth, API conventions, error handling) | 1 cross-cutting BE spec (`00-*`) | Content is about "how all endpoints work" not "what this feature does" |
+| **Structural reference** | Maps structure, naming, or routing without defining API behavior | 0 BE specs | No data model, no user flows, no endpoints — just reference tables |
+| **Composite** | Contains both a structural reference section AND feature behavior | Depends — feature portion may belong in another shard's BE spec | Look for cross-references pointing feature content to its owning domain |
+
+## Multi-Domain Split Heuristic
+
+Before classifying as multi-domain, build a **sub-feature endpoint inventory**:
+
+| Sub-feature | Expected endpoints | Data model(s) | Independent? |
+|-------------|-------------------|---------------|-------------|
+| [sub-feature] | `POST /api/...`, `GET /api/...` | [table/collection names] | [Yes/No] |
+
+**Split criterion**: Two or more independent groups each have their own data model and could be assigned to a different developer without coordination → split. Section header count alone is NOT the criterion — independence of data models and API surfaces is.
+
+## Endpoint Completeness Reconciliation Table
+
+Use during `/write-be-spec-write` Step 7 before writing spec sections:
+
+| Sub-feature | Expected endpoints | Specced? | Notes |
+|-------------|-------------------|----------|-------|
+| [sub-feature] | `POST /api/...` | ✅ | — |
+| [sub-feature] | `GET /api/...` | ❌ | [Deferred to Phase N — reason] |
+
+**Rule**: For every unspecced expected endpoint, either add it to the spec or add an explicit `[Deferred to Phase N — reason]` note. An empty Notes column for an unspecced endpoint is a spec failure.
+
+## Naming Convention
+
+- Same number prefix as the IA shard source
+- Kebab-case feature name
+- Multi-domain splits: append letter suffix (e.g., `09a-chat-api.md`, `09b-agent-flow-api.md`)
+- Cross-cutting specs: `00-` prefix (e.g., `00-api-conventions.md`)

package/template/.agent/skills/prd-templates/references/bootstrap-verification-protocol.md

@@ -0,0 +1,50 @@
+# Bootstrap Verification Protocol
+
+**Purpose**: Every bootstrap invocation MUST be verified. This protocol replaces all inline "fire bootstrap" instructions with a hard-gated fire→verify→stop cycle.
+
+---
+
+## Procedure
+
+### 1. Fire
+
+Read `.agent/workflows/bootstrap-agents.md` and execute with the provided key(s).
+
+### 2. Verify
+
+After bootstrap returns, verify that the target was actually filled:
+
+| Key Type | Where to Verify | How to Verify |
+|----------|----------------|---------------|
+| Language/Framework/DB/ORM | Surface stack map in `.agent/instructions/tech-stack.md` | The cell for the provided key's surface row is no longer empty |
+| CI/CD, Hosting, Auth, Security | Cross-cutting section of surface stack map | The cell is no longer empty |
+| Design direction | `.agent/skills/brand-guidelines/SKILL.md` | `{{DESIGN_DIRECTION}}` no longer appears as literal text |
+| Project structure | `.agent/instructions/structure.md` | `{{PROJECT_STRUCTURE}}` no longer appears as literal text |
+| Dev tooling | `.agent/instructions/commands.md` | Template values are replaced with real commands |
+| New dependency skill | `.agent/skills/[skill-name]/SKILL.md` | The skill directory exists and `SKILL.md` is readable |
+
+### 3. Hard Gate
+
+> **HARD STOP** — If any verification check fails, do NOT proceed. Report to the user:
+>
+> "Bootstrap was invoked with `[KEY]=[VALUE]` but verification failed:
+> - Expected `[target file]` cell `[cell name]` to contain `[VALUE]`
+> - Actual: `[what was found — empty, still placeholder, etc.]`
+>
+> This is a bootstrap bug. Do not proceed until resolved."
+
+### 4. Log
+
+After successful verification, note in the current workflow step: `Bootstrap verified: [KEY]=[VALUE] → [target cell] confirmed filled.`
+
+---
+
+## When to Use
+
+Any workflow step that says:
+- "fire bootstrap"
+- "invoke `/bootstrap-agents`"
+- "execute bootstrap"
+- "read bootstrap-agents.md and execute"
+
+MUST follow this protocol. There are no exceptions. A bootstrap fire without verification is an enforcement failure.

package/template/.agent/skills/prd-templates/references/constraint-exploration.md

@@ -0,0 +1,41 @@
+# Constraint Exploration Questions
+
+Use during `/ideate-validate` Step 8 to explore constraints with the user. Write answers to `docs/plans/ideation/meta/constraints.md`.
+
+## Core Constraint Categories
+
+1. **Budget** — Self-funded? VC-backed? Monthly infrastructure ceiling?
+2. **Timeline** — Launch target? Phased rollout?
+3. **Team** — Solo dev? Small team? Skill gaps?
+4. **Compliance** — GDPR, PCI, COPPA, HIPAA, SOC 2? Age restrictions?
+5. **Performance** — Expected scale (users, requests, data)? Latency requirements?
+6. **Surface classification validation** — Verify the structural classification from `ideation-index.md` (set in `ideate-extract` Step 1.3) still holds. Have any new surfaces been discovered during exploration? Has the project shape changed?
+
+## Deep Think Prompt
+
+> "Based on the product type and user personas, what constraints would I expect that haven't been mentioned? For example, does this product handle payments (PCI)? Does it serve minors (COPPA)? Does it store health data (HIPAA)?"
+
+## Tier-Specific Behavior
+
+| Tier | Behavior |
+|---|---|
+| **Interactive/Hybrid** | Present each constraint question to user, wait for answers. Write each confirmed constraint immediately. |
+| **Auto** | Self-interview using Deep Think. Write all answers with reasoning immediately. Mark each answer as `[AUTO-CONFIRMED]` for traceability. |
+
+## Success Metrics (Per Persona)
+
+For each persona, define concrete success metrics:
+- What metric proves this product solves the persona's problem?
+- What's the target number? (specific — not "good response times")
+- What's the measurement method?
+
+Write to `ideation-index.md` (or link to domain files where the metric applies).
+
+## Competitive Positioning
+
+If not already explored during `/ideate-discover`:
+- Name 2-4 direct competitors
+- For each: what they do well, where they fail, how we differentiate
+- What's the moat? (network effects, data, expertise, switching costs)
+
+Write to `docs/plans/ideation/meta/competitive-landscape.md`.

package/template/.agent/skills/prd-templates/references/decision-confirmation-protocol.md

@@ -0,0 +1,68 @@
+# Decision Confirmation Protocol
+
+**Purpose**: Every decision that gets written to a spec or instruction file MUST be explicitly confirmed before writing. This protocol replaces all "refine based on discussion" patterns.
+
+---
+
+## Procedure
+
+### 1. Present
+
+Present the decision to the user with:
+- The specific question or choice
+- Your recommendation and reasoning
+- The options (if applicable)
+- Where the decision will be written (file + section)
+
+### 2. Wait for Confirmation
+
+**HARD GATE** — Do NOT write anything until the user explicitly confirms.
+
+Acceptable confirmations: explicit "yes", "approved", "confirmed", "go ahead", "looks good", selection of an option, or equivalent affirmative.
+
+NOT acceptable: silence, moving on to other topics, ambiguous responses. If ambiguous → ask again.
+
+### 3. Handle Requests for Changes
+
+If the user requests changes:
+1. Apply the requested changes to your proposed content
+2. Re-present the updated version
+3. Return to Step 2 — wait for confirmation again
+
+Do NOT write a partially-confirmed version. The full content must be confirmed before writing.
+
+### 4. Write
+
+After confirmation, write the decision to the target file + section.
+
+### 5. Verify Write
+
+Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`):
+- Read back the target file
+- Verify the section header exists and content matches what was confirmed
+- If missing or mismatched → write failed, retry
+
+---
+
+## Tier-Aware Variant (for /create-prd workflows)
+
+When the current engagement tier is known:
+
+| Tier | Behavior |
+|------|----------|
+| **Interactive** | Full present → wait → confirm → write cycle per decision |
+| **Hybrid** | Group related decisions, present batch, confirm batch, write batch |
+| **Auto** | Use Deep Think reasoning, write with `[AUTO-CONFIRMED]` tag, present all auto-confirmed decisions for batch review at end of shard |
+
+**Even in Auto mode**, the user reviews and can reject auto-confirmed decisions at the batch review step. Rejection triggers re-presentation at Interactive tier for that decision.
+
+---
+
+## What This Replaces
+
+This protocol replaces all instances of:
+
+> ~~"Refine based on discussion before proceeding"~~
+> ~~"Adjust based on feedback"~~
+
+Those patterns allow agents to skip refinement and write unconfirmed content. This protocol requires explicit confirmation before any write.

package/template/.agent/skills/prd-templates/references/decision-propagation.md

@@ -0,0 +1,121 @@
+# Decision Propagation Reference
+
+Templates, formats, and scan procedures for `/propagate-decision` workflows.
+
+## Decision Type Sources
+
+| Decision Type | Source Document | Downstream Scope |
+|--------------|-----------------|-------------------|
+| **structure** | `.agent/instructions/structure.md` | All IA shards, BE specs, FE specs |
+| **tech-stack** | `.agent/instructions/tech-stack.md` + architecture doc | All IA shards, BE specs, FE specs |
+| **auth-model** | Architecture doc (auth/security section) | All BE specs with middleware, all FE specs with auth flows |
+| **data-placement** | `docs/plans/data-placement-strategy.md` | All IA shards with data models, all BE specs with storage |
+| **patterns** | `.agent/instructions/patterns.md` | All IA shards, BE specs with implementation patterns, FE specs with component patterns |
+| **error-architecture** | Architecture doc `## Error Architecture` (5 sub-sections) | All BE specs, all FE specs |
+
+## Selection Menu Format
+
+```
+Decision propagation pre-scan:
+
+[1] structure — structure.md — inconsistencies detected in X documents
+[2] tech-stack — tech-stack.md — inconsistencies detected in X documents
+[3] auth-model — architecture doc — inconsistencies detected in X documents
+[4] data-placement — data-placement-strategy.md — inconsistencies detected in X documents
+[5] patterns — patterns.md — inconsistencies detected in X documents
+[6] error-architecture — architecture doc ## Error Architecture — inconsistencies detected in X documents
+
+[A] All with inconsistencies
+[Q] Quit — no propagation needed
+```
+
+## Error-Architecture Scan Procedure
+
+**Source extraction:**
+- Locate `docs/plans/*-architecture-design.md` using glob
+- Read `## Error Architecture` and extract locked decisions from: `### Global Error Envelope`, `### Error Propagation Chain`, `### Unhandled Exception Strategy`, `### Client Fallback Contract`, `### Error Boundary Strategy`
+
+**BE spec conformance** (scan `docs/plans/be/`):
+- Check error envelope by locked name and canonical field names
+- Check propagation chain rules
+- Classify: explicit contradiction / implicit assumption / consistent
+
+**FE spec conformance** (scan `docs/plans/fe/`):
+- Check client fallback contract for surface type
+- Check error boundary placement
+- Same classification
+
+## Contradiction Display Format
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Contradiction N of X
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Document: [path]
+Section:  [section name]
+Current:  [current text]
+Locked:   [locked value]
+Fix to:   [proposed fix]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+[Y] Apply fix and move to next
+[n] Skip this item
+[skip] Skip entire document
+[stop-and-save] Save progress and stop
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+## Assumption Display Format
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Assumption N of X
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Document: [path]
+Section:  [section name]
+Current:  [current text]
+Issue:    [ambiguity description]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+[Y] Flag for /resolve-ambiguity
+[n] Ignore
+[skip] Skip entire document
+[stop-and-save] Save progress and stop
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+## Impact Report Format
+
+### Explicit Contradictions
+
+| Document | Line | Current Text | Locked Value | Decision Type |
+|----------|------|--------------|--------------|---------------|
+| [path] | [N] | [text] | [value] | [type] |
+
+### Implicit Assumptions
+
+| Document | Line | Current Text | Concern | Decision Type |
+|----------|------|--------------|---------|---------------|
+| [path] | [N] | [text] | [concern] | [type] |
+
+### Summary
+
+- **Explicit contradictions**: X items across Y documents
+- **Implicit assumptions**: X items across Y documents
+- **Consistent references**: X items (no action needed)
+
+## Completion Summary Format
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Propagation Complete
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Fixed:   X contradictions across Y documents
+Flagged: X implicit assumptions for /resolve-ambiguity
+Skipped: X items
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Recommended next steps:
+1. Run `/resolve-ambiguity` to address the X flagged assumptions
+   (see docs/audits/propagation-ambiguity-[date].md)
+2. Run `/remediate-pipeline` to audit all layers with the corrected specs
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```

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

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

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

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