cfsa-antigravity 2.7.0 → 2.8.0

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.

package/template/.agent/workflows/create-prd-design-system.md

@@ -31,9 +31,7 @@ Establish the structural UI architecture — navigation paradigm, layout grid, p
 
 Read `## Engagement Tier` from `docs/plans/ideation/ideation-index.md`.
 
-**Tier behavior for design system decisions** (all 7 decisions are product decisions):
-- 🤖 **Auto**: Agent selects based on design direction + constraints via Deep Think. Writes reasoning. Marks `[AUTO-CONFIRMED]`. User reviews compiled `design-system.md` at Step 9.
-- 🤝 **Hybrid** / 💬 **Interactive**: Present options, wait for explicit confirmation per decision (current behavior).
+Read the engagement tier protocol (`.agent/skills/prd-templates/references/engagement-tier-protocol.md`) — apply the tier behavior for design system decisions (all 7 decisions are product decisions).
 
 1. Read `docs/plans/ideation/meta/constraints.md` — extract the **Project Surfaces** section. Read `docs/plans/ideation/ideation-index.md` — extract the feature inventory from the MoSCoW Summary.
 2. Read `.agent/skills/brand-guidelines/SKILL.md` — extract the confirmed `DESIGN_DIRECTION`.
@@ -50,9 +48,13 @@ Present surface-appropriate options from the **Navigation Paradigm Options** sec
 
 > **Decision prompt**: "Which navigation pattern fits your app's usage pattern and audience?"
 
-**Wait for explicit user confirmation before proceeding.**
+**Tier-aware confirmation** *(applies to all 7 decisions in this shard)*:
+- **Interactive/Hybrid** → "Wait for explicit user confirmation" means present and wait.
+- **Auto** → auto-confirm with Deep Think reasoning. Write the decision with `[AUTO-CONFIRMED]` tag. The Auto Tier Review Checkpoint in `/ideate-validate` or the review in Step 9 is where the user can override.
+
+**Wait for explicit user confirmation before proceeding** *(Interactive/Hybrid)* or auto-confirm with Deep Think *(Auto)*.
 
-On confirmation, write the `## Navigation Paradigm` section to `docs/plans/design-system.md` immediately.
+On confirmation, write the `## Navigation Paradigm` section to `docs/plans/design-system.md` immediately. Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`).
 
 ---
 
@@ -67,7 +69,7 @@ Provide a **default recommendation** based on the confirmed design direction:
 
 **Wait for explicit user confirmation before proceeding.**
 
-On confirmation, write the `## Layout Grid` table to `docs/plans/design-system.md`.
+On confirmation, write the `## Layout Grid` table to `docs/plans/design-system.md`. Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`).
 
 ---
 
@@ -77,7 +79,7 @@ Based on the feature inventory from `ideation-index.md`, propose a named archety
 
 Present the proposed archetypes to the user. Ask whether any are missing or should be renamed. **Wait for explicit user confirmation before proceeding.**
 
-On confirmation, write the `## Page Archetypes` section to `docs/plans/design-system.md`.
+On confirmation, write the `## Page Archetypes` section to `docs/plans/design-system.md`. Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`).
 
 ---
 
@@ -89,7 +91,7 @@ Present the derived list. Ask: (1) Are any components missing? (2) Should any be
 
 **Wait for explicit user confirmation before proceeding.**
 
-On confirmation, write the `## Global Component Inventory` section to `docs/plans/design-system.md`. This serves as the **Component Inventory Seed** — all FE specs must consume (not re-invent) these global components.
+On confirmation, write the `## Global Component Inventory` section to `docs/plans/design-system.md`. Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`). This serves as the **Component Inventory Seed** — all FE specs must consume (not re-invent) these global components.
 
 ---
 
@@ -97,7 +99,7 @@ On confirmation, write the `## Global Component Inventory` section to `docs/plan
 
 Present the options from the **Motion Language Options** in `design-system-decisions.md`. Present a recommendation based on the confirmed design direction. **Wait for explicit user confirmation before proceeding.**
 
-On confirmation, write the `## Motion Language` section to `docs/plans/design-system.md`.
+On confirmation, write the `## Motion Language` section to `docs/plans/design-system.md`. Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`).
 
 ---
 
@@ -105,7 +107,7 @@ On confirmation, write the `## Motion Language` section to `docs/plans/design-sy
 
 Present the options from the **Data Density Options** in `design-system-decisions.md`. If **Hybrid** is selected, ask the user to define per-archetype density rules. **Wait for explicit user confirmation before proceeding.**
 
-On confirmation, write the `## Data Density Philosophy` section to `docs/plans/design-system.md`.
+On confirmation, write the `## Data Density Philosophy` section to `docs/plans/design-system.md`. Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`).
 
 ---
 
@@ -113,7 +115,7 @@ On confirmation, write the `## Data Density Philosophy` section to `docs/plans/d
 
 Two-part decision. Present the loading state, error state, and empty state options from the **Global State Design Language Options** in `design-system-decisions.md`. Present recommendations based on the confirmed design direction. **Wait for explicit user confirmation before proceeding.**
 
-On confirmation, write the `## Global State Design Language` section to `docs/plans/design-system.md`.
+On confirmation, write the `## Global State Design Language` section to `docs/plans/design-system.md`. Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`).
 
 ---
 
@@ -128,10 +130,12 @@ Verify:
 
 If any section is incomplete, loop back to the relevant decision step and resolve with the user.
 
+**Completeness loop guard**: If the same section fails completeness 2 times → **STOP**: present the incomplete section to the user with what's missing and ask: "Provide the missing content directly, or accept this section as-is with a note?"
+
 ---
 
-### Propose next step
+### Next step
 
-Design system decisions are locked. Next: Run `/create-prd-architecture` to design the system architecture and data strategy.
+**STOP** — do NOT proceed to any other workflow. The only valid next step is `/create-prd-architecture`.
 
-> 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-security.md

@@ -26,22 +26,16 @@ Define the security model with full compliance escalation, and document all inte
 
 ## 0. Map guard
 
-Read the surface stack map from `.agent/instructions/tech-stack.md`. Check the following cross-cutting 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 | Category | Recovery | Why this matters |
-|---|---|---|---|
-| Cross-Cutting | Security | Run `/create-prd-stack` to confirm security framework, then bootstrap. | Security model (Step 6) needs stack-specific threat analysis patterns. |
-| Cross-Cutting | Auth | Run `/create-prd-stack` to confirm auth provider, then bootstrap. | Authentication design (Step 6.1) needs provider-specific auth flow patterns. |
+| Map Location | Category | Why this matters |
+|---|---|---|
+| Cross-Cutting | Security | Security model (Step 6) needs stack-specific threat analysis patterns. |
+| Cross-Cutting | Auth | Authentication design (Step 6.1) needs provider-specific auth flow 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 security decisions:**
-- 🤖 **Auto**: Agent designs security model + attack surface + integrations via Deep Think. Writes reasoning. Marks `[AUTO-CONFIRMED]`. User reviews at end of shard.
-- 🤝 **Hybrid** / 💬 **Interactive**: Present each 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 security decisions.
 
 ---
 
@@ -52,6 +46,9 @@ Read .agent/skills/security-scanning-security-hardening/SKILL.md and follow its
 Load the Auth and Security skill(s) from the cross-cutting section per the skill loading protocol (`.agent/skills/prd-templates/references/skill-loading-protocol.md`).
 
 1. **Authentication** — How do users prove identity?
+
+**No-auth project detection**: If the ideation output indicates no user accounts, no login, and no personalized data (e.g., a static content site, CLI tool, or public API) → skip items 1-2 and 5. Write a `## Security Model` section that documents WHY auth is not needed, and cover only items 3-4 and 6-8. If the project has partial auth (e.g., admin-only auth, API keys but no user accounts), scope items 1-2 to the applicable auth surface only.
+
 2. **Authorization** — RBAC vs ABAC? Permission model?
 3. **Data protection** — PII handling, encryption at rest/transit
 4. **Input validation** — Where and how? (Zod recommended for TypeScript)
@@ -76,13 +73,13 @@ Read .agent/skills/resolve-ambiguity/SKILL.md and follow its methodology.
 - "Can you think of a way to bypass any of these controls?"
 - "Are there edge cases in the age/payment/compliance flows I haven't covered?"
 
-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.
 
 **Bootstrap fire — security decision confirmed**
 
-If the security model confirmed a specific security framework or compliance approach (e.g., crypto patterns, custom HSM approach), read `.agent/workflows/bootstrap-agents.md` and invoke `/bootstrap-agents SECURITY=[confirmed value]` to provision additional skills. Note: surface-triggered security skills (`owasp-web-security`, `csp-cors-headers`, `input-sanitization`, `api-security-checklist`, `dependency-auditing`, `desktop-security-sandboxing`) are provisioned automatically by bootstrap when surfaces are confirmed in `/create-prd-stack` — no manual fire needed for those.
+If the security model confirmed a specific security framework or compliance approach (e.g., crypto patterns, custom HSM approach), read `.agent/workflows/bootstrap-agents.md` and invoke `/bootstrap-agents SECURITY=[confirmed value]` to provision additional skills. **HARD GATE**: Follow the bootstrap verification protocol (`.agent/skills/prd-templates/references/bootstrap-verification-protocol.md`). Note: surface-triggered security skills (`owasp-web-security`, `csp-cors-headers`, `input-sanitization`, `api-security-checklist`, `dependency-auditing`, `desktop-security-sandboxing`) are provisioned automatically by bootstrap when surfaces are confirmed in `/create-prd-stack` — no manual fire needed for those.
 
-Write the completed `## Security Model` section to `docs/plans/architecture-draft.md` immediately after user confirmation. Do not wait for later steps.
+Write the completed `## Security Model` 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`). Do not wait for later steps.
 
 ## 6.5. Attack Surface Review
 
@@ -92,10 +89,12 @@ Read .agent/skills/security-scanning-security-hardening/SKILL.md and follow its
 - "Are there any attack vectors I've missed for your specific domain?"
 - "Do the OWASP mechanisms look correct, or are any of them actually handled differently?"
 
-Write the completed `## Security — Attack Surface` section to `docs/plans/architecture-draft.md` immediately after user confirmation.
+Write the completed `## Security — Attack Surface` 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`).
 
 ## 7. Integration points
 
+**0-integrations check**: Scan the ideation output and architecture for external service dependencies. If there are genuinely 0 external integrations (no auth provider, no email service, no payment processor, no analytics, no CDN) → write a brief `## Integration Points` section stating: "No external service integrations identified. All functionality is self-contained." Skip the per-service framework below.
+
 For each external service:
 
 1. **What it provides** — Specific features used
@@ -103,21 +102,20 @@ For each external service:
 3. **Fallback strategy** — Graceful degradation plan
 4. **Cost model** — Pricing tier, expected usage
 
-Write the completed `## Integration Points` section to `docs/plans/architecture-draft.md` immediately after user confirmation.
+Write the completed `## Integration Points` 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`).
 
 ## 7.5. Observability Architecture
 
-Read .agent/skills/logging-best-practices/SKILL.md and follow its Observability Architecture Interview — all 5 decisions (logging, tracing, alerting, dashboards, retention) must be confirmed. Fire bootstrap per the skill's instructions for each confirmed tool.
+Read .agent/skills/logging-best-practices/SKILL.md and follow its Observability Architecture Interview — all 5 decisions (logging, tracing, alerting, dashboards, retention) must be confirmed. Fire bootstrap per the skill's instructions for each confirmed tool. **HARD GATE**: Follow the bootstrap verification protocol (`.agent/skills/prd-templates/references/bootstrap-verification-protocol.md`).
 
 **Present to user**: Show the observability architecture decisions. Ask:
 - "Are these logging levels and PII exclusions correct for your compliance requirements?"
 - "Are the alerting thresholds appropriate for your expected traffic?"
 
-Write the completed `## Observability Architecture` section to `docs/plans/architecture-draft.md` immediately after user confirmation.
-
-### Propose next step
+Write the completed `## Observability Architecture` 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`).
 
-Security model and integration points are defined. Next: Run `/create-prd-compile` to document the development methodology, phasing strategy, and compile the final architecture design document and Engineering Standards.
+### Next step
 
-> If this shard was invoked standalone (not from `/create-prd`), surface this via `notify_user`.
+**STOP** — do NOT proceed to any other workflow. The only valid next step is `/create-prd-compile`.
 
+> If invoked standalone, surface via `notify_user` and wait for user confirmation.