cfsa-antigravity 2.19.0 → 2.19.2

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

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

package/template/.claude/skills/prd-templates/references/architecture-design-template.md

@@ -0,0 +1,88 @@
+# Architecture Design Template
+
+Use this template when compiling `docs/plans/YYYY-MM-DD-architecture-design.md`.
+
+```markdown
+# [Project Name] — Architecture Design
+
+> **Ideation**: [link to ideation-index.md]
+> **Date**: YYYY-MM-DD
+> **Status**: Draft | Review | Approved
+> **Project Type**: [Single-surface: web/desktop/mobile/CLI/API | Multi-surface: list surfaces]
+
+## Tech Stack
+[Explicit decision for each applicable axis with rationale — not just the choice,
+but WHY this choice over alternatives, what trade-offs were accepted, and what
+constraints drove the decision. For multi-surface projects, organized by surface.]
+
+## System Architecture
+[Component diagram, data flow, deployment topology — every service named, every
+communication path documented, every failure mode identified. For multi-surface:
+include surface interconnection diagram and shared domain boundary.]
+
+## Data Strategy
+[Placement, schema design, query patterns, migrations — which data lives where
+and why, what the hot paths are, how schema evolves. For multi-surface: data
+ownership, sync protocol, conflict resolution.]
+
+## Error Architecture
+[Global error envelope with locked example JSON — all four fields defined with types. Error
+propagation chain per layer (DB → service → API handler → transport → client) — what is caught,
+logged, and exposed at each layer. Unhandled exception strategy — process-level catch, log fields,
+client response, alerting timeline. Client fallback contract per surface — offline mode decision,
+UI behaviour on network failure, retry strategy, timeout threshold. Error boundary strategy per
+applicable surface — boundary placement and fallback rendering.]
+
+## Security Model
+[Auth, authorization, validation, rate limits — every flow specified step-by-step,
+every permission rule scoped, every error case handled]
+
+## Compliance & Safety
+[If applicable — full depth on minors/payments/health/regulated domains.
+This section may be the largest in the document if compliance constraints
+are significant. Every account type, every consent flow, every content filter,
+every notification trigger, every audit requirement.]
+
+## API Design
+[Surface type, versioning, conventions — endpoint naming, request/response shapes,
+error format, pagination strategy. For multi-surface: shared API contract format.]
+
+## Integration Points
+[External services, failure modes, fallbacks, cost models — for each: what it
+provides, what happens when it's down, what the fallback is]
+
+## Observability Architecture
+[Logging strategy — library named, structured JSON (yes/no for prod), log levels per environment,
+PII field names that are never logged (named explicitly), log destination. Tracing strategy —
+service boundaries traced, sampling rate per environment, trace ID propagation to API clients.
+Alerting thresholds — error rate %, latency threshold + duration, queue depth warning, delivery
+mechanism named. Launch dashboards — minimum required panels named, tool named, owner named.
+Retention — log retention duration, trace retention duration, compliance alignment.]
+
+## Development Methodology
+[Contract-first, TDD, vertical slices, spec layers, quality gates — the full
+process, not just labels]
+
+## Phasing
+[Phase breakdown with feature allocation, dependency order, and timeline estimates.
+Each phase has explicit entry/exit criteria. For multi-surface: per-surface or
+cross-surface phasing strategy.]
+
+## Directory Structure
+[The approved source directory tree from Step 9.5, with one-line descriptions per directory.
+Includes: contracts directory path, test layout, build output path, surface subtrees for multi-surface projects.]
+
+## Architecture Separation
+[The concern/location/runtime table from Step 9.5 — maps each architectural concern to its
+directory and the runtime where it executes.]
+
+## Installed Skills
+[List of skills installed during this workflow with versions]
+
+## Decisions Log
+[Every decision made during this workflow with rationale — not just what was
+decided, but what alternatives were considered and why they were rejected]
+
+## Open Questions
+[Anything needing resolution before decomposition — with owner and deadline]
+```

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

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

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

@@ -0,0 +1,107 @@
+# BE Spec Template
+
+Use this template when writing BE specs to `docs/plans/be/[NN-feature-name].md`.
+
+```markdown
+# [Feature] — Backend Specification
+
+> **IA Source**: [link to IA shard]
+> **Deep Dives**: [links to consumed deep dives, if any]
+> **Status**: Draft | Review | Complete
+
+## Split Group _(include only if this spec resulted from a split)_
+
+> **Split origin**: [IA shard that was split, e.g., `09-messaging`]
+> **Companion specs**: [sibling BE spec files, e.g., `09b-agent-flow-api.md`]
+> **Shared entities**: [data models shared across companions, e.g., `Message`, `Thread`]
+
+## IA Source Map
+
+[Which IA shard sections, deep dives, and cross-shard references
+inform each part of this BE spec. This is the traceability record
+that lets a reviewer verify nothing was missed or invented.]
+
+| BE Spec Section | IA Source | Section/Lines |
+|-----------------|----------|---------------|
+| API Endpoints | [primary-shard.md] | § User Flows |
+| Database Schema | [primary-shard.md] | § Data Model |
+| Middleware | [cross-ref-shard.md] | § Access Control (lines N–M) |
+| Error Handling | [primary-shard.md] | § Edge Cases |
+| [specific subsystem] | [deep-dive.md] | § Key Decisions |
+
+## API Endpoints
+## Request/Response Contracts ({{CONTRACT_LIBRARY}} schemas)
+## Database Schema
+## Middleware & Policies
+## Data Flow
+## Error Handling
+## Open Questions
+
+## Changelog
+
+| Date | Change | Workflow | Sections Affected |
+|------|--------|----------|-------------------|
+| [date] | Initial creation | /write-be-spec | All |
+```
+
+## Quality Gates Checklist
+
+Apply after writing every BE spec:
+
+- [ ] Every endpoint has a {{CONTRACT_LIBRARY}} request AND response schema
+- [ ] Every database table has defined fields, indexes, and permissions
+- [ ] Security constraints from IA shard reflected in middleware section
+- [ ] Error codes are specific (not generic 500s)
+- [ ] Rate limits specified per endpoint
+- [ ] Access control requirements mapped to middleware checks
+- [ ] Every deep dive key decision is reflected in the spec (not ignored)
+- [ ] Every cross-shard reference has been resolved (no dangling pointers)
+- [ ] IA Source Map is complete — no BE spec section lacks a traceable IA source
+- [ ] Testability criteria from IA shard reflected as performance targets
+
+## BE Spec Seed Stub
+
+Use when creating a spec file during classification:
+
+```markdown
+# [Feature] — Backend Specification
+
+> **IA Source**: [link to IA shard]
+> **Deep Dives**: [links, if any]
+> **Status**: Classifying
+
+## Classification
+- **Type**: [single-domain | multi-domain-split | cross-cutting | structural reference]
+- **IA Source**: [shard name]
+- **BE Spec(s) to produce**: [list]
+
+## Referenced Material Inventory
+[Primary shard, cross-refs with file + section + line numbers]
+```
+
+## FE Spec Seed Stub
+
+Use when creating a spec file during FE classification:
+
+```markdown
+# [Feature] — Frontend Specification
+
+> **BE Source**: [link to BE spec(s)]
+> **IA Source**: [link to IA shard]
+> **Status**: Classifying
+
+## Classification
+- **Type**: [feature spec | cross-cutting]
+- **BE Source(s)**: [list]
+- **IA Source**: [shard name]
+
+## Referenced Material Inventory
+[same format as BE classify stub]
+
+## Design Requirements (extracted from brand-guidelines)
+**Direction**: [confirmed direction]
+**Typography**: [extracted]
+**Colors**: [extracted]
+**Motion**: [extracted]
+**Anti-patterns**: [extracted]
+```

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

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

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

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

package/template/.claude/skills/prd-templates/references/data-placement-template.md

@@ -0,0 +1,74 @@
+# Data Placement Strategy Template
+
+Use this template to create `docs/plans/data-placement-strategy.md` during `/create-prd-architecture`.
+
+```markdown
+# Data Placement Strategy
+
+## N-Tier Model Responsibilities
+
+Define each tier in the system and what it is responsible for:
+
+| Tier | Responsibility | Examples |
+|------|---------------|----------|
+| [Client / Edge / API / Database / Cache / Object Storage / External Service] | [What this tier owns and manages] | [Specific technologies] |
+
+## Complete Data Placement Map
+
+For every data type in the system, specify its canonical owner:
+
+| Data Type | Canonical Owner | Stored Content | Encryption | Rationale |
+|-----------|----------------|----------------|------------|-----------|
+| [e.g., User profile] | [e.g., Database] | [Fields stored] | [at-rest / in-transit / both / none] | [Why this placement] |
+| [e.g., Session tokens] | [e.g., Cache] | [Token data] | [encryption approach] | [Why this placement] |
+| [e.g., Uploaded files] | [e.g., Object storage] | [File content + metadata] | [encryption approach] | [Why this placement] |
+
+## Security Boundaries
+
+For each tier, explicitly state what it stores AND what it does NOT store:
+
+| Tier | Stores | Does NOT Store |
+|------|--------|---------------|
+| [Client] | [e.g., UI state, cached display data] | [e.g., raw PII, API secrets, decryption keys] |
+| [Edge/CDN] | [e.g., static assets, cached public responses] | [e.g., user-specific data, PII] |
+| [API Server] | [e.g., request context, short-lived auth tokens] | [e.g., persistent user data, raw credentials] |
+| [Database] | [e.g., user records, PII (encrypted)] | [e.g., API secrets, session tokens] |
+| [Cache] | [e.g., computed values, session data] | [e.g., PII, source-of-truth records] |
+
+## PII Boundaries
+
+- Which fields contain PII (enumerate every one)
+- Where PII is stored vs where it is NOT stored
+- How PII is isolated from AI/analytics pipelines
+- PII access logging requirements
+
+## GDPR/Compliance Data Lifecycle
+
+| Data Category | Retention Period | Deletion Trigger | Deletion Responsibility | Verification |
+|--------------|-----------------|-----------------|------------------------|-------------|
+| [e.g., Account data] | [e.g., Account lifetime + 30 days] | [e.g., Account deletion request] | [e.g., API server → database cascade] | [How deletion is verified] |
+| [e.g., Usage analytics] | [e.g., 90 days] | [e.g., TTL expiry] | [e.g., Database auto-purge] | [How deletion is verified] |
+
+## Tenancy Model
+
+[Single-tenant / Multi-tenant / Hybrid]
+- Isolation mechanism: [e.g., row-level security, schema-per-tenant, database-per-tenant]
+- Data co-mingling rules: [What data is shared vs isolated]
+- Cross-tenant query prevention: [How enforced]
+
+## Sync Protocol (multi-surface only)
+
+- What data syncs between surfaces
+- Sync frequency and mechanism
+- Conflict resolution strategy
+- Network partition behavior
+
+## Summary Table
+
+| Layer | Stores | Does NOT Store |
+|-------|--------|---------------|
+| [Layer 1] | [List] | [List] |
+| [Layer 2] | [List] | [List] |
+```
+
+This document is consumed by `/write-be-spec` and `/write-architecture-spec` to ensure every spec places data consistently.

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

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

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

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