Files
msd-core/tests
Behruz Nassre Esfahani e3acdd89cb fix(#1514): exclude retired/folded phases from progress.total_phases
A retired/folded phase (struck through in ROADMAP, marked [x], with a
directory but no completion artifact) was counted in the total_phases
denominator via max(phaseDirs.length, roadmapPhaseCount), yet could never
satisfy the numerator (no SUMMARY → never "completed"), freezing shipped
milestones below 100% (e.g. 5/6 = 83%).

Both STATE counting paths now read the current-milestone ROADMAP scope and
exclude retired phases from BOTH the disk phase-dir set and the heading
count, so a retired phase counts toward neither denominator nor numerator:
  - buildStateFrontmatter (`state json`)
  - cmdStateSync (`state sync --verify` / rebuild) — previously re-derived the
    inflated denominator and reported "no drift", per the issue.

Retired detection (extractRetiredPhaseNumbers) is scoped to the lines that
canonically mark a phase retired — a checklist entry (`- [x] …`) or a phase
heading — and within those, only a struck span whose SUBJECT is the phase
(`~~**Phase 04: Delta**~~`). So struck prose, a struck goal line, and the fold
target ("folded into Phase 05") are not misread as retired.

Phase matching uses the canonical phase-id helpers (normalizePhaseName +
extractPhaseToken), so numeric, decimal, and project-code IDs (PROJ-42) match
consistently across ROADMAP tokens and on-disk dir names.

Scope boundaries (separate, pre-existing concerns left unchanged):
  - `roadmap analyze` (src/roadmap.cts) intentionally trusts the [x] checkbox
    (incl. externally-completed phases) — a different reporting surface.
  - cmdStateSync does not apply the milestone phase-dir filter (so 999.x /
    other-milestone dirs can still affect its count); that is the #1445 /
    milestone-filter axis, independent of retired phases.

Same counting family as #549 / #500 / #1445.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-21 23:29:05 -07:00
..