* feat(#2833): parseStateMd reads phase-lifecycle frontmatter fields
Extend parseStateMd() to parse 4 new STATE.md frontmatter fields that drive
the phase-lifecycle status-line proposed in #2833:
- active_phase : phase number when orchestrator is in-flight, null when idle
- next_action : recommended next command when idle
- next_phases : YAML flow array of phase numbers for next_action
- progress : nested block with completed_phases / total_phases / percent
All fields default to undefined when absent — formatGsdState() (next commit)
degrades gracefully so existing STATE.md files keep rendering as before.
YAML scope intentionally narrow:
- Only top-level scalar keys (status, milestone, active_phase, next_action)
- Only single-line flow array for next_phases ([...])
- progress block requires 2-space indent for nested keys
Block sequences (- item over multiple lines) and inline comments inside
nested blocks are NOT parsed — keeping the regex-based parser predictable.
Comments outside frontmatter or after the closing --- still work.
Tests: all 27 existing tests still pass (no behavior change for STATE.md
files that don't carry the new fields).
Refs #2833
* feat(#2833): formatGsdState renders phase-lifecycle scenes + opt-in progress bar
Extend formatGsdState() with three lifecycle scenes that activate when the
new STATE.md frontmatter fields (added in the previous commit) are present.
Also append an opt-in progress bar to the milestone segment when
progress.percent is available.
Scenes (first match wins; falls through to the existing path otherwise):
1. active_phase set → 'v2.0 [██░] X% · Phase 4.5 executing'
(status field carries the lifecycle stage:
discussing / planning / executing / verifying)
2. active_phase null + → 'v2.0 [██░] X% · next execute-phase 4.5'
next_action set (idle state — surfaces what the user should
run next without opening STATE.md)
3. percent=100 (or → 'v2.0 [██████████] 100% · milestone complete'
completed=total)
4. (default fallback) → 'v1.9 Code Quality · executing · ph (1/5)'
(existing rendering, byte-for-byte preserved
when none of the new fields are populated)
Backward compat is the design priority:
- STATE.md files without the new fields render identically to v1.38.x
- progress bar is opt-in (empty string when percent absent)
- Each new scene only activates when its specific fields are populated
A new helper renderProgressBar() generates the 10-segment bar that matches
the existing context meter style (so the two bars on the status-line are
visually consistent).
Tests: 27/27 existing tests still pass.
Refs #2833
* test(#2833): cover parseStateMd lifecycle fields + formatGsdState scenes
26 new tests organized in 5 describe blocks, modeled after the existing
enh-2538-statusline-last-command.test.cjs convention:
parseStateMd #2833 lifecycle fields (7 tests)
- reads active_phase / next_action / next_phases / progress.percent
- 'null' literal handled correctly
- YAML flow array parsing (1 item, multiple items)
- progress nested block (3 fields)
- absent fields return undefined
formatGsdState #2833 lifecycle scenes (6 tests)
- Scene 1: active_phase set → 'Phase X.Y <stage>'
- Scene 2: idle + next_action → 'next <action> <phases>' (1+ phases)
- Scene 3: percent=100 OR completed=total → 'milestone complete'
formatGsdState #2833 backward compatibility (4 tests) — CRITICAL
- Legacy STATE.md (no new fields) renders byte-for-byte unchanged
- Empty state, partial state, progress-bar-opt-in all preserved
progress bar rendering (6 tests)
- 0% / 50% / 100% / clamping / opt-in absence
formatGsdState #2833 scene priority (3 tests)
- active_phase wins over next_action when both populated
- next_action wins over fallback when active_phase null
- percent=100 wins over fallback even with phase set
Combined run: 53/53 tests pass (existing 27 + new 26).
Refs #2833
* docs(#2833): describe phase-lifecycle frontmatter fields and rendering scenes
Add docs/STATE-MD-LIFECYCLE.md as the canonical reference for the four new
STATE.md frontmatter fields and the four status-line rendering scenes
introduced by this proposal:
- Frontmatter field reference (active_phase / next_action / next_phases /
progress.percent) with type and population semantics
- Why progress.percent is intentionally the phase dimension and not the
plans dimension (plans dimension trends optimistic when future phases
are unplanned)
- The four rendering scenes including their priority order
- Stage-label convention for Scene 1 (discussing / planning / executing /
verifying matching the four phase orchestrators)
- Frontmatter parsing constraints — frontmatter must start at file head,
no comments inside nested blocks, next_phases is single-line flow only
- Backward-compatibility guarantee (locked in by the test suite)
- Cross-links to the foundation issue #1989 and the read-side issues
this proposal helps close
The document deliberately scopes itself to the read-side (what the hook
parses, what it renders). Write-side SDK and workflow changes that
auto-maintain the fields are out of scope for this PR so each piece can
be reviewed independently — see the issue thread for the full proposal.
Refs #2833
* test(#2833): simplify '0% renders 10 empty segments' assertion
Address CodeRabbit nitpick — drop the convoluted assert.equal that built
the expected value via .replace() and rely on the existing assert.ok
includes-check. The behavior under test is unchanged; the assertion is
just easier to read.
Refs #2884 review comment
8fc1fa263c