ef823ca9d9
* test(#2830): add failing regression tests for halted-plan dependent blocking Add tests/fix-2830-halted-plan-dependents.test.cjs covering direct, transitive (2 and 3 hop), and diamond dependents of a halted plan across both independent "which plans are incomplete" readers (phase-plan-index's cmdPhasePlanIndex and findPhaseInternal/searchPhaseInDir), the negative case (an unrelated decoupled plan stays runnable), and a parity check that the two readers agree. Uses only modules that already exist at this commit (gsd-tools.cjs via subprocess, the pre-existing phase-locator.cjs) so the test file loads and runs cleanly on a fresh clone of this exact commit. These fail against current behavior: neither reader has any concept of a halted plan or a blocked_by/runnable view yet. * fix(#2830): a halted plan no longer leaves its dependents on the runnable work list A plan that reaches a designed stop still writes a SUMMARY, so both "which plans are incomplete" readers saw it as an ordinary completion and reported its dependents as ordinary runnable work — never checking whether an upstream plan had halted rather than finished. - New `status: halted` frontmatter value, documented in all four SUMMARY templates alongside the existing `status: complete`. - New shared src/plan-dependency-graph.cts: a single computeHaltPropagation pass that both phase.cts's cmdPhasePlanIndex (wave-grouping) and phase-locator.cts's searchPhaseInDir (the phase-location primitive, ~50 dependent symbols across 5 command routers) now call, so the two-implementation divergence that caused this bug cannot recur. It accepts an optional precomputedOrder so cmdPhasePlanIndex — which already runs Kahn's algorithm in computeDependencyLevels for wave assignment — passes that order straight through instead of a second traversal; searchPhaseInDir (no prior traversal) lets the module derive its own. The two small duplicated predicates each reader would otherwise carry (is this status "halted"?, which summary file matches which plan id?) are centralized in the same module as isHaltedStatus/buildSummaryFileIndex. - Additive fields only: `halted`/`blocked_by`/`runnable` on cmdPhasePlanIndex's plans[] and top level, `halted_plans`/`blocked_by`/ `runnable_plans` on searchPhaseInDir's result. The pre-existing `incomplete`/`incomplete_plans` fields are unchanged in meaning and membership. - execute-phase.md's discover_and_group_plans step now also skips any plan whose `blocked_by` is non-empty, reporting it by name with its blocking chain, in addition to (not instead of) the existing has_summary skip rule. Extends tests/fix-2830-halted-plan-dependents.test.cjs (introduced in the prior commit) with direct unit coverage of computeHaltPropagation (including the precomputedOrder call shape) and a fast-check property test — both only possible once this commit's new module exists. Closes #2830 * fix(#2830): surface the halt-aware view from init execute-phase The adopted work made phase-locator compute halted_plans / blocked_by / runnable_plans, but cmdInitExecutePhase builds its output by explicitly enumerating fields, so all three were computed and then silently dropped at the exact consumer the issue names as regressed. Forwards them additively -- incomplete_plans and incomplete_count keep their name, type and semantics byte-for-byte -- and adds the same three empty defaults to the roadmap-only fallback so the shape is consistent in both branches. Covered by a new test that drives the real CLI end to end rather than the locator function, since the locator already worked. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(#2830): fail closed on dependency cycles and stop the templates inviting the defect Three review findings, all fixed: - BLOCKER (isolated adversarial). Cycle participants never reach indegree 0 in the Kahn pass, so they were excluded from the topological order, never visited by the forward pass, and vanished from blocked_by entirely -- i.e. reported as runnable. The wave-grouping reader hard-fails on a cycle so it never hit this, but the phase-location reader does not, so init execute-phase offered a plan depending directly on a halted plan. Reproduced, then fixed in the shared engine so every consumer is safe regardless of pre-checks: a node absent from the order is now blocked with a deterministic, non-empty named cause. A plan silently missing from both blocked_by and runnable is the exact disappearance this issue exists to prevent. - MAJOR (isolated adversarial). All four summary templates showed the field as an inline comment on the value line. Frontmatter parsing does not strip trailing comments, so an executor copying the templates' own presentation wrote a halt that parsed as a non-halted string, silently reproducing the original bug. Guidance moved off the value line, and the halt predicate now tolerates an unquoted trailing comment. - HARD standards violation. A test regex-matched child-process stderr prose for /cycle/i, which CONTRIBUTING bans. Replaced with the structured failure signal plus a differential assertion (same fixture without the cycle edge must succeed), so it stays cycle-specific without matching prose. Also folds the duplicated read-summary-and-check-halted wrapper out of both readers into the shared module -- centralizing only the predicate left the exact two-copies-that-drift pattern the module exists to prevent -- and commits the artifact-types documentation for the new status value. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(#2830): stop the property generator hanging the whole suite The remote runner did not fail -- it hung. Two containers sat in this file for 31+ minutes, and an earlier attempt ran 9 hours before I killed it. The runner passes --test-timeout=0, so nothing ever reaps it: this would have hung CI indefinitely, not reported a failure. Root cause: the DAG generator built edges by rejection -- from: fc.integer({ min: 0, max: n - 1 }) to: fc.integer({ min: 0, max: n - 1 }) .filter(({ from, to }) => from < to) With n === 1 both integers are forced to 0, so the predicate is unsatisfiable and fast-check retries value generation forever. n is drawn from 1..12 and fast-check biases toward boundary values, so n === 1 is reached almost at once. This also explains why the failing-first run completed normally while the fixed run hung: before the fix the graph module did not exist, so the property test threw on import and never reached generation. It only starts hanging once the code under test works. Generates the DAG by construction instead -- `to` is drawn strictly above `from`, with the degenerate single-node case short-circuited to an empty edge list -- so no rejection sampling is involved. Switches the import to the shared fast-check setup so the seed and run count are pinned per CONTRIBUTING, and adds a bounded regression guard that samples the arbitrary directly, so a future reintroduction fails loudly instead of hanging. Verified: the file now completes in 2 seconds, 29 tests started and 29 finished, zero failures, against an indefinite hang before. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(#2830): restore the depends_on display contract and acknowledge the workflow growth Full-suite run surfaced two things the focused harnesses could not. 1. Regression of a pinned pre-existing contract (#3785). A refactor routed the EMITTED depends_on field through the new dependency resolver, which also consults the canonical-prefix map. The original consulted the plan map only, so a short canonical prefix passed through verbatim -- '24-01' stayed '24-01' rather than becoming '24-01-auth-hardening'. The emitted field is a DISPLAY mapping, not the DAG resolution, and #3785 pins that. Reverted with a comment recording why it must not use the resolver; full resolution is still used for the wave DAG and halt propagation, which is what needs it. 2. The workflow file grew 518 bytes without an acknowledgment, from the halt-aware skip rule and the widened parse contract. Acknowledged. Note on where the acknowledgment landed: the guidance is to add a NEW fragment, but execute-phase.md is already named by an existing fragment and the linter hard-fails when two ack sources name the same path. Appending to the owning fragment, following its own established multi-PR pattern, was the only lint-clean option. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(#2830): backfill changeset pr number Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: sim <sim@local> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
GSD Canonical Artifact Registry
This directory contains the template files for every artifact that GSD workflows officially produce. The table below is the authoritative index: if a .planning/ root file is not listed here, gsd-health will flag it as W019 (unrecognized artifact).
Agents should query this file before treating a .planning/ file as authoritative. If the file name does not appear below, it is not a canonical GSD artifact.
.planning/ Root Artifacts
These files live directly at .planning/ — not inside phase subdirectories.
| File | Template | Produced by | Purpose |
|---|---|---|---|
PROJECT.md |
project.md |
/gsd:new-project |
Project identity, goals, requirements summary |
ROADMAP.md |
roadmap.md |
/gsd:new-milestone, /gsd:new-project |
Phase plan with milestones and progress tracking |
STATE.md |
state.md |
/gsd:new-project, /gsd:health --repair |
Current session state, active phase, last activity |
REQUIREMENTS.md |
requirements.md |
/gsd:new-milestone |
Functional requirements with traceability |
MILESTONES.md |
milestone.md |
/gsd:complete-milestone |
Log of completed milestones with accomplishments |
BACKLOG.md |
(inline) | /gsd-add-backlog |
Pending ideas and deferred work |
LEARNINGS.md |
(inline) | /gsd:extract-learnings, /gsd:execute-phase |
Phase retrospective learnings for future plans |
THREADS.md |
(inline) | /gsd:thread |
Persistent discussion threads |
config.json |
config.json |
/gsd:new-project, /gsd:health --repair |
Project-specific GSD configuration |
CLAUDE.md |
claude-md.md |
/gsd-profile |
Auto-assembled Claude Code context file |
RETROSPECTIVE.md |
(inline) | /gsd:complete-milestone |
Living milestone retrospective updated at each milestone close |
Version-stamped artifacts (pattern: vX.Y-*.md)
| Pattern | Produced by | Purpose |
|---|---|---|
vX.Y-MILESTONE-AUDIT.md |
/gsd:audit-milestone |
Milestone audit report before archiving |
These files are archived to .planning/milestones/ by /gsd:complete-milestone. Finding them at the .planning/ root after completion indicates the archive step was skipped.
Phase Subdirectory Artifacts (.planning/phases/NN-name/)
These files live inside a phase directory. They are NOT checked by W019 (which only inspects the .planning/ root).
| File Pattern | Template | Produced by | Purpose |
|---|---|---|---|
NN-MM-PLAN.md |
phase-prompt.md |
/gsd:plan-phase |
Executable implementation plan |
NN-MM-SUMMARY.md |
summary.md |
/gsd:execute-phase |
Post-execution summary with learnings |
NN-CONTEXT.md |
context.md |
/gsd:discuss-phase |
Scoped discussion decisions for the phase |
NN-RESEARCH.md |
research.md |
/gsd:plan-phase, /gsd:plan-phase --research-phase <N> |
Technical research for the phase |
NN-VALIDATION.md |
VALIDATION.md |
/gsd:plan-phase (Nyquist) |
Validation architecture (Nyquist method) |
NN-UAT.md |
UAT.md |
/gsd:validate-phase |
User acceptance test results |
NN-PATTERNS.md |
(inline) | /gsd:plan-phase (pattern mapper) |
Analog file mapping for the phase |
NN-UI-SPEC.md |
UI-SPEC.md |
/gsd:ui-phase |
UI design contract |
NN-SECURITY.md |
SECURITY.md |
/gsd:secure-phase |
Security threat model |
NN-AI-SPEC.md |
AI-SPEC.md |
/gsd:ai-integration-phase |
AI integration spec with eval strategy |
NN-DEBUG.md |
DEBUG.md |
/gsd:debug |
Debug session log |
NN-REVIEWS.md |
(inline) | /gsd:review |
Cross-AI review feedback |
Milestone Archive (.planning/milestones/)
Files archived by /gsd:complete-milestone. These are never checked by W019.
| File Pattern | Source |
|---|---|
vX.Y-ROADMAP.md |
Snapshot of ROADMAP.md at milestone close |
vX.Y-REQUIREMENTS.md |
Snapshot of REQUIREMENTS.md at milestone close |
vX.Y-MILESTONE-AUDIT.md |
Moved from .planning/ root |
vX.Y-phases/ |
Archived phase directories (if --archive-phases used) |
Adding a New Canonical Artifact
When a new workflow produces a .planning/ root file:
- Add the file name to
CANONICAL_EXACTingsd-core/bin/lib/artifacts.cjs - Add a row to the
.planning/Root Artifacts table above - Add the template to
gsd-core/templates/if one exists