golem15/msd-core
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(sdk): derive completed_phases from ROADMAP and refresh all STATE.md fields after phase.complete

Browse Source 
Fixes two root causes behind bug #3517:

1. Idempotency: completed_phases was blindly incremented (parseInt + 1),
   causing phase.complete N run twice to double-count (4 → 5 → 6).
   Now derives from ROADMAP progress table Complete-row count, making
   the operation idempotent.

2. Field coverage: eight STATE.md fields were left stale after phase
   completion. Now updates in the same atomic lock section:
   - frontmatter: stopped_at, last_updated, total_plans, completed_plans
   - body: Current focus, Status line, By Phase table row

   completed_plans = count of *-SUMMARY.md files across all phase dirs
   total_plans = sum of M/N plan counts from ROADMAP progress table
   percent = recomputed from fresh derived counts

Closes #3517

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Tom Boucher
2026-05-14 16:56:10 -04:00
parent f45f2ec746
commit 200c012f84
3 changed files with 533 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
.changeset/3517-phase-complete-state-staleness.md Normal file
View File

@@ -0,0 +1,5 @@
---
type: Fixed
pr: 0
---
**`phase.complete` STATE.md staleness and idempotency fixed** — Two root causes corrected atomically: (1) `completed_phases` was blindly incremented (`+1`), making `phase.complete N` non-idempotent — running it twice on the same phase double-counted (4→5→6). It now derives the count from the ROADMAP progress table's `Complete` rows, so repeated calls produce the same result. (2) Eight STATE.md fields were left stale after phase completion: `stopped_at`, `last_updated`, `total_plans`, `completed_plans` (frontmatter) and `Current focus:`, `Status:`, `Progress:` bar, `By Phase` table row (body). All fields are now updated in the same atomic write guarded by the existing `acquireStateLock`/`releaseStateLock` pair. `completed_plans` is derived from on-disk `*-SUMMARY.md` file counts; `total_plans` from ROADMAP M/N plan column sums; `percent` from the freshly-derived phase counts. (#3517)