cfsa-antigravity 2.19.0 → 2.19.2

package/template/.claude/skills/prd-templates/references/fractal-feature-template.md

@@ -0,0 +1,93 @@
+# Feature: {Feature Name}
+
+> **Number**: {NN.NN.NN}
+> **Parent**: [{sub-domain-name}](./{sub-domain}-index.md)
+> **Status**: [SURFACE] / [PARTIAL] / [DEEP] / [EXHAUSTED]
+> **Last updated**: {timestamp}
+
+## Overview
+
+_What this feature is, why it exists, what user problem it solves. 2-3 sentences._
+
+## Role Lens
+
+| Role | Access | What They See/Do |
+|------|--------|-------------------|
+| {Persona 1} | Full | _specific behavior for this role — actions, views, capabilities_ |
+| {Persona 2} | Config | _specific behavior — what they configure, what they see_ |
+| {Persona 3} | Read-only | _specific behavior — what they can view, what's hidden_ |
+| {Persona 4} | None | _not visible — brief note on why or what they see instead_ |
+
+> **Access levels**: Full · Config · Read-only · Reports · None
+>
+> **Rules:**
+> - Every feature file MUST have a Role Lens table — no exceptions
+> - Use persona names from `meta/personas.md`
+> - "What They See/Do" must be SPECIFIC to this feature, not generic role descriptions
+> - If a persona has "None" access, still list them — the explicit absence is valuable for downstream spec writers
+> - This is the implementation-ready detail that IA/BE/FE spec writers consume directly
+
+## Behavior
+
+_Detailed description of the feature's behavior._
+
+### Happy Path
+
+_Step-by-step user interaction for the normal/expected case. Number each step._
+
+1. _User does X_
+2. _System responds with Y_
+3. _User confirms Z_
+4. _System completes action, shows confirmation_
+
+### Edge Cases / Failure Modes
+
+| Scenario | What Happens | User Sees |
+|----------|-------------|-----------|
+| _edge case 1_ | _system behavior_ | _error message or fallback UI_ |
+| _edge case 2_ | _system behavior_ | _error message or fallback UI_ |
+
+### States
+
+| State | Trigger | What User Sees |
+|-------|---------|---------------|
+| Loading | _action initiated_ | _spinner, skeleton, progress bar_ |
+| Empty | _no data exists yet_ | _empty state with CTA_ |
+| Populated | _data loaded_ | _populated view_ |
+| Error | _request failed_ | _error message with retry option_ |
+| Partial | _incomplete data_ | _partial view with missing-data indicator_ |
+
+## Deep Think Annotations
+
+| # | Hypothesis | Source | Outcome |
+|---|-----------|--------|---------|
+| DT-01 | _hypothesis about what this feature needs_ | _reasoning or industry precedent_ | ✅ CONFIRMED / ❌ REJECTED: _reason_ |
+
+> Log every Deep Think hypothesis — both confirmed and rejected. This is the audit trail showing the agent explored beyond the obvious.
+
+## Cross-Cut Notes
+
+_Quick references to how this feature interacts with features in other domains/sub-domains. These are pointers — detailed cross-cut analysis lives in the parent's CX file._
+
+- Touches **{Domain/Sub-domain/Feature}** ([path](../../../path)) — _why: shared entity, trigger dependency, permission, etc._
+- Consumed by **{Surface/Domain}** via API — _why: spoke surface reads this data through platform API_
+
+> For detailed cross-cut analysis (synthesis questions, role scoping), see the CX file at the appropriate level.
+
+## Decisions
+
+| # | Decision | Context |
+|---|----------|---------|
+| D-01 | _what was decided_ | _why this was the right call_ |
+
+## Open Questions
+
+| # | Question | Owner | Deferred To |
+|---|----------|-------|-------------|
+| Q-01 | _question_ | User / Agent / /create-prd | _pipeline stage_ |
+
+> **Notes for agents:**
+> - Feature files are LEAF NODES — they are `.md` files, never folders
+> - If a feature reveals 2+ interacting capabilities during drilling, it should be PROMOTED to a sub-domain (see Reactive Depth Protocol in `idea-extraction/SKILL.md`)
+> - Status markers: `[SURFACE]` = identified only, `[PARTIAL]` = some depth, `[DEEP]` = all sections filled with edge cases, `[EXHAUSTED]` = Deep Think yields zero hypotheses + user confirms nothing missing
+> - The Role Lens is the PRIMARY output consumed by `/write-fe-spec` and `/write-be-spec` — make it thorough

package/template/.claude/skills/prd-templates/references/fractal-node-index-template.md

@@ -0,0 +1,55 @@
+# {Node Name} — Index
+
+> **Level**: {surface | domain | sub-domain}
+> **Parent**: [{parent-name}](../{parent}-index.md)
+> **Status**: [SURFACE] / [BREADTH] / [DEEP] / [EXHAUSTED]
+> **Last updated**: {timestamp}
+
+## Overview
+
+_What this node contains and why it exists. 2-3 sentences describing the domain or sub-domain's purpose and scope._
+
+## Children
+
+| # | Name | Type | Path | Status | Deep Think |
+|---|------|------|------|--------|------------|
+| 01 | _{child-name}_ | domain / sub-domain / feature | [01-slug](./01-slug/) or [01.01-slug.md](./01.01-slug.md) | [SURFACE] | _N hypotheses_ |
+| 02 | ... | ... | ... | ... | ... |
+
+> **Type column values:**
+> - `domain` — a top-level grouping within a surface (folder with index + CX)
+> - `sub-domain` — a grouping within a domain that has 2+ interacting capabilities (folder with index + CX)
+> - `feature` — a leaf node describing a single capability (.md file)
+
+## Role Matrix
+
+| Child | {Persona 1} | {Persona 2} | {Persona 3} | {Persona 4} |
+|-------|-------------|-------------|-------------|-------------|
+| 01-child | ✅ Full | ⚙️ Config | 👁️ View | ❌ None |
+| 02-child | ✅ Full | ✅ Full | ❌ None | ❌ None |
+
+> **Legend**: ✅ Full access · ⚙️ Configuration only · 👁️ Read-only · 📊 Reports only · ❌ No access
+>
+> **Rules:**
+> - Persona names come from `meta/personas.md` — use short names (e.g., "Tech", "Owner", "CSR", "Consumer")
+> - NEVER redefine a persona here — reference only
+> - Only list children that exist — the matrix grows as children are added
+> - Access icons are shorthand; detailed per-role behavior lives in each feature file's **Role Lens**
+
+## Decision Log
+
+| # | Decision | Context | Source |
+|---|----------|---------|--------|
+| D-01 | _what was decided_ | _why this was the right call_ | _conversation / document / user directive_ |
+
+## Open Questions
+
+| # | Question | Owner | Deferred To |
+|---|----------|-------|-------------|
+| Q-01 | _question_ | User / Agent / /create-prd | _pipeline stage_ |
+
+> **Notes for agents:**
+> - This template is used at EVERY folder level in the fractal structure (surface, domain, sub-domain)
+> - The content differs by level — a surface index lists domains, a domain index lists sub-domains/features
+> - Status propagates upward: all children `[EXHAUSTED]` → node is `[EXHAUSTED]`; all `[DEEP]`+ → node is `[DEEP]`
+> - When adding a new child, update BOTH the Children table AND the Role Matrix

package/template/.claude/skills/prd-templates/references/gate-applicability.md

@@ -0,0 +1,92 @@
+# Gate Applicability Reference
+
+Reference for `/validate-phase-readiness` Step 5.85. Defines which readiness gates apply based on phase content.
+
+## Content Classification Table
+
+Read the phase plan and completed slices. Determine which content categories are present:
+
+| Content Category | How to Detect | Gates It Triggers |
+|-----------------|---------------|-------------------|
+| **New/modified API endpoints** | BE spec slices, new route files, new controllers | 5.9 (API docs), 8 (Security — full) |
+| **New/modified UI components** | FE spec slices, new component files, new pages/routes | 6 (Accessibility), 7a (Performance — Web Vitals/Bundle) |
+| **New/modified data models** | Schema changes, new migrations, new DB queries | 7a (Performance — DB Query Time), 8 (Security — data flow) |
+| **Infrastructure-only changes** | CI/CD config, hosting config, env vars, no app code | Skip 5.9, 6; apply 8 (infra security only) |
+| **Auth/security changes** | Auth middleware, RBAC, token handling, secrets | 8 (Security — mandatory, elevated priority) |
+
+## Gate Applicability Table Template
+
+Build this table for each phase:
+
+```markdown
+| Gate | Applies? | Reason |
+|------|----------|--------|
+| 5.9 API Documentation | Yes/No/Deferred | [why] |
+| 6 Accessibility | Yes/No/Deferred | [why] |
+| 7a Performance Budget | Yes/No/Deferred | [why] |
+| 7b Deep Performance | Yes/No/Deferred | [why] |
+| 8 Security Review | Always Yes | Core audit always runs |
+| 8.5 Dependency Audit | Always Yes | Always runs |
+| 8.7 Feature Ledger | Always Yes | Always runs (if ledger exists) |
+| 8.8 Boundary Stub Audit | Always Yes | Always runs |
+```
+
+## Always-On Gates (never skippable)
+
+- **8 Security Review** — Core adversarial review + defense-in-depth always runs. DAST scan is conditional on having a staging deployment with endpoints.
+- **8.5 Dependency Audit** — Always runs.
+- **8.7 Feature Ledger Reconciliation** — Always runs (if ledger exists).
+- **8.8 Boundary Stub Audit** — Always runs.
+
+## Content-Triggered Gates (skip when content category is absent)
+
+- **5.9 API Documentation** — Skip if no new/modified API endpoints in this phase.
+- **6 Accessibility** — Skip if no new/modified UI components in this phase.
+- **7a Performance Budget (Web Vitals/Bundle)** — Skip if no UI changes. DB Query Time sub-gate skips if no new queries/models.
+- **7b Deep Performance** — Skip if no performance-critical changes.
+
+## Deferred Gate Rules
+
+A gate may be **deferred** (not skipped) when:
+- The gate applies but a prerequisite is not yet available (e.g., staging deployment not configured yet for DAST)
+- The phase is early infrastructure and the gate will apply to the next phase that adds the relevant content
+
+**Hard deadline required**: Specify which phase or milestone must run the deferred gate. Log deferred gates in `docs/audits/phase-N-validation.md` with the deadline.
+
+**Single-deferral limit**: A gate may NOT be deferred more than once. If a previously deferred gate's deadline arrives, it MUST run — no further deferral.
+
+## Validation Report Structure
+
+### Gate Applicability Summary
+
+Include the gate applicability table. For each gate, report one of:
+- **Applied** — gate ran, results follow
+- **Skipped** — gate did not apply to this phase (with reason)
+- **Deferred** — gate applies but prerequisite missing (with hard deadline)
+
+### Applied Gate Results
+
+Report only for gates that were applied:
+- Test results and coverage
+- Lint and type-check status
+- Build status
+- Accessibility findings (if gate applied)
+- Performance budget results 7a and deep audit findings 7b (if gate applied)
+- Security review findings (including DAST results if applicable)
+- Dependency audit results
+- API documentation sync status (if gate applied)
+- Deployment strategy compliance (if applicable)
+- CI/CD pipeline status, staging deployment result, migration verification status
+
+### Deferred Gates Section
+
+For each deferred gate:
+- Gate name and step number
+- Reason for deferral
+- Hard deadline (phase number or milestone)
+- Whether this is the first deferral (second deferral is forbidden)
+
+### Verdict
+
+- Pass/fail verdict
+- If any gates were deferred: "Phase N passes with deferred gates. Deferred gates MUST run by [deadline]."

package/template/.claude/skills/prd-templates/references/ideation-crosscut-template.md

@@ -0,0 +1,36 @@
+# Global Cross-Cuts — {{PROJECT_NAME}}
+
+> **Scope**: Cross-surface interactions for multi-product projects, or cross-domain interactions for single-surface projects.
+> **Format**: Index + one-line summary. Detailed synthesis lives in lower-level CX files.
+
+## Cross-Surface Interaction Map
+
+> Each row records that an interaction EXISTS between two surfaces or top-level domains. The Detail column links to the lower-level CX file where the full synthesis questions are answered.
+
+| # | Source Surface/Domain | Target Surface/Domain | Summary | Roles | Detail |
+|---|----------------------|----------------------|---------|-------|--------|
+| CX-01 | _Web / Consumer Platform_ | _Desktop / Shop Ops_ | _Desktop diagnostic workflow consumes web supplier data via API_ | Tech, Owner | [detail](surfaces/desktop/desktop-cx.md#CX-03) |
+| CX-02 | _Web / Device History_ | _Mobile / Device Guardian_ | _Mobile app syncs with web device history for owner verification_ | Consumer | [detail](surfaces/mobile/mobile-cx.md#CX-01) |
+
+> **Rules:**
+> - This file is an INDEX with one-line summaries — not the source of truth for cross-cut details
+> - Detailed synthesis (5 questions, role scoping) lives in the lower-level CX file linked in the Detail column
+> - For single-surface projects, this file covers cross-DOMAIN interactions (same content as would appear in a surface-level CX)
+> - For multi-product projects, this file covers cross-SURFACE interactions
+> - Use `CX-NN` numbering. This file's entries are distinct from CX entries in lower-level files.
+> - When referencing from other files, use `ideation-cx.md#CX-NN`
+
+## Shared Domain Consumption _(multi-product only)_
+
+> Which shared domains are consumed by which spoke surfaces, and through what mechanism.
+
+| Shared Domain | Owner | Consumed By | Mechanism | Detail |
+|--------------|-------|-------------|-----------|--------|
+| _Device History_ | Web (hub) | Desktop, Mobile | REST API | [web/02-device-history-cx.md](surfaces/web/02-device-history/device-history-cx.md) |
+| _Payments_ | Web (hub) | Desktop | REST API | [web/03-payments-cx.md](surfaces/web/03-payments/payments-cx.md) |
+
+## Rejected Cross-Surface Pairs
+
+| # | Surface A | Surface B | Reason for Rejection |
+|---|-----------|-----------|---------------------|
+| R-01 | _Desktop_ | _Mobile_ | _No direct interaction — both consume web API independently_ |

package/template/.claude/skills/prd-templates/references/ideation-index-template.md

@@ -0,0 +1,111 @@
+# Ideation Index — {{PROJECT_NAME}}
+
+> **Pipeline key file.** All downstream workflows read this index to locate ideation documents.
+> This file is the entry point for `/create-prd`, `/decompose-architecture`, `/audit-ambiguity ideation`, and all other workflows that consume ideation output.
+
+## Project Overview
+
+**Problem**: _One-sentence problem statement — who has it, why it matters._
+
+**One-liner**: _Elevator pitch — what the product does in ≤15 words._
+
+## Expansion Mode
+
+- Type: [full | vertical | horizontal | cross-cutting | combination | as-is]
+- Targets: [list of domains/features to focus on, if applicable]
+- Cross-cut Detection: always-on
+- Deep Think Protocol: active
+
+## Structural Classification
+
+- **Project Shape**: [single-surface | multi-surface-shared | multi-product-hub | multi-product-peer]
+- **Hub Surface** _(hub-and-spoke only)_: [surface name that owns shared domains]
+- **Surfaces**: [list of identified surfaces, e.g., "Web (Astro/React), Desktop (Rust/Tauri), Mobile (React Native)" — or "N/A" for single-surface]
+- **Classification Basis**: [how this was determined — "detected from document", "user interview", "inferred from one-liner"]
+
+> **Project Shapes:**
+> - `single-surface` — One platform. Domains are top-level children of `ideation/`.
+> - `multi-surface-shared` — 2+ platforms, same stack, >80% shared logic. Domains at top level with surface annotations.
+> - `multi-product-hub` — 2+ platforms, one is the central platform/API. Hub owns shared domains. Spokes reference via CX.
+> - `multi-product-peer` — 2+ platforms, no primary. `shared/` folder as a peer for cross-surface domains.
+
+## Progress Summary
+
+| Metric | Value |
+|--------|-------|
+| Total surfaces | _N_ |
+| Total domains | _N_ |
+| Total leaf features | _N_ |
+| Max depth reached | _N_ |
+| Leaf nodes at [SURFACE] | _N_ |
+| Leaf nodes at [DEEP] | _N_ |
+| Leaf nodes at [EXHAUSTED] | _N_ |
+| CX entries confirmed | _N_ |
+| Deep Think hypotheses confirmed | _N_ |
+| Deep Think hypotheses rejected | _N_ |
+
+## Document Map
+
+> Downstream workflows: read this table to find the specific file you need.
+
+### Meta Documents
+
+| Document | Path | Status |
+|----------|------|--------|
+| Problem Statement | [problem-statement.md](meta/problem-statement.md) | _status_ |
+| Personas | [personas.md](meta/personas.md) | _status_ |
+| Competitive Landscape | [competitive-landscape.md](meta/competitive-landscape.md) | _status_ |
+| Constraints | [constraints.md](meta/constraints.md) | _status_ |
+
+### Global Cross-Cuts
+
+| Document | Path |
+|----------|------|
+| Global Cross-Cuts | [ideation-cx.md](ideation-cx.md) |
+
+### Structure Map
+
+> **For single-surface projects**, domains are listed directly below.
+> **For multi-product projects**, expand each surface section.
+> Every domain below is a FOLDER containing: `{domain}-index.md`, `{domain}-cx.md`, and child features/sub-domains.
+
+#### _{Surface Name or "Top-Level Domains" for single-surface}_
+
+| # | Domain | Path | Status | Children | Depth | Deep Think |
+|---|--------|------|--------|----------|-------|------------|
+| 01 | _Domain Name_ | [01-slug/](./01-slug/) | `[SURFACE]` | _N children_ | _N levels_ | _N hypotheses_ |
+
+_Repeat surface sections for multi-product projects._
+
+#### Hub-Owned Shared Domains _(hub-and-spoke only)_
+
+_Shared domains live inside the hub surface's domain tree. Listed here for visibility._
+
+| # | Domain | Hub Path | Consumed By | Status |
+|---|--------|----------|-------------|--------|
+| NN | _Domain Name_ | [web/NN-slug/](surfaces/web/NN-slug/) | Desktop, Mobile | `[SURFACE]` |
+
+## Decision Log
+
+Numbered decisions with source references.
+
+| # | Decision | Source | Domain |
+|---|----------|--------|--------|
+| D-01 | _Decision description_ | _Discussion context_ | [domain-index.md](./path) |
+
+## MoSCoW Summary
+
+> Features reference their fractal path. Path format: `{surface}/{domain}.{sub-domain}.{feature}`
+
+### Must Have
+- _Feature 1_ → `web/01.02.01` ([link](./path/01.02.01-feature.md))
+- _Feature 2_ → `desktop/01.01.03` ([link](./path/01.01.03-feature.md))
+
+### Should Have
+- _Feature 3_ → `web/02.01` ([link](./path))
+
+### Could Have
+- _Feature 4_ → `desktop/01.03.02.04` ([link](./path))
+
+### Won't Have (Now)
+- _Feature 5_ — Reason for exclusion

package/template/.claude/skills/prd-templates/references/ideation-meta-template.md

@@ -0,0 +1,126 @@
+# Ideation Meta Document Templates
+
+> These are the templates for the `ideation/meta/` directory.
+> Each meta file captures product-level information that isn't domain-specific.
+
+---
+
+## problem-statement.md
+
+```markdown
+# Problem Statement
+
+## The Problem
+
+_One sentence: what problem exists, who has it, and why current solutions fail._
+
+## Why It Matters
+
+_Market size, pain severity, frequency of occurrence._
+
+## Why Now
+
+_What has changed that makes this solvable or valuable today._
+
+## Root Cause
+
+_The underlying cause, not just the symptom. Why do current solutions fail?_
+```
+
+---
+
+## personas.md
+
+```markdown
+# User Personas
+
+> Every persona must have all 6 fields. Do not proceed to features until all personas
+> are complete. See Vision Rubric Dimension 2.
+
+## Persona: {{Name}}
+
+| Field | Detail |
+|-------|--------|
+| **Name + Role** | _Named role with context — not "a user"_ |
+| **Primary Pain Point** | _Specific friction in one sentence_ |
+| **Current Workaround** | _Exact tool, process, or coping mechanism today_ |
+| **Success Criteria** | _What "solved" looks like, measurable if possible_ |
+| **Switching Trigger** | _What event/threshold makes them switch_ |
+| **Unique Constraint** | _What makes their situation different from other personas_ |
+
+### Workflow
+
+_Primary workflow through the product — step by step._
+
+### Anti-Persona Behavior
+
+_Worst thing they could intentionally do. Worst thing they could accidentally do._
+
+---
+
+_Repeat for each persona (2-4 recommended)._
+```
+
+---
+
+## competitive-landscape.md
+
+```markdown
+# Competitive Landscape
+
+## Top Competitors
+
+| Competitor | What They Do | Strength | Weakness | Our Angle |
+|-----------|-------------|----------|----------|-----------|
+| _Name_ | _Description_ | _Why users choose them_ | _Where they fall short_ | _How we differentiate_ |
+
+## Unique Differentiators
+
+1. _Differentiator 1_ — why this matters to our personas
+2. _Differentiator 2_ — why this is hard to copy
+
+## Moat
+
+_What makes this defensible over time? Network effects, data, expertise, switching costs?_
+```
+
+---
+
+## constraints.md
+
+```markdown
+# Project Constraints
+
+## Budget
+- _Self-funded / VC-backed / enterprise budget_
+- _Monthly infrastructure ceiling_
+
+## Timeline
+- _Launch target_
+- _Phased rollout plan_
+
+## Team
+- _Solo dev / small team / full org_
+- _Skill gaps, if any_
+
+## Compliance
+- _GDPR / PCI / COPPA / HIPAA / SOC 2 / Other_
+- _Age restrictions_
+
+## Performance
+- _Expected scale (users, requests, data volume)_
+- _Latency requirements_
+
+## Project Surfaces
+
+| Surface | Type | Cross-Platform? | Notes |
+|---------|------|----------------|-------|
+| _Web app_ | _SPA / SSR / Static_ | N/A | _Primary surface_ |
+| _Desktop_ | _Tauri / Electron_ | _Yes/No_ | _Offline capability_ |
+| _Mobile_ | _Native / RN / PWA_ | _Yes/No_ | |
+| _API_ | _REST / GraphQL / tRPC_ | N/A | |
+| _CLI_ | _Yes/No_ | _Yes/No_ | |
+
+> Surface classification drives tech stack in `/create-prd`, folder structure in
+> `/decompose-architecture`, and spec shapes downstream.
+```

package/template/.claude/skills/prd-templates/references/infrastructure-report-template.md

@@ -0,0 +1,71 @@
+# Infrastructure Verification Report Template
+
+Use this template when creating the report during `/verify-infrastructure`.
+
+## Initial Report (Step 0.6)
+
+Create at `docs/audits/verify-infrastructure-YYYY-MM-DD-HHMM[-auth].md`:
+
+```markdown
+# Infrastructure Verification Report
+
+**Date**: YYYY-MM-DD HH:MM
+**Trigger**: [infrastructure slice | auth slice]
+**Verdict**: ⏳ in-progress
+
+## Results
+
+| # | Check | Status | Notes |
+|---|-------|--------|-------|
+| 0 | Placeholder audit | ⏳ | |
+| 1 | CI/CD config | ⏳ | |
+| 2 | CI/CD green | ⏳ | |
+| 3 | Environment audit | ⏳ | |
+| 4 | Migration check | ⏳ | |
+| 5 | Staging deployment | ⏳ | |
+| 6 | Auth smoke test | ⏳ | |
+| 6.5 | Logging gate | ⏳ | |
+| 6.6 | Error tracking gate | ⏳ | |
+
+## Failures (if any)
+
+None yet.
+
+## Next Steps
+
+In progress.
+```
+
+## Final Report (Step 8)
+
+Update the same file — change the Verdict and fill in results:
+
+```markdown
+# Infrastructure Verification Report
+
+**Date**: YYYY-MM-DD
+**Trigger**: [infrastructure slice | auth slice]
+**Verdict**: [PASS | FAIL]
+
+## Results
+
+| # | Check | Status | Notes |
+|---|-------|--------|-------|
+| 0 | Placeholder audit | ✅/❌ | |
+| 1 | CI/CD config | ✅/❌ | |
+| 2 | CI/CD green | ✅/❌ | |
+| 3 | Environment audit | ✅/❌ | |
+| 4 | Migration check | ✅/❌ | |
+| 5 | Staging deployment | ✅/❌ | |
+| 6 | Auth smoke test | ✅/❌/⏭️ | |
+| 6.5 | Logging gate | ✅/❌ | |
+| 6.6 | Error tracking gate | ✅/❌ | |
+
+## Failures (if any)
+
+[Details of any failing checks]
+
+## Next Steps
+
+[What to do next based on the verdict]
+```

package/template/.claude/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/.claude/skills/prd-templates/references/map-guard-protocol.md

@@ -0,0 +1,65 @@
+# Map Guard Protocol
+
+**Purpose**: Enforce strict surface stack map verification before any workflow step that depends on tech stack decisions. Auto-recover when possible, hard stop when not.
+
+---
+
+## 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. Classify Empty Cells
+
+**If ALL required cells are filled** → proceed. No action needed.
+
+**If ANY required cell is empty** → classify each empty cell:
+
+| Empty Cell | Recovery Action | Auto-Recoverable? |
+|---|---|---|
+| Languages / Frameworks / Databases / ORMs | Run `/bootstrap-agents` with confirmed values from `architecture-draft.md` | **YES** — auto-invoke |
+| Auth / Security | Run `/bootstrap-agents` with confirmed values from `architecture-draft.md` | **YES** — auto-invoke |
+| CI/CD / Hosting | Run `/bootstrap-agents` with confirmed values from `architecture-draft.md` | **YES** — auto-invoke |
+| Commands section | Run `/bootstrap-agents` | **YES** — auto-invoke |
+| `patterns.md` | Run `/bootstrap-agents-provision` | **YES** — auto-invoke |
+| `structure.md` | Run `/create-prd-compile` Step 9.5 | **NO** — hard stop |
+| Cells requiring decisions not yet made | Run `/create-prd-stack` | **NO** — hard stop |
+
+### 4. Auto-Recovery (for YES cells)
+
+If the empty cells are auto-recoverable:
+
+1. **Read `docs/plans/architecture-draft.md`** — extract confirmed tech stack decisions (languages, frameworks, databases, ORMs, hosting, auth, CI/CD)
+2. **Build the bootstrap key set** from confirmed decisions
+3. **Execute `/bootstrap-agents`** with those keys — read `.agent/workflows/bootstrap-agents.md` and run BOTH shards (fill + provision)
+4. **Re-read the surface stack map** after bootstrap completes
+5. **Re-check the required cells** — if now filled → proceed. If still empty → escalate to hard stop (Step 5)
+
+> This auto-recovery fires silently. Do NOT ask the user "should I run bootstrap?" — just run it. Bootstrap is idempotent and safe.
+
+### 5. Hard Stop (for NO cells or failed auto-recovery)
+
+> **HARD STOP** — The surface stack map has empty cells that cannot be auto-recovered.
+>
+> | Empty Cell | Required Action |
+> |---|---|
+> | [cell name] | [what needs to happen] |
+>
+> Do NOT proceed. Do NOT use conversation-confirmed values. Do NOT apply timing fallbacks.
+
+---
+
+## 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 and auto-recovery fails, the upstream workflow that should have filled it has a bug. Surface the bug, don't work around it.