cfsa-antigravity 2.7.0 → 2.9.0

package/template/.agent/skills/prd-templates/references/evolution-layer-guidance.md

@@ -0,0 +1,91 @@
+# Evolution Layer Guidance
+
+Reference for `/evolve-feature-classify` Step 4 and `/evolve-feature-cascade` Step 1 — specifies what to write at each pipeline layer when evolving a feature.
+
+## Entry Point Writing Depth
+
+### Ideation Layer (`docs/plans/ideation/`)
+
+1. **Placement**: Read `ideation-index.md` Structure Map. Identify the domain folder. Create new domain if needed.
+2. **Classification Gate**: Apply Node Classification Gate from `.agent/skills/idea-extraction/SKILL.md` — leaf feature or sub-domain folder.
+3. **Write**: Use `.agent/skills/prd-templates/references/fractal-feature-template.md`. Include:
+   - Feature description (what and why)
+   - Affected personas
+   - Success criteria
+   - Constraints
+   - Role Lens — which personas interact and how
+4. **Update parent index**: Add to parent domain's `*-index.md` children table
+5. **Update CX files**: If cross-domain interactions exist, update parent `*-cx.md` and/or `ideation-cx.md`
+6. **Update `ideation-index.md`**: Add to MoSCoW Summary at appropriate priority
+
+### Architecture Layer (`architecture-design.md`)
+
+- Technical constraint description
+- Affected components
+- Non-functional requirements (performance, scalability, compliance)
+- Integration points
+
+### IA Layer (specific IA shard)
+
+- Domain interactions (new/modified user flows)
+- Contracts (new/modified API contracts)
+- Data models (new entities, fields, relationships)
+- Access control (RBAC implications)
+
+### BE Layer (BE spec)
+
+- New API endpoints
+- Updated schemas
+- Middleware requirements
+- Validation rules
+
+### FE Layer (FE spec)
+
+- New components
+- State management updates
+- New routes
+- Accessibility requirements
+
+### Phase Plan
+
+- New slices or updated slice acceptance criteria
+
+## Cascade Layer Guidance
+
+When cascading through downstream layers in `/evolve-feature-cascade`:
+
+| Layer | What to Add |
+|-------|------------|
+| Architecture | New components, system diagram references, NFRs, integration points |
+| IA | New domain interactions, updated contracts, data model changes, access control updates |
+| BE | New API endpoints, updated schemas, middleware requirements, validation rules |
+| FE | New components, state management updates, new routes, accessibility requirements |
+| Phase plan | New slices or updated slice acceptance criteria |
+
+## Impact Assessment Format
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+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]
+
+Recommended action: [specific next step]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+## Completion Summary Format
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Feature Evolution Complete
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Entry point:       [document]
+Layers updated:    [list]
+New content:       [summary]
+Implementation:    [impact summary]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```

package/template/.agent/skills/prd-templates/references/expansion-modes.md

@@ -0,0 +1,27 @@
+# Expansion Mode Options
+
+Present these options after engagement tier selection. All input types see the same options.
+
+| # | Mode | When to Recommend | Description |
+|---|------|-------------------|-------------|
+| 1 | **Full exploration** | 3+ domains | Breadth-before-depth with Deep Think |
+| 2 | **Process as-is** | Thin input where user is confident | Proceed with what's captured |
+| 3 | **Expand vertically** | Domains exist but are shallow | Drill deeper into existing features |
+| 4 | **Expand horizontally** | Domains are deep but coverage gaps exist | Add new domains |
+| 5 | **Cross-cutting concerns** | Domains mapped but interactions unexplored | Map feature interactions |
+| 6 | **Combination** | User has specific priorities | User specifies dimensions and order |
+| 7 | **Audit ambiguity first** | Unclear whether depth or breadth is needed | Inline ambiguity check before deciding |
+
+## Default Recommendations
+
+| Input Type | Default |
+|---|---|
+| Rich document (≥3 domains) | Full exploration |
+| Rich document (<3 domains) | Expand vertically |
+| Thin document | Full exploration |
+| Verbal / one-liner | Full exploration |
+| Re-run (continue) | Audit ambiguity first |
+
+## Recording
+
+Write the selected mode to `ideation-index.md` under `## Expansion Mode` immediately after user selection.

package/template/.agent/skills/prd-templates/references/folder-seeding-protocol.md

@@ -0,0 +1,77 @@
+# Folder Seeding Protocol
+
+Rules for creating the `docs/plans/ideation/` folder structure during `/ideate-extract`.
+
+## Additive-Only Rule
+
+The `docs/plans/ideation/` directory already exists in the kit with `.gitkeep` and `README.md`. You are ADDING files into this existing directory.
+
+- Do NOT delete, overwrite, or replace the directory itself
+- Do NOT remove any existing files (`.gitkeep`, `README.md`)
+- Create new files alongside what already exists
+
+## Base Structure (All Project Shapes)
+
+After seeding, the folder should contain kit-shipped files PLUS new pipeline files:
+
+```
+docs/plans/ideation/
+├── .gitkeep                ← KIT-SHIPPED — do not touch
+├── README.md               ← KIT-SHIPPED — do not touch
+├── ideation-index.md       ← NEW: super-index (from ideation-index-template)
+├── ideation-cx.md          ← NEW: global cross-cuts (from ideation-crosscut-template)
+└── meta/                   ← NEW: created by this step
+    ├── problem-statement.md
+    ├── personas.md
+    ├── competitive-landscape.md
+    └── constraints.md
+```
+
+For multi-product projects, additionally create `surfaces/` with sub-folders per surface.
+
+## Templates
+
+Read these templates when creating files:
+
+- `.agent/skills/prd-templates/references/ideation-index-template.md` (super-index)
+- `.agent/skills/prd-templates/references/ideation-crosscut-template.md` (global CX)
+- `.agent/skills/prd-templates/references/fractal-node-index-template.md` (node index)
+- `.agent/skills/prd-templates/references/fractal-cx-template.md` (node CX)
+- `.agent/skills/prd-templates/references/fractal-feature-template.md` (feature file)
+
+## Domain Seeding Rules
+
+Domains come from the **confirmed classification table** (Step 1.4.5), NOT from source headings.
+
+### Placement by Structural Classification
+
+| Classification | Placement |
+|---|---|
+| Single-surface | `docs/plans/ideation/{NN}-{slug}/` |
+| Hub-and-spoke | Surface-exclusive in `surfaces/{surface}/{NN}-{slug}/`, shared in hub surface |
+| Peer | Surface-exclusive in `surfaces/{surface}/{NN}-{slug}/`, shared in `shared/{NN}-{slug}/` |
+
+### Node Type → Action
+
+| Gate Result | Action |
+|---|---|
+| **Domain** | Create domain folder with `{slug}-index.md` + `{slug}-cx.md` |
+| **Sub-domain** | Create sub-domain folder nested inside parent domain |
+| **Feature** | Create feature file inside parent domain or sub-domain |
+| **Cross-cut** | Add entries to appropriate CX files (domain-level or global) |
+| **Not-a-product-domain** | Add notes to `meta/constraints.md` for `/create-prd` |
+
+After all nodes are created, update `ideation-index.md` structure map with paths.
+
+## Content Seeding by Input Type
+
+| Input Type | Content Strategy |
+|---|---|
+| **Rich document** | Seed each node with content from source using classification table citations. Run fidelity check: every major concept in source must map to SOMETHING in the output. Add `> Source: path/to/original.md` to index. |
+| **Chat transcript** | Noise filter → extract signal → seed domain folders with structured output |
+| **Thin document** | Create domain folders with depth markers on feature files |
+| **Verbal / one-liner** | Create domain folders with scaffolding. Feature files are `[SURFACE]`. |
+
+## Post-Seeding Verification Gate
+
+After creating all files, verify that `docs/plans/ideation/.gitkeep` and `docs/plans/ideation/README.md` still exist. If EITHER file is missing → **STOP**: "Kit-shipped files were destroyed during seeding. Restore `.gitkeep` and/or `README.md` to `docs/plans/ideation/` before continuing."

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

@@ -0,0 +1,23 @@
+# Input Classification Table
+
+Classify user-provided input to determine which mode the `idea-extraction` skill operates in.
+
+| Input Type | Detection Criteria | Extraction Mode |
+|---|---|---|
+| **Rich document** | >5KB, detailed docs, design conversations, prior specs | Extraction |
+| **Thin document** | <5KB, structured but shallow (bullet list, rough PRD) | Expansion |
+| **Conversational dump** | Chat logs, unstructured conversation transcripts | Extraction (with noise filtering) |
+| **Verbal / one-liner** | User describes idea in chat, no files | Interview |
+| **Nothing** | "I want to build an app" or similar zero-context input | Interview (deep) |
+
+## Mode References
+
+Each mode's full process is defined in `.agent/skills/idea-extraction/SKILL.md`:
+
+- **Extraction Mode** → `## Input-Adaptive Modes → Extraction Mode — Rich Input`
+- **Expansion Mode** → `## Input-Adaptive Modes → Expansion Mode — Thin Input`
+- **Interview Mode** → `## Input-Adaptive Modes → Interview Mode — No Input / One-Liner`
+
+## Proportionality Rule (Extraction Mode only)
+
+If source input > 50KB, total ideation output must be ≥ 30% of source line count.

package/template/.agent/skills/prd-templates/references/map-guard-protocol.md

@@ -0,0 +1,44 @@
+# Map Guard Protocol
+
+**Purpose**: Enforce strict surface stack map verification before any workflow step that depends on tech stack decisions. No timing fallbacks. No conversation-confirmed values.
+
+---
+
+## Procedure
+
+### 1. Read the Map
+
+Read the surface stack map from `.agent/instructions/tech-stack.md`.
+
+### 2. Check Required Cells
+
+For the current workflow, verify that every cell the workflow depends on is filled (non-empty, no `{{PLACEHOLDER}}` literal).
+
+Required cells vary by workflow — check the `requires_placeholders` frontmatter of the current workflow file, or the specific cells referenced in the workflow steps.
+
+### 3. Hard Gate
+
+**If ANY required cell is empty:**
+
+> **HARD STOP** — The surface stack map has empty cells required by this workflow.
+>
+> | Empty Cell | Recovery |
+> |---|---|
+> | Languages / Databases / Frameworks | Run `/create-prd-stack` |
+> | Auth / Security | Run `/create-prd-security` |
+> | CI/CD / Hosting | Run `/create-prd-stack` (dev tooling axis) |
+> | Commands section | Run `/bootstrap-agents` |
+> | `structure.md` | Run `/create-prd-compile` Step 9.5 |
+> | `patterns.md` | Run `/bootstrap-agents-provision` |
+>
+> Do NOT proceed. Do NOT use conversation-confirmed values. Do NOT apply timing fallbacks. If the cell should have been filled by a previous workflow step, the previous step has a bug — surface it.
+
+---
+
+## What This Replaces
+
+This protocol replaces all instances of the timing fallback pattern:
+
+> ~~"If a cell is empty but the value was just confirmed in the current conversation... proceed using the conversation-confirmed value"~~
+
+That pattern is **permanently banned**. It creates an escape hatch that allows agents to bypass map guards entirely. If a cell is empty, the upstream workflow that should have filled it has a bug. Surface the bug, don't work around it.

package/template/.agent/skills/prd-templates/references/persona-completeness-gate.md

@@ -0,0 +1,20 @@
+# Persona Completeness Gate
+
+Applies to every persona in `meta/personas.md` during ideation.
+
+## Required Fields (6)
+
+Every persona must have all 6 fields populated before proceeding past persona exploration:
+
+1. **Name + specific role** — not generic ("Shop Owner" not "User")
+2. **Specific pain point** — the problem this product solves for them
+3. **Current workaround** — how they solve it today without this product
+4. **Success criteria** — what "solved" looks like for them (measurable)
+5. **Switching trigger** — what event would make them adopt this product
+6. **Edge case or constraint** — at least one thing unique to this persona (regulatory, workflow, scale)
+
+## Enforcement
+
+If any field is absent for any persona → probe the user before proceeding.
+
+Reference: `.agent/skills/pipeline-rubrics/references/ideation-rubric.md` Dimension 2.

package/template/.agent/skills/prd-templates/references/shard-boundary-analysis.md

@@ -0,0 +1,76 @@
+# Shard Boundary Analysis
+
+Reference data for the decompose-architecture workflow — shard boundary heuristics, load thresholds, classification types, and split proposal format.
+
+## Fractal Tree Signals for Shard Boundaries
+
+| Signal | What It Means for Sharding |
+|--------|---------------------------|
+| Deep fractal tree (3+ levels) | Domain is complex enough for its own shard |
+| Many children (5+ features) | Consider splitting into multiple shards |
+| Dense CX file (5+ cross-cuts) | High coupling — keep together in one shard, or isolate carefully |
+| Rich Role Matrix (3+ roles with access) | Shard needs multi-role IA spec coverage |
+| Hub-and-spoke shared domains | Shared domains often become `00-*` cross-cutting shards |
+| Leaf features marked `[EXHAUSTED]` | Most confident for shard scoping — behavior is fully defined |
+
+## Standard Boundary Heuristics
+
+- Features that share the same data models belong together
+- Features that can be developed/deployed independently are candidates for separation
+- Features that share the same access control model may belong together
+- Cross-cutting concerns (auth, API conventions, error handling) become `00-*` shards
+
+## Shard Load Thresholds (Pre-check from Ideation)
+
+| Ideation Sub-Areas | Pre-Check Action |
+|---|---|
+| ≤6 | ✅ No concern — proceed |
+| 7–9 | ⚠️ **Pre-flag for split review** — note in the shard skeleton |
+| ≥10 | 🚩 **Proactive split proposal** — present to user NOW before calibration gate |
+
+## Sub-feature Count Thresholds (Calibration Gate)
+
+Count sub-features using the **bullet/named-item rule**: count every bullet or named item under `## Features`, excluding group headers that introduce a group but are not themselves a concrete capability. Sub-bullets count independently. Test: "Would a product manager list this as a separate line item in a release note?"
+
+| Sub-feature Count | Action |
+|-------------------|--------|
+| **≤6** | ✅ OK — proceed |
+| **7–9** | ⚠️ Flag for user review — present sub-feature list and ask: "Keep as-is, or split?" |
+| **≥10** | 🛑 **Hard stop** — present mandatory split proposal. No shard may exit with ≥10 sub-features. |
+
+## Shard Document Type Classification
+
+| Classification | Expected BE Specs |
+|---------------|-------------------|
+| **Feature domain** | 1 |
+| **Multi-domain** | N (split along sub-feature boundaries) |
+| **Cross-cutting** | 1 (`00-*`) |
+| **Structural reference** | 0 |
+
+Annotation format for shard skeletons:
+```markdown
+> **Document Type** (preliminary): Feature domain | Multi-domain | Cross-cutting | Structural reference
+```
+
+## Split Proposal Format
+
+When a shard exceeds the ≥10 threshold:
+
+```
+Shard [NN] — [domain name] has [N] sub-features (threshold: ≥10 → mandatory split)
+
+Current sub-features:
+  1. [sub-feature]
+  2. [sub-feature]
+  ...
+
+Proposed split:
+  [NN]a — [new domain name] → file: docs/plans/ia/[NN]a-[domain].md
+    Sub-features: 1, 3, 5
+  [NN]b — [new domain name] → file: docs/plans/ia/[NN]b-[domain].md
+    Sub-features: 2, 4, 6
+
+Split rationale: [why these groups are independent]
+```
+
+**After any split**: Update `docs/plans/ia/decomposition-plan.md` with the revised table and re-run the Must Have coverage gate.

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

@@ -0,0 +1,57 @@
+# Write Verification Protocol
+
+**Purpose**: Every file write MUST be verified by reading the file back. This protocol eliminates the ~18 instances of "write the completed section" without verification.
+
+---
+
+## Procedure
+
+### 1. Write
+
+Write the content to the target file at the specified section.
+
+### 2. Read Back
+
+Immediately after writing, read the target file. Locate the section header that was just written.
+
+### 3. Verify
+
+Check ALL of these conditions:
+
+- [ ] The section header exists in the file
+- [ ] The section content is non-empty (not just a header with no body)
+- [ ] The content matches what was intended (key fields present, no truncation)
+
+### 4. Handle Failure
+
+**If ANY check fails:**
+
+1. Log: "Write verification failed for `[file]` section `[section]`."
+2. Retry the write once.
+3. Read back again and re-verify.
+4. If second attempt fails → **STOP**: "Unable to write `[section]` to `[file]` after 2 attempts. Investigate before proceeding."
+
+### 5. Confirm
+
+After successful verification, log: `Write verified: [file] § [section]`
+
+---
+
+## When to Use
+
+Any workflow step that says:
+- "Write the completed [section]"
+- "Write [content] to [file]"
+- "Update [file] with [content]"
+- "Append [content] to [file]"
+
+MUST follow this protocol. There are no exceptions. A write instruction without read-back verification is an enforcement failure.
+
+---
+
+## Scope
+
+This protocol applies to **spec and instruction file writes** — the documents that drive downstream pipeline behavior. It does NOT apply to:
+- Progress tracking file writes (those have their own verification in the completion checklist)
+- Temporary/scratch files
+- Audit report writes (those are progressive and self-verifying)

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

@@ -24,23 +24,17 @@ Design the high-level system architecture and data strategy. Create the data pla
 
 ## 0. Map guard
 
-Read the surface stack map from `.agent/instructions/tech-stack.md`. Check the following columns/categories for filled values:
+Follow the map guard protocol (`.agent/skills/prd-templates/references/map-guard-protocol.md`). Required cells for this shard:
 
-| Map Location | Column/Category | Recovery | Why this matters |
-|---|---|---|---|
-| Cross-Cutting | Hosting | Run `/create-prd-stack` to confirm hosting provider, then bootstrap. | Deployment topology (Step 4.3) needs hosting-specific conventions. |
-| Per-Surface (shared) | ORMs | Run `/create-prd-stack` to confirm ORM, then bootstrap. | Migration strategy (Step 5.4) needs ORM-specific schema conventions. |
-| Per-Surface (shared) | Databases | Run `/create-prd-stack` to confirm database(s), then bootstrap. | Data strategy (Step 5) needs database-specific schema design patterns. |
+| Map Location | Column/Category | Why this matters |
+|---|---|---|
+| Cross-Cutting | Hosting | Deployment topology (Step 4.3) needs hosting-specific conventions. |
+| Per-Surface (shared) | ORMs | Migration strategy (Step 5.4) needs ORM-specific schema conventions. |
+| Per-Surface (shared) | Databases | Data strategy (Step 5) needs database-specific schema design patterns. |
 
-> **Timing fallback**: During `/create-prd`, the map may be partially populated. If a cell is empty but the value was just confirmed in the current conversation (from `/create-prd-stack`), proceed using the conversation-confirmed value. Bootstrap will fill the map after `/create-prd` completes.
+**HARD GATE** — If ANY required cell is empty → STOP. No timing fallbacks. No conversation-confirmed values. See map guard protocol for recovery.
 
-If cells are empty AND the value hasn't been confirmed in conversation → **HARD STOP**: tell the user to run `/create-prd-stack` first.
-
-Read `## Engagement Tier` from `docs/plans/ideation/ideation-index.md`.
-
-**Tier behavior for architecture decisions:**
-- 🤖 **Auto**: Agent designs system architecture + data strategy via Deep Think. Writes reasoning. Marks decisions `[AUTO-CONFIRMED]`. User reviews at end of shard.
-- 🤝 **Hybrid** / 💬 **Interactive**: Present each major section, walk through, wait for user confirmation (current behavior).
+Read the engagement tier protocol (`.agent/skills/prd-templates/references/engagement-tier-protocol.md`) — apply the tier behavior for architecture decisions.
 
 ---
 
@@ -76,9 +70,9 @@ For each component, also define:
 - "Are there failure modes I haven't accounted for?"
 - For multi-surface: "What happens if the sync layer goes down? Can each surface degrade gracefully?"
 
-Refine based on discussion before proceeding.
+Follow the decision confirmation protocol (`.agent/skills/prd-templates/references/decision-confirmation-protocol.md`) — do not write until explicitly confirmed.
 
-Write the completed `## System Architecture` section to `docs/plans/architecture-draft.md` (create the file if it does not exist). Do not wait until the end — write this section as soon as it is completed and confirmed by the user.
+Write the completed `## System Architecture` section to `docs/plans/architecture-draft.md` (create the file if it does not exist). Do not wait until the end — write this section as soon as it is completed and confirmed by the user. Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`).
 
 > **Decision recording**: For each non-trivial architecture decision (technology choices, deployment topology, API style, failure handling strategy), read `.agent/skills/session-continuity/protocols/06-decision-analysis.md` and follow the **Decision Effect Analysis Protocol**. Architecture decisions have the highest downstream impact in the pipeline — record them to `memory/decisions.md` with the Philosopher + Devil's Advocate deliberation.
 
@@ -88,7 +82,7 @@ Write the completed `## System Architecture` section to `docs/plans/architecture
 
 Read `.agent/skills/error-handling-patterns/SKILL.md` and follow its Error Architecture Interview methodology. All 5 decisions must receive explicit user confirmation before proceeding to Data Strategy. This step is a hard gate — do not proceed until all five decisions are confirmed.
 
-Write the completed decisions to `docs/plans/architecture-draft.md` under a new top-level `## Error Architecture` section (between `## System Architecture` and `## Data Strategy`). The section must contain five sub-sections matching the five decisions above (`### Global Error Envelope`, `### Error Propagation Chain`, `### Unhandled Exception Strategy`, `### Client Fallback Contract`, `### Error Boundary Strategy`), with the locked canonical JSON example included verbatim under `### Global Error Envelope`.
+Write the completed decisions to `docs/plans/architecture-draft.md` under a new top-level `## Error Architecture` section (between `## System Architecture` and `## Data Strategy`). The section must contain five sub-sections matching the five decisions above (`### Global Error Envelope`, `### Error Propagation Chain`, `### Unhandled Exception Strategy`, `### Client Fallback Contract`, `### Error Boundary Strategy`), with the locked canonical JSON example included verbatim under `### Global Error Envelope`. Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`).
 
 ## 5. Data strategy
 
@@ -111,22 +105,22 @@ For multi-surface projects, additionally define:
 - "Does every entity have a clear owner?"
 - "Are there query patterns I'm missing that could become hot paths?"
 
-Refine based on discussion before proceeding.
+Follow the decision confirmation protocol (`.agent/skills/prd-templates/references/decision-confirmation-protocol.md`) — do not write until explicitly confirmed.
 
-Write the completed `## Data Strategy` section to `docs/plans/architecture-draft.md`.
+Write the completed `## Data Strategy` section to `docs/plans/architecture-draft.md`. Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`).
 
 ### 5.5. Cross-Store Entity Consistency
 
 Read .agent/skills/database-schema-design/SKILL.md and follow its Cross-Store Entity Consistency Protocol for every entity that spans more than one store.
 
-Write the completed cross-store consistency table to `docs/plans/architecture-draft.md` as part of the `## Data Strategy` section.
+Write the completed cross-store consistency table to `docs/plans/architecture-draft.md` as part of the `## Data Strategy` section. Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`).
 
 ### Data placement strategy document
 
 Read `.agent/skills/prd-templates/references/data-placement-template.md` for the template structure. Create `docs/plans/data-placement-strategy.md` using the template, filling each section with the data decisions confirmed above.
 
-### Propose next step
+### Next step
 
-System architecture and data placement strategy are complete. Next: Run `/create-prd-security` to define the security model, compliance escalation, and integration points.
+**STOP** — do NOT proceed to any other workflow. The only valid next step is `/create-prd-security`.
 
-> If this shard was invoked standalone (not from `/create-prd`), surface this via `notify_user`.
+> If invoked standalone, surface via `notify_user` and wait for user confirmation.

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

@@ -20,29 +20,25 @@ requires_map_columns: [Unit Tests, E2E Tests, CI/CD]
 
 Document the development methodology and phasing strategy. Compile the architecture design document and engineering standards.
 
-**Prerequisite**: Security model and integration points must be defined (from `/create-prd-security`). All tech stack decisions, system architecture, data strategy, and security model must be complete.
+**Prerequisite**: Security model and integration points must be defined (from `/create-prd-security`).
+
+Verify `docs/plans/architecture-draft.md` exists. If it does not → **STOP**: "architecture-draft.md is missing. Previous shards should have created it. Run `/create-prd-architecture` first."
 
 ---
 
 ## 0. Map guard
 
-Read the surface stack map from `.agent/instructions/tech-stack.md`. Check the following columns/categories for filled values:
-
-| Map Location | Column/Category | Recovery | Why this matters |
-|---|---|---|---|
-| Per-Surface (any) | Unit Tests | Run `/create-prd-stack` to confirm unit testing framework, then bootstrap. | Development methodology (Step 8) needs framework-specific TDD patterns. |
-| Per-Surface (any) | E2E Tests | Run `/create-prd-stack` to confirm E2E testing framework, then bootstrap. | Development methodology (Step 8) needs E2E-specific test conventions. |
-| Cross-Cutting | CI/CD | Run `/create-prd-stack` to confirm CI/CD platform, then bootstrap. | Phasing strategy (Step 9) needs platform-specific pipeline patterns. |
+Follow the map guard protocol (`.agent/skills/prd-templates/references/map-guard-protocol.md`). Required cells for this shard:
 
-> **Timing fallback**: During `/create-prd`, the map may be partially populated. If a cell is empty but the value was just confirmed in the current conversation (from `/create-prd-stack`), proceed using the conversation-confirmed value. Bootstrap will fill the map after `/create-prd` completes.
+| Map Location | Column/Category | Why this matters |
+|---|---|---|
+| Per-Surface (any) | Unit Tests | Development methodology (Step 8) needs framework-specific TDD patterns. |
+| Per-Surface (any) | E2E Tests | Development methodology (Step 8) needs E2E-specific test conventions. |
+| Cross-Cutting | CI/CD | Phasing strategy (Step 9) needs platform-specific pipeline patterns. |
 
-If cells are empty AND the value hasn't been confirmed in conversation → **HARD STOP**: tell the user to run `/create-prd-stack` first.
+**HARD GATE** — If ANY required cell is empty → STOP. No timing fallbacks. No conversation-confirmed values. See map guard protocol for recovery.
 
-Read `## Engagement Tier` from `docs/plans/ideation/ideation-index.md`.
-
-**Tier behavior for compile decisions:**
-- 🤖 **Auto**: Agent selects methodology, phasing, and performance budgets via Deep Think. Writes reasoning. Marks `[AUTO-CONFIRMED]`. User reviews compiled documents.
-- 🤝 **Hybrid** / 💬 **Interactive**: Present each decision, wait for user confirmation (current behavior).
+Read the engagement tier protocol (`.agent/skills/prd-templates/references/engagement-tier-protocol.md`) — apply the tier behavior for compile decisions.
 
 ---
 
@@ -59,7 +55,7 @@ Document the agreed approach:
 4. **Spec layers** — IA → BE → FE pipeline
 5. **Quality gates** — What must pass before merge
 
-Write the completed `## Development Methodology` section to `docs/plans/architecture-draft.md` immediately after user confirmation.
+Write the completed `## Development Methodology` section to `docs/plans/architecture-draft.md` immediately after user confirmation. Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`).
 
 ## 9. Phasing strategy
 
@@ -83,9 +79,9 @@ Each phase should have a rough timeline estimate and must pass the full validati
 - "Are there features in Phase 2 that actually depend on something not in Phase 1?"
 - "Is the Phase 1 scope achievable without cutting quality?"
 
-Refine based on discussion before proceeding.
+Follow the decision confirmation protocol (`.agent/skills/prd-templates/references/decision-confirmation-protocol.md`) — do not write until explicitly confirmed.
 
-Write the completed `## Phasing Strategy` section to `docs/plans/architecture-draft.md` immediately after user confirmation.
+Write the completed `## Phasing Strategy` section to `docs/plans/architecture-draft.md` immediately after user confirmation. Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`).
 
 ## 9.5. Lock project directory structure
 
@@ -95,7 +91,7 @@ Based on the locked tech stack, generate a canonical directory tree.
 2. Present the tree to the user with one-line descriptions per top-level directory. Adapt the tree to the actual stack — e.g., a CLI project won't have `components/`, a monorepo will have `apps/` and `packages/`
 3. Build an architecture separation table mapping each concern to its directory and runtime
 4. **Present to user**: Show the directory tree and architecture table. Ask: "Does this structure match your expectations?" **Do not proceed until explicit approval.**
-5. After approval, fire bootstrap with: `PROJECT_STRUCTURE`, `ARCHITECTURE_TABLE`, `CONTRACTS_DIR`, `BUILD_OUTPUT_DIR`
+5. After approval, fire bootstrap with: `PROJECT_STRUCTURE`, `ARCHITECTURE_TABLE`, `CONTRACTS_DIR`, `BUILD_OUTPUT_DIR`. **HARD GATE**: Follow the bootstrap verification protocol (`.agent/skills/prd-templates/references/bootstrap-verification-protocol.md`) — verify all 4 keys.
 6. Append a `## Directory Structure` section to `docs/plans/architecture-draft.md`
 
 > If invoked standalone, surface via `notify_user`.
@@ -106,7 +102,18 @@ Read .agent/skills/technical-writer/SKILL.md and follow its methodology.
 
 Read .agent/skills/technical-writer/SKILL.md and apply its clarity and structure standards throughout document compilation.
 
-Read `docs/plans/architecture-draft.md` as the authoritative source. Read `.agent/skills/prd-templates/references/architecture-design-template.md` for the document structure. Compile it into `docs/plans/YYYY-MM-DD-architecture-design.md` (use today's date).
+Read `docs/plans/architecture-draft.md` as the authoritative source.
+
+**Section validation**: Before compiling, verify these sections exist in architecture-draft.md:
+- `## System Architecture`
+- `## Error Architecture`
+- `## Data Strategy`
+- `## Security Model`
+- `## Integration Points` (or explicit "no integrations" note)
+
+If any required section is missing → **STOP**: "architecture-draft.md is missing `[section]`. This section should have been written by a previous shard. Run the relevant shard: architecture → `/create-prd-architecture`, security → `/create-prd-security`."
+
+Read `.agent/skills/prd-templates/references/architecture-design-template.md` for the document structure. Compile it into `docs/plans/YYYY-MM-DD-architecture-design.md` (use today's date).
 
 > **Depth rule**: Each section must contain the full detail gathered during steps 3-9. If a section is under 200 words, it's almost certainly too shallow. Apply the two-implementer test.
 
@@ -142,6 +149,8 @@ Call `notify_user` presenting:
 
 > **Both documents must be approved before proceeding. Do NOT proceed until the user sends a message explicitly approving this output.**
 
-### Proposed next steps
+### Next step
+
+**STOP** — do NOT propose `/decompose-architecture` or any other pipeline workflow. The only valid next step is:
 
-**Hard gate**: Run `/audit-ambiguity architecture`. This is unconditionally mandatory — the self-check above cannot replace it.
+- `/audit-ambiguity architecture` — unconditionally mandatory. The self-check above cannot replace an independent audit.