docs(#2126): correct malformed_roadmap prior-behavior note (re-review)

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>
This commit is contained in:
Tom Boucher
2026-07-10 01:07:00 -04:00
parent b85996e95e
commit a22602e276
2 changed files with 9 additions and 9 deletions

View File

@@ -2,4 +2,4 @@
type: Fixed
pr: 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 query against a checklist-only roadmap now reports the same `malformed_roadmap` diagnostic a bare query always did, instead of a silent empty result. (#2114)
**`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)