cfsa-antigravity 2.0.0 → 2.1.0

package/template/.agent/workflows/evolve-contract.md

@@ -1,5 +1,5 @@
 ---
-description: Safely evolve a Zod schema — identify all consumers, write migration tests, update across all four surfaces
+description: Safely evolve a {{CONTRACT_LIBRARY}} schema — identify all consumers, write migration tests, update across all four surfaces
 pipeline:
   position: utility
   stage: maintenance
@@ -11,7 +11,7 @@ pipeline:
 
 # Evolve Contract
 
-Safely modify a Zod schema without breaking existing consumers.
+Safely modify a {{CONTRACT_LIBRARY}} schema without breaking existing consumers.
 
 **Input**: The contract to change and the desired modification
 **Output**: Updated contract, migration tests, and all consumers updated
@@ -44,9 +44,9 @@ Read these skills for safe schema migration:
 
 ## 1. Identify the contract
 
-Read .agent/skills/{{LANGUAGE_SKILL}}/SKILL.md and follow its language conventions.
+Determine which surface this contract belongs to (from the file path or calling context). Load the Languages skill(s) from that surface's row per the skill loading protocol (`.agent/skills/prd-templates/references/skill-loading-protocol.md`).
 
-Determine which Zod schema needs to change and what the change is:
+Determine which {{CONTRACT_LIBRARY}} schema needs to change and what the change is:
 - **Additive** (new optional field) — Low risk
 - **Narrowing** (tighter validation) — Medium risk
 - **Breaking** (rename, remove, type change) — High risk
@@ -77,32 +77,32 @@ If a new API version is needed, document the versioning approach (URL prefix, he
 
 Read .agent/skills/tdd-workflow/SKILL.md and follow its Red→Green→Refactor cycle for contract evolution.
 
-Read .agent/skills/{{UNIT_TESTING_SKILL}}/SKILL.md and follow its test writing conventions.
+Load the Unit Tests skill(s) from this contract's surface row per the skill loading protocol.
 
 Before changing anything, write tests that validate:
 - Existing data still passes the new schema (backward compatibility)
 - New data shape is accepted
 - Invalid data is rejected
 
-Run `{{TEST_COMMAND}}` — tests should FAIL until the schema is updated.
+Run the Test Cmd from this contract's surface row in the surface stack map (see `.agent/instructions/tech-stack.md`) — tests should FAIL until the schema is updated.
 
 ## 4. Update the contract
 
-Read .agent/skills/{{LANGUAGE_SKILL}}/SKILL.md and follow its language conventions.
+Load the Languages skill(s) from this contract's surface row per the skill loading protocol.
 
-Modify the Zod schema. For breaking changes:
+Modify the {{CONTRACT_LIBRARY}} schema. For breaking changes:
 - Consider versioning (v1 → v2)
 - Add runtime migration helpers if needed
 
 ## 4.5. New dependency check
 
-If the contract change introduces a dependency not currently in the skill set — for example, a new Zod plugin, a Pydantic extension, a binary serialization library, or a new validation pattern — read `.agent/workflows/bootstrap-agents.md` and invoke `/bootstrap-agents NEW_DEPENDENCY=[package]` before updating consumers in Step 5.
+If the contract change introduces a dependency not currently in the skill set — for example, a new validation library plugin, a schema extension, a binary serialization library, or a new validation pattern — read `.agent/workflows/bootstrap-agents.md` and invoke `/bootstrap-agents NEW_DEPENDENCY=[package]` before updating consumers in Step 5.
 
 Confirm the matching skill is installed (or no new dependency was introduced) before proceeding to Step 5.
 
 ## 5. Update all consumers
 
-Read .agent/skills/{{LANGUAGE_SKILL}}/SKILL.md and follow its language conventions.
+Load the Languages skill(s) from this contract's surface row per the skill loading protocol.
 
 For each consumer found in Step 2:
 - Update the code to use the new schema shape
@@ -110,7 +110,7 @@ For each consumer found in Step 2:
 
 ## 6. Validate
 
-Run `{{VALIDATION_COMMAND}}` (see `.agent/instructions/commands.md` for the configured validation command).
+Run the Validation Cmd from this contract's surface row in the surface stack map (see `.agent/instructions/tech-stack.md` and `.agent/instructions/commands.md`).
 
 All must pass.
 

package/template/.agent/workflows/ideate-discover.md

@@ -27,19 +27,23 @@ Explore domains through recursive breadth-before-depth with the Deep Think proto
 
 Read `.agent/skills/idea-extraction/SKILL.md` and follow its Recursive Domain Exhaustion Protocol and Deep Think Protocol.
 
-Read the `## Expansion Mode` section from `docs/plans/ideation/ideation-index.md` and route accordingly. All findings are written to the appropriate files in `docs/plans/ideation/` in real time — not held in context.
+Read the `## Expansion Mode` and `## Structural Classification` sections from `docs/plans/ideation/ideation-index.md`. The expansion mode shapes exploration behavior. The structural classification determines where domain files are created.
+
+> **Multi-product projects:** When creating domain files, always check whether the domain belongs to a specific surface or is shared. Use `surfaces/{name}/` for surface-exclusive domains and `domains/` for shared/cross-cutting domains. Ask the user if placement is unclear.
 
 ### Full Mode (recommended for 3+ domains)
 
 #### Level 0 — Global Domain Map
 
-1. Read `ideation-index.md` for currently identified domains
+1. Read `ideation-index.md` for currently identified domains and structural classification
 2. Apply the idea-extraction skill's Deep Think Protocol:
    - "Based on this product type and industry, what domains would I expect to see that haven't been mentioned?"
    - Present hypotheses to user for confirmation or rejection
-3. For each confirmed domain, create a domain file in `domains/` using the `ideation-domain-template.md`
+3. For each confirmed domain, create a domain file:
+   - **Single-surface**: Create in `domains/` using the `ideation-domain-template.md`
+   - **Multi-product**: Determine placement first — "Does this belong to a specific surface, or is it shared?" Create in `surfaces/{name}/` or `domains/` accordingly.
 4. Note preliminary cross-cuts: "Domain A might touch Domain B because [reason]" → add to `cross-cuts/cross-cut-ledger.md` as **Level 0** entries
-5. Update `ideation-index.md` with the complete domain map
+5. Update `ideation-index.md` with the complete domain map (paths reflect actual folder locations)
 6. **Gate**: Present complete domain map to user. Get confirmation before Level 1.
 
 #### Level 1 — Domain Breadth Sweep
@@ -50,7 +54,7 @@ For each domain (dependency order — foundational first):
 2. **Deep Think**: "Based on this domain in this industry, what sub-areas would an expert expect that haven't been mentioned?" Present hypotheses.
 3. Write the breadth map to the domain file. Mark each sub-area as `[SURFACE]`.
 4. Note cross-cuts at sub-area level → add to ledger as **Level 1** entries
-5. **NEW DOMAINS DISCOVERED?** → Create domain file, update index, loop back to Level 0 for the new domain. Do NOT proceed until domain map is stable.
+5. **NEW DOMAINS DISCOVERED?** → Classify placement (surface-specific or shared), create domain file in the correct folder, update index, loop back to Level 0 for the new domain. Do NOT proceed until domain map is stable.
 6. Mark domain status as `[BREADTH]` in the index
 7. **Gate**: Pause after EACH domain's breadth map. "Here's what I mapped for [Domain]. Anything missing?" Then after ALL domains: "All domains are at BREADTH. Ready to drill?"
 
@@ -67,7 +71,7 @@ For each domain (dependency order), for each sub-area:
 4. Record Deep Think outcomes in the domain file's Deep Think Annotations table
 5. Cross-cuts with evidence → add to ledger as **Level 2+** entries with specific evidence
 6. **NEW SUB-AREAS DISCOVERED?** → Add to domain file breadth map as `[SURFACE]`, complete breadth mapping first, THEN drill
-7. **NEW DOMAINS DISCOVERED?** → Create domain file, update index, loop back to Level 0
+7. **NEW DOMAINS DISCOVERED?** → Classify placement (surface-specific or shared), create domain file in the correct folder, update index, loop back to Level 0
 8. When Deep Think yields zero new hypotheses AND user confirms → mark sub-area `[EXHAUSTED]`
 9. When all sub-areas are `[DEEP]` or `[EXHAUSTED]` → mark domain `[DEEP]` or `[EXHAUSTED]` in index
 10. **Gate**: Pause after each domain is drilled. "Here's what I captured for [Domain]. Anything missing?"

package/template/.agent/workflows/ideate-extract.md

@@ -54,8 +54,41 @@ uses and how the rest of the workflow behaves.
 **For verbal / no input (Interview mode):**
 1. Read `.agent/skills/idea-extraction/SKILL.md` and enter Interview mode
 2. Start with: "In one sentence, what problem does this solve and for whom?"
-3. From that sentence, identify the key nouns — these become initial domains
-4. Proceed to folder seeding (Step 1.5) then domain exploration in `/ideate-discover`
+3. **Immediately after**: Run Structural Classification (Step 1.3) — ask about audiences and surfaces before identifying domains
+4. From that sentence + classification, identify the key nouns — these become initial domains
+5. Proceed to folder seeding (Step 1.5) then domain exploration in `/ideate-discover`
+
+## 1.3. Structural Classification
+
+Read the **Structural Classification Protocol** in `.agent/skills/idea-extraction/SKILL.md`.
+
+This step determines the folder layout for all ideation output. It MUST run **before** any domain files are created (Step 1.5).
+
+**For rich/thin document input:**
+1. Scan the document for surface signals:
+   - Distinct platform names in section headings (e.g., "Consumer Web Platform", "Shop Software")
+   - Different tech stacks per surface (e.g., "Astro for web", "Tauri for desktop")
+   - Surface-exclusive features (e.g., "Board Viewer (desktop only)")
+2. If signals detected → classify as **multi-product**
+3. If no signals → classify as **single-surface**
+4. If ambiguous → ask the user the two classification questions before proceeding
+
+**For interview / verbal input:**
+1. After the opening problem statement, ask:
+   - "Who are the distinct user types or audiences for this?"
+   - "What platforms does this need to live on?" (web, mobile, desktop, API, CLI)
+2. Based on the answers, classify the project shape
+3. If the user's one-liner already specifies a single surface ("make me a website"), classify as **single-surface** without asking
+
+**Record the classification** in `ideation-index.md` under `## Structural Classification`:
+
+```markdown
+## Structural Classification
+
+- **Project Shape**: [single-surface | multi-surface-shared | multi-product]
+- **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"]
+```
 
 ## 1.4. Re-run check
 
@@ -72,7 +105,9 @@ Read `.agent/skills/prd-templates/references/ideation-index-template.md` and the
 
 Read `.agent/skills/technical-writer/SKILL.md` and follow its methodology.
 
-Create the `docs/plans/ideation/` folder structure:
+Read the **Structural Classification** from Step 1.3 and create the appropriate folder structure.
+
+**Single-surface layout** (project shape = `single-surface` or `multi-surface-shared`):
 
 ```
 docs/plans/ideation/
@@ -88,9 +123,31 @@ docs/plans/ideation/
     └── cross-cut-ledger.md
 ```
 
+**Multi-product layout** (project shape = `multi-product`):
+
+```
+docs/plans/ideation/
+├── ideation-index.md
+├── meta/
+│   ├── problem-statement.md
+│   ├── personas.md
+│   ├── competitive-landscape.md
+│   └── constraints.md
+├── surfaces/
+│   ├── {surface-1-name}/
+│   ├── {surface-2-name}/
+│   └── {surface-N-name}/
+├── domains/
+│   └── (shared/cross-cutting domain files)
+└── cross-cuts/
+    └── cross-cut-ledger.md
+```
+
+Create the surface folders based on the surfaces identified in Step 1.3.
+
 **Seeding behavior by input type:**
 
-- **Rich document**: Parse by domain → create one domain file per identified domain → seed each with relevant content from source. Preserve all detail. Add reference at top of index: `> Source: path/to/original.md`. Do not modify the original. Run the **Source → Domain Files fidelity check**: every major section of the source maps to a domain file — nothing dropped during parsing.
+- **Rich document**: Parse by domain → create one domain file per identified domain → seed each with relevant content from source. **For multi-product projects:** place each domain file in the correct surface folder or shared `domains/` folder based on the domain placement rules in the idea-extraction skill. Preserve all detail. Add reference at top of index: `> Source: path/to/original.md`. Do not modify the original. Run the **Source → Domain Files fidelity check**: every major section of the source maps to a domain file — nothing dropped during parsing.
 - **Chat transcript**: Run the noise filter (read full transcript, extract decisions/ideas/rejections, discard filler, present extracted signal to user for confirmation), then create domain files with the clean structured signal. Attribute decisions: `> Decided in conversation: [decision]`.
 - **Thin document**: Create domain files annotated with `[SURFACE]`, `[PARTIAL]`, or `[DEEP]` depth markers per sub-area.
 - **Verbal / one-liner**: Create domain files with scaffolding based on the initial description. Sub-areas are `[SURFACE]` placeholders.

package/template/.agent/workflows/ideate-validate.md

@@ -36,11 +36,11 @@ Explore constraints with the user. Write to `docs/plans/ideation/meta/constraint
 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** — What platforms will this run on? (web, mobile, desktop, CLI, API)
+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 (e.g., what started as single-surface now has a mobile app too)? If the classification needs updating, update it now and note any domain files that need to be relocated.
 
 **Deep Think**: "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)?"
 
-Write the surface classification to `meta/constraints.md` — downstream workflows use this to determine which decision axes apply.
+Write constraints to `meta/constraints.md`. If the surface classification changed, update `ideation-index.md` `## Structural Classification` section.
 
 ### Success metrics
 
@@ -162,7 +162,7 @@ Read `.agent/skills/pipeline-rubrics/references/ideation-rubric.md` before apply
 | 9 | **Domain Coverage** | Are all domains at `[DEEP]` or `[EXHAUSTED]`? |
 | 10 | **Deep Think Coverage** | Were hypotheses tracked? Are all resolved (confirmed/rejected)? |
 | 11 | **Cross-Cut Completeness** | Is the ledger clean? No pending entries? |
-| 12 | **Folder Structure Compliance** | Does the folder match the template structure? |
+| 12 | **Folder Structure Compliance** | Does the folder match the classified structure? (flat `domains/` for single-surface, `surfaces/` + `domains/` for multi-product) |
 
 For any dimension that scores ⚠️ or ❌, resolve it NOW — don't present a document with known gaps. Loop back to the relevant step and work through it with the user.
 

package/template/.agent/workflows/ideate.md

@@ -4,8 +4,8 @@ pipeline:
   position: 1
   stage: vision
   predecessors: [] # entry point
-  successors: [create-prd]
-  skills: [brainstorming, idea-extraction, pipeline-rubrics, prd-templates, resolve-ambiguity, technical-writer]
+  successors: [audit-ambiguity, create-prd] # audit-ambiguity recommended before create-prd
+  skills: [brainstorming, idea-extraction, pipeline-rubrics, prd-templates, prompt-engineer, resolve-ambiguity, technical-writer]
   calls-bootstrap: false
 shards: [ideate-extract, ideate-discover, ideate-validate]
 ---

package/template/.agent/workflows/implement-slice-setup.md

@@ -23,25 +23,28 @@ Check progress state, load skills, read the slice, detect parallel mode, and wri
 
 ## -1. Placeholder verification (CRITICAL — run before anything else)
 
-Scan for unfilled placeholders before writing code. Read each file and scan for `{{`:
+Scan the surface stack map in `.agent/instructions/tech-stack.md` for completeness before writing code.
 
-1. `AGENTS.md`
-2. `GEMINI.md`
-3. `.agent/instructions/workflow.md`
-4. `.agent/instructions/commands.md`
-5. `.agent/instructions/structure.md`
-6. `.agent/instructions/patterns.md`
-7. `.agent/instructions/tech-stack.md`
+Verify:
+1. The slice's surface row has filled values for **all** required columns (Languages, Databases, BE Frameworks, FE Frameworks, ORMs, Unit Tests, E2E Tests, FE Design, State Mgmt)
+2. Cross-cutting categories have filled values (Auth, Security, CI/CD, Hosting, Accessibility)
+3. Commands section in `.agent/instructions/commands.md` has non-template values
 
-**If ANY `{{PLACEHOLDER}}` found** → STOP. Tell user which files contain unfilled placeholders with remediation:
+Also scan these instruction files for any remaining template markers:
+- `.agent/instructions/structure.md`
+- `.agent/instructions/patterns.md`
+- `.agent/instructions/tech-stack.md`
 
-| Unfilled pattern | Remediation |
-|-----------------|-------------|
-| `AGENTS.md`, `GEMINI.md`, `workflow.md`, `commands.md`, `tech-stack.md` | Run `/create-prd` |
-| `structure.md` (`{{PROJECT_STRUCTURE}}`, `{{ARCHITECTURE_TABLE}}`) | Run `/create-prd-compile` Step 9.5 |
-| `patterns.md` (`{{FRAMEWORK_PATTERNS}}`) | Run `/bootstrap-agents-provision` |
+**If the map has empty cells for this slice's surface** → STOP. Tell user which cells are empty with remediation:
 
-Only proceed when zero `{{` patterns remain in all seven files.
+| Empty Cell | Remediation |
+|---|---|
+| Languages / Databases / Frameworks | Run `/create-prd-stack` first |
+| Commands section | Run `/bootstrap-agents` |
+| `structure.md` (project structure) | Run `/create-prd-compile` Step 9.5 |
+| `patterns.md` (framework patterns) | Run `/bootstrap-agents-provision` |
+
+Only proceed when the map is fully populated for this slice's surface.
 
 ---
 
@@ -55,10 +58,9 @@ Verify previous slice was fully marked complete before starting this one.
 
 Read these skill SKILL.md files: `tdd-workflow`, `error-handling-patterns`, `git-workflow`, `code-review-pro`, `testing-strategist`, `clean-code`, `logging-best-practices`, `minimalist-surgical-development`, `systematic-debugging`. All are in `.agent/skills/[name]/SKILL.md`.
 
-Read .agent/skills/{{LANGUAGE_SKILL}}/SKILL.md and follow its language conventions.
-If this slice includes BE tasks: Read .agent/skills/{{ORM_SKILL}}/SKILL.md and follow its migration and schema conventions. Skip if no BE tasks or `{{ORM_SKILL}}` is not provisioned.
-Read .agent/skills/{{UNIT_TESTING_SKILL}}/SKILL.md and follow its test writing conventions.
-If this slice includes FE tasks: Read .agent/skills/{{STATE_MANAGEMENT_SKILL}}/SKILL.md and follow its state management conventions. Skip if no FE tasks or `{{STATE_MANAGEMENT_SKILL}}` is not provisioned.
+Determine which surface this slice belongs to from the phase plan. Read the surface stack map.
+
+Read `.agent/skills/prd-templates/references/skill-loading-protocol.md` and load skills for this slice's surface: Languages, Unit Tests, and conditionally ORMs (if BE tasks) and State Mgmt (if FE tasks).
 
 Use `find-skills` to discover a test framework skill if needed.
 
@@ -95,16 +97,16 @@ Log each dispatch phase to `.agent/progress/slices/phase-NN-slice-NN.md` `## Dis
 
 ---
 
-## 2. Write the contract (Zod schema)
+## 2. Write the contract ({{CONTRACT_LIBRARY}} schema)
 
 Before writing the schema, locate the BE endpoint(s) referenced by this slice's acceptance criteria. For each endpoint:
-1. Read the BE spec section that defines it. Copy the typed Zod contract completely — every request field, response field, error code, and validation rule.
+1. Read the BE spec section that defines it. Copy the typed {{CONTRACT_LIBRARY}} contract completely — every request field, response field, error code, and validation rule.
 2. Read the slice's acceptance criteria. Add any additional request/response shapes required by behavioral assertions that are not already present in the BE contract (e.g., query parameters implied by filter behavior, UI-specific error payloads).
 3. Verify the combined schema covers every acceptance criterion and every BE contract field. Flag any drift between the BE spec and the IA shard it implements.
 
-Read .agent/skills/{{LANGUAGE_SKILL}}/SKILL.md and follow its language conventions.
+Load the Languages skill(s) from this slice's surface row per the skill loading protocol.
 
-Define request/response shapes as Zod schemas in the contracts directory (see `.agent/instructions/structure.md`). This is the source of truth.
+Define request/response shapes as {{CONTRACT_LIBRARY}} schemas in the contracts directory (see `.agent/instructions/structure.md`). This is the source of truth.
 
 ### Propose next step
 

package/template/.agent/workflows/implement-slice-tdd.md

@@ -17,7 +17,7 @@ pipeline:
 
 Execute the TDD cycle (Red → Green → Refactor), run validation, handle synthesis, and update all progress tracking files.
 
-**Prerequisite**: Contract (Zod schema) must be written (from `/implement-slice-setup` or equivalent). If in parallel mode, QA-RED and BE/FE/QA-GREEN dispatch should be completed during setup.
+**Prerequisite**: Contract ({{CONTRACT_LIBRARY}} schema) must be written (from `/implement-slice-setup` or equivalent). If in parallel mode, QA-RED and BE/FE/QA-GREEN dispatch should be completed during setup.
 
 ---
 
@@ -26,153 +26,112 @@ Execute the TDD cycle (Red → Green → Refactor), run validation, handle synth
 Read .agent/skills/tdd-workflow/SKILL.md and follow its methodology.
 Read .agent/skills/clean-code/SKILL.md and follow its methodology.
 Read .agent/skills/systematic-debugging/SKILL.md and follow its methodology.
-Read .agent/skills/{{LANGUAGE_SKILL}}/SKILL.md and follow its language conventions.
-Read .agent/skills/{{UNIT_TESTING_SKILL}}/SKILL.md and follow its test writing conventions.
-Read .agent/skills/{{E2E_TESTING_SKILL}}/SKILL.md and follow its E2E test conventions.
+Determine which surface this slice belongs to from the phase plan or slice path. Read the surface stack map from `.agent/instructions/tech-stack.md`.
 
-Cross-reference **all three** sources — acceptance criteria from the phase plan, the Zod contract from step 2, AND IA edge cases traced through the BE Source Map:
+Load the Languages, Unit Tests, and E2E Tests skill(s) from this slice's surface row per the skill loading protocol (`.agent/skills/prd-templates/references/skill-loading-protocol.md`).
+
+Cross-reference **all three** sources — acceptance criteria from the phase plan, the {{CONTRACT_LIBRARY}} contract from step 2, AND IA edge cases traced through the BE Source Map:
 1. Write a test for each acceptance criterion
 2. Write a test for each contract field, error type, and validation rule not already covered by criteria
-3. For each endpoint in this slice, read the IA shard section(s) cited in that endpoint's BE spec `## Source Map`. Extract every item from the IA shard's `## Edge Cases` section that is relevant to the endpoint(s) under test. Write a failing test for each uncovered edge case. Tag these tests with `// IA-EDGE: [IA §X.Y — description]` so QA-GREEN can audit traceability.
+3. For each endpoint, read the IA shard section(s) cited in the BE spec `## Source Map`. Extract every relevant `## Edge Cases` item. Write a failing test for each, tagged `// IA-EDGE: [IA §X.Y — description]`
 4. Run all tests — they MUST fail
 5. Commit the failing tests
 
-**Test order**: Unit → Integration → E2E (if applicable)
+Read `.agent/skills/prd-templates/references/tdd-testing-policy.md` and apply its **Assertion Depth Rule** and **Anti-Mock-Abuse Rules** to all tests written above.
 
 > **In parallel mode**, this step is handled by the `QA` agent dispatch in step 1.5.
-> In sequential mode, the orchestrator handles it directly.
 
-Run `{{TEST_COMMAND}}` to verify tests fail.
+Run the Test Cmd from this slice's surface row in the surface stack map to verify tests fail.
 
 ## 4. Implement (GREEN)
 
-Read .agent/skills/{{LANGUAGE_SKILL}}/SKILL.md and follow its language conventions.
+Load the Languages skill(s) from this slice's surface row per the skill loading protocol.
 
-Write the minimum code to make all tests pass:
+Write the simplest *correct* implementation to make all tests pass. "Minimal" means no unnecessary abstractions — it does **NOT** mean skipping error handling, input validation, logging, or edge cases that the spec defines:
 1. Database schema/migration
 2. API endpoint handler
 3. Business logic
 4. UI component
 
-**If in parallel mode**: Each agent claims its task via the **Parallel Claim Protocol** (`.agent/skills/session-continuity/protocols/09-parallel-claim.md`) — marking `[!]`, writing `files:` list, and working through subtasks. Agents release claims on completion.
-
-**Before using any stub or placeholder**, apply the three-part test from the
-`boundary-not-placeholder` rule:
-- Does the spec exist? → Implement it. No stub.
-- Could you write the spec now? → Write the spec first, then implement.
-- Information genuinely doesn't exist? → `BOUNDARY:` stub with typed interface, tracking issue, and sentinel test.
+**If in parallel mode**: Each agent claims its task via the **Parallel Claim Protocol** (`.agent/skills/session-continuity/protocols/09-parallel-claim.md`).
 
-> **"This is a lot of work" is not a valid boundary.** Amount of work, task
-> scope, and complexity are never reasons to stub. Only missing information is.
+**Before using any stub or placeholder**, apply the three-part test from the `boundary-not-placeholder` rule. Only missing information is a valid boundary — amount of work, scope, and complexity are never reasons to stub.
 
-**Spec traceability**: if you make any implementation decision not explicitly covered by the spec or contract (e.g., choosing enum values, default behaviors, retry counts, timeout durations, error messages), annotate it with `// DECISION: [what was decided and why]`. QA will audit these.
+**Spec traceability**: Annotate any implementation decision not covered by the spec with `// DECISION: [what was decided and why]`. QA will audit these.
 
-Run `{{TEST_COMMAND}}` to verify tests pass.
+> **Decision recording**: For decisions with ripple effects (touching other components, changing contracts, setting precedent), read `.agent/skills/session-continuity/protocols/06-decision-analysis.md` and follow the **Decision Effect Analysis Protocol**. Isolated decisions don't need this — only decisions where changing it later requires editing more than the current file.
 
-## 4.1. Debug cycle (if tests fail after initial implementation)
+Run the Test Cmd to verify tests pass.
 
-If `{{TEST_COMMAND}}` shows failures after completing Step 4:
+## 4.1. Debug cycle (if tests fail)
 
-Read .agent/skills/systematic-debugging/SKILL.md and follow its ACH methodology.
-Read .agent/skills/parallel-debugging/SKILL.md if failures span multiple subsystems.
+Read `.agent/skills/systematic-debugging/SKILL.md` and follow its ACH methodology. Read `.agent/skills/parallel-debugging/SKILL.md` if failures span multiple subsystems.
 
-1. Classify failures: contract mismatch vs logic error vs integration issue
-2. For contract mismatches: re-read the BE spec — is the contract wrong or the implementation?
-3. For logic errors: apply ACH (Analysis of Competing Hypotheses) per the debugging skill
-4. For integration issues: check cross-surface wiring, env vars, service connectivity
-5. Maximum 3 debug iterations before escalating to user with findings
+1. Classify: contract mismatch vs logic error vs integration issue
+2. Contract mismatch → re-read BE spec — contract wrong or implementation?
+3. Logic error → ACH per debugging skill
+4. Integration issue → check cross-surface wiring, env vars, service connectivity
+5. Maximum 3 iterations before escalating to user
 
-Run `{{TEST_COMMAND}}` after each debug iteration to verify progress.
+Run the Test Cmd after each iteration.
 
 ## 4.5. New dependency check
 
-After making all tests pass (GREEN), scan the new imports introduced in the implementation files.
-
-If any package or module was introduced that does **not** have a corresponding skill directory in `.agent/skills/`:
-1. Identify the stack category (e.g., `QUEUE`, `CACHE`, `SEARCH`, `STORAGE`, `REALTIME`)
-2. Read `.agent/workflows/bootstrap-agents.md` and fire bootstrap with `PIPELINE_STAGE=implement-slice` + the key-value pair (e.g., `NEW_DEPENDENCY=[package-name]`)
-3. Confirm the matching skill is installed before proceeding to REFACTOR
+After GREEN, scan new imports. If any package lacks a corresponding skill directory in `.agent/skills/`:
+1. Identify the stack category (e.g., `QUEUE`, `CACHE`, `SEARCH`)
+2. Read `.agent/workflows/bootstrap-agents.md` and fire bootstrap with `PIPELINE_STAGE=implement-slice` + the key-value pair
+3. Confirm skill installed before proceeding to REFACTOR
 
-If no new unregistered dependencies were introduced, skip and proceed to Step 5.
+No new unregistered dependencies → skip to Step 5.
 
 ## 5. Refactor
 
-With tests green, improve code quality:
-- Extract shared logic
-- Improve naming
-- Remove duplication
-- Add documentation
+With tests green, improve code quality: extract shared logic, improve naming, remove duplication, add documentation.
 
-Read `.agent/skills/code-review-pro/SKILL.md` and apply its adversarial review: "How would a senior engineer reject this in a PR review?" Fix issues before running tests.
+Read `.agent/skills/code-review-pro/SKILL.md` and apply its adversarial review: "How would a senior engineer reject this in a PR review?"
 
-**Spec traceability check**: Re-read the BE spec and IA shard sections for this slice. Verify every Zod contract field maps to a BE spec field. Verify every `// IA-EDGE:` tagged test's edge case is covered by the implementation, not just tested. Fix any spec drift before proceeding.
+**Spec traceability check**: Re-read the BE spec and IA shard for this slice. Verify every contract field maps to a BE spec field and every `// IA-EDGE:` test's edge case is covered by the implementation. Fix spec drift before proceeding.
 
-Run `{{TEST_COMMAND}}` to verify tests still pass after refactor.
+Run the Test Cmd to verify tests still pass.
 
 ## 6. Validate
 
-Read .agent/skills/verification-before-completion/SKILL.md and apply its evidence-before-claims discipline.
+Read `.agent/skills/verification-before-completion/SKILL.md` and apply its evidence-before-claims discipline.
 
-Run the full validation suite: `{{VALIDATION_COMMAND}}`.
+Run the Validation Cmd from this slice's surface row. At least one integration test per BE endpoint must hit a real test server + real test database and assert the full response body.
 
 All must pass before the slice is complete.
 
 ## 6.5. Synthesis (parallel mode only)
 
-**Skip this step if not in parallel mode.**
+**Skip if not in parallel mode.**
 
-Read `.agent/skills/session-continuity/protocols/11-parallel-synthesis.md` and follow its full procedure — write synthesis plan, resolve stubs, wire integrations, run `{{VALIDATION_COMMAND}}`.
+Read `.agent/skills/session-continuity/protocols/11-parallel-synthesis.md` and follow its full procedure.
 
 ## 7. Update progress (Mandatory)
 
-**CRITICAL ANTI-HALLUCINATION RULE**: You MUST NOT skip the progress update. Agents routinely skip this step after validation passes.
-
-Read `.agent/skills/session-continuity/protocols/03-progress-update.md` and follow **every step** in the protocol. You must physically open and edit each of the four file targets (slice file, phase file, index, memory) using your file editing tools.
-
-The protocol covers:
-- **7a**: Slice file — status, criteria, implementation notes, files changed
-- **7b**: Phase file — slice entry, sub-tasks, progress fraction, claim releases
-- **7c**: Index — overall percentage, phase row
-- **7d**: Memory — patterns and blockers
+**CRITICAL**: You MUST NOT skip progress updates. Read `.agent/skills/session-continuity/protocols/03-progress-update.md` and follow **every step** — physically edit all four file targets (slice, phase, index, memory).
 
 ## 8. Completion Gate
 
-Read .agent/skills/verification-before-completion/SKILL.md and apply its evidence-before-claims discipline.
-
-### UI Completeness Check (FE slices only)
+Read `.agent/skills/verification-before-completion/SKILL.md` and apply its discipline.
 
-- [ ] (FE slices only) Every acceptance criterion mentioning "user sees", "user can", "displays", or "shows" has a rendered implementation — not just a passing test
-- [ ] (FE slices only) Every new route in this slice is wired into the app's navigation (not just exported as a component)
-- [ ] (FE slices only) Loading, error, and empty states are rendered in the UI — not just covered by tests
-- [ ] (FE slices only) The feature is reachable from the app's entry point via normal user navigation
+Read `.agent/skills/prd-templates/references/slice-completion-gates.md` and verify every applicable checklist passes:
+- **UI Completeness Check** — FE slices only
+- **Spec Traceability Gate** — all slices
 
-These items apply only when the slice is tagged `FE`. Non-FE slices skip this block.
+Read `.agent/skills/prd-templates/references/tdd-testing-policy.md` and run the **QA Anti-Cheat Audit** checklist.
 
-### Spec Traceability Gate (all slices)
+You may not call `notify_user` until you have edited all four progress file targets (7a–7d).
 
-Before calling `notify_user`, verify:
-
-- [ ] Re-read the BE spec section(s) for every endpoint in this slice — every response field, error code, and validation rule has a corresponding test tagged with the spec reference
-- [ ] Re-read the IA shard's `## Edge Cases` section for this slice's domain — every edge case relevant to this slice has a `// IA-EDGE:` tagged test
-- [ ] No `// DECISION:` annotations exist for behaviors that are actually specified in the BE spec or IA shard (i.e., no spec-defined behavior was treated as an undocumented implementation decision)
-- [ ] The Zod contract written in Step 2 matches the delivered implementation field-for-field — no fields added, removed, or renamed during implementation without a corresponding contract update
-
-> ❌ STOP — Do not call `notify_user` if any of the above are unchecked. Fix the gap and re-run `{{TEST_COMMAND}}`.
-
-You may not call `notify_user` until you have edited all four file targets above (7a–7d).
-
-Verify your edits by reading each of the following files:
-- Read `.agent/progress/slices/phase-NN-slice-NN.md` — must show Status: complete and [x] criteria
-- Read `.agent/progress/phases/phase-NN.md` — search for "Progress" and verify it shows the incremented fraction
-- Read `.agent/progress/index.md` — search for "Overall" and verify it shows the new overall percentage
-
-Replace `NN` with the actual phase and slice numbers you just completed.
+Verify your edits by reading:
+- `.agent/progress/slices/phase-NN-slice-NN.md` — Status: complete, [x] criteria
+- `.agent/progress/phases/phase-NN.md` — incremented progress fraction
+- `.agent/progress/index.md` — updated overall percentage
 
 Your `notify_user` payload **MUST** include:
-1. The raw output from the three commands above.
-2. The updated overall progress (e.g., "Overall progress is now 75% (24/32 slices)").
-3. The explicit next command: Run `/implement-slice` for [next slice name].
-
-If any command output shows unchecked criteria, a stale fraction, or a missing file, you have failed the workflow.
+1. Raw output from the three reads above
+2. Updated overall progress (e.g., "Overall progress is now 75% (24/32 slices)")
+3. Explicit next command: Run `/implement-slice` for [next slice name]
 
-**Infrastructure/Auth slice gate**: After completing progress tracking, check the slice name against the phase plan. If this was the `00-infrastructure` slice or the auth slice, the next command to run is `/verify-infrastructure`, not `/implement-slice`. Do not propose the next feature slice until `/verify-infrastructure` passes and produces a green report in `docs/audits/`.
+**Infrastructure/Auth slice gate**: If this was the `00-infrastructure` or auth slice, the next command is `/verify-infrastructure`, not `/implement-slice`.

package/template/.agent/workflows/implement-slice.md

@@ -6,7 +6,7 @@ pipeline:
   predecessors: [plan-phase]
   successors: [validate-phase]
   loop: true # repeats per slice within a phase
-  skills: [clean-code, code-review-pro, parallel-agents, parallel-debugging, parallel-feature-development, session-continuity, systematic-debugging, tdd-workflow, verification-before-completion]
+  skills: [clean-code, code-review-pro, minimalist-surgical-development, parallel-agents, parallel-debugging, parallel-feature-development, session-continuity, systematic-debugging, tdd-workflow, verification-before-completion]
   calls-bootstrap: true # may discover new dependencies during implementation
 shards: [implement-slice-setup, implement-slice-tdd]
 ---
@@ -35,7 +35,7 @@ Implement a single vertical slice using strict TDD: Red → Green → Refactor.
 
 ### Step A — Run `.agent/workflows/implement-slice-setup.md`
 
-Checks progress state and session continuity, loads all bundled skills, reads the slice acceptance criteria, determines if parallel mode applies, and writes the contract (Zod schema). If parallel mode is detected, dispatches agents for the TDD cycle.
+Checks progress state and session continuity, loads all bundled skills, reads the slice acceptance criteria, determines if parallel mode applies, and writes the contract ({{CONTRACT_LIBRARY}} schema). If parallel mode is detected, dispatches agents for the TDD cycle.
 
 ### Step B — Run `.agent/workflows/implement-slice-tdd.md`
 
@@ -46,7 +46,7 @@ Executes the TDD cycle (RED: write failing tests → GREEN: implement → REFACT
 ## Quality Gate
 
 You may not call `notify_user` until:
-- [ ] All tests pass (`{{TEST_COMMAND}}`)
-- [ ] Full validation passes (`{{VALIDATION_COMMAND}}`)
+- [ ] All tests pass (Test Cmd from surface stack map)
+- [ ] Full validation passes (Validation Cmd from surface stack map)
 - [ ] All 4 progress tracking files updated (slice, phase, index, memory)
 - [ ] Each tracking file verified by re-reading after edit

package/template/.agent/workflows/plan-phase-preflight.md

@@ -50,7 +50,7 @@ Read these skills for slice planning guidance:
 
 ## 0.5. Application Completeness Audit
 
-Read `{{SURFACES}}` from `.agent/instructions/tech-stack.md`. For each row below, only run the check if "Applies To" matches the project's confirmed surfaces. Skip inapplicable rows.
+Read the **Surfaces** list from the Global Settings section of `.agent/instructions/tech-stack.md`. For each row below, only run the check if "Applies To" matches the project's confirmed surfaces. Skip inapplicable rows.
 
 Read all FE specs in `docs/plans/fe/` and check the following table.
 
@@ -106,14 +106,18 @@ Do not proceed until the user confirms all uncovered specs are resolved.
 
 ### 0.6b. Cross-Layer Field and Contract Consistency
 
-Using the `cross-layer-consistency` skill's methodology, verify:
+Using the `cross-layer-consistency` skill's methodology as a guide, verify the following **minimum checks** regardless of skill depth:
 
 1. **Field mapping**: For every BE response field consumed by an FE component, verify the field name, type, and nullability match exactly between the BE spec and FE spec.
 2. **Error code propagation**: For every error code defined in a BE spec, verify the corresponding FE spec documents how that error is displayed to the user.
 3. **Access control consistency**: For every RBAC role referenced in a BE spec's access control, verify the FE spec's conditional rendering matrix includes that role.
+4. **Data contract drift**: For every IA shard entity, verify that the BE spec's request/response schemas contain all fields defined in the IA shard's data model — no fields silently dropped or renamed.
+5. **State management consistency**: For every FE component that manages optimistic updates, verify the corresponding BE endpoint's error response is specified well enough for the FE to roll back.
 
 Collect all mismatches into a consistency report. If any exist → **hard stop** and present them to the user for resolution before proceeding.
 
+> These 5 checks are **non-negotiable minimums**. The `cross-layer-consistency` skill may define additional checks — run those too, but never skip these 5 even if the skill doesn't mention them.
+
 ---
 
 ## 0.8. Draft continuity check