Files
msd-core/tests
Tom Boucher 0ebc3cf279 fix(#4455): PROJECT.md is shared across workstreams, not workstream-scoped (#4543)
* fix: PROJECT.md is shared across workstreams, not workstream-scoped (#4455 follow-up)

Self-discovered regression, found while diagnosing #4456: #4455 (PR #4542,
merged as c6df4e1e46) resolved `project_path` in cmdInitCompleteMilestone
via the workstream-scoped planningDir(cwd), reasoning by analogy from
MILESTONES.md (which cmdMilestoneComplete genuinely does write
workstream-scoped, per an explicit #1911 comment) without checking an
actual PROJECT.md write call site.

PROJECT.md is documented as SHARED across workstreams, not cloned per
workstream:
- gsd-core/references/workstream-flag.md's directory diagram marks it
  `# Shared`.
- new-milestone.md states it outright: "PROJECT.md is shared across
  workstreams" — and explicitly SKIPS writing its `## Current Milestone`
  heading under an active workstream specifically to avoid clobbering the
  one shared file (#2308): "whichever workstream runs new-milestone last
  would silently win the shared heading."
- cmdWorkstreamCreate (src/workstream.cts) never creates a PROJECT.md
  under a new workstream directory — only STATE.md and phases/.

Under an active workstream, complete-milestone.md's safety commit was
therefore silently missing the real PROJECT.md from its --files list
(staging a path that never exists instead).

Also fixed, in the same change: withProjectRoot (src/init.cts) — a
helper every cmdInit* function calls to enrich its JSON output — read
PROJECT.md via the workstream-aware planningDir(cwd) to extract
project_title. This predates #4455 entirely (unrelated diff, no prior
test either direction) but is the identical defect class, one line,
directly adjacent to what this fix already touches: under an active
workstream, every init.* command's project_title field silently
vanished, since no PROJECT.md ever exists at the workstream path.

Deliberately NOT fixed here: cmdInitNewMilestone (src/init.cts, the
function backing new-milestone.md's own init.new-milestone call) has
the identical bug for project_path/project_exists/config_path
(config.json is ALSO marked `# Shared` in the same diagram). That
function is exactly what #4456 (new-milestone.md's own missing --ws
forwarding) already needs to modify — its field-by-field scoping
belongs in that follow-up, not here.

Also deliberately NOT touched: getLatestCompletedMilestone reads
MILESTONES.md via the ROOT-ONLY planningRoot(cwd), contradicting
cmdMilestoneComplete's workstream-scoped WRITE. Resolving that
disagreement requires a genuine product-intent call (is "latest
completed milestone" scoped to the current workstream or pooled
project-wide?) that isn't derivable from the code alone — left alone
rather than guessed.

Verified: direct CLI invocation confirms project_path/project_title
now resolve to the root PROJECT.md under GSD_WORKSTREAM=alpha instead
of a workstream-scoped path that no writer ever populates. New
regression tests cover both the real cmdInitCompleteMilestone function
(tests/init-manager.test.cjs) and withProjectRoot's project_title
(same file); the existing fence-level test in
tests/workstream-scoped-paths.test.cjs (which enshrined the wrong
behavior) is corrected to reflect reality.

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

* fix: extend PROJECT.md root-scoping to 6 more cmdInit* functions found via grep

A code-review pass on this fix's first draft (which only touched
cmdInitCompleteMilestone and withProjectRoot) flagged that cmdInitNewProject
had the identical bug and asked whether other call sites were missed.
Grepping the exact literal patterns found SEVEN total occurrences across
cmdInitNewProject, cmdInitNewMilestone, cmdInitIngestDocs, cmdInitResume,
cmdInitMilestoneOp, cmdInitManager, and cmdInitProgress — not just the one
the review happened to spot.

All seven are the exact same defect with the exact same one-line fix
(resolve via planningRoot(cwd) instead of the workstream-scoped
planningDir(cwd)), so all seven are fixed here via a uniform find/replace,
including cmdInitNewMilestone — an earlier plan was to leave that one for
#4456 (which already needs to touch that function to add missing --ws
forwarding), but leaving exactly one of seven identical, equally-evidenced
occurrences unfixed for no functional reason would have been an arbitrary
inconsistency, not a principled scope boundary. #4456 still needs to add
the actual --ws parameter threading to cmdInitNewMilestone and separately
fix its also-wrong config_path field (config.json is marked `# Shared` in
workstream-flag.md's diagram too — a different field, needing its own
verification, not swept up in this mechanical grep-and-replace).

Also fixed: buildInitCompletenessFields (used by cmdInitNewProject and
cmdInitResume for the `init_incomplete` partial-bootstrap discriminator)
had the same bug in a differently-shaped literal (bare
fs.existsSync(path.join(dir, 'PROJECT.md')), not the pathExistsInternal/
toPosixPath wrapper the grep matched) — only its PROJECT.md check moves to
planningRoot(cwd); the REQUIREMENTS.md/MILESTONES.md/ROADMAP.md/STATE.md
checks in the same function correctly stay workstream-scoped.

Verified: direct CLI invocation of `init ingest-docs`, `init resume`,
`init progress`, `init new-project`, and `init milestone-op` under
GSD_WORKSTREAM=alpha all now report the root PROJECT.md correctly. New
parametrized regression test in tests/init-manager.test.cjs exercises all
five through the real CLI router (catching a router-wiring regression too,
not just a src/init.cts internals check).

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

* fix: PROJECT.md respects GSD_PROJECT namespacing, just not GSD_WORKSTREAM

gsd-test caught a real regression in this fix's own previous push:
resolving PROJECT.md via planningRoot(cwd) ignores BOTH GSD_PROJECT and
GSD_WORKSTREAM, but only the workstream dimension is actually meant to be
ignored for PROJECT.md. tests/init.test.cjs's pre-existing #3749 coverage
("init.new-project — GSD_PROJECT scoping") establishes that PROJECT.md
legitimately lives at `.planning/<project>/PROJECT.md` when GSD_PROJECT is
set — a genuine, tested, pre-existing multi-project namespace, distinct
from a single project's own workstreams (which DO share one PROJECT.md,
per the evidence in the prior two commits).

Corrected every PROJECT.md path resolution in this diff to
planningDir(cwd, null): `ws` explicitly nulled (so GSD_WORKSTREAM is never
consulted), `project` left as undefined so it still defaults from
GSD_PROJECT. This is the correct middle ground between the original bug
(fully workstream-scoped, #4455's mistake) and the previous commit's
overcorrection (fully root-only, breaking #3749).

Verified empirically, all three combinations: GSD_WORKSTREAM alone
resolves to root; GSD_PROJECT alone resolves to the namespaced path; both
set together resolves to the namespaced path (workstream ignored, matching
the resolution-priority contract in workstream-flag.md — project owns a
distinct planning tree, workstreams exist inside ONE project's tree). New
regression tests cover both the GSD_PROJECT-alone and
GSD_PROJECT+GSD_WORKSTREAM-together cases.

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

* docs: backfill changeset PR number

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

---------

Co-authored-by: sim <sim@local>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-08 06:26:54 -04:00
..