* fix(#1591): phase.complete recognizes checkbox-list phases in the isLastPhase fallback When the active milestone's phase checklist is written as `- [ ] Phase N:` checkbox items inside a <details> block (the @Azd325 structure) and the next phase has no directory yet, the disk-based next-phase resolver finds nothing and phase.complete falls back to the roadmap-enumeration guard at the isLastPhase site. That guard's phasePattern was heading-only (/#{2,4}\s*Phase…/), so it never matched checklist items → is_last_phase=true and next_phase=null on a mid-milestone phase, and STATE.md was wrongly marked 'Milestone complete' with total_phases decremented. Broaden the marker alternation to match BOTH heading-style (### Phase N:) and checkbox-list items (- [ ] Phase N: / - [x] Phase N:); the number/name captures are unchanged. extractCurrentMilestone already surfaces the <details>-wrapped checklist correctly, so no parser change is needed. The heading-only sibling patterns elsewhere in phase.cts are left untouched (scope discipline — only the reproduced isLastPhase fallback is changed). Regression: a phase complete 36 on a <details>-wrapped v2.0 checklist (Phases 36-38, only 36 has a dir) returns is_last_phase=false, next_phase=37, and does NOT flip STATE.md to 'Milestone complete'. * docs(#1591): add changeset fragment for phase.complete checkbox-list fix * test(#1752): add total_phases-preservation regression for the #1591 follow-up #1752 is the scoped follow-up to #1591 — same <details>-wrapped-checkbox defect, with the additional emphasis on the total_phases decrement cascade. The #1591 fix (is_last_phase=false) already resolves it: with all 8 phase dirs on disk, phase.complete 36 on a v2.0 <details> checklist leaves total_phases at 8 (not decremented to 7) and does not flip STATE.md to 'Milestone complete'. Verified manually before adding the test. Add the #1752 regression case (8 phase dirs, curated total_phases: 8) to the phase complete command block in tests/phase.test.cjs, and update the changeset to reference both issues (#1591, #1752) since this is one user-facing change resolving both.
This commit is contained in:
@@ -1648,7 +1648,16 @@ function cmdPhaseComplete(cwd: string, phaseNum: string, raw: boolean): void {
|
||||
if (isLastPhase && roadmapContent !== null) {
|
||||
try {
|
||||
const roadmapForPhases = extractCurrentMilestone(roadmapContent, cwd);
|
||||
const phasePattern = /#{2,4}\s*Phase\s+(\d+[A-Z]?(?:\.\d+)*)\s*:\s*([^\n]+)/gi;
|
||||
// #1591: match BOTH heading-style phases (`### Phase N:`) AND
|
||||
// checkbox-list items (`- [ ] Phase N:` / `- [x] Phase N:`). When
|
||||
// the active milestone's checklist is `- [ ]` items inside a
|
||||
// <details> block (and the next phase has no directory yet, so the
|
||||
// disk-based resolver finds nothing), this roadmap-enumeration
|
||||
// fallback is the only path that can find the next phase. The prior
|
||||
// heading-only pattern missed checkbox items → is_last_phase=true on
|
||||
// a mid-milestone phase. The marker alternation is the only change;
|
||||
// the number/name captures are unchanged.
|
||||
const phasePattern = /(?:#{2,4}|-\s*\[[ xX]\])\s*Phase\s+(\d+[A-Z]?(?:\.\d+)*)\s*:\s*([^\n]+)/gi;
|
||||
let pm: RegExpExecArray | null;
|
||||
while ((pm = phasePattern.exec(roadmapForPhases)) !== null) {
|
||||
if (comparePhaseNum(pm[1], phaseNum) > 0) {
|
||||
|
||||
Reference in New Issue
Block a user