cfsa-antigravity 2.7.0 → 2.9.0

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.

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

@@ -27,11 +27,12 @@ Build the decision constraints map from the ideation output, then walk through e
 
 Before any tech stack decision, read `docs/plans/ideation/meta/constraints.md` to build the **decision constraints map**.
 
+- **If `meta/constraints.md` does not exist** → **STOP**: "Constraints file missing. Run `/ideate` to completion — constraint exploration is required before tech stack decisions."
+- **If it exists but has no `## Project Surfaces` section** → **STOP**: "Constraints file is missing Project Surfaces. Run `/ideate-validate` to complete constraint exploration."
+
 Also read `docs/plans/ideation/ideation-index.md` — specifically `## Structural Classification` (authoritative surface list and project shape) and `## Engagement Tier` (gate behavior for this session).
 
-**Tier behavior for tech stack decisions:**
-- 🤖 **Auto**: Agent uses constraints + Deep Think to select best-fit option per axis. Records reasoning. Writes decisions. User reviews all stack decisions at end of shard.
-- 🤝 **Hybrid** / 💬 **Interactive**: Present options, wait for user confirmation per axis (current behavior).
+Read the engagement tier protocol (`.agent/skills/prd-templates/references/engagement-tier-protocol.md`) — apply the tier behavior for tech stack decisions.
 
 Build the constraints map:
 
@@ -58,8 +59,10 @@ Score Fit from 1–5 based on how well the option matches the constraints map. I
 1. Ask the constraint questions for this axis
 2. Filter options based on answers
 3. Present the filtered option table with recommendation
-4. **Interactive/Hybrid**: Wait for user confirmation. **Auto**: Select highest-fit option via Deep Think, write reasoning to `architecture-draft.md`, mark as `[AUTO-CONFIRMED]`.
-5. Fire bootstrap with only that key: read `.agent/workflows/bootstrap-agents.md` and call with `PIPELINE_STAGE=create-prd` + the confirmed key
+4. Follow the decision confirmation protocol (`.agent/skills/prd-templates/references/decision-confirmation-protocol.md`) — tier-aware.
+5. Fire bootstrap with only that key: read `.agent/workflows/bootstrap-agents.md` and call with `PIPELINE_STAGE=create-prd` + the confirmed key. **HARD GATE**: Follow the bootstrap verification protocol (`.agent/skills/prd-templates/references/bootstrap-verification-protocol.md`). If bootstrap verification fails:
+   - **1st failure** → retry bootstrap once with the same key
+   - **2nd failure** → **STOP**: tell the user which key failed verification and ask: "Retry, skip this skill provisioning, or abort?"
 6. Move to next axis
 
 > **Note on backend axis bootstrap keys**: `BACKEND_FRAMEWORK` and `API_LAYER` are distinct bootstrap keys and must each fire as a separate `/bootstrap-agents` call — do not combine them.
@@ -70,21 +73,27 @@ Score Fit from 1–5 based on how well the option matches the constraints map. I
 
 Get explicit user decisions *(Interactive/Hybrid)* or auto-select with Deep Think reasoning *(Auto)* — no "TBD" allowed. Use the brainstorming skill's approach — one decision at a time.
 
+**User indecision handling**: If the user expresses uncertainty ("I don't know", "not sure", "you pick") on any decision:
+- Present your recommendation with clear reasoning
+- If user accepts → proceed with it
+- If user remains uncertain → read `.agent/skills/resolve-ambiguity/SKILL.md` and apply its methodology to narrow the decision space
+- If after ambiguity resolution the user still can't decide → lock your recommendation with a note: "[Agent-recommended, user deferred]" — this can be revisited later via `/propagate-decision`
+
 > **Decision recording**: For each confirmed tech stack decision, read `.agent/skills/session-continuity/protocols/06-decision-analysis.md` and follow the **Decision Effect Analysis Protocol**. Tech stack choices have high downstream impact (they constrain frameworks, skills, deployment, and testing). Record each decision to `memory/decisions.md` with upstream/downstream effects.
 
 ### Database: Persistence Map Interview
 
 Instead of a single DATABASE decision pass, use the following structured persistence map interview to identify all required stores.
 
-Read .agent/skills/database-schema-design/SKILL.md and follow its Persistence Map Interview methodology (Sub-steps A–E). Fire bootstrap per the skill's instructions for each confirmed store.
+Read .agent/skills/database-schema-design/SKILL.md and follow its Persistence Map Interview methodology (Sub-steps A–E). Fire bootstrap per the skill's instructions for each confirmed store. **HARD GATE**: Follow the bootstrap verification protocol (`.agent/skills/prd-templates/references/bootstrap-verification-protocol.md`) after each store is confirmed.
 
 ### Design Direction
 
-Read `.agent/skills/design-direction/SKILL.md` and follow its interview methodology to determine the project's visual direction. After confirmation, fire bootstrap with `DESIGN_DIRECTION=[confirmed direction]`.
+Read `.agent/skills/design-direction/SKILL.md` and follow its interview methodology to determine the project's visual direction. After confirmation, fire bootstrap with `DESIGN_DIRECTION=[confirmed direction]`. **HARD GATE**: Follow the bootstrap verification protocol (`.agent/skills/prd-templates/references/bootstrap-verification-protocol.md`).
 
 ### Development tooling
 
-Read `.agent/skills/tech-stack-catalog/references/dev-tooling-decisions.md` for the tooling axes and bootstrap keys. After the user confirms all development tooling, fire bootstrap immediately with all keys listed in that reference file.
+Read `.agent/skills/tech-stack-catalog/references/dev-tooling-decisions.md` for the tooling axes and bootstrap keys. After the user confirms all development tooling, fire bootstrap immediately with all keys listed in that reference file. **HARD GATE**: Follow the bootstrap verification protocol (`.agent/skills/prd-templates/references/bootstrap-verification-protocol.md`) — verify every key.
 
 ### After each tech decision
 
@@ -94,8 +103,8 @@ Read each installed skill's SKILL.md before proceeding. Append the confirmed dec
 
 Read `.agent/workflows/bootstrap-agents.md` and call it with `PIPELINE_STAGE=create-prd` plus only the keys just decided. Bootstrap runs after **each confirmed decision**, not in a batch at the end. At the end of all tech decisions, call bootstrap once more with `ARCHITECTURE_DOC` set to the dated filename.
 
-### Propose next step
+### Next step
 
-All tech stack 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 invoked standalone, surface via `notify_user`.
+> If invoked standalone, surface via `notify_user` and wait for user confirmation.

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

@@ -19,13 +19,7 @@ Transform the ideation output into a production-grade architecture design docume
 **Input**: `docs/plans/ideation/ideation-index.md` (must exist and be approved)
 **Output**: `docs/plans/YYYY-MM-DD-architecture-design.md` + `docs/plans/ENGINEERING-STANDARDS.md` + `docs/plans/data-placement-strategy.md`
 
-> **Depth standard**: Every section of the architecture document must be specified
-> to the point where a developer cannot misinterpret it. If you can write a
-> one-paragraph section summary, it's not detailed enough. Each section should
-> define every field, every flow, every error case, every permission boundary.
-> The specificity-standards rule (`.agent/rules/specificity-standards.md`) applies to every
-> word of the output. One-line placeholders like `[Auth, authorization, rate limits]`
-> are not architecture — they are headings waiting for content.
+> **Depth standard**: Every section must be specified to the point where a developer cannot misinterpret it. The specificity-standards rule (`.agent/rules/specificity-standards.md`) applies to every word of the output.
 
 ---
 
@@ -33,43 +27,30 @@ Transform the ideation output into a production-grade architecture design docume
 
 Read `docs/plans/ideation/ideation-index.md`.
 
-If the file doesn't exist, tell the user to run `/ideate` first. Do not proceed without approved ideation output.
+If the file doesn't exist → **STOP**: tell the user to run `/ideate` first.
 
-Use the **Structure Map** in `ideation-index.md` to locate specific files:
-- Constraints + surface classification → `meta/constraints.md`
-- Personas → `meta/personas.md`
-- Domain details → fractal tree under `domains/` (or `surfaces/` for multi-product). Each domain is a **folder** containing `*-index.md` (children + Role Matrix), `*-cx.md` (cross-cuts), and child feature `.md` files. Walk the tree to the depth needed.
-- Cross-cutting concerns → `ideation-cx.md` (global cross-surface) + per-domain `*-cx.md` files within the fractal tree
-- Role coverage → Role Matrix in each domain index, Role Lens in each feature file (use for RBAC planning in security shard)
+**Completeness validation**: If the file exists, verify it contains these required sections:
+- `## Structural Classification`
+- `## Engagement Tier`
+- `## MoSCoW Summary` (with at least 1 Must Have feature)
 
-Pay special attention to the **Project Surfaces** section in `meta/constraints.md` — it determines which tech stack axes apply.
+If any required section is missing → **STOP**: "ideation-index.md is incomplete — missing `[section]`. Run `/ideate` to complete ideation before proceeding."
 
-Also read `## Engagement Tier` from `ideation-index.md`. If not set during ideation, ask now:
+Use the **Structure Map** in `ideation-index.md` to locate: constraints, personas, domain details (fractal tree), cross-cutting concerns, and role coverage.
 
-> **How involved do you want to be?**
-> 1. 🤖 **Auto** — I design the full architecture via Deep Think. You review the compiled output.
-> 2. 🤝 **Hybrid** *(recommended)* — Structural steps auto. Architecture/product decisions pause for you.
-> 3. 💬 **Interactive** — I pause at every step.
+Pay special attention to **Project Surfaces** in `meta/constraints.md` — it determines which tech stack axes apply.
 
-**Wait for user answer.** If an ideation tier exists, present it as default. Write to `ideation-index.md` immediately.
+Read `## Engagement Tier` from `ideation-index.md`. If not set, ask the user and write immediately.
 
-Each shard reads the tier and adapts gates: **Auto** = all gates auto-confirm with Deep Think reasoning. **Hybrid** = structural auto, architecture/product pause. **Interactive** = all pause.
+Read `.agent/skills/prd-templates/references/engagement-tier-protocol.md` — each shard reads the tier and adapts gates.
 
 ---
 
 ## 2. Load skills
 
-### Bundled skills
+Read each skill SKILL.md listed in the frontmatter `skills` array.
 
-These skills are included in the kit — read each SKILL.md:
-1. `.agent/skills/api-design-principles/SKILL.md` — API design principles
-3. `.agent/skills/security-scanning-security-hardening/SKILL.md` — Security model
-4. `.agent/skills/clean-code/SKILL.md` — Architecture principles
-5. `.agent/skills/brainstorming/SKILL.md` — For collaborative decisions
-
-### Stack-specific skill discovery
-
-Check `.agent/skills/` for relevant skills. Read `.agent/skills/find-skills/SKILL.md` for guidance on discovering community skills for your chosen stack.
+Check `.agent/skills/` for stack-specific skills. Read `.agent/skills/find-skills/SKILL.md` for community skill discovery.
 
 ---
 
@@ -83,103 +64,50 @@ Check `.agent/skills/` for relevant skills. Read `.agent/skills/find-skills/SKIL
 | 3 | [`create-prd-security`](.agent/workflows/create-prd-security.md) | Security model, compliance escalation, integration points |
 | 4 | [`create-prd-compile`](.agent/workflows/create-prd-compile.md) | Development methodology, phasing, compile architecture-design.md + ENGINEERING-STANDARDS.md |
 
-> **Progressive working artifact**: `docs/plans/architecture-draft.md` is written incrementally by shards 1–3 (stack decisions, system architecture, data strategy, security model, integration points) and read by shard 4 (compile) to produce the final dated `architecture-design.md`.
+> **Progressive working artifact**: `docs/plans/architecture-draft.md` is written incrementally by shards 1–3 and read by shard 4 to compile the final dated `architecture-design.md`.
 
 ---
 
 ## Orchestration
 
 ### Step A — Run `.agent/workflows/create-prd-stack.md`
-
-Builds the constraints map from `ideation/meta/constraints.md`, presents tech stack options per axis, gets user decisions, fires bootstrap after each confirmation.
-
 ### Step A.5 — Run `.agent/workflows/create-prd-design-system.md`
-
-Establishes the structural UI architecture — navigation paradigm, layout grid, page archetypes, global component inventory, motion language, data density philosophy, and global state design language. Produces `docs/plans/design-system.md` which all FE specs must consume.
-
 ### Step B — Run `.agent/workflows/create-prd-architecture.md`
-
-Designs system architecture (components, data flow, deployment topology, API surface) and data strategy (placement, schema, queries, migrations, PII boundaries). Creates `docs/plans/data-placement-strategy.md`.
-
 ### Step C — Run `.agent/workflows/create-prd-security.md`
-
-Defines the security model (auth, authorization, validation, rate limits). Escalates compliance-heavy domains to full-depth sections. Documents integration points with failure modes and fallbacks.
-
 ### Step D — Run `.agent/workflows/create-prd-compile.md`
 
-Documents development methodology and phasing strategy. Compiles `docs/plans/YYYY-MM-DD-architecture-design.md` and `docs/plans/ENGINEERING-STANDARDS.md`.
-
 ---
 
 ## Step E — Quality gate
 
 ### Self-check against Architecture rubric
 
-Read .agent/skills/pipeline-rubrics/SKILL.md and apply its Architecture rubric for the self-check.
-
-Before presenting to the user, self-check both documents against the **Architecture Rubric** (12 dimensions) from `/audit-ambiguity`:
+Read `.agent/skills/pipeline-rubrics/references/architecture-rubric.md` and apply all 15 dimensions as the self-check.
 
-| # | Dimension | Check |
-|---|-----------|-------|
-| 1 | Tech Stack Decisiveness | Is every applicable axis decided with rationale? No TBDs? |
-| 2 | System Architecture | Are all components, flows, and failure modes documented? |
-| 3 | Data Strategy | Are placement, schema, queries, migrations, and PII boundaries defined? |
-| 4 | Security Model | Are auth, authz, validation, rate limits, and CSP fully specified? |
-| 5 | Compliance Depth | Are regulated domains (minors, payments, health) given full-depth sections? |
-| 6 | API Design | Are surface, versioning, conventions, errors, and pagination defined? |
-| 7 | Integration Robustness | Do all externals have failure + fallback plans? |
-| 8 | Phasing Clarity | Are phases dependency-ordered with entry/exit criteria? |
-| 9 | Engineering Standards | Are all thresholds concrete? No TBDs in ENGINEERING-STANDARDS.md? |
-| 10 | Persistence Architecture | Is the persistence map complete? Do all cross-store entities have a consistency contract (canonical ID, creation sequence, deletion cascade, read join)? |
-| 11 | Error Architecture | Is the global error envelope defined with all four fields? Are all five error decisions confirmed (envelope, propagation chain, unhandled exceptions, client fallback, error boundaries)? |
-| 12 | Attack Surface Coverage | Is the attack surface review complete? Are OWASP Top 10 (web) and API Top 10 (API) addressed with named mechanisms? Are security headers configured? Is the observability architecture documented? |
+Read `.agent/skills/prd-templates/references/architecture-completeness-checklist.md` and verify all items.
 
-Also verify completeness:
+For any dimension that scores ⚠️ or ❌ → resolve it NOW. Loop back to the relevant shard.
 
-- [ ] Every "Must Have" feature from `ideation-index.md` MoSCoW list has a home in the architecture
-- [ ] Security model addresses all compliance constraints from `ideation/meta/constraints.md`
-- [ ] Compliance-heavy domains have their own top-level sections (not buried as sub-bullets)
-- [ ] All relevant skills installed for chosen stack
-- [ ] Validation command in Engineering Standards matches `AGENTS.md` validation command
-- [ ] For multi-surface: sync strategy defined, data ownership clear, conflict resolution specified
-- [ ] For cross-platform: platform-specific considerations documented for each target OS
-- [ ] Design system document exists at docs/plans/design-system.md and all seven decision areas are filled (no placeholders)
+**Remediation loop guard**: Track remediation attempts per dimension. After **3 failed attempts** on the same dimension → **STOP**: present the dimension to the user as a known gap with context on what was tried. Include it in the review presentation as an unresolved item for user decision.
 
-For any dimension that scores ⚠️ or ❌, resolve it NOW. Loop back to the relevant step and resolve with the user.
-
-> ❌ STOP — do not call notify_user until all dimensions score ✅.
+> ❌ STOP — do not call notify_user until all dimensions score ✅ and all checklist items pass.
 
 ### Depth audit
 
-Before presenting to the user, re-read the entire architecture document and for EACH section ask:
-
-> "Could a developer implement this without asking a single clarifying question?"
-
-If the answer is no for ANY section:
-1. Identify what's missing (field types? flow steps? error cases? permission rules?)
-2. Add the missing detail NOW — do not flag it, resolve it
-3. Re-check the section
-
-This is the single most important step. The difference between a useful architecture document and a useless one is whether this audit is done honestly. A 2,000-word architecture doc is almost certainly too shallow for any non-trivial project.
+Re-read the entire architecture document and for EACH section ask: "Could a developer implement this without asking a single clarifying question?"
 
-If gaps are found, loop back to the relevant step and resolve with the user.
+If no → identify what's missing, add the detail NOW, re-check.
 
-> **Note**: This is an internal self-check, not a formal audit. For a rigorous,
-> independent audit with evidence citations, run `/audit-ambiguity architecture` as a
-> separate step after this workflow completes.
+> **Note**: This is an internal self-check. For a rigorous independent audit, run `/audit-ambiguity architecture` after this workflow completes.
 
 ## Step F — Request review and next steps
 
-Use `notify_user` to present to the user:
-- **Both** the architecture design document and the Engineering Standards document
-- Summary of the self-check results (all 12 dimensions + completeness checklist)
-- Any areas where you resolved gaps during the self-check
+Use `notify_user` to present both documents with self-check results.
 
-Both documents must be approved before proceeding. Do NOT proceed to the next step until the user sends a message explicitly approving this output. Proposing next steps is not the same as receiving approval. Wait for explicit approval before continuing.
+**STOP** — do NOT proceed until the user explicitly approves.
 
-### Proposed next steps
+### Next step
 
-Once approved, present the user with the appropriate next step:
+**STOP** — do NOT propose `/decompose-architecture` or any other pipeline workflow. The only valid next step is:
 
-- **Default recommendation**: Run `/audit-ambiguity architecture` — recommended for all projects, especially those with compliance constraints
-- **Skip condition**: Only skip `/audit-ambiguity architecture` if all 12 dimensions scored ✅ AND the project has zero compliance constraints. In that case, recommend `/decompose-architecture` directly.
+- `/audit-ambiguity architecture` — unconditionally mandatory. The self-check above cannot replace an independent audit. After the audit passes, the next step is `/decompose-architecture`.

package/template/.agent/workflows/decompose-architecture-structure.md

@@ -19,7 +19,10 @@ pipeline:
 
 Create directory structure, shard skeleton files, and all layer indexes.
 
-**Prerequisite**: Read the approved domain boundaries from `docs/plans/ia/decomposition-plan.md`. If this file does not exist, the boundaries have not been approved — tell the user to run `/decompose-architecture` Steps 3-4.5 first.
+**Prerequisite**: Read the approved domain boundaries from `docs/plans/ia/decomposition-plan.md`.
+
+- If this file does not exist → **STOP**: "Decomposition plan missing. Run `/decompose-architecture` Steps 3-4.5 first."
+- If the file exists but contains no `## Domain Boundary Table` → **STOP**: "Decomposition plan is incomplete — no domain boundary table found. Run `/decompose-architecture` Step 3 to generate domain boundaries."
 
 ---
 
@@ -55,6 +58,13 @@ Read `.agent/skills/prd-templates/SKILL.md` and follow its Shard Seeding Procedu
 
 Fallback for domains not covered in the ideation domain folders is defined in the skill's Shard Seeding Procedure.
 
+**Post-creation verification**: After all skeletons are created, list the `docs/plans/ia/` directory. Verify:
+- Every shard in the decomposition plan has a corresponding `.md` file
+- `00-infrastructure.md` exists regardless of domain decomposition
+- No empty files (0 bytes)
+
+If any skeleton is missing → create it now. Do not proceed to index creation with missing skeletons.
+
 ## 6. Create IA index
 
 Read `.agent/skills/prd-templates/references/decomposition-templates.md` for the **IA Index** template. Create `docs/plans/ia/index.md` using the template, populating the shards table with all shards created in Step 5.
@@ -73,8 +83,8 @@ Read `.agent/skills/prd-templates/references/decomposition-templates.md` for the
 
 For multi-surface projects, each surface's own `index.md` contains the standard three-layer table (IA/BE/FE) scoped to that surface, following the same format as the single-surface master index.
 
-### Propose next step
+### Next step
 
-Directory structure, shard skeletons, and all layer indexes are created. Next: Run `/decompose-architecture-validate` to identify deep dive candidates, annotate shard types, validate the dependency graph, and generate the spec pipeline tracker.
+**STOP** — do NOT proceed to any other workflow. The only valid next step is `/decompose-architecture-validate`.
 
-> If this shard was invoked standalone (not from `/decompose-architecture`), surface this via `notify_user`.
+> If invoked standalone, surface via `notify_user` and wait for user confirmation.