create-harness-vibe-coding 0.6.2 → 0.6.4

package/templates/common/docs/harness/context-loading.md

@@ -1,108 +1,104 @@
-# Context Loading Protocol
-
-Use when context is growing, subagents are needed, or an agent is unsure which harness doc applies.
-
-## Routing Authority
-
-`Harness/README.md` is the primary router. This file is a secondary context-splitting protocol for subagents and long tasks.
-
-If this file and `Harness/README.md` disagree, follow `Harness/README.md`, record the assumption in `Harness/tasks/<task-id>/PROGRESS.md`, and update this file later.
-
-project files are the only durable communication channel; chat/subagent transcript state is non-authoritative. Important assumptions, decisions, blockers, evidence, and handoffs must be written to `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md`, the current feature doc, `Harness/MEMORY.md`, or `Harness/memory/*` as appropriate.
-
-## Main Context
-
-Always keep:
-
-- `CLAUDE.md`
-- `Harness/MEMORY.md`
-- `Harness/README.md`
-- `Harness/PROGRESS.md` when active
-- `Harness/tasks/<task-id>/PROGRESS.md` when active
-- `Harness/tasks/<task-id>/PLAN.md` when active
-- current feature doc when active
-
-Load other docs only by trigger.
-
-## Trigger Matrix
-
-| Trigger | Load |
-| --- | --- |
-| idea, scope, MVP | `Harness/lifecycle.md`, `Harness/research/PRD.md` |
-| research, competitors, stack choice | `Harness/research/README.md`, `Harness/research/research-results.md` |
-| official docs, API, SDK, version, limits | `Harness/research/README.md`, `Harness/architecture.md`, `Harness/domain/ports.md` as needed |
-| layer, dependency, module boundary | `Harness/architecture.md`, `Harness/domain/ports.md` |
-| task split, owner, write set | `Harness/tasks/<task-id>/PROGRESS.md`, `Harness/tasks/<task-id>/PLAN.md`, `Harness/agent-workflow.md` |
-| parallel agents, dispatch, worktree decision | `Harness/subagents.md`, `Harness/dispatch.md`, `Harness/tasks/<task-id>/PLAN.md` |
-| memory, repeated tool failure, repeated user correction, reusable lesson | `Harness/MEMORY.md`, the relevant `Harness/memory/*.md` file |
-| event, retry, failure path | `Harness/data-flow.md` |
-| status, transition, resume | `Harness/state-machines.md` |
-| subagent spawn | `Harness/subagents.md`, this file plus the role pack below |
-
-## Subagent Packs
-
-Explorer Pass:
-- inject: question, read boundary, relevant docs
-- forbid: writes
-- return: files found, facts, risks, suggested tests
-
-Planner:
-- inject: user goal, lifecycle phase, PRD or PLAN section, dispatch constraints
-- forbid: production code
-- return: tasks, dependencies, read/write sets, dispatch table, gates, open questions
-
-Researcher:
-- inject: question, decision needed, source boundaries, tool options
-- forbid: production code
-- return: sources, adopted/rejected/watch decisions, risks, research-results.md patch
-
-Docs Researcher:
-- inject: library/API/config, implementation question, version/date constraints
-- forbid: production code
-- return: official links, constraints, errors, examples, affected docs
-
-Architect:
-- inject: PRD, current architecture, ports
-- forbid: implementation
-- return: boundary decision, affected docs, risks
-
-Test Writer:
-- inject: acceptance criteria, feature doc, test write set
-- forbid: production code
-- return: failing tests and test intent
-
-Implementer:
-- inject: task, tests, allowed write set, forbidden scope
-- forbid: unrelated refactor and test loosening
-- return: changed files and implementation notes
-
-Reviewer:
-- inject: diff, acceptance criteria, architecture docs
-- forbid: writes
-- return: findings by severity, missing tests, boundary issues
-
-Debugger:
-- inject: failing command, error output, related files
-- forbid: broad rewrites
-- return: root cause, fix, proof
-
-Verifier:
-- inject: verification commands and acceptance criteria
-- forbid: code changes
-- return: commands run, results, residual risk
-
-Memory Master:
-- inject: trigger reason, current failure/user-correction/closeout context, task PROGRESS.md section
-- forbid: source code, unrelated Harness docs
-- return: memory action summary, files written, cross-project flag
-
-Context Master:
-- inject: trigger reason (threshold % or closeout), current task PROGRESS.md, task phase
-- forbid: source code, memory files, MEMORY.md writes
-- return: context usage %, stale blocks, compressible blocks, durable knowledge candidates, compression suggestion
-
-## Handoff Rule
-
-Only the subagent summary enters main context. If details are needed, load the named files directly instead of replaying the subagent conversation.
-
-Use the handoff format in [dispatch.md](dispatch.md) for every dispatched agent.
+# Context Loading Protocol
+
+Use when context is growing, subagents are needed, or an agent is unsure which harness doc applies.
+
+## Routing Authority
+
+`Harness/README.md` is the primary router. This file is a secondary context-splitting protocol for subagents and long tasks.
+
+If this file and `Harness/README.md` disagree, follow `Harness/README.md`, record the assumption in `Harness/tasks/<task-id>/PROGRESS.md`, and update this file later.
+
+project files are the only durable communication channel; chat/subagent transcript state is non-authoritative. Important assumptions, decisions, blockers, evidence, and handoffs must be written to `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md`, the current feature doc, `Harness/MEMORY.md`, or `Harness/memory/*` as appropriate.
+
+## Main Context
+
+Always keep:
+
+- `CLAUDE.md`
+- `Harness/MEMORY.md`
+- `Harness/README.md`
+- `Harness/PROGRESS.md` when active
+- `Harness/tasks/<task-id>/PROGRESS.md` when active
+- `Harness/tasks/<task-id>/PLAN.md` when active
+- current feature doc when active
+
+Load other docs only by trigger.
+
+## Trigger Matrix
+
+| Trigger | Load |
+| --- | --- |
+| idea, scope, MVP | `Harness/lifecycle.md`, `Harness/research/PRD.md` |
+| research, competitors, stack choice | `Harness/research/README.md`, `Harness/research/research-results.md` |
+| task split, owner, write set | `Harness/tasks/<task-id>/PROGRESS.md`, `Harness/tasks/<task-id>/PLAN.md`, `Harness/agent-workflow.md` |
+| parallel agents, dispatch, worktree decision | `Harness/subagents.md`, `Harness/dispatch.md`, `Harness/tasks/<task-id>/PLAN.md` |
+| memory, repeated tool failure, repeated user correction, reusable lesson | `Harness/MEMORY.md`, the relevant `Harness/memory/*.md` file |
+| subagent spawn | `Harness/subagents.md`, this file plus the role pack below |
+
+## Subagent Packs
+
+Explorer Pass:
+- inject: question, read boundary, relevant docs
+- forbid: writes
+- return: files found, facts, risks, suggested tests
+
+Planner:
+- inject: user goal, lifecycle phase, PRD or PLAN section, dispatch constraints
+- forbid: production code
+- return: tasks, dependencies, read/write sets, dispatch table, gates, open questions
+
+Researcher:
+- inject: question, decision needed, source boundaries, tool options
+- forbid: production code
+- return: sources, adopted/rejected/watch decisions, risks, research-results.md patch
+
+Docs Researcher:
+- inject: library/API/config, implementation question, version/date constraints
+- forbid: production code
+- return: official links, constraints, errors, examples, affected docs
+
+Architect:
+- inject: PRD, current architecture, ports
+- forbid: implementation
+- return: boundary decision, affected docs, risks
+
+Test Writer:
+- inject: acceptance criteria, feature doc, test write set
+- forbid: production code
+- return: failing tests and test intent
+
+Implementer:
+- inject: task, tests, allowed write set, forbidden scope
+- forbid: unrelated refactor and test loosening
+- return: changed files and implementation notes
+
+Reviewer:
+- inject: diff, acceptance criteria, architecture docs
+- forbid: writes
+- return: findings by severity, missing tests, boundary issues
+
+Debugger:
+- inject: failing command, error output, related files
+- forbid: broad rewrites
+- return: root cause, fix, proof
+
+Verifier:
+- inject: verification commands and acceptance criteria
+- forbid: code changes
+- return: commands run, results, residual risk
+
+Memory Master:
+- inject: trigger reason, current failure/user-correction/closeout context, task PROGRESS.md section
+- forbid: source code, unrelated Harness docs
+- return: memory action summary, files written, cross-project flag
+
+Context Master:
+- inject: trigger reason (threshold % or closeout), current task PROGRESS.md, task phase
+- forbid: source code, memory files, MEMORY.md writes
+- return: context usage %, stale blocks, compressible blocks, durable knowledge candidates, compression suggestion
+
+## Handoff Rule
+
+Only the subagent summary enters main context. If details are needed, load the named files directly instead of replaying the subagent conversation.
+
+Use the handoff format in [dispatch.md](dispatch.md) for every dispatched agent.

package/templates/common/docs/harness/extension.md

@@ -1,79 +1,70 @@
-# Extension Contract
-
-Purpose: keep stack-specific agents, skills, rules, and hooks compatible with this harness.
-
-Use during setup whenever adding assets from ECC, SuperClaude, toolboxes, or local project conventions.
-
-## Non-Invasive Extension Rules
-
-Extensions must preserve project and harness ownership boundaries.
-
-- Preserve existing `.claude/`, `CLAUDE.md`, `AGENTS.md`, `.gitignore`, `Harness/README.md`, `Harness/workflows/*.md`, settings, hooks, and local rules unless the user explicitly requests an overwrite.
-- Treat existing project config as project fact. Read it before adding assets, then adapt new assets to the project instead of replacing the project.
-- Register added agents, skills, workflows, rules, and hooks in `Harness/MEMORY.md` and this docs router where applicable.
-- Added assets may extend `.claude/skills/`, `.claude/agents/`, `.claude/rules/`, or `Harness/workflows/`, but they must not replace core harness docs.
-- Core harness docs are `Harness/README.md`, `Harness/PROGRESS.md`, `Harness/subagents.md`, `Harness/context-loading.md`, `Harness/dispatch.md`, `Harness/agent-workflow.md`, and this file.
-- If an optional workflow needs a new command or tool, document the command and fallback in `Harness/workflows/<name>.md` instead of changing core harness behavior.
-
-## Agent Contract
-
-Every added agent must have frontmatter:
-
-```yaml
----
-name: stack-agent-name
-description: Use when ...
-tools: Read, Grep, Glob
-model: sonnet
-skills: harness-context
----
-```
-
-Choose one harness skill:
-
-| Agent Type | Skill |
-| --- | --- |
-| research, docs, API lookup | `harness-research` |
-| planning, architecture, context split | `harness-context` |
-| tests, implementation, debugging, review, verification | `harness-build-loop` |
-
-Agent body must state:
-
-- load first
-- inputs required
-- allowed write set or read-only
-- forbidden scope
-- verification or evidence
-- return format from [subagents.md](subagents.md) and [dispatch.md](dispatch.md)
-
-## Skill Contract
-
-Every added skill must state:
-
-- when to use
-- docs to load
-- required inputs
-- allowed writes
-- output format
-- whether to update `Harness/PROGRESS.md` and task files
-- whether to use [subagents.md](subagents.md) and [dispatch.md](dispatch.md)
-
-Skills should extend the harness. They should not replace `Harness/README.md`, `Harness/PROGRESS.md`, `subagents.md`, `context-loading.md`, `dispatch.md`, or `agent-workflow.md`.
-
-## Rules
-
-- Do not add broad agents that can write anywhere.
-- Do not add agents whose role overlaps an existing common agent without naming the difference.
-- Do not add tools that bypass project permissions or user approval.
-- Do not run stack-specific writing agents in parallel unless write sets are disjoint.
-- If an added asset conflicts with this harness, adapt the asset instead of changing the core contract.
-
-## Registration
-
-After adding assets:
-
-- list agents in `Harness/MEMORY.md#Agents`
-- list skills in `Harness/MEMORY.md#Skills`
-- list workflows by path in `Harness/MEMORY.md` or `Harness/README.md`
-- update `Harness/PROGRESS.md` and `Harness/tasks/<task-id>/PROGRESS.md` when the asset affects current work
-- run `node Harness/scripts/validate-harness.mjs`
+# Extension Contract
+
+Purpose: keep stack-specific agents, skills, rules, and hooks compatible with this harness.
+
+Use during setup whenever adding assets from ECC, SuperClaude, toolboxes, or local project conventions.
+
+## Non-Invasive Extension Rules
+
+Extensions must preserve project and harness ownership boundaries.
+
+- Preserve existing `.claude/`, `CLAUDE.md`, `AGENTS.md`, `.gitignore`, `Harness/README.md`, `Harness/workflows/*.md`, settings, hooks, and local rules unless the user explicitly requests an overwrite.
+- Treat existing project config as project fact. Read it before adding assets, then adapt new assets to the project instead of replacing the project.
+- Register added agents, skills, workflows, rules, and hooks in `Harness/MEMORY.md` and this docs router where applicable.
+- Added assets may extend `.claude/skills/`, `.claude/agents/`, `.claude/rules/`, or `Harness/workflows/`, but they must not replace core harness docs.
+- Core harness docs are `Harness/README.md`, `Harness/PROGRESS.md`, `Harness/subagents.md`, `Harness/context-loading.md`, `Harness/dispatch.md`, `Harness/agent-workflow.md`, and this file.
+- If an optional workflow needs a new command or tool, document the command and fallback in `Harness/workflows/<name>.md` instead of changing core harness behavior.
+
+## Agent Contract
+
+Every added agent must have frontmatter:
+
+```yaml
+---
+name: stack-agent-name
+description: Use when ...
+tools: Read, Grep, Glob
+model: sonnet
+---
+```
+
+Agent body must state:
+
+- load first
+- inputs required
+- allowed write set or read-only
+- forbidden scope
+- verification or evidence
+- return format from [subagents.md](subagents.md) and [dispatch.md](dispatch.md)
+
+## Skill Contract
+
+Every added skill must state:
+
+- when to use
+- docs to load
+- required inputs
+- allowed writes
+- output format
+- whether to update `Harness/PROGRESS.md` and task files
+- whether to use [subagents.md](subagents.md) and [dispatch.md](dispatch.md)
+
+Skills should extend the harness. They should not replace `Harness/README.md`, `Harness/PROGRESS.md`, `subagents.md`, `context-loading.md`, `dispatch.md`, or `agent-workflow.md`.
+
+## Rules
+
+- Do not add broad agents that can write anywhere.
+- Do not add agents whose role overlaps an existing common agent without naming the difference.
+- Do not add tools that bypass project permissions or user approval.
+- Do not run stack-specific writing agents in parallel unless write sets are disjoint.
+- If an added asset conflicts with this harness, adapt the asset instead of changing the core contract.
+
+## Registration
+
+After adding assets:
+
+- list agents in `Harness/MEMORY.md#Agents`
+- list skills in `Harness/MEMORY.md#Skills`
+- list workflows by path in `Harness/MEMORY.md` or `Harness/README.md`
+- update `Harness/PROGRESS.md` and `Harness/tasks/<task-id>/PROGRESS.md` when the asset affects current work
+- run `node Harness/scripts/validate-harness.mjs`

package/templates/common/docs/harness/lifecycle.md

@@ -1,33 +1,33 @@
-# 0-1 Product Lifecycle
-
-Use when starting a new product, clarifying a vague idea, or deciding the next phase.
-
-## Phase Contract
-
-| Phase | Input | Output | Gate |
-| --- | --- | --- | --- |
-| Idea | user intent | problem, target user, non-goals | unclear points asked or assumptions recorded |
-| Research | problem and constraints | `research/research-results.md` | `research/README.md` followed; at least 3 references or explicit reason not possible |
-| PRD | research decision | `research/PRD.md` | MVP, non-goals, acceptance criteria are verifiable |
-| Architecture | PRD | `Harness/architecture.md`, `Harness/domain/ports.md` | boundaries and first ports are defined |
-| Plan | PRD and architecture | `Harness/PROGRESS.md`, `Harness/tasks/<task-id>/PLAN.md`, optional `Harness/dispatch.md`, one `Harness/features/<name>.md` per PRD scope item | tasks have owners, write sets, verification |
-| Build | plan and tests | minimal vertical slice | tests or manual checks prove behavior |
-| Verify | implementation | review findings, test evidence | no unresolved critical/high findings |
-| Feedback | verified slice | next iteration or release decision | learnings recorded in PRD, `Harness/tasks/<task-id>/PROGRESS.md`, or MEMORY |
-
-## Operating Rules
-
-- Move one phase at a time unless the user explicitly asks for a fast lane.
-- Start coding only after PRD and minimum architecture gates pass.
-- Prefer one thin vertical slice over broad scaffolding.
-- If feedback changes scope, update PRD before implementation.
-- If implementation reveals a boundary problem, update architecture or ports before continuing.
-
-## Fast Lane
-
-Small edits may skip full lifecycle when all are true:
-
-- user intent is clear
-- one file or one narrow behavior
-- no architecture, port, data-flow, state, permission, or public API change
-- one verification command or one manual check is enough
+# 0-1 Product Lifecycle
+
+Use when starting a new product, clarifying a vague idea, or deciding the next phase.
+
+## Phase Contract
+
+| Phase | Input | Output | Gate |
+| --- | --- | --- | --- |
+| Idea | user intent | problem, target user, non-goals | unclear points asked or assumptions recorded |
+| Research | problem and constraints | `research/research-results.md` | `research/README.md` followed; at least 3 references or explicit reason not possible |
+| PRD | research decision | `research/PRD.md` | MVP, non-goals, acceptance criteria are verifiable |
+| Architecture | PRD | `Harness/architecture.md` | boundaries and first ports are defined |
+| Plan | PRD and architecture | `Harness/tasks/<task-id>/PLAN.md`, optional `Harness/dispatch.md` | tasks have owners, write sets, verification |
+| Build | plan and tests | minimal vertical slice | tests or manual checks prove behavior |
+| Verify | implementation | review findings, test evidence | no unresolved critical/high findings |
+| Feedback | verified slice | next iteration or release decision | learnings recorded in PRD, PLAN, or MEMORY |
+
+## Operating Rules
+
+- Move one phase at a time unless the user explicitly asks for a fast lane.
+- Start coding only after PRD and minimum architecture gates pass.
+- Prefer one thin vertical slice over broad scaffolding.
+- If feedback changes scope, update PRD before implementation.
+- If implementation reveals a boundary problem, update architecture or ports before continuing.
+
+## Fast Lane
+
+Small edits may skip full lifecycle when all are true:
+
+- user intent is clear
+- one file or one narrow behavior
+- no architecture, permission, or public API change
+- one verification command or one manual check is enough

package/templates/common/docs/harness/subagents.md

@@ -72,7 +72,7 @@ Then add phase-specific agents:
 - `context-master` before closeout for knowledge extraction
 - `memory-master` after repeated failures and during closeout for consolidation
 
-The default decision ratio is a 7:3 collaboration bias: choose multi-agent collaboration for substantial or uncertain work about 70% of the time; choose solo mode only for clearly local, low-risk work that is not explicitly in WF/WK mode.
+Collaboration mode is determined by concrete conditions, not a fixed ratio. See `Harness/WF.md#Multi-Subagent Requirement` for the full decision tree. Summary: explicit WF/WK mode → always multi-agent. 3+ files or cross-layer → multi-agent. 1-2 local files, well-understood, not in WF mode → solo acceptable. Repeated failure → stop solo, switch to multi-agent.
 
 ## Efficiency Ladder
 

package/templates/common/docs/research/PRD.md

@@ -1,65 +1,65 @@
-# PRD: {{projectName}}
-
-> **Audience**: AI + future you. Not for PM approval — for implementation and review.
-> **Principle**: One page max. Use checkboxes, not prose. Negative definitions > positive definitions.
->
-> Philosophy source: Miqdad Jaffer (OpenAI)'s lean PRD template for the AI era.
-
----
-
-## 1. Why
-
-{{WHY_THIS_PROJECT_EXISTS}}
-
-## 2. MVP Scope
-
-### v0.1 Must Be Able To
-
-> Each item below must be split into a separate `Harness/features/<name>.md` created from `Harness/features/_template.md` before implementation begins. One feature = one doc = one implementation unit.
-
-- [ ] {{MUST_1}}
-- [ ] {{MUST_2}}
-- [ ] {{MUST_3}}
-
-### Explicitly Out of Scope
-
-- {{NON_GOAL_1}}
-- {{NON_GOAL_2}}
-- {{NON_GOAL_3}}
-
-## 3. Decision Priorities
-
-1. **Security Boundary** — No bypassing permissions, security gates, or audit.
-2. **Architecture Boundary** — Domain must not depend on harness/infrastructure/interfaces, and harness must not make domain judgments.
-3. **Verifiability** — New behavior must have tests or explicit manual verification records.
-4. **Correctness** — Behavior must match design docs, port contracts, data flows, and state machines.
-5. **Simplicity** — Minimum code to solve the current MVP. No abstractions pre-built for future scenarios.
-
-## 4. Users & Usage Scenarios
-
-| User Role | Core Scenario | Frequency | Pain Point |
-| --- | --- | --- | --- |
-| {{USER_ROLE_1}} | {{SCENARIO}} | {{FREQUENCY}} | {{PAIN}} |
-| {{USER_ROLE_2}} | {{SCENARIO}} | {{FREQUENCY}} | {{PAIN}} |
-
-## 5. Acceptance Criteria
-
-- [ ] {{ACCEPTANCE_1}}
-- [ ] {{ACCEPTANCE_2}}
-- [ ] {{ACCEPTANCE_3}}
-
-## 6. Non-Functional Requirements
-
-| Dimension | Target | Measurement |
-| --- | --- | --- |
-| {{DIMENSION_1}} | {{TARGET}} | {{MEASUREMENT}} |
-| {{DIMENSION_2}} | {{TARGET}} | {{MEASUREMENT}} |
-
----
-
-## Fill Completion Standard
-
-- [ ] MVP and Non-goals are project facts; no `{{...}}` placeholders remain.
-- [ ] Decision priorities guide tradeoffs, not generic platitudes.
-- [ ] Every acceptance criterion is verifiable by test, command, or manual step.
-- [ ] If implementation diverges from the PRD, update this file before changing code.
+# PRD: {{projectName}}
+
+> **Audience**: AI + future you. Not for PM approval — for implementation and review.
+> **Principle**: One page max. Use checkboxes, not prose. Negative definitions > positive definitions.
+>
+> Philosophy source: Miqdad Jaffer (OpenAI)'s lean PRD template for the AI era.
+
+---
+
+## 1. Why
+
+{{WHY_THIS_PROJECT_EXISTS}}
+
+## 2. MVP Scope
+
+### v0.1 Must Be Able To
+
+> Each item below should have a task capsule created from `Harness/tasks/_template/` with its own `PROGRESS.md` and `PLAN.md`.
+
+- [ ] {{MUST_1}}
+- [ ] {{MUST_2}}
+- [ ] {{MUST_3}}
+
+### Explicitly Out of Scope
+
+- {{NON_GOAL_1}}
+- {{NON_GOAL_2}}
+- {{NON_GOAL_3}}
+
+## 3. Decision Priorities
+
+1. **Security Boundary** — No bypassing permissions, security gates, or audit.
+2. **Architecture Boundary** — Domain must not depend on harness/infrastructure/interfaces, and harness must not make domain judgments.
+3. **Verifiability** — New behavior must have tests or explicit manual verification records.
+4. **Correctness** — Behavior must match design docs, port contracts, data flows, and state machines.
+5. **Simplicity** — Minimum code to solve the current MVP. No abstractions pre-built for future scenarios.
+
+## 4. Users & Usage Scenarios
+
+| User Role | Core Scenario | Frequency | Pain Point |
+| --- | --- | --- | --- |
+| {{USER_ROLE_1}} | {{SCENARIO}} | {{FREQUENCY}} | {{PAIN}} |
+| {{USER_ROLE_2}} | {{SCENARIO}} | {{FREQUENCY}} | {{PAIN}} |
+
+## 5. Acceptance Criteria
+
+- [ ] {{ACCEPTANCE_1}}
+- [ ] {{ACCEPTANCE_2}}
+- [ ] {{ACCEPTANCE_3}}
+
+## 6. Non-Functional Requirements
+
+| Dimension | Target | Measurement |
+| --- | --- | --- |
+| {{DIMENSION_1}} | {{TARGET}} | {{MEASUREMENT}} |
+| {{DIMENSION_2}} | {{TARGET}} | {{MEASUREMENT}} |
+
+---
+
+## Fill Completion Standard
+
+- [ ] MVP and Non-goals are project facts; no `{{...}}` placeholders remain.
+- [ ] Decision priorities guide tradeoffs, not generic platitudes.
+- [ ] Every acceptance criterion is verifiable by test, command, or manual step.
+- [ ] If implementation diverges from the PRD, update this file before changing code.