@sienklogic/plan-build-run 2.21.0 → 2.21.2

package/plugins/pbr/templates/PROJECT.md.tmpl

@@ -0,0 +1,126 @@
+<!-- Downstream consumers:
+  - Planner agent: reads Vision/Scope to bound phases. Needs: project name, in-scope features, constraints, success criteria.
+  - Executor agent: reads Constraints/Key Decisions for implementation choices. Needs: locked technology decisions.
+  - Verifier agent: reads Success Criteria for pass/fail. Needs: testable, observable criteria.
+  - Dashboard PlanningReader: parses heading structure. Needs: standard ## headings.
+  Breaks if missing: Planner plans without boundaries; verifier has no criteria; dashboard shows empty project card.
+-->
+# {project_name}
+
+> {ONE sentence core value statement}
+<!-- Guidelines: One sentence, under 20 words. State what the project IS and its primary value. -->
+
+## What This Is
+
+<!-- Guidelines: 2-3 sentences. Product description, target user, problem being solved.
+     Avoid implementation details -- this is a "what" not "how" section. -->
+{2-3 sentences describing the product and problem it solves. Who is it for? What does it replace or improve?}
+
+## Core Value
+
+<!-- Guidelines: Expand on the one-liner. What makes this worth building? What does it replace or improve?
+     Keep to 2-3 sentences. This is the "why" behind the project. -->
+{Why this project matters -- the value proposition in 2-3 sentences.}
+
+## Requirements Summary
+
+<!-- Guidelines: Bulleted features grouped by area. Each Active Requirement must trace to a REQ-ID in REQUIREMENTS.md. -->
+
+### Active Requirements (Current Milestone)
+
+- {Feature area}: {brief description}
+
+### Validated Requirements (Completed in Prior Milestones)
+
+- {Feature}: {validated in milestone vX.Y}
+
+### Out of Scope
+
+<!-- Guidelines: Explicit exclusions with rationale. Prevents scope creep during planning. -->
+- {Feature}: {brief reason why excluded}
+
+## Context
+
+### Constraints
+
+<!-- Guidelines: Budget, timeline, team size, hosting, skill level. Non-negotiable external factors.
+     Even if there are no constraints, state "None identified" rather than omitting. -->
+- {constraint}
+
+### Key Decisions
+
+<!-- Guidelines: Technology and architecture decisions locked at project start. Each needs rationale.
+     These are LOCKED after creation -- changes require explicit scope-change discussion via /pbr:discuss-phase. -->
+| Decision | Rationale | Decided By | Outcome |
+|----------|-----------|------------|---------|
+| {decision} | {rationale} | {user/claude} | {Good/Revisit/Pending} |
+
+## Success Criteria
+
+<!-- Guidelines: Observable, testable conditions that define project success. No subjective adjectives.
+     Each should be verifiable by an automated test or manual inspection. -->
+- {Criterion 1 -- specific and measurable}
+- {Criterion 2 -- specific and measurable}
+- {Criterion 3 -- specific and measurable}
+
+## Milestones
+
+{project_name} planned in {phase_count} phases across {milestone_count} milestone(s).
+See `.planning/ROADMAP.md` for phase details.
+
+{{#brownfield}}
+## Existing Codebase
+
+### Validated Requirements
+
+<!-- Guidelines: Requirements inferred from existing code analysis. Each should reference the source file
+     or pattern that demonstrates the capability. Confidence reflects how certain the inference is. -->
+| Inferred Requirement | Evidence | Confidence |
+|---------------------|----------|------------|
+| {requirement} | {source file/pattern} | {HIGH/MEDIUM/LOW} |
+
+### Existing Architecture
+
+<!-- Guidelines: Current system structure as discovered by codebase scan.
+     Reference .planning/codebase/ analysis files where available. -->
+{Architecture summary from scan results}
+
+### Known Tech Debt
+
+<!-- Guidelines: Issues discovered during codebase analysis that should be addressed.
+     Include impact assessment and suggested remediation priority. -->
+- {debt item}: {impact and suggested remediation}
+{{/brownfield}}
+
+## Evolution
+
+This document evolves through the project lifecycle:
+- **Created by:** `/pbr:new-project` during project initialization
+- **Updated by:** `/pbr:discuss-phase` when scope or constraints change
+- **Frozen after:** Roadmap creation -- subsequent changes require explicit scope-change discussion via `/pbr:discuss-phase`
+
+## Evolution Protocol
+
+At each milestone boundary, review and update:
+1. Move completed Active Requirements to Validated Requirements
+2. Review Out of Scope -- any items now in scope?
+3. Annotate Key Decisions with outcomes (Good/Revisit/Pending)
+4. Update Constraints if any changed
+5. Refresh Core Value if project direction shifted
+
+## Quality Criteria
+
+A good PROJECT.md satisfies:
+- [ ] Core value is one sentence, under 20 words
+- [ ] What This Is answers: what, who, why in 2-3 sentences
+- [ ] Every Active Requirement maps to at least one REQ-ID in REQUIREMENTS.md
+- [ ] Validated Requirements reference the milestone where completed
+- [ ] Every Out of Scope item has a rationale
+- [ ] Success criteria are observable and testable
+- [ ] Key Decisions table has at least one entry with Outcome column
+- [ ] Constraints section is populated (even if "none identified")
+- [ ] Evolution Protocol section is present
+{{#brownfield}}
+- [ ] Validated Requirements cite evidence from existing code
+- [ ] Existing Architecture references codebase scan files
+{{/brownfield}}

package/plugins/pbr/templates/REQUIREMENTS.md.tmpl

@@ -0,0 +1,96 @@
+<!-- Downstream consumers:
+  - Planner agent: reads requirements for phase scoping. Needs: REQ-IDs, priorities, categories.
+  - Verifier agent: reads for completion checking. Needs: requirement status, testable statements.
+  - Roadmap skill: reads for phase-to-requirement mapping. Needs: REQ-ID to phase mapping in traceability table.
+  - Dashboard: parses requirement checkboxes and status columns. Needs: consistent table format.
+  Breaks if missing: Planner creates plans without requirement coverage; verifier cannot confirm completion; roadmap has no requirement traceability.
+-->
+# Requirements
+
+> Living document. Generated by `/pbr:new-project`, updated via `/pbr:discuss-phase`.
+> All requirements flow from here into plans via `implements:[]` in PLAN.md frontmatter.
+
+## Functional Requirements
+
+<!-- Guidelines: Capabilities the system must provide from the user's perspective.
+     Group by feature category. Each requirement must be testable -- if you can't write a test for it, rewrite it.
+     Priority: Must (blocks launch), Should (high value), Could (nice to have). -->
+
+Capabilities the system must provide from the user's perspective.
+
+### {Category} (e.g., Authentication, API, UI)
+
+| ID | Requirement | Priority | Status |
+|----|-------------|----------|--------|
+| REQ-F-001 | {User-centric, testable statement of capability} | Must | Open |
+| REQ-F-002 | {User-centric, testable statement of capability} | Should | Open |
+
+### {Category 2}
+
+| ID | Requirement | Priority | Status |
+|----|-------------|----------|--------|
+| REQ-F-010 | {User-centric, testable statement of capability} | Must | Open |
+
+## Non-Functional Requirements
+
+<!-- Guidelines: Quality attributes and constraints. Each must be observable and measurable.
+     "Fast" is not a requirement. "Page loads in <2s on 4G" is a requirement.
+     Categories: Performance, Security, Reliability, Scalability, Accessibility, Maintainability. -->
+
+Quality attributes and constraints the system must satisfy.
+
+| ID | Requirement | Category | Priority |
+|----|-------------|----------|----------|
+| REQ-NF-001 | {Observable quality statement -- e.g., "Page loads in <2s on 4G"} | Performance | Must |
+| REQ-NF-002 | {Observable quality statement} | Security | Must |
+| REQ-NF-003 | {Observable quality statement} | Reliability | Should |
+
+## Deferred Requirements (v2+)
+
+<!-- Guidelines: Requirements explicitly out of scope for v1 but tracked for future.
+     Include the reason for deferral so future planners understand the decision. -->
+
+Requirements explicitly out of scope for v1.
+
+| ID | Requirement | Deferred Reason |
+|----|-------------|----------------|
+| REQ-F-099 | {requirement} | {reason -- e.g., "Phase 2 priority"} |
+
+## Out of Scope
+
+<!-- Guidelines: Features explicitly excluded from the entire project. These must NOT appear in any plan.
+     Different from Deferred -- these are permanent exclusions. -->
+
+Features explicitly excluded. These must NOT appear in any plan.
+
+- {Feature}: {brief rationale}
+
+## Traceability
+
+<!-- Guidelines: Maps every requirement to its implementation phase and verification.
+     Phase column tracks which phase addresses the requirement.
+     Status tracks lifecycle: Open -> In Progress -> Implemented -> Verified.
+     Update this table as plans are created and completed. -->
+
+| REQ-ID | Phase | Implemented In | Verified In | Status |
+|--------|-------|---------------|------------|--------|
+| REQ-F-001 | Phase 01 | Phase 01 PLAN-01 | Phase 01 VERIFICATION.md | Verified |
+| REQ-F-002 | Phase 02 | -- | -- | Open |
+
+## Evolution
+
+This document evolves through the project lifecycle:
+- **Created by:** `/pbr:new-project` during project initialization
+- **Updated by:** `/pbr:discuss-phase` when requirements change or are reprioritized
+- **Updated by:** `/pbr:execute-phase` when implementations complete (status column updates)
+- **Referenced by:** `/pbr:verify` for completion checking
+
+## Quality Criteria
+
+A good REQUIREMENTS.md satisfies:
+- [ ] Every requirement has a unique ID following the naming convention (REQ-F-NNN or REQ-NF-NNN)
+- [ ] Every requirement is testable -- can write a pass/fail check for it
+- [ ] Every In Scope item in PROJECT.md maps to at least one requirement here
+- [ ] Traceability table is populated with phase assignments for all Must-priority requirements
+- [ ] No orphan requirements (every REQ-ID appears in at least one plan's `implements:[]`)
+- [ ] Status column is current (no stale "Open" for completed work)

package/plugins/pbr/templates/RETROSPECTIVE.md.tmpl

@@ -0,0 +1,43 @@
+# Retrospective
+
+> Living document updated after each milestone.
+> Cross-milestone trends help improve the development process.
+
+## {version} {name} (Shipped: {date})
+
+### What Was Built
+{Summary of deliverables from MILESTONES.md entry}
+
+### What Worked
+- {process or approach that went well}
+
+### What Was Inefficient
+- {process or approach that wasted time or context}
+
+### Patterns Established
+- {reusable pattern discovered during this milestone}
+
+### Key Lessons
+- {lesson learned — apply to future milestones}
+
+### Cost Observations
+- Model mix: {opus/sonnet/haiku percentages if known}
+- Sessions: {count}
+- Duration: {days}
+
+---
+
+## Cross-Milestone Trends
+
+### Process Evolution
+| Milestone | Sessions | Phases | Key Process Change |
+|-----------|----------|--------|-------------------|
+| {version} | {count} | {count} | {what changed} |
+
+### Cumulative Quality
+| Milestone | Tests | Coverage | Zero-Dep Additions |
+|-----------|-------|----------|-------------------|
+| {version} | {count} | {%} | {count} |
+
+### Top Lessons (Verified Across Milestones)
+- {lesson confirmed by 2+ milestones}

package/plugins/pbr/templates/ROADMAP.md.tmpl

@@ -1,45 +1,139 @@
-# Project Roadmap
+<!-- Downstream consumers:
+  - Planner agent: reads phase goals/dependencies for plan creation. Needs: phase Goal, Provides, Depends on, Requirements, Success Criteria fields.
+  - Build agent: reads current phase details for execution context. Needs: phase name, goal, planned plans, success criteria.
+  - Status skill: reads progress table for completion tracking. Needs: Progress table with Milestone and Plans Complete columns.
+  - Verifier agent: reads success criteria for phase verification. Needs: Success Criteria (2-5 observable behaviors) per phase.
+  - check-plan-format.js (validateRoadmap): parses ## Milestone: sections and ### Phase NN: headings. Needs: exact heading format, **Goal:**, **Provides:**, **Depends on:** in each phase.
+  - check-roadmap-sync.js: parses progress table rows against STATE.md phase status. Needs: progress table structure with Phase, Milestone, Plans Complete, Status, Completed columns.
+  - Dashboard parseRoadmapMd: parses Phase Overview table. Needs: standard table format.
+  Breaks if missing: Planner creates plans without dependency awareness; validators reject malformed roadmaps; dashboard shows empty roadmap.
+-->
+# Roadmap: {Project Name}
 
 > Generated: {date}
 > Total phases: {n}
 > Estimated plans: {n}
 
-## Phase Overview
+## Milestones
 
-| Phase | Name | Goal | Plans | Wave | Status |
-|-------|------|------|-------|------|--------|
-| 01 | Project Setup | Development environment ready | 2 | 1 | pending |
-| 02 | Authentication | Users can sign in | 3 | 1 | pending |
-| 03 | Core Models | Data layer complete | 4 | 2 | pending |
-| ... | ... | ... | ... | ... | ... |
+<!-- Guidelines: Milestone index for quick navigation. Emoji key: checkmark = shipped, construction = in progress, clipboard = planned. -->
+- {emoji} v1.0 {Name} — Phases 1-{N} ({status: shipped YYYY-MM-DD | in progress | planned})
+- {emoji} v1.1 {Name} — Phases {N+1}-{M} ({status})
 
 ## Dependency Graph
 
+<!-- Guidelines: ASCII art showing phase dependencies. Arrow direction = "depends on".
+     Keep it simple -- complex graphs should reference a separate dependency map file. -->
 ```
-Phase 01 ──→ Phase 02 ──→ Phase 04
-         └──→ Phase 03 ──→ Phase 05
-                       └──→ Phase 04
+Phase 01 ──> Phase 02 ──> Phase 04
+         └──> Phase 03 ──> Phase 05
+                       └──> Phase 04
 ```
 
 ---
 
 ## Milestone: {project name} v1.0
 
+<!-- Guidelines: Milestone heading MUST use exact format "## Milestone: {name}".
+     The validator splits content by this heading pattern.
+     For completed milestones, wrap in <details> collapse (see template below). -->
 **Goal:** {overall project goal from requirements}
 **Phases:** 1 - {n}
+**Requirement coverage:** {covered}/{total} requirements mapped
+
+### Phase Checklist
+<!-- Guidelines: One checkbox per phase. Format: "- [ ] Phase NN: {name} -- {one-line goal}".
+     Check off phases as they complete. -->
+- [ ] Phase 01: {name} -- {one-line goal summary}
+- [ ] Phase 02: {name} -- {one-line goal summary}
+- [ ] Phase 03: {name} -- {one-line goal summary}
+
+## Phase Details
 
 ### Phase 01: Project Setup
 
+<!-- Guidelines: Phase heading MUST use exact format "### Phase NN: {name}".
+     Each phase MUST include **Goal:**, **Provides:**, **Depends on:**, **Requirements:**, and **Success Criteria:** fields.
+     The validator checks for Goal, Provides, and Depends on -- missing any triggers a warning. -->
 **Goal**: {goal statement}
+**Provides**:
+- {what this phase delivers for downstream phases}
+**Depends on**: None (starting phase)
+**Requirements:** [{REQ-IDs relevant to this phase, e.g., REQ-F-001, REQ-F-002}]
+
+**Success Criteria:**
+1. {Observable user behavior when phase is complete}
+2. {Another observable outcome}
+3. {Third observable outcome — 2-5 items total}
+
 **Must-Haves**:
 - {truth 1}
 - {truth 2}
 
 **Planned Plans**:
+<!-- Guidelines: Numbered list of plans within this phase. Include wave and autonomy level.
+     Wave indicates parallelization grouping. Autonomous plans need no human checkpoints. -->
 1. {plan name} (Wave 1, autonomous)
 2. {plan name} (Wave 1, autonomous)
 
-**Dependencies**: None (starting phase)
+### Phase 02: {name}
+
+**Goal**: {goal statement}
+**Provides**:
+- {deliverable}
+**Depends on**: Phase 01
+**Requirements:** [{REQ-IDs}]
+
+**Success Criteria:**
+1. {Observable behavior}
+2. {Observable behavior}
+
+**Must-Haves**:
+- {truth 1}
+
+**Planned Plans**:
+1. {plan name} (Wave 1, autonomous)
+
+## Completed Milestones
+
+<!-- Guidelines: When a milestone ships, collapse it into a <details> block.
+     Move content from the active milestone section into here. -->
+<details>
+<summary>v0.9 {Name} (Phases 1-{N}) — SHIPPED YYYY-MM-DD</summary>
+
+{Collapsed milestone content: phase checklist, phase details, etc.}
+
+</details>
+
+## Progress
+
+<!-- Guidelines: Progress table MUST include "Phase", "Milestone", "Plans Complete", "Status", and "Completed" columns.
+     The validator checks for "Plans Complete" column header with proper separator row.
+     Update this table as plans complete. -->
+| Phase | Milestone | Plans Complete | Status | Completed |
+|-------|-----------|---------------|--------|-----------|
+| Phase 01 | v1.0 | 0/2 | Not Started | |
+| Phase 02 | v1.0 | 0/1 | Not Started | |
+
+## Evolution
+
+This document evolves through the project lifecycle:
+- **Created by:** `/pbr:new-project` during roadmap generation
+- **Updated by:** `/pbr:execute-phase` as phases and plans complete (progress table, phase checklist)
+- **Updated by:** `/pbr:discuss-phase` if scope changes require phase restructuring
+- **Referenced by:** `/pbr:plan-phase` for phase scoping and dependency resolution
+
+## Quality Criteria
 
-### Phase 02: Authentication
-...
+A good ROADMAP.md satisfies:
+- [ ] Every phase has **Goal:**, **Provides:**, and **Depends on:** fields
+- [ ] Every phase has **Requirements:** with mapped REQ-IDs
+- [ ] Every phase has **Success Criteria:** with 2-5 observable behaviors
+- [ ] Phase numbers are sequential with no gaps (MUST start at 1, increment by 1 — no gap numbering like 10, 20, 30)
+- [ ] Progress table row count matches phase count
+- [ ] Progress table includes Milestone column for each phase
+- [ ] Dependencies form a DAG (no circular dependencies)
+- [ ] Phase Checklist items match Phase Details sections 1:1
+- [ ] Requirement coverage line accounts for all Must-priority requirements
+- [ ] Dependency graph is consistent with phase **Depends on:** declarations
+- [ ] Completed milestones are collapsed in `<details>` blocks

package/plugins/pbr/templates/SUMMARY-complex.md.tmpl

@@ -0,0 +1,133 @@
+# SUMMARY-complex.md Template
+
+<!-- Downstream consumers:
+  - check-plan-format.js (validateSummary): validates frontmatter fields (phase, plan, status, provides, requires, key_files). Does NOT validate body sections.
+  - Status skill: reads plan completion status and metrics. Needs: frontmatter status field, metrics block.
+  - Dashboard: displays plan details and accomplishments. Needs: frontmatter + body structure.
+  Breaks if missing: Validator rejects summary without required frontmatter; status skill cannot track completion; dashboard shows empty plan card.
+-->
+
+> Use when: decisions were made OR fileCount > 6
+> Referenced by: executor agent (complex plans, architectural work)
+
+## Frontmatter (YAML)
+
+```yaml
+---
+phase: "{phase_id}"
+plan: "{plan_id}"
+status: "complete"           # complete | partial | checkpoint
+subsystem: "{main subsystem affected}"
+tags:
+  - "{tag1}"
+requires:
+  - "{plan_id}: {artifact}"
+provides:
+  - "{export/artifact description}"
+affects:
+  - "{affected area 1}"
+tech_stack:
+  - "{technology used}"
+key_files:
+  - "{file1}: {what it does}"
+key_decisions:
+  - "{decision 1}: {rationale}"
+patterns:
+  - "{pattern used}: {where}"
+metrics:
+  duration_minutes: {n}
+  tasks_completed: {n}
+  tasks_total: {n}
+  commits: {n}
+  files_created: {n}
+  files_modified: {n}
+requirements_completed:
+  - "REQ-ID: brief description of how it was satisfied"
+deviations:
+  - rule: 1          # 1=Bug, 2=Missing Critical, 3=Blocking, 4=Architectural
+    description: "..."
+    action: "auto"   # auto | ask
+    justification: "..."
+deferred:
+  - "{thing noticed but not implemented}"
+self_check_failures:
+  - "{failure description}"
+architecture_notes:
+  - "{key architectural decision and why}"
+---
+```
+
+## Body Structure
+
+```markdown
+# Plan Summary: {plan_id}
+
+## What Was Built
+
+{2-3 paragraph description of what was accomplished}
+
+## Architecture Decisions
+
+| Decision | Options Considered | Chosen | Rationale |
+|----------|-------------------|--------|-----------|
+| {decision} | {opt1}, {opt2} | {chosen} | {why} |
+
+## Task Results
+
+| Task | Status | Commit | Files | Verify |
+|------|--------|--------|-------|--------|
+| {task_id}: {name} | done | {hash} | {count} | passed |
+
+## Key Implementation Details
+
+{Important details about HOW things were implemented}
+
+## Integration Points
+
+{How this plan connects to other plans - imports, exports, shared state}
+
+## Known Issues
+
+{Issues discovered during execution}
+
+## Dependencies Provided
+
+{What other plans can now depend on}
+
+## Deviations
+
+| # | Rule | Description | Action | Justification |
+|---|------|-------------|--------|---------------|
+| 1 | Rule 1 (Bug) | {description} | auto | {why} |
+
+## Self-Check
+
+- [ ] All tasks completed per plan
+- [ ] Commits match task count
+- [ ] No TODO/FIXME left in new code
+- [ ] Key files exist and are substantive
+- [ ] requirements_completed matches plan implements
+
+## Deferred Items
+
+{Items noticed but intentionally deferred - with rationale}
+
+## Quality Criteria
+
+A good plan summary satisfies:
+- [ ] All frontmatter fields are populated (no empty or placeholder values)
+- [ ] key_files paths reference files that exist in the repository
+- [ ] What Was Built section describes concrete outcomes, not process
+- [ ] Architecture Decisions table documents any deviations from the plan
+- [ ] Task Results table has a row for every task in the plan
+- [ ] Deferred Items section explains rationale for each deferral
+```
+
+## Selection Heuristic
+
+Use this template when ANY of the following are true:
+- Key architectural decisions were made during execution
+- Total files created or modified > 6
+- Deviations from the plan occurred
+- Multiple integration points were established
+- The plan touched shared infrastructure or patterns

package/plugins/pbr/templates/SUMMARY-minimal.md.tmpl

@@ -0,0 +1,55 @@
+# SUMMARY-minimal.md Template
+
+> Use when: taskCount <= 2 AND fileCount <= 3
+> Referenced by: executor agent (quick tasks, simple plans)
+
+## Frontmatter (YAML)
+
+```yaml
+---
+phase: "{phase_id}"
+plan: "{plan_id}"
+status: "complete"           # complete | partial | checkpoint
+requires: []
+provides:
+  - "{export/artifact description}"
+key_files:
+  - "{file1}: {what it does}"
+requirements_completed: []
+deviations: []
+deferred: []
+metrics:
+  tasks_completed: {n}
+  tasks_total: {n}
+  commits: {n}
+---
+```
+
+## Body Structure
+
+```markdown
+# Plan Summary: {plan_id}
+
+## What Was Built
+
+{1 paragraph description}
+
+## Task Results
+
+| Task | Status | Commit | Files |
+|------|--------|--------|-------|
+| {task_id}: {name} | done | {hash} | {count} |
+
+## Self-Check
+
+- [ ] All tasks completed per plan
+- [ ] Key files exist and are substantive
+```
+
+## Selection Heuristic
+
+Use this template when ALL of the following are true:
+- Total tasks in the plan <= 2
+- Total files created or modified <= 3
+- No key decisions were made
+- No deviations from the plan occurred

package/plugins/pbr/templates/SUMMARY.md.tmpl

@@ -37,6 +37,13 @@ metrics:
   commits: {n}
   files_created: {n}
   files_modified: {n}
+requirements_completed:
+  - "REQ-ID: brief description of how it was satisfied"
+deviations:
+  - rule: 1          # 1=Bug, 2=Missing Critical, 3=Blocking, 4=Architectural
+    description: "..."
+    action: "auto"   # auto | ask
+    justification: "..."
 deferred:
   - "{thing noticed but not implemented}"
 self_check_failures:         # Only present if self-check found issues
@@ -67,6 +74,20 @@ self_check_failures:         # Only present if self-check found issues
 
 {Any issues discovered during execution that weren't blockers but should be tracked}
 
+## Deviations
+
+| # | Rule | Description | Action | Justification |
+|---|------|-------------|--------|---------------|
+| 1 | Rule 1 (Bug) | {description} | auto | {why} |
+
+## Self-Check
+
+- [ ] All tasks completed per plan
+- [ ] Commits match task count
+- [ ] No TODO/FIXME left in new code
+- [ ] Key files exist and are substantive
+- [ ] requirements_completed matches plan implements
+
 ## Dependencies Provided
 
 {What other plans can now depend on — exports, files, APIs created}