a22602e276
Re-review found the test comment + changeset prose inaccurately claimed a bare
query "always" surfaced malformed_roadmap. Empirically, on origin/next a
project-code-prefixed checklist entry was a silent {found:false} for BOTH query
forms — the prefixed pass discarded its malformed candidate and the bare regex
could not match the PROJ- prefix at all. The unified 3-source lookup newly grants
the diagnostic to both forms; correct the prose to say so. No logic change.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
579 B
579 B
type, pr
| type | pr |
|---|---|
| Fixed | 0 |
roadmap get-phase resolves project-code-prefixed headings by bare number — a bare-number query (e.g. 29) now resolves a drifted ### Phase AB-29: heading, matching the internal resolver used by init.phase-op; previously the CLI returned empty. A bare sibling (### Phase 29:) still takes precedence. A project-code-prefixed heading present only as a summary/checklist line (no matching detail section) now reports a malformed_roadmap diagnostic — for both prefixed and bare-number queries — instead of a silent empty result. (#2114)