fix: close requirements verification loop and enforce MUST language

Tighten all requirements references to use MUST/REQUIRED/CRITICAL language
instead of passive suggestions. Close the verification loop by extracting
phase requirement IDs from ROADMAP and passing them through the full chain:
researcher receives IDs → planner writes to PLAN frontmatter → executor
copies to SUMMARY → verifier cross-references against REQUIREMENTS.md with
orphan detection.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Lex Christopherson
2026-02-16 13:03:14 -06:00
parent cbf809417a
commit 9ef582ef23
9 changed files with 58 additions and 16 deletions

View File

@@ -308,6 +308,7 @@ Verified patterns from official sources:
## Step 1: Receive Scope and Load Context
Orchestrator provides: phase number/name, description/goal, requirements, constraints, output path.
- Phase requirement IDs (e.g., AUTH-01, AUTH-02) — the specific requirements this phase MUST address
Load phase context using init command:
```bash
@@ -377,6 +378,20 @@ For each domain: Context7 first → Official docs → WebSearch → Cross-verify
</user_constraints>
```
**If phase requirement IDs were provided**, MUST include a `<phase_requirements>` section:
```markdown
<phase_requirements>
## Phase Requirements
| ID | Description | Research Support |
|----|-------------|-----------------|
| {REQ-ID} | {from REQUIREMENTS.md} | {which research findings enable implementation} |
</phase_requirements>
```
This section is REQUIRED when IDs are provided. The planner uses it to map requirements to plans.
Write to: `$PHASE_DIR/$PADDED_PHASE-RESEARCH.md`
⚠️ `commit_docs` controls git only, NOT file writing. Always write first.

View File

@@ -73,6 +73,8 @@ Same methodology (goal-backward), different timing, different subject matter.
4. For each requirement, find covering task(s) in the plan that claims it
5. Flag requirements with no coverage or missing from all plans' `requirements` fields
**FAIL the verification** if any requirement ID from the roadmap is absent from all plans' `requirements` fields. This is a blocking issue, not a warning.
**Red flags:**
- Requirement has zero tasks addressing it
- Multiple requirements share one vague task ("implement auth" for login, logout, session)

View File

@@ -345,7 +345,7 @@ wave: N # Execution wave (1, 2, 3...)
depends_on: [] # Plan IDs this plan requires
files_modified: [] # Files this plan touches
autonomous: true # false if plan has checkpoints
requirements: [] # Requirement IDs this plan addresses (from ROADMAP)
requirements: [] # REQUIRED — Requirement IDs from ROADMAP this plan addresses. MUST NOT be empty.
user_setup: [] # Human-required setup (omit if empty)
must_haves:
@@ -411,7 +411,7 @@ After completion, create `.planning/phases/XX-name/{phase}-{plan}-SUMMARY.md`
| `depends_on` | Yes | Plan IDs this plan requires |
| `files_modified` | Yes | Files this plan touches |
| `autonomous` | Yes | `true` if no checkpoints |
| `requirements` | Yes | Requirement IDs this plan addresses (from ROADMAP) |
| `requirements` | Yes | **MUST** list requirement IDs from ROADMAP. Every roadmap requirement ID MUST appear in at least one plan. |
| `user_setup` | No | Human-required setup items |
| `must_haves` | Yes | Goal-backward verification criteria |
@@ -453,7 +453,7 @@ Only include what Claude literally cannot do.
## The Process
**Step 0: Extract Requirement IDs**
Read ROADMAP.md `**Requirements:**` line for this phase. Strip brackets if present (e.g., `[AUTH-01, AUTH-02]` → `AUTH-01, AUTH-02`). Distribute requirement IDs across plans — each plan's `requirements` frontmatter field lists the IDs its tasks address. Every requirement ID must appear in at least one plan.
Read ROADMAP.md `**Requirements:**` line for this phase. Strip brackets if present (e.g., `[AUTH-01, AUTH-02]` → `AUTH-01, AUTH-02`). Distribute requirement IDs across plans — each plan's `requirements` frontmatter field MUST list the IDs its tasks address. **CRITICAL:** Every requirement ID MUST appear in at least one plan. Plans with an empty `requirements` field are invalid.
**Step 1: State the Goal**
Take phase goal from ROADMAP.md. Must be outcome-shaped, not task-shaped.

View File

@@ -233,17 +233,31 @@ Status: WIRED (state displayed) | NOT_WIRED (state exists, not rendered)
## Step 6: Check Requirements Coverage
If REQUIREMENTS.md has requirements mapped to this phase:
**6a. Extract requirement IDs from PLAN frontmatter:**
```bash
grep -A5 "^requirements:" "$PHASE_DIR"/*-PLAN.md 2>/dev/null
```
Collect ALL requirement IDs declared across plans for this phase.
**6b. Cross-reference against REQUIREMENTS.md:**
For each requirement ID from plans:
1. Find its full description in REQUIREMENTS.md (`**REQ-ID**: description`)
2. Map to supporting truths/artifacts verified in Steps 3-5
3. Determine status:
- ✓ SATISFIED: Implementation evidence found that fulfills the requirement
- ✗ BLOCKED: No evidence or contradicting evidence
- ? NEEDS HUMAN: Can't verify programmatically (UI behavior, UX quality)
**6c. Check for orphaned requirements:**
```bash
grep -E "Phase $PHASE_NUM" .planning/REQUIREMENTS.md 2>/dev/null
```
For each requirement: parse description → identify supporting truths/artifacts → determine status.
- ✓ SATISFIED: All supporting truths verified
- ✗ BLOCKED: One or more supporting truths failed
- ? NEEDS HUMAN: Can't verify programmatically
If REQUIREMENTS.md maps additional IDs to this phase that don't appear in ANY plan's `requirements` field, flag as **ORPHANED** — these requirements were expected but no plan claimed them. ORPHANED requirements MUST appear in the verification report.
## Step 7: Scan for Anti-Patterns
@@ -396,8 +410,8 @@ human_verification: # Only if status: human_needed
### Requirements Coverage
| Requirement | Status | Blocking Issue |
| ----------- | ------ | -------------- |
| Requirement | Source Plan | Description | Status | Evidence |
| ----------- | ---------- | ----------- | ------ | -------- |
### Anti-Patterns Found