@sienklogic/plan-build-run 2.1.0 → 2.1.1

package/plugins/codex-pbr/skills/undo/SKILL.md

@@ -0,0 +1,214 @@
+---
+name: undo
+description: "Revert recent PBR-generated commits by phase/plan, safely using git revert."
+---
+
+**STOP — DO NOT READ THIS FILE. You are already reading it. This prompt was injected into your context by Claude Code's plugin system. Begin executing Step 0 immediately.**
+
+## Step 0 — Immediate Output
+
+**Before ANY tool calls**, display this banner:
+
+```
+╔══════════════════════════════════════════════════════════════╗
+║  PLAN-BUILD-RUN ► UNDO                                       ║
+╚══════════════════════════════════════════════════════════════╝
+```
+
+Then proceed to Step 1.
+
+# $pbr-undo — Safe Commit Reversal
+
+You are running the **undo** skill. Your job is to help the user safely revert recent PBR-generated commits using `git revert` (history-preserving), not `git reset` (destructive).
+
+This skill runs **inline** (no Task delegation).
+
+---
+
+## Step 1 — Gather PBR Commits
+
+Run:
+
+```bash
+git log --oneline --no-merges -50
+```
+
+Filter lines matching the PBR commit pattern:
+`^[0-9a-f]+ (feat|fix|refactor|test|docs|chore|wip|revert)(\([a-zA-Z0-9._-]+\))?:`
+
+If no PBR commits found, display:
+
+```
+No PBR commits found in the last 50 commits.
+```
+
+Then exit.
+
+**Parse $ARGUMENTS for flags**:
+- `--last N`: limit to N most recent PBR commits (default 20)
+- `--phase NN`: filter to commits for a specific phase number (e.g. `--phase 55`)
+- `--plan NN-MM`: filter to commits for a specific plan (e.g. `--plan 55-02`)
+- `--range HASH..HASH`: preselect a hash range for revert — if provided, skip to Step 5 with that range pre-filled
+
+**Phase manifest mode (`--phase NN`):**
+
+When `--phase NN` is specified, first check for a `.phase-manifest.json` in the phase directory:
+
+1. Resolve the phase directory: `.planning/phases/{NN}-*/`
+2. Check for `.phase-manifest.json` in that directory
+3. If manifest exists: use `manifest.commits` as the commit list (skip git log scan)
+4. If manifest missing (phases completed before manifest support): fall back to git log scan and filter by scope pattern
+
+Phase manifests are written by `completePhase()`. Older phases may not have manifests.
+
+Apply filters to the collected PBR commits before proceeding.
+
+---
+
+## Step 2 — Group Commits by Scope
+
+Parse the scope from each commit message (e.g., `55-02`, `quick-003`, `planning`). If no scope is present, use `(no scope)`.
+
+Present grouped output:
+
+```
+Recent PBR commits (grouped by scope):
+
+[undo]
+  abc1234  feat(undo): add undo skill
+  def5678  chore(undo): register undo command
+
+[quick-003]
+  ghi9012  fix(quick-003): fix hook path resolution
+
+[planning]
+  jkl3456  docs(planning): update roadmap phase 55
+```
+
+For descriptive scopes, show just the scope label. For phase-plan scopes (NN-MM pattern, from older commits), add a "Phase NN, Plan MM" annotation.
+
+---
+
+## Step 3 — Prompt for Selection
+
+Use AskUserQuestion with the **select-action** pattern:
+
+- **question**: "Which commit(s) do you want to undo? Select a scope to revert all commits in that scope, or choose a custom option."
+- **header**: "Select commits to undo"
+- **options**: (dynamic — top 8 scope labels from grouped list, each formatted as `[{scope}] {N} commit(s)`, plus "Enter custom hash or range" and "Cancel")
+- **multiSelect**: false
+
+If user selects a scope label: collect all commits with that scope as the revert set.
+If user selects "Enter custom hash or range": use AskUserQuestion (freeform) to ask:
+  - "Enter a commit hash or range (e.g. abc1234 or abc..def):"
+  - Parse the response as a hash or HASH1..HASH2 range
+If user selects "Cancel": print "Undo cancelled." and exit.
+
+---
+
+## Step 3.5 — Pre-Revert Safety Gates (for `--phase NN` mode)
+
+When reverting an entire phase (`--phase NN`), run these 3 safety checks before proceeding to confirmation:
+
+**Gate 1: Downstream dependency check**
+Parse `.planning/ROADMAP.md` to find phases that list the target phase in their "Depends on" field. If any dependent phase has been started (has PLAN files or SUMMARY files), block with:
+```
+Phase {M} ({name}) depends on phase {N} and has already begun. Undo would break downstream work.
+To proceed anyway, use --force.
+```
+
+**Gate 2: Commit preview**
+Display all commits that will be reverted as a numbered list:
+```
+Commits to revert ({count}):
+  1. abc1234  feat(auth): implement discord oauth
+  2. def5678  fix(auth): handle null profile
+  3. ghi9012  docs(planning): add phase 3 summaries
+```
+
+**Gate 3: Explicit confirmation**
+Use AskUserQuestion with the **yes-no** pattern:
+- **question**: "Revert {count} commits from phase {N}? This uses git revert (history-preserving)."
+- **options**: ["Proceed with revert", "Cancel"]
+
+If user selects "Cancel": print "Undo cancelled." and exit.
+
+For non-phase mode (single commits, custom ranges), skip Gate 1 and proceed to Step 4.
+
+---
+
+## Step 4 — Confirm Selection
+
+Display the commits that will be reverted:
+
+```
+The following commits will be reverted (using git revert, NOT git reset):
+
+  abc1234  feat(undo): add undo skill
+  def5678  chore(undo): register undo command
+
+This creates new revert commits — your history is preserved.
+```
+
+Use AskUserQuestion with the **yes-no** pattern:
+- **question**: "Proceed with reverting these commits?"
+- **options**: ["Proceed with revert", "Cancel"]
+
+If user selects "Cancel": print "Undo cancelled." and exit.
+
+---
+
+## Step 5 — Execute git revert
+
+For each commit hash in **reverse chronological order** (newest first):
+
+```bash
+git revert --no-commit {hash}
+```
+
+After all reverts are staged, determine the commit message:
+- Extract scope from the first commit being reverted (e.g., `undo`, `auth`, `executor`)
+- If reverting a **single commit**: `revert({scope}): undo {original description}`
+- If reverting **multiple commits**: `revert({scope}): undo {N} commits from {scope}`
+
+Commit with:
+
+```bash
+git commit -m "revert({scope}): undo {description}"
+```
+
+**Conflict handling**: If `git revert --no-commit` exits non-zero or produces conflict markers:
+1. Run `git revert --abort` to clean up
+2. Display:
+   ```
+   Revert failed due to merge conflicts. Manual resolution required.
+   Run: git revert {hashes} and resolve conflicts.
+   ```
+3. Exit without committing.
+
+---
+
+## Step 6 — Report Result
+
+Display completion banner:
+
+```
+╔══════════════════════════════════════════════════════════════╗
+║  PLAN-BUILD-RUN ► UNDO COMPLETE                              ║
+╚══════════════════════════════════════════════════════════════╝
+
+Reverted: {N} commit(s) from scope {scope}
+New revert commit: {hash} — revert({scope}): undo {description}
+
+$pbr-progress — check current state
+```
+
+---
+
+## Anti-Patterns
+
+1. **DO NOT** use `git reset` — always use `git revert` to preserve history
+2. **DO NOT** revert commits from other users without confirmation
+3. **DO NOT** revert merge commits without warning the user about potential complexity
+4. **DO NOT** skip the confirmation step (Step 4)
+5. **DO NOT** commit if `git revert` reports conflicts — abort and report instead

package/plugins/codex-pbr/templates/CONTEXT.md.tmpl

@@ -0,0 +1,52 @@
+# CONTEXT.md Template
+
+> Referenced by: begin skill (Step 9c), discuss skill, plan skill
+> Created during /pbr:new-project. Updated by /pbr:discuss-phase and /pbr:plan-phase --assumptions.
+
+## Structure
+
+```markdown
+# Project Context
+
+## Locked Decisions
+
+{Technology choices, architecture decisions, and constraints that are NON-NEGOTIABLE.
+ These MUST be honored by every plan and executor — no exceptions.}
+
+| Decision | Rationale | Locked By |
+|----------|-----------|-----------|
+| {e.g., "Use TypeScript"} | {User preference, team skill} | User |
+| {e.g., "PostgreSQL via Supabase"} | {Existing infrastructure} | User |
+
+## User Constraints
+
+{Budget, timeline, skill level, hosting, team size — factors that shape planning}
+
+- {e.g., "Solo developer, no team"}
+- {e.g., "Deploy to Hetzner VPS"}
+- {e.g., "Must work offline"}
+
+## Deferred Ideas
+
+{Features explicitly moved to v2 or out-of-scope. Plans MUST NOT include these.}
+
+| Idea | Reason Deferred |
+|------|----------------|
+| {feature} | {reason} |
+
+## Claude's Discretion Areas
+
+{Areas where the planner can make implementation choices without asking the user.
+ Document the choice made and rationale when exercised.}
+
+| Area | Choice Made | Rationale |
+|------|------------|-----------|
+| {e.g., "State management library"} | {e.g., "Zustand"} | {e.g., "Lightweight, fits project size"} |
+```
+
+## Rules
+
+- Locked decisions are immutable once set — only the user can change them
+- Deferred ideas must NEVER appear in plans
+- Discretion areas are documented when the planner exercises choice
+- Phase-level CONTEXT.md files (in phase directories) override project-level for that phase

package/plugins/codex-pbr/templates/INTEGRATION-REPORT.md.tmpl

@@ -0,0 +1,167 @@
+<!-- Source: agents/integration-checker.md | Purpose: Output format for cross-phase integration verification reports -->
+
+```markdown
+# Integration Verification Report
+
+> Verified: {date}
+> Phases checked: {comma-separated list of phase IDs}
+> Status: **{INTEGRATED | GAPS_FOUND}**
+
+## Phase Dependency Graph
+
+```
+Phase 01 (Setup) ──provides──→ Phase 02 (Auth)
+Phase 01 (Setup) ──provides──→ Phase 03 (Core)
+Phase 02 (Auth)  ──provides──→ Phase 03 (Core)
+Phase 02 (Auth)  ──provides──→ Phase 04 (Frontend)
+Phase 03 (Core)  ──provides──→ Phase 04 (Frontend)
+```
+
+## 1. Export/Import Wiring
+
+### Export Status Summary
+
+| Phase | Total Exports | Consumed | Orphaned | Unused Imports | Mismatched |
+|-------|--------------|----------|----------|---------------|------------|
+| 01 | {n} | {n} | {n} | {n} | {n} |
+| 02 | {n} | {n} | {n} | {n} | {n} |
+
+### Detailed Export Map
+
+| Export | Source Phase | Source File:Line | Consumer(s) | Status |
+|--------|------------|-----------------|-------------|--------|
+| DatabaseConnection | 01 | src/db/conn.ts:5 | Phase 02, 03 | CONSUMED |
+| ConfigLoader | 01 | src/config/index.ts:12 | Phase 03 | CONSUMED |
+| ThemeProvider | 04 | src/theme/provider.tsx:8 | - | ORPHANED |
+
+### Orphaned Exports (created but never used)
+
+| Export | Phase | File | Line | Likely Intended Consumer |
+|--------|-------|------|------|------------------------|
+| {name} | {phase} | {file} | {line} | {best guess or "unknown"} |
+
+### Unused Imports (imported but symbol never called)
+
+| File | Imported Symbol | Source Module | Line |
+|------|----------------|--------------|------|
+| {file} | {symbol} | {module} | {line} |
+
+## 2. API Coverage
+
+### Route Coverage Matrix
+
+| Route | Method | Handler | Frontend Caller | Auth | Status |
+|-------|--------|---------|----------------|------|--------|
+| /api/users | GET | users.ts:12 | UserList.tsx:34 | YES | COVERED |
+| /api/users/:id | DELETE | users.ts:45 | - | YES | NO_CALLER |
+| /api/settings | PUT | - | Settings.tsx:22 | - | NO_HANDLER |
+
+### Uncovered Routes (backend exists, no frontend caller)
+
+| Route | Method | Handler | Possible Reason |
+|-------|--------|---------|----------------|
+| {route} | {method} | {file:line} | {guess: future feature, admin only, etc.} |
+
+### Missing Handlers (frontend calls, no backend route)
+
+| Frontend File | Calls | Expected Route | Expected Method |
+|--------------|-------|---------------|----------------|
+| {file} | fetch('/api/X') | /api/X | GET |
+
+## 3. Auth Protection
+
+### Route Protection Summary
+
+| Category | Total | Protected | Unprotected | Status |
+|----------|-------|-----------|-------------|--------|
+| API Routes | {n} | {n} | {n} | {OK/ISSUES} |
+| Pages | {n} | {n} | {n} | {OK/ISSUES} |
+| Public Routes | {n} | - | {n} | OK |
+
+### Unprotected Routes (SECURITY ISSUES)
+
+| Route | Method | Handler | Should Protect | Evidence |
+|-------|--------|---------|---------------|----------|
+| {route} | {method} | {file:line} | YES | No auth middleware in chain |
+
+### Auth Flow Completeness
+
+| Step | Status | Evidence |
+|------|--------|----------|
+| Login form exists | {YES/NO} | {file:line} |
+| Auth API called | {YES/NO} | {file:line} |
+| Token/session created | {YES/NO} | {file:line} |
+| Token sent with requests | {YES/NO} | {file:line} |
+| Auth middleware applied | {YES/NO} | {file:line} |
+| Unauthorized redirect | {YES/NO} | {file:line} |
+
+## 4. End-to-End Flows
+
+### Flow 1: {Flow Name} - {STATUS}
+
+| Step | Description | Component | Exists | Connected to Next | Evidence |
+|------|------------|-----------|--------|-------------------|----------|
+| 1 | {step desc} | {file} | YES | YES | import at L12, call at L45 |
+| 2 | {step desc} | {file} | YES | NO | handler exists but not called |
+| 3 | {step desc} | - | NO | - | File not found |
+
+**Break point**: {If BROKEN, where exactly the chain breaks}
+**Impact**: {What user action fails because of this break}
+
+### Flow 2: {Flow Name} - {STATUS}
+...
+
+## 5. Data-Flow Propagation
+
+### Cross-Boundary Data Flows
+
+| Data Field | Source | Intermediate Steps | Destination | Status |
+|------------|--------|-------------------|-------------|--------|
+| {field name} | {origin, e.g., hook stdin `data.session_id`} | {module1:L12 → module2:L45} | {dest, e.g., metrics.jsonl `session_id`} | PROPAGATED |
+| {field name} | {origin} | {module1:L12 → module2:L45} | {dest} | DATA_DROPPED |
+
+### Data-Flow Issues
+
+| Field | Dropped At | Available In Scope | Passed Instead | Fix |
+|-------|-----------|-------------------|----------------|-----|
+| {field} | {file:line} | `data.session_id` | `undefined` | Pass `data.session_id` |
+
+## 6. Integration Issues Summary
+
+### Critical Issues (system cannot function)
+
+1. **{Issue}**: {description with evidence}
+   - Impact: {what breaks}
+   - Fix: {recommended action}
+
+### Warnings (partial functionality)
+
+1. **{Issue}**: {description with evidence}
+   - Impact: {what's degraded}
+   - Fix: {recommended action}
+
+### Info (cleanup opportunities)
+
+1. **{Issue}**: {description}
+   - Fix: {recommended action}
+
+## 7. Integration Score
+
+| Category | Items Checked | Passed | Failed | Score |
+|----------|--------------|--------|--------|-------|
+| Export wiring | {n} | {n} | {n} | {%} |
+| API coverage | {n} | {n} | {n} | {%} |
+| Auth protection | {n} | {n} | {n} | {%} |
+| E2E flows | {n} | {n} | {n} | {%} |
+| Data-flow propagation | {n} | {n} | {n} | {%} |
+| **Overall** | {n} | {n} | {n} | **{%}** |
+
+## Recommendations
+
+{Prioritized list of actions to fix integration issues}
+
+1. **[CRITICAL]** {Most important fix}
+2. **[CRITICAL]** {Second most important}
+3. **[WARNING]** {Important but not blocking}
+4. ...
+```

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

@@ -0,0 +1,111 @@
+<!-- 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 In Scope item must trace to a REQ-ID in REQUIREMENTS.md. -->
+
+### In Scope (v1)
+
+- {Feature area}: {brief description}
+
+### 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 |
+|----------|-----------|------------|
+| {decision} | {rationale} | {user/claude} |
+
+## 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`
+
+## 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 In Scope item maps to at least one REQ-ID in REQUIREMENTS.md
+- [ ] Every Out of Scope item has a rationale
+- [ ] Success criteria are observable and testable
+- [ ] Key Decisions table has at least one entry
+- [ ] Constraints section is populated (even if "none identified")
+{{#brownfield}}
+- [ ] Validated Requirements cite evidence from existing code
+- [ ] Existing Architecture references codebase scan files
+{{/brownfield}}

package/plugins/codex-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)