cfsa-antigravity 2.0.0 → 2.2.0

package/template/AGENTS.md

@@ -76,12 +76,16 @@ Once a stage is locked, downstream stages may not contradict it. To change a loc
 | ↳ | `/evolve-feature-classify` | Feature description | Classified change + new content at entry point | Evolution |
 | ↳ | `/evolve-feature-cascade` | Classified change + entry point | Layer-by-layer additions + implementation impact | Evolution |
 | 8 | `/plan-phase` | Architecture + specs | Dependency-ordered TDD slices | Planning |
+| ↳ | `/plan-phase-preflight` | Approved specs | Phase gate + completeness audit + consistency check | Planning |
+| ↳ | `/plan-phase-write` | Preflight pass | Slices + acceptance criteria + progress files | Planning |
 | 9 | `/implement-slice` | Slice acceptance criteria | Working code via Red→Green→Refactor | Implementation |
 | ↳ | `/implement-slice-setup` | Slice from phase plan | Progress check + skills + contracts + parallel mode | Implementation |
 | ↳ | `/implement-slice-tdd` | Contract + tests | Red→Green→Refactor + validation + progress tracking | Implementation |
 | 9.5 | `/verify-infrastructure` | Implemented infra or auth slice | Operational verification report | Verification |
 | 10 | `/validate-phase` | Completed phase | Full validation gate | Verification |
-| 11 | `/evolve-contract` | Changed Zod schema | Safe schema migration | Maintenance |
+| ↳ | `/validate-phase-quality` | Completed phase | Code quality gates — tests, coverage, lint, type-check, build, CI/CD, staging, migrations, spec coverage | Verification |
+| ↳ | `/validate-phase-readiness` | Quality gates passed | Production readiness gates — API docs, accessibility, performance, security, dependency audit, results | Verification |
+| 11 | `/evolve-contract` | Changed `{{CONTRACT_LIBRARY}}` schema | Safe schema migration | Maintenance |
 
 > **Note**: Rows marked with ↳ are independently-invocable sub-workflows (shards)
 > of their parent command. The parent orchestrates them in sequence, but each shard
@@ -173,4 +177,4 @@ graph TD
 
 ### Mandatory Validation
 
-**CRITICAL:** Run `{{VALIDATION_COMMAND}}` after **EVERY** code change. Do not finish a task until all pass.
+**CRITICAL:** Run the Validation Cmd from `.agent/instructions/commands.md` after **EVERY** code change. Do not finish a task until all pass.

package/template/GEMINI.md

@@ -81,9 +81,11 @@ Once a stage is locked, downstream stages may not contradict it. To change a loc
 | 9 | `/implement-slice` | Slice acceptance criteria | Working code via Red→Green→Refactor | Implementation |
 | ↳ | `/implement-slice-setup` | Slice from phase plan | Progress check + skills + contracts + parallel mode | Implementation |
 | ↳ | `/implement-slice-tdd` | Contract + tests | Red→Green→Refactor + validation + progress tracking | Implementation |
-| 9.5 | `/verify-infrastructure` | Implemented infra or auth slice | Operational verification report | Verification |
+| 7.5 | `/verify-infrastructure` | Implemented infra or auth slice | Operational verification report | Verification |
 | 10 | `/validate-phase` | Completed phase | Full validation gate | Verification |
-| 11 | `/evolve-contract` | Changed Zod schema | Safe schema migration | Maintenance |
+| ↳ | `/validate-phase-quality` | Completed phase | Code quality gates — tests, coverage, lint, type-check, build, CI/CD, staging, migrations, spec coverage | Verification |
+| ↳ | `/validate-phase-readiness` | Quality gates passed | Production readiness gates — API docs, accessibility, performance, security, dependency audit, results | Verification |
+| 11 | `/evolve-contract` | Changed `{{CONTRACT_LIBRARY}}` schema | Safe schema migration | Maintenance |
 
 
 > **Note**: Rows marked with ↳ are independently-invocable sub-workflows (shards)
@@ -176,4 +178,4 @@ graph TD
 
 ### Mandatory Validation
 
-**CRITICAL:** Run `{{VALIDATION_COMMAND}}` after **EVERY** code change. Do not finish a task until all pass.
+**CRITICAL:** Run the Validation Cmd from `.agent/instructions/commands.md` after **EVERY** code change. Do not finish a task until all pass.

package/template/docs/README.md

@@ -35,19 +35,19 @@ The pipeline is a linear sequence of commands. Each step tells you what to run n
       You describe your idea (or point to a document with @file).
       The pipeline explores your idea using recursive breadth-before-depth:
         - Level 0: Maps all domains in your product
-        - Level 1: Sweeps sub-areas within each domain
+        - Level 1: Sweeps each domain for sub-areas (Classification Gate: sub-domain folder or feature file?)
         - Level 2+: Drills vertically until each domain is exhausted
       At every level, a Deep Think protocol generates hypotheses based on
       domain knowledge — "Based on this industry, I'd expect X. Is that relevant?"
-      Cross-cutting concerns are tracked continuously in a dedicated ledger.
-      Each domain gets its own file the moment it's discovered (shard-as-you-go).
-
-      Output: docs/plans/ideation/ folder:
-                ideation-index.md   ← pipeline key file (domain map, MoSCoW, coverage)
-                domains/*.md        ← one file per domain
-                meta/*.md           ← problem, personas, constraints, competitive landscape
-                cross-cuts/         ← cross-cut ledger
-              docs/plans/vision.md  ← human-readable executive summary (not a pipeline input)
+      Cross-cutting concerns are tracked at the level where they occur (CX files).
+      Each domain gets its own folder the moment it's discovered (fractal-as-you-go).
+
+      Output: docs/plans/ideation/ folder (fractal tree):
+                ideation-index.md      ← pipeline key file (structure map, MoSCoW, coverage)
+                ideation-cx.md         ← global cross-cuts
+                domains/*/             ← domain folders (index + CX + feature files)
+                meta/*.md              ← problem, personas, constraints, competitive landscape
+              docs/plans/vision.md     ← human-readable executive summary (not a pipeline input)
 
     Step 2: /audit-ambiguity ideation  ── MANDATORY ──
       Scores the ideation folder against a 12-dimension rubric.

package/template/docs/kit-architecture.md

@@ -15,14 +15,16 @@ The intelligence of the kit lives entirely within the `.agent/` directory.
 ├── instructions/    # Core directives (the "brainstem")
 ├── progress/        # State and memory (the "hippocampus")
 ├── rules/           # Non-negotiable constraints (the "laws")
-├── skills/          # Reusable capabilities (the "tools")
+├── skill-library/   # Installable skill packages (the "toolbox")
+├── skills/          # Active capabilities (the "tools")
 └── workflows/       # Structured processes (the "playbooks")
 ```
 
 ### Core Components
 
-*   **Instructions:** (`workflow.md`, `tech-stack.md`, `structure.md`, `patterns.md`, etc.) Baseline knowledge the agent needs to operate in the specific environment. These files ship as templates with `{{PLACEHOLDER}}` markers — they are not static files. The bootstrap system fills them progressively as tech decisions are confirmed during `/create-prd`. An instruction file with unfilled placeholders is a broken agent context. `workflow.md` enforces the mandatory execution sequence: Understand Context -> Check Skills -> Execute -> Validate.
+*   **Instructions:** (`workflow.md`, `tech-stack.md`, `structure.md`, `patterns.md`, `commands.md`) Baseline knowledge the agent needs to operate in the specific environment. These files ship as templates with `{{PLACEHOLDER}}` markers — they are not static files. The bootstrap system fills them progressively as tech decisions are confirmed during `/create-prd`. An instruction file with unfilled placeholders is a broken agent context. `workflow.md` enforces the mandatory execution sequence: Understand Context -> Check Skills -> Execute -> Validate.
 *   **Rules:** Preemptively loaded constraints that apply to *every* task. Includes security best practices (`security-first.md`), TDD mandates (`tdd-contract-first.md`), and vertical-slice enforcement (`vertical-slices.md`).
+*   **Skill Library:** (`.agent/skill-library/`) Installable skill packages organized by category (e.g., `stack/databases/`, `stack/frontend-frameworks/`). Skills are provisioned from here into `.agent/skills/` by the bootstrap system when tech decisions are confirmed. Contains `MANIFEST.md` with the full taxonomy.
 *   **Skills:** Modular capabilities (e.g., `technical-writer`, `brainstorming`). Agents load these explicitly when a task requires them, preventing context bloat.
 *   **Workflows:** Step-by-step markdown checklists invoked via `/slash-commands` (e.g., `/create-prd`, `/implement-slice`). They chain skills together to achieve complex, multi-stage goals.
 
@@ -30,36 +32,87 @@ The intelligence of the kit lives entirely within the `.agent/` directory.
 
 ## 2. Ideation Architecture
 
-The ideation layer is the pipeline's first output and the source of truth for all downstream specification work. It replaces the former monolithic `vision.md` approach with a sharded folder structure that scales with project complexity.
+The ideation layer is the pipeline's first output and the source of truth for all downstream specification work. It uses a **fractal folder structure** — every node (surface, domain, sub-domain) is a folder containing an index file, a cross-cut (CX) file, and its children. Leaf nodes are `.md` feature files. This pattern is universal regardless of project complexity.
 
 ### Pipeline Key File
 
-`docs/plans/ideation/ideation-index.md` is the **pipeline key file** — the primary entry point for all downstream workflows. When `/create-prd`, `/decompose-architecture`, or any specification workflow needs to understand the product, it reads `ideation-index.md` first, then follows links to relevant domain files for detail.
+`docs/plans/ideation/ideation-index.md` is the **pipeline key file** — the primary entry point for all downstream workflows. When `/create-prd`, `/decompose-architecture`, or any specification workflow needs to understand the product, it reads `ideation-index.md` first, then follows links into the fractal tree.
 
 `docs/plans/vision.md` still exists but is a **human-readable executive summary** only — a sales pitch compiled from the ideation folder. No downstream workflow reads it as a data source.
 
-### Folder Structure
+### Structural Classification (4 Project Shapes)
+
+During `/ideate-extract`, every project is classified into one of four shapes that governs folder layout:
+
+| Shape | When | Folder Pattern |
+|-------|------|----------------|
+| `single-surface` | One surface (e.g., web app only) | Flat `domains/` at top level |
+| `multi-surface-shared` | Multiple surfaces sharing the same backend (e.g., web + mobile) | Flat `domains/` with surface annotations in feature files |
+| `multi-product-hub` | One primary surface owns most logic; others consume it | Primary surface's folder owns shared domains; others reference them |
+| `multi-product-peer` | Independent products with shared infrastructure | `shared/` folder for shared domains; surface folders for exclusive domains |
+
+### Fractal Folder Structure
 
 ```text
 docs/plans/ideation/
-├── ideation-index.md          # Pipeline key file — domain map, MoSCoW summary, coverage
-├── domains/                   # One file per product domain
-│   ├── user-management.md
-│   ├── billing.md
-│   └── ...
+├── ideation-index.md          # Super-index — shape, structure map, MoSCoW, progress
+├── ideation-cx.md             # Global CX — cross-surface interactions (if multi-product)
+├── domains/                   # Top-level domains (single/multi-surface-shared)
+│   ├── 01-user-management/    # Each domain is a FOLDER, not a file
+│   │   ├── user-management-index.md   # Children table, Role Matrix, decisions
+│   │   ├── user-management-cx.md      # Cross-cuts between this domain's children
+│   │   ├── 01-registration.md         # Leaf feature file (Role Lens, behavior, edge cases)
+│   │   ├── 02-authentication/         # Sub-domain (promoted from feature if complex)
+│   │   │   ├── authentication-index.md
+│   │   │   ├── authentication-cx.md
+│   │   │   ├── 01-login.md
+│   │   │   └── 02-password-reset.md
+│   │   └── 03-roles.md
+│   └── 02-billing/
+│       ├── billing-index.md
+│       ├── billing-cx.md
+│       └── ...
 ├── meta/                      # Structured metadata
 │   ├── problem-statement.md
 │   ├── personas.md
 │   ├── constraints.md
 │   └── competitive-landscape.md
-└── cross-cuts/                # Cross-cutting concern tracking
-    └── cross-cut-ledger.md
+└── [surfaces/]                # Only for multi-product-hub or multi-product-peer
+    ├── web/
+    │   ├── web-index.md
+    │   ├── web-cx.md
+    │   └── 01-dashboard/...
+    └── mobile/
+        ├── mobile-index.md
+        ├── mobile-cx.md
+        └── 01-notifications/...
 ```
 
 **Key properties:**
-- **Shard-as-you-go**: Domain files are created the moment a domain is identified during exploration, not batched after all exploration is complete
-- **Living documents**: Domain files and the index are updated in place as exploration deepens — they are never dated (see Dated File Convention below)
-- **Downstream consumers**: `/create-prd` reads `ideation-index.md` + `meta/constraints.md`; `/decompose-architecture` reads `ideation-index.md` + domain files; specification workflows reference domain files for sub-feature detail
+- **Fractal pattern**: Every folder has an index + CX file. Every leaf is a feature `.md` file. This is universal — no exceptions.
+- **Reactive depth**: Folders are created during exploration when complexity is discovered, not pre-scaffolded. A feature file can be promoted to a sub-domain folder if it reveals internal complexity.
+- **Numbering**: Children are numbered `{NN}-{slug}` within their parent. Paths are expressed as dot-separated (e.g., `01.02.03` = domain 01, sub-domain 02, feature 03).
+- **Soft depth limit**: 4 levels recommended. Level 5 triggers a user prompt to confirm structured complexity isn't runaway nesting.
+
+### Role Integration
+
+Roles (personas) are defined once in `meta/personas.md` and then referenced at every level of the tree:
+
+| Location | What | Purpose |
+|----------|------|---------|
+| `meta/personas.md` | Full persona definitions (6 fields each) | Single source of truth |
+| Node index files | **Role Matrix** — which personas access which children | Structural overview of role coverage |
+| Feature files | **Role Lens** — per-persona behavior details | Downstream input for IA/BE/FE multitenancy specs |
+
+### Node Classification Gate
+
+Before creating any new node (domain, sub-domain, or feature), the agent runs a classification gate:
+
+1. **What is it?** — Domain (top-level concept), sub-domain (2+ interacting capabilities), or feature (single capability)
+2. **Where does it go?** — Surface-exclusive, hub-owned, shared, or top-level (depends on project shape)
+3. **Does it already exist?** — Check for duplicates before creating
+
+This prevents incorrect domain placement — the primary failure mode of the old flat structure.
 
 ### Exploration Model
 
@@ -67,20 +120,20 @@ The `/ideate` workflow uses **recursive breadth-before-depth exploration**:
 
 | Level | Scope | What happens |
 |---|---|---|
-| **Level 0** | Global domain map | Identify all top-level domains in the product. Each gets a file in `domains/`. |
-| **Level 1** | Sub-area sweep per domain | For each domain, identify all sub-areas. Mark each with a depth status marker. |
-| **Level 2+** | Vertical drilling | Drill into each sub-area until no new information emerges. Recursion: new domains discovered during drilling loop back to Level 0. |
+| **Level 0** | Global domain map | Identify all top-level domains. Run Classification Gate for each. Create domain folders. |
+| **Level 1** | Domain breadth sweep | For each domain, identify sub-areas. Classification Gate: sub-domain folder or feature file? Update Role Matrix. |
+| **Level 2+** | Vertical drilling | Drill each child. Fill feature files (Role Lens, behavior, edge cases). Promote features to sub-domains if complex. |
 
-Each domain file tracks its sub-areas with status markers:
+Each node tracks its status:
 
 | Marker | Meaning |
 |---|---|
 | `[SURFACE]` | Identified but unexplored |
-| `[BREADTH]` | Sub-areas listed, not detailed |
+| `[BREADTH]` | Children listed, not detailed |
 | `[DEEP]` | Core logic, edge cases, interactions documented |
 | `[EXHAUSTED]` | Deep Think yielded nothing new — domain complete |
 
-A domain reaches `[EXHAUSTED]` only when the Deep Think protocol generates no new hypotheses.
+Status propagates upward: a node is `[EXHAUSTED]` only when ALL its children are `[EXHAUSTED]`.
 
 ### Deep Think Protocol
 
@@ -88,14 +141,30 @@ At every exploration level, the agent actively generates hypotheses:
 
 > *"Based on [industry knowledge / domain patterns / cross-domain interaction], I'd expect [feature/concern/edge case]. Is that relevant to your product?"*
 
-Hypotheses are tracked in domain files with resolution status (confirmed/rejected/deferred). This prevents shallow exploration — the agent doesn't just record what the user says, it actively probes for what the user hasn't mentioned yet.
+Hypotheses are tracked in feature files with resolution status (confirmed/rejected/deferred). This prevents shallow exploration — the agent doesn't just record what the user says, it actively probes for what the user hasn't mentioned yet.
+
+### Hierarchical Cross-Cuts
+
+Cross-cutting concerns are tracked **at the level where they occur**, not in a single flat ledger:
 
-### Cross-Cut Ledger
+| CX File Location | What It Tracks |
+|-----------------|----------------|
+| `ideation-cx.md` (global) | Cross-surface interactions (multi-product only) |
+| `{surface}-cx.md` | Cross-domain interactions within a surface |
+| `{domain}-cx.md` | Cross-sub-domain interactions within a domain |
+| `{sub-domain}-cx.md` | Cross-feature interactions within a sub-domain |
 
-Cross-cutting concerns (security, notifications, analytics, error handling, etc.) are tracked continuously in `cross-cuts/cross-cut-ledger.md` as they're discovered at any level, not batched into a separate pass. Each entry includes:
-- Which domains are involved
-- Confidence level (increases as exploration deepens)
-- Resolution status
+Each CX entry includes which nodes interact, confidence level, 5 synthesis questions (trigger, data, flow, failure, scope), role scoping, and rejected pairs with reasoning.
+
+### Downstream Consumption
+
+| Consumer | What It Reads |
+|----------|--------------|
+| `/create-prd` | `ideation-index.md` + `meta/constraints.md` |
+| `/decompose-architecture` | `ideation-index.md` + domain indexes (walks fractal tree for shard boundary signals: depth, child count, CX density, Role Matrix) |
+| Spec workflows | Domain indexes + feature files for sub-feature detail |
+
+> **Important**: Ideation does NOT prescribe shard boundaries. `/decompose-architecture` reads the fractal tree and makes architectural decisions about where to draw shard lines.
 
 ---
 
@@ -136,7 +205,7 @@ This directory acts as the agent's long-term and working memory.
 
 ### Cross-references
 
-- **Dated File Convention** — See below in this section (Section 2) — governs which artifact paths use glob patterns vs. hardcoded names.
+- **Dated File Convention** — See below in this section (Section 3) — governs which artifact paths use glob patterns vs. hardcoded names.
 - **Placeholder Verification Gate Protocol** — See Section 4.5 — governs the Step 0 guard that prevents workflows from reading `{{PLACEHOLDER}}`-dependent skills before bootstrap has run.
 - **Kit Maintenance Checklist** — See Section 6 — governs what must be updated when new workflows or skills are added.
 - **Surface Model** — `.agent/skills/prd-templates/references/surface-model.md` — The authoritative reference for surface types (web/mobile/cli/etc.) and implementation layers, and how the two models relate.
@@ -183,6 +252,29 @@ Workflow files declare skills in two places with different semantics:
 
 **Leaf workflows (shards)** should have body reads that match their frontmatter — if a skill is listed in a shard's frontmatter, the shard body should contain a corresponding `Read` instruction.
 
+### Shared References (`prd-templates/references/`)
+
+The `prd-templates` skill contains a `references/` directory with 23 shared reference files that are consumed by multiple workflows. These references eliminate content duplication by centralizing:
+
+| Reference Category | Examples | Used By |
+|---|---|---|
+| **Document templates** | `architecture-design-template.md`, `be-spec-template.md`, `fe-spec-template.md` | Spec and PRD writing workflows |
+| **Shared policies** | `tdd-testing-policy.md`, `slice-completion-gates.md` | Implementation and validation workflows |
+| **Classification procedures** | `fe-classification-procedures.md`, `placeholder-guard-template.md` | Classify shards of spec workflows |
+| **Design system** | `design-system-decisions.md`, `design-system-prerequisite-check.md` | FE spec and PRD workflows |
+| **Cross-cutting protocols** | `skill-loading-protocol.md`, `spec-coverage-sweep.md`, `surface-model.md` | 15+ workflows |
+
+When a workflow needs a policy, template, or procedure, it references the shared file rather than inlining the content. This keeps workflows focused on orchestration logic and keeps shared policies maintainable in one place.
+
+### Skill Loading Protocol
+
+Workflows that need stack-specific skills (Languages, Databases, FE Frameworks, etc.) reference `.agent/skills/prd-templates/references/skill-loading-protocol.md` instead of repeating the loading instructions inline. The protocol centralizes:
+
+- How to read the surface stack map in `tech-stack.md`
+- Which skill categories to load per workflow
+- The missing-skill fallback procedure
+- Surface stack map verification before loading
+
 ---
 
 ## 4.5. Bootstrap System
@@ -224,10 +316,11 @@ Two distinct gate types enforce placeholder readiness at different pipeline stag
 
 | Gate type | Where it runs | When | Purpose |
 |---|---|---|---|
-| **Spec-phase gate** | Step 0 of specification workflows (`create-prd-architecture`, `write-architecture-spec-design`, `write-fe-spec-classify`) | Before any skill reads | Guard spec authoring from unfilled stack placeholders |
-| **Implementation-phase gate** | `/implement-slice-setup` Step -1 | Before any code is written | Guard code generation from broken agent context across all seven instruction files |
+| **Spec-phase gate** | Step 0 of specification workflows (`write-architecture-spec-design`, `write-be-spec-classify`, `write-fe-spec-classify`) | Before any skill reads | Guard spec authoring from unfilled stack placeholders |
+| **Planning-phase gate** | `/plan-phase-write` | Before slice planning | Guard phase planning from unfilled CI/CD and Hosting skill placeholders |
+| **Implementation-phase gate** | `/implement-slice-setup` Step -1 | Before any code is written | Guard code generation from broken agent context across all five instruction files |
 
-Both gates emit a **four-part hard stop message** per unfilled placeholder:
+All three gates emit a **four-part hard stop message** per unfilled placeholder:
 
 1. **Which exact `{{PLACEHOLDER}}` is unfilled** — the literal placeholder name
 2. **Which pipeline stage fills it** — the `/create-prd-stack` decision that triggers bootstrap
@@ -242,7 +335,7 @@ For detailed per-workflow placeholder mappings and recovery commands, see `.agen
 
 ### Implementation-Phase Placeholder Gate
 
-Before any implementation begins, `/implement-slice-setup` (Step -1) scans all seven instruction files for unfilled `{{` patterns. If any are found, implementation stops with a specific remediation path per file. This gate is the last line of defense against broken agent context reaching the implementation phase.
+Before any implementation begins, `/implement-slice-setup` (Step -1) scans all five instruction files for unfilled `{{` patterns. If any are found, implementation stops with a specific remediation path per file. This gate is the last line of defense against broken agent context reaching the implementation phase.
 
 ---
 
@@ -252,7 +345,7 @@ Before any implementation begins, `/implement-slice-setup` (Step -1) scans all s
 
 The defining architectural pattern of the code produced by this kit.
 
-1.  **Contract (Zod):** Define the schema first.
+1.  **Contract ({{CONTRACT_LIBRARY}}):** Define the schema first.
 2.  **Tests (Failing):** Write tests that assert against the contract.
 3.  **Implementation:** Write the code to make the tests pass.
 

package/template/docs/plans/ideation/README.md

@@ -8,11 +8,16 @@ Ideation output created by `/ideate` — the pipeline's source of truth for prod
 
 ## Structure
 
-| Directory | Description |
+The ideation folder uses a **fractal folder structure** — every domain is a folder containing an index file (`*-index.md`), a cross-cut file (`*-cx.md`), and child feature `.md` files. Sub-domains are nested folders following the same pattern.
+
+| Path | Description |
 |---|---|
-| `domains/` | One file per domain, created during `/ideate-discover` as domains are explored |
+| `ideation-index.md` | Pipeline key file — structural classification, structure map, MoSCoW, progress |
+| `ideation-cx.md` | Global cross-cuts (cross-surface interactions for multi-product projects) |
+| `domains/` | Fractal domain folders — each containing index + CX + child features/sub-domains |
 | `meta/` | Structured metadata — problem statement, personas, constraints, competitive landscape |
-| `cross-cuts/` | Cross-cutting concern ledger, accumulated continuously during exploration |
+
+> See `docs/kit-architecture.md` Section 2 for the full tree diagram and detailed documentation.
 
 ## Completion Requirement
 

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

@@ -1,55 +0,0 @@
-# Domain: {{DOMAIN_NAME}}
-
-> **Status**: `[SURFACE]` / `[BREADTH]` / `[DEEP]` / `[EXHAUSTED]`
-> **Domain number**: NN
-> **Last updated**: _timestamp_
-
-## Overview
-
-_What this domain is, why it exists, what problem it solves within the product._
-
-## Sub-Area Breadth Map
-
-Map all sub-areas before drilling any of them. Status markers track progress.
-
-| # | Sub-Area | Status | Sub-Topics | Deep Think |
-|---|----------|--------|------------|------------|
-| 1 | _Sub-area name_ | `[SURFACE]` | _N_ | _N hypotheses_ |
-| 2 | _Sub-area name_ | `[SURFACE]` | _N_ | _N hypotheses_ |
-
-## Sub-Area Detail
-
-### 1. {{Sub-Area Name}}
-
-**Status**: `[SURFACE]` / `[BREADTH]` / `[DEEP]` / `[EXHAUSTED]`
-
-#### Exploration
-
-_Vertical drill content — features, behaviors, edge cases, failure modes._
-
-#### Deep Think Annotations
-
-| Hypothesis | Source | Outcome |
-|-----------|--------|---------|
-| _"[X] likely needed because [Y]"_ | Agent domain knowledge | ✅ CONFIRMED / ❌ REJECTED |
-
-#### Cross-Cut Notes
-
-- Touches **Domain NN** ([domain-file.md](../domains/NN-domain.md)) because: _reason_
-- Touches **Domain NN** ([domain-file.md](../domains/NN-domain.md)) because: _reason_
-
----
-
-_Repeat the Sub-Area Detail section for each sub-area._
-
-## Domain-Level Decisions
-
-| # | Decision | Context |
-|---|----------|---------|
-| _D#_ | _Decision_ | _Why this was decided_ |
-
-## Open Questions
-
-| # | Question | Owner | Deferred To |
-|---|----------|-------|-------------|
-| 1 | _Question_ | User / Agent / `/create-prd` | _Stage_ |