fix(#4906): migrate the ROADMAP.md Plans: line onto the PlanningDoc seam — Phase 2 (#4933)

* feat(#4906): migrate the ROADMAP.md **Plans:** line onto the PlanningDoc seam

Phase 2 of epic #4906. Migrates the two writers of ROADMAP.md's Plans field onto
the seam ADR-4910 locks, and deletes both bespoke regexes per Decision 2 — a
correct copy of a rule the seam now owns is the same divergence risk as an
incorrect one.

src/phase.cts's mutateMilestonePhase carried planCountBodyPattern, one capture
group, replace-to-end-of-line: this is #4852, still live before this change.
src/roadmap.cts's cmdRoadmapUpdatePlanProgress carried the correct three-arm
sibling (the #2853/#3584 correction) that phase.cts never adopted. Both now call
findField/setFieldValue/serialize against a PlanningDoc parsed from the same
milestone/phase-confined substring their existing withPhaseSection /
replaceInCurrentMilestone wrappers already compute — those confinement
wrappers are unchanged, only the field-write mechanism inside them moved.

Verified end-to-end through the real commands against real fixtures, not
against an isolated reimplementation of the classification logic:
cmdRoadmapUpdatePlanProgress and cmdPhaseComplete both preserve a trailing
human annotation across a real count rewrite, and both leave a bracketed
human annotation (the #3584 Finding A discriminator) untouched.

Found and fixed inline, in the already-merged src/planning-document.cts,
rather than deferred: BOLD_FIELD_RE recognized only **Label:** (colon inside
the closing bold). gsd-core/templates/roadmap.md ships every field, Plans
included, as **Label**: (colon outside) -- migrating roadmap.cts onto the
seam as it stood would have silently regressed real generated ROADMAP.md
files back to the bug this migration exists to remove. Widened to recognize
both spellings; deliberately NOT widened to a bare unbolded Label: form,
which would register ordinary prose as a spurious field.

roadmap.cts's writer also recognizes a bare singular/plural count (1 plan /
3 plans, no fraction) as an existing count token to overwrite, not template-
placeholder or freeform prose -- the template's own single-plan-phase shape
and #3584 Finding B's fix. Preserved exactly; this shape is easy to drop by
only porting the more common fraction form.

Two of Phase 2's three originally-cited defects turned out to be already
fixed on next, independent of this epic, and are struck via a dated ADR
amendment rather than silently narrowed: #4862 (stateReplaceField's own
anchoring hardening already preserves sibling fields) and #4499
(spliceFrontmatter's per-key preservation already keeps block sequences
byte-identical). Both reproduced against the built module before being
struck, not assumed. STATE.md's field-write engine is re-scoped out of this
phase entirely -- not because of its get_impact rating alone (measured the
same way, the two sites THIS phase keeps are also CRITICAL, and an earlier
draft of the amendment claimed otherwise without checking; corrected) but
because updateCore is a multi-field transaction with frontmatter sync and
preservation reconciliation that does not map onto PlanningDoc's node model,
where migrating it would mean designing that model, not calling an existing
seam function.

Refs #4852
Refs #4906

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(#4906): preserve a trailing annotation with no em-dash separator

Test authoring surfaced a real regression against an existing #3584 fixture:
`**Plans**: 0/1 plans executed (11-16 are gap closure from VERIFICATION)` -- a
parenthetical annotation glued on with a bare space, no em-dash -- was left
completely untouched by the migrated code instead of being rewritten with the
count updated and the parenthetical preserved.

Root cause: planning-document.cts's parseBoldFieldLine splits a field's value
from its trailing annotation only on the literal " -- " separator. An
em-dash-separated annotation already lives outside `value` in `trailingSpan`,
untouched by setFieldValue regardless -- that path was never broken. A
parenthetical with no em-dash has nowhere to go but inside `value`, and the
migrated classification required the WHOLE value to match a count-token shape
exactly, so this case fell into "leave untouched."

Fixed in the migrated call sites, not in the seam: prefix-match the count
token against the field's current value, then re-glue whatever textual suffix
follows WITHIN that value onto the new count text before writing. Correct for
both shapes with no special-casing -- the em-dash case's suffix-within-value
is empty by construction (the annotation already lives outside value), the
parenthetical case's suffix is exactly the glued content, preserved verbatim.

Deliberately not fixed by widening planning-document.cts's separator grammar
to also recognize a bare-space-then-parenthesis: that seam is already-merged
and already-tested, and guessing at an open-ended set of annotation shapes at
the seam level is exactly what isTemplatePlaceholder already avoids by
staying caller-side. "What counts as a Plans-field count token" is domain
knowledge about this one field.

phase.cts's writePlansField had no arm-2/arm-3 classification before this
migration -- its original regex unconditionally overwrote whatever value was
present. That unconditional-overwrite behavior is preserved exactly for
values with no recognizable count-token prefix; only the recognized-count
case gained suffix preservation, matching what phase.cts actually did before.

Verified end-to-end via the real cmdRoadmapUpdatePlanProgress and
cmdPhaseComplete commands against real fixtures for both the parenthetical
and em-dash shapes at both sites.

Refs #4906

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* test(#4906): cover the migrated Plans-line writers at both sites

15 cases across tests/phase.test.cjs and tests/roadmap.test.cjs, one per row
of the phase test matrix, extending the existing describe blocks and helper
functions those files already use for these two commands rather than
building parallel fixtures.

Covers: trailing-prose preservation on a real count rewrite at both sites
(the #4852 regression, and the #2853/#3584 non-regression); zero-trailing-
content boundary; the bracketed-template-placeholder vs bracketed-human-
annotation discriminator (#3584 Finding A); a missing Plans field not
crashing either command; an unrelated unreadable sibling node in the same
confined section surfacing rather than corrupting the field; confinement
holding across sibling phases and milestones; a round trip through the
command's own read path; CRLF safety; and a parity assertion that both sites
now produce identical Plans-line text for identical inputs, proving one
shared mechanism rather than source-grepping for the deleted regex literals.

Authoring caught a real regression before it could land silently: an
existing #3584 fixture using a parenthetical annotation with no em-dash
separator failed against the first version of the migration. Reported rather
than edited to match the broken behavior -- see the paired fix commit. That
existing test needed no changes once the fix landed; its assertion was
verified independently against the real CLI before this commit.

Refs #4906

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(#4906): give phase.cts's Plans writer the same arm-2/arm-3 classification as roadmap.cts

Isolated adversarial review (mandatory orthogonal review pass) executed
writePlansField against `[Deferred pending re-scope]` and the fresh-template
placeholder wording and found the first version of this migration kept
phase.cts's OLD unconditional-overwrite behavior for the no-count-prefix
case instead of adopting the same isTemplatePlaceholder / arm-3-untouched
classification roadmap.cts's sibling site already uses. A bracketed human
annotation was being silently rewritten to a new count -- a real
content-destroying regression against this phase's own design-doc behavior
table, not an accepted trade-off, and exactly the kind of divergence between
the two sites Decision 2's parity requirement exists to eliminate.

writePlansField now runs the same template-placeholder check and "no count
prefix and not a placeholder => leave untouched" branch before ever calling
setFieldValue. Added two site-1 tests (rows 4 and 6 of the phase test
matrix) mirroring the existing site-2 coverage for this exact discriminator.

Refs #4906

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(#4906): restore plain (non-bold) Plans: line support and fix a test helper mismatch

gsd-test (mandatory verification, run before every push) surfaced two real
defects the migration's manual CLI checks had not caught:

1. #1163 regression: a hand-edited/pre-template ROADMAP.md can carry a PLAIN
   (non-bold) `Plans:` line rather than the canonical `**Plans**:`/
   `**Plans:**` bold field. The old deleted regexes tolerated this shape;
   the seam's BOLD_FIELD_RE is deliberately bold-only (widening it would
   register ordinary prose like "Note: see below" as a spurious field
   seam-wide), so the migrated writers silently no-op'd on it instead of
   updating the count -- a real, previously-tested behavior lost.

   Fixed with a caller-side fallback in both src/roadmap.cts (where the
   failing #1163 test lives) and src/phase.cts (added for parity, per
   Decision 2 -- the two sites should not diverge on which legacy shapes
   they tolerate): when findField finds no boldField Plans node, look for a
   plain `Plans:` line directly and apply the same arm-1/2/3 classification
   against it. This is domain knowledge about one field's legacy tolerated
   shape, the same class of thing isTemplatePlaceholder already keeps
   caller-side rather than seam grammar.

2. tests/roadmap.test.cjs's new rows 4/5 (site 2) seeded the colon-outside
   spelling (`**Plans**: ...`) but their plansLineIn() helper only matched
   colon-inside (`**Plans:**`), so both assertions compared against
   `undefined` regardless of whether the write logic was correct -- a
   test-authoring bug, not a source defect. Fixed the helper to recognize
   both BOLD_FIELD_RE spellings, matching what the production code actually
   supports.

Verified via a real gsd-test run before this fix (outcome: failed, 5
failures, all in tests/roadmap.test.cjs) and will be re-verified via a real
gsd-test run on this commit before push, per this repo's non-rationalization
rule: a red gate is fixed, never explained away.

Refs #4906

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* chore(#4906): backfill the Phase 2 changeset fragment's PR number

pr:0 -> pr:4933, now that gh api POST /pulls has returned the real number.

Refs #4906

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

---------

Co-authored-by: sim <sim@local>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

docs/adr/4910-planning-document-seam.md

@@ -613,3 +613,83 @@ Raised by a maintainer ruling on 2026-09-21, after §5 shipped in
 recorded in that PR as an interpretation of #4906's *"an unparseable shape surfaces `could-not-parse`
 with the offending span"* — a sentence that carries no read-or-write qualifier — and the
 interpretation was made without examining the write side at all.
+
+## Amendment (2026-09-22): two of Phase 2's cited defects are already fixed, and STATE.md's field-write engine is re-scoped out
+
+Phase 2's evidence list read *#4852, #4862, #4499*. Two of those three are **already fixed on
+`next`, independently of this epic**, and the third — #4862 — exposed a subsystem whose blast radius
+disqualifies it from a mechanical migration. All three claims below were reproduced against the
+built module, not inferred from reading source.
+
+### #4499 is already fixed
+
+`src/frontmatter.cts`'s `spliceFrontmatter` already preserves untouched top-level keys verbatim,
+per-key, comparing structural equality before deciding whether to regenerate a key's raw text.
+Reproduced: a document with `must_haves` and `tags` block sequences, with only `wave` changed,
+round-trips those two keys **byte-identically**. This predates this epic — the mechanism (`#1572`
+in its own comments) already implements the identity-preservation rule Decision 3 asks for, for
+YAML frontmatter specifically.
+
+**Struck from Phase 2's evidence.** Frontmatter is a different grammar from the body-field grammar
+this seam models (`boldField` / `table` / `checklist`) — Decision 1 treats it as one opaque region,
+supplied by `frontmatter.cts` as a layer, not decomposed into writable nodes. `spliceFrontmatter`'s
+internal per-key YAML splicing is therefore not a "verb writes a field with its own regex" instance
+in the sense this phase targets, and it is not broken. No migration is owed here.
+
+### #4862 is already fixed at its own level, and its subsystem is re-scoped out
+
+`state-document.cts`'s `stateReplaceField` already anchors its bold-field pattern to line start with
+same-line-only leading whitespace (its own comments cite `#4243`). Reproduced: writing `Last
+Activity` leaves a sibling `**Last Activity Description:**` field and the `state_head` frontmatter
+key both intact. The exact symptom #4862 reported does not reproduce.
+
+**What #4862's site actually is, measured rather than assumed:** `stateReplaceField` /
+`stateReplaceFieldWithFallback` carries a **CRITICAL** `get_impact(direction=both)` rating — 190+
+affected symbols, truncated as a lower bound. So, measured the same way, do `phase.cts`'s
+`mutateMilestonePhase` (121) and `roadmap.cts`'s `cmdRoadmapUpdatePlanProgress` (200) — the two
+sites Phase 2 *does* keep. **The CRITICAL label does not distinguish these groups**, and an earlier
+draft of this amendment claimed it did without checking the second two; corrected here. All three
+symbols live in large, single-file modules (`phase.cts` at 4,800+ lines, `roadmap.cts` at 1,600+,
+`state-transition.cts` at 3,500+), and `direction: both` walks into every sibling function such a
+file touches — a known measurement artifact of bidirectional impact on a large shared module, not
+evidence specific to any one of these three symbols' actual behavior.
+
+**What genuinely distinguishes them is architectural, and this is the actual basis for the
+re-scoping:** `stateReplaceField` is one building block inside `updateCore`
+(`state-transition.cts`), which is a full read-modify-write transaction — session-vs-body field
+routing (`sessionLabelsForBodyField`), a three-condition frontmatter-fallback case (`#3699` case D),
+frontmatter reconstruction and re-sync, and post-write preservation reconciliation
+(`readModifyWriteStateMd`). Its own comments cite four prior hardening passes against exactly the
+corruption classes this epic worries about — `#3374`, `#3699`, `#4010`, `#4243` — predating #4906.
+`mutateMilestonePhase` and `cmdRoadmapUpdatePlanProgress`, by contrast, are each **one field, one
+grammar, a three-arm decision that collapses onto a single `setFieldValue` call plus a caller-side
+pre-check**, inside a confinement window another module already computes — a substitution of
+mechanism with the same inputs and outputs, not a design task.
+
+This is not "a verb brings its own regex to a field write." `updateCore` is a proven,
+actively-maintained transactional engine that already defends against silent corruption, and it
+does not map onto `PlanningDoc`'s current node model at all: there is no node concept for a
+multi-field transaction, a frontmatter-derived-from-body sync pass, or a session-scoped write with
+an archive-shadowing guard. Migrating it would mean designing that model, not calling an existing
+seam function.
+
+**The STATE.md field-write engine is re-scoped out of Phase 2** on that architectural basis. It is
+not defective, so there is no urgency, and its migration — if ever undertaken — needs its own design
+phase with its own node-model design, not a slot inside a phase whose other deliverable is a
+same-mechanism substitution in `phase.cts`/`roadmap.cts`.
+
+**Struck from Phase 2's evidence.**
+
+### What Phase 2 actually delivers
+
+With both struck, Phase 2's census is exactly the `**Plans:**` line: `src/phase.cts`'s
+`planCountBodyPattern` (still live — one capture group, confined by `withPhaseSection` but still a
+regex the seam should own) and `src/roadmap.cts`'s `planCountPattern` (the correct three-arm sibling,
+still a duplicate implementation under Decision 2's "two copies that agree today are the same
+defect" rule). Both write the same field on the same artifact and migrate together onto one seam
+call. `#4852` remains the phase's fail-first evidence; `Refs #4852`, since it is already closed
+`NOT_PLANNED`.
+
+No new phase number is opened for the STATE.md engine. If a future contributor wants to bring
+`STATE.md` under this seam, that is new work requiring its own issue, its own design, and its own
+`get_impact` accounting — not an unclaimed fragment of this phase.