gsd-tools: requirements mark-complete reports not_found for IDs that ARE registered in REQUIREMENTS.md

Summary

gsd-tools.cjs requirements mark-complete <ID> reports not_found for requirement IDs that are definitely present in .planning/REQUIREMENTS.md, causing silent requirements-traceability drift across phases.

Repro

On our project (custom-content-portal, v1.2.2 milestone), multiple phases in the same run hit this:

• Phase 21: UNBREAK-05, UNBREAK-06, VERIFY-01, PROCESS-01 all reported not_found during execute-phase
• Phase 22: DEPLOY-01 reported not_found during execute-phase

But a direct grep of REQUIREMENTS.md shows they ARE registered:

.planning/REQUIREMENTS.md:60  ### DEPLOY-01 — Migrations apply automatically on deploy
.planning/REQUIREMENTS.md:102 | DEPLOY-01 | #51 | 22 |

And the matching ROADMAP entry:

.planning/ROADMAP.md:103 **Requirements**: DEPLOY-01

The verifier agent (gsd-verifier) caught the false negative by re-grepping the file directly and flagged it in VERIFICATION.md.

Impact

Silent requirements drift. requirements mark-complete is supposed to update REQUIREMENTS.md so the traceability table stays in sync with phase completion state. When it silently fails with not_found, the ID never gets marked complete, and audits later see it as unfulfilled — leading to false "gap" reports during milestone audits and audit-uat runs.

Worse: the error is non-fatal, so executors just log it and continue. Unless a human reads the execute output carefully, the drift goes undetected until much later.

Hypothesized root cause

The parser probably expects requirements in a specific heading format (e.g. ## Requirement: ID or a table row with a particular column layout) and fails to match the actual format in use. Our REQUIREMENTS.md uses both ### ID — description heading form and a traceability table — possibly only one of those is recognized.

Suggested fix

1. Make requirements mark-complete accept the common REQUIREMENTS.md formats gsd-planner produces: ### ID — description, ## ID: description, and traceability table rows.
2. When a mark-complete fails with not_found, grep REQUIREMENTS.md for the exact ID as a fallback check and either (a) mark it via fallback path or (b) return a clearer error that distinguishes "truly missing" from "parse mismatch".
3. Add an integration test that loads the gsd-planner-emitted REQUIREMENTS.md template and round-trips a mark-complete call.

Workaround

For now, run grep -n "ID " .planning/REQUIREMENTS.md after each phase to confirm the mark landed. The gsd-verifier agent already does this as a sanity check, so milestone-level auditing catches it — but per-phase drift still happens.

Context

Encountered during autonomous execution of milestone v1.2.2 (Data Query Stability) on a custom-content-portal project. Both affected phases still passed overall because the verifier cross-checks, but the warning noise and risk of silent drift warrants a fix.