---
type: Fixed
pr: 3791
---
**`state.advance-plan` now reads a plan position written as `Current Plan: N of M`, and advances every site that carries one instead of leaving the document disagreeing with itself.** The legacy field name carrying a compound value was accepted by neither parse branch, so the command reported a parse failure against a STATE.md whose plan numbers were plainly readable.

The total is no longer read out of prose. Both accepted shapes are matched by a grammar anchored at the start of the value, and every number comes from a capture group. Previously an unanchored search for `of <digits>` anywhere in the value made `Current Plan: 4 — blocked on review of 2 PRs` parse as "4 of 2", conclude the phase was over, and write `Status: Phase complete — ready for verification` into the file. A trailing annotation is still accepted on both shapes (`Plan: 2 of 5 in current phase`, `Total Plans in Phase: 5 phases`), and survives the write.

Advancing rewrites only the leading digits, so the zero-padding width and everything after it survive: `04 of 06` advances to `05 of 06`, widening to `10 of 12` rather than truncating, and the legacy pair no longer collapses `2 of 99` into a bare `3` or `04` into `5`. That holds for **each** spelling independently — a `Plan: 2 of 9` line beside a `Total Plans in Phase: 5` advances to `3 of 9`, keeping its own total, because every field is advanced from its own text rather than re-stamped with the numbers some other field supplied. The `## Current Position` section advances alongside the header for every spelling — plain, bold and pipe-table — so the two can no longer report different plans.

A document whose two plan positions carry **different numbers** — say `Current Plan: 7` beside `Plan: 2 of 5` — is now refused with `reason: "ambiguous_plan_position"` and both candidates named, rather than advancing one and silently stamping its number onto the other. A `Plan:` line that carries no readable number at all is left exactly as authored instead of being overwritten. When the position cannot be read at all, the error names the accepted shapes rather than asserting a cause it cannot know.

Two narrowings against the old `parseInt` behaviour, both deliberate. A trailing annotation must be separated from the number by whitespace: `Total Plans in Phase: 5 phases` parses, `5phases` no longer does — `parseInt` read that as `5`, which is the half-parse this change exists to remove. And `Plan: N` paired with a `Total Plans in Phase: M` sibling and no `Current Plan` field is not an accepted shape; it was not accepted before this change either.