* test(#3809): generalize dead-ref guard into a rule table (failing first)
The #2020 guard hardcoded `sdk/(src|dist|handlers)/` — the three dead paths
that had caused that storm. That proved those three paths were gone and said
nothing about the class, so #3809 reproduced the identical Windows find.exe
storm under a different token and the guard could not see it.
Replaces the single regex with a rule table over the same runtime-loaded
markdown surface, adds `commands/` to the scan set (previously uncovered),
and adds rule B: the runtime shim filename must never appear in command
position, because it is not a PATH command and an agent that meets it falls
back to locating the file.
Rule B's matcher is deliberately lenient — the launcher's own resolver
assignment, `node <path>/<shim>` calls, bare paths, and prose that names the
file all stay unflagged, each pinned by a negative-space row.
This commit is expected to FAIL: 50 offenders across 23 files remain in the
tree. The remediation lands next.
Refs #3809
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(#3809): route every workflow call through the gsd_run launcher
50 places across 23 runtime-loaded workflow, agent, reference, and command
files instructed the agent to run the runtime shim by filename. That filename
is not on PATH under any name -- package.json ships gsd-core, gsd-tools,
gsd_run and gsd-mcp-server -- so the call exited 127, the file-shaped token
sent the agent looking for the file, and on Git Bash for Windows the resulting
`find /` walked the entire drive (7268 CPU-seconds in the report) until
somebody killed it by hand.
CONTEXT.md -> Runtime Launcher Module already makes gsd_run the single entry
point: "Canonical space-safe shell preamble (`gsd_run`) used by every workflow
bash block to invoke the GSD runtime CLI." These sites predate that rule --
they trace to 0e6907050 (docs(#195): migrate workflow markdown off gsd-sdk
query), which swapped one non-PATH token for another.
Two further instances of the same class surfaced during remediation and are
fixed here rather than left for later:
- references/model-profiles.md prescribed `node <shim> effort sync` with no
path at all; node resolves a bare filename against cwd, so it fails the
same way.
- references/universal-anti-patterns.md rule 25 instructed every agent to
"use <shim>" when shelling out. That rule did not contain the defect, it
prescribed it repo-wide.
Five "(or legacy <shim>)" parentheticals left dangling by the substitution are
removed; after the rewrite they offered the non-resolving form as an
alternative.
The guard from the previous commit now passes. Its node-prefix exemption was
tightened to require a path separator, which is what exposed model-profiles.
Fixes #3809
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(#3809): key the guard on the CLI's whole verb roster, not observed usage
Review found the first cut of rule B repeating the very mistake it exists to
prevent. Its verb set held query, commit and effort -- the verbs that happened
to appear in the tree -- so it could not see `<shim> phase add`,
`<shim> state load`, `<shim> verify ...` or twenty-odd other real single-word
subcommands. A guard that only recognises yesterday's offenders is not a guard.
The set is now the CLI's full advertised roster, unioned from the usage banner
and HOST_COMMAND_ROUTERS (which carries verification, planning, uat, stats,
todo and windows, all absent from the banner).
Widening it immediately caught a live offender the first pass had missed:
references/planning-config.md prescribed `node <shim> worktree set-baseref`
with no path. Fixed here.
Also drops the "a hyphen or a dot means subcommand" heuristic, which was
unsound for prose -- it flagged `built-in` and `v1.2`. Detection now keys
entirely on the roster, testing the first dot-segment so that phase.add and
state.patch still match while prose does not. Both false positives are pinned
as negative-space rows.
Guard verified against the pre-fix tree at origin/next: 52 offenders across 25
files, and 0 after this branch's remediation.
Refs #3809
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(#3809): derive the verb roster from the router; repair launcher parity
Standards review caught the guard repeating the defect it exists to prevent.
Its verb list was a hand-copied literal -- and worse, transcribed from an
INSTALLED older binary, so it was missing 22 verbs this tree actually ships
(websearch, windows, state-snapshot, context-predicates and the dispatch-*
family among them). gsd-tools.cjs already carries three hand-maintained
rosters whose drift is a named defect pinned by the parity test in
tests/commands.test.cjs; a hand-copied fourth was that same defect wearing a
guard's clothes.
The roster is now derived from HOST_COMMAND_ROUTERS + TOP_LEVEL_USAGE, lazily
and memoised, with `query` supplemented explicitly -- it dispatches through
the routing hub ahead of the host-router table, so it appears in neither
export, yet 45 of the 50 offenders used it. A parity test pins the derivation.
Two regressions this branch introduced, both caught by the remote runner:
- runtime-launcher-parity: rewriting a comment in gsd-research-synthesizer.md
put a `gsd_run` token at line 65 while the canonical preamble sits at 158,
breaking "exactly ONE preamble, before the first gsd_run call". The comment
is descriptive and needs no command token at all; it now names none.
- The #2751 guard's PROSE_ALLOWLIST entry for that same line went stale once
the line stopped carrying a bare mention. Pruned, exactly as that guard's
own stale-entry test instructs.
Also corrects git-planning-commit.md, where the first pass rewrote only the
trailing "legacy" clause and left the sentence reading backwards.
Note the #2751 guard and this one are complementary, not duplicates: its regex
requires whitespace immediately after `gsd-tools`, so it cannot match the
`.cjs` form, and this one only matches the `.cjs` form.
Refs #3809
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(#2751): extend the bare-command guard to references/ and commands/
The #2751 guard has only ever scanned agents/ and gsd-core/workflows/. Two
runtime-loaded directories were never in its scan set, and 47 bare
`gsd-tools <verb>` calls had accumulated there unseen -- the same defect that
guard exists to catch, in the rooms it never entered.
- gsd-core/references/: 37 calls, all rewritten to gsd_run. references are
fragments inlined into a parent that defines the launcher, which is why 21
of the 22 files already using gsd_run carry no local preamble.
- commands/gsd/: 10 operative calls rewritten. The remaining 10 are
descriptive prose ("resolved inside the workflow via ...") and are
allowlisted with reasons, bringing PROSE_ALLOWLIST to 15.
commands/ also came under launcher propagation. sync-runtime-launcher.cjs
walked only WORKFLOWS_DIR and AGENTS_DIR, so every preamble under commands/
was a hand-pasted copy nothing propagated and no test checked -- graphify.md
had accumulated five. It now walks COMMANDS_DIR too, which collapses those
five to the canonical one-per-file, and runtime-launcher-parity gains a
(B-commands) arm mirroring (B-agents) exactly so the placement stays honest.
The parity arm keys on shell blocks, so commands/gsd/workstreams.md and
config.md -- which name gsd_run only in inline backtick prose -- are exempt,
as they should be. gsd_run is itself a shipped npm bin, so those inline
instructions resolve from PATH exactly as the gsd-tools form they replace did.
skills/ is deliberately NOT added to either guard's scan set: it is generated
from commands/ and pinned by lint:generated-sync, so guarding the source
guards both, and scanning the mirror would double-report every future
offender. Regenerated here.
Refs #2751, #3809
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* test(#3809): acknowledge the one emitted file this change grows
The emitted-attribution gate failed on the previous sha: gsd-research-synthesizer.md
grew 3 bytes (13847 -> 13850) with no acknowledgment. The substitution SHRANK the
other 19 emitted files, which is why the growth arm was not expected to fire at all.
The 3 bytes are unavoidable. Line 65 is a descriptive comment inside a fenced block;
naming any command there puts a gsd_run token ahead of the file's canonical preamble
at line 158, which runtime-launcher-parity's (B-agents) arm correctly rejects. So the
comment names no command and says where the config is actually loaded instead, which
reads longer than the token it replaced.
Acks only the path the gate reported, per the fragment rules.
Refs #3809
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* revert(#2751): drop the commands/ half — three contracts pin it in place
The remote runner refuted the commands/ extension outright. Reverting it and
keeping the references/ conversion, which passed.
What broke, all of it caused by bringing commands/ under launcher propagation:
- graphify.md's five per-block preambles are LOAD-BEARING, not accumulated
drift. tests/graphify-visualization.test.cjs extracts individual Step-3
shell chains and executes them standalone, so each fenced block needs its
own definition of gsd_run. Collapsing them to the canonical one-per-file
produced `bash: gsd_run: command not found`, exit 127, across four tests.
The "define once per file" contract holds for workflows and agents because
nothing extracts their blocks in isolation; commands/ is not like that.
- explore.md broke "the preamble that DEFINES gsd_run must appear before the
first USE of gsd_run anywhere in the file".
- tests/gsd-tools-path-refs.test.cjs (#1766) ASSERTS that
commands/gsd/workstreams.md contains the literal string
`gsd-tools query workstream.list`. Rewriting it to gsd_run contradicts a
test that pins the opposite, so the two guards disagree about that file by
construction.
So commands/ is not a scan-set widening. It needs those contracts reconciled
first, and that is its own change. SCAN_DIRS keeps gsd-core/references/ and
drops commands/, the ten commands/ allowlist entries go with it (back to 5),
and the reasoning is recorded in the guard itself so the next person does not
rediscover it by burning a matrix run.
commands/gsd/import.md keeps its #3809 fix — that one is the .cjs form this
PR exists to remove, and it is untouched by any of the above.
Refs #2751, #3809
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* revert(#3809): restore explore.md's Step 1 preamble placement
Running the launcher sync script processed workflows/ and agents/ too, not
just the commands/ directory the run was aimed at, and it MOVED
gsd-core/workflows/explore.md's preamble from Step 1 down to Step 3.
The script inserts into the first bash block that USES gsd_run. explore.md's
Step 1 block only DEFINES it, and that placement is deliberate -- the file
says so on the line above: "Placed in Step 1 rather than Step 3 so declining
the research offer cannot leave Step 5's commit call unbootstrapped."
tests/explore-command.test.cjs pins it.
explore.md carried no #3809 offender, so reverting it costs this fix nothing.
This was collateral from invoking the sync script at all, not from the
COMMANDS_DIR change, which is why the earlier commands/ revert did not catch it.
Refs #3809
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* chore(#3809): backfill PR number into changeset fragments
pr:0 -> pr:3815 for both fragments now that the PR exists.
Refs #3809
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(#3809): drop the hand-rolled regex escaper CodeQL flagged
CodeQL raised js/incomplete-sanitization (HIGH) on the guard's pattern build:
`SHIM.replace(/\./g, '\\.')` escapes the dot and nothing else, so it does not
escape backslashes. It blocked PR #3815.
The repo already bans this shape -- local/no-adhoc-regex-escape exists exactly
to stop hand-rolled escapers, with the canonical one in src/pattern.cts. Rather
than reach for that helper, the pattern now carries no escaping logic at all:
SHIM is a compile-time constant whose only metacharacter is the dot, so the
regex source is spelled out literally. The generated source string is
byte-identical to what the replace() produced, verified before and after --
0 offenders on this tree, 52 against origin/next, unchanged.
A drift pin asserts SHIM_PATTERN still matches SHIM exactly, and that the dot
is escaped rather than acting as a wildcard, so the two cannot separate.
Refs #3809
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: sim <sim@local>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
25 KiB
Interactive command center for managing a milestone from a single terminal. Shows a dashboard of all phases with visual status, dispatches discuss inline and runs plan/execute inline (backgrounded when dispatch-should-flatten returns false), and loops back to the dashboard after each action. Enables parallel phase work from one terminal.
<required_reading>
Read all files referenced by the invoking prompt's execution_context before starting.
</required_reading>
1. Initialize
Bootstrap via manager init:
_GSD_SHIM_NAME="gsd-tools.cjs"; _GSD_RUNTIME_ROOT="${RUNTIME_DIR:-$(git rev-parse --show-toplevel 2>/dev/null || pwd)}"; GSD_TOOLS="${_GSD_RUNTIME_ROOT}/gsd-core/bin/${_GSD_SHIM_NAME}"; if [ -f "$GSD_TOOLS" ]; then gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${_GSD_RUNTIME_ROOT}/.claude/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${_GSD_RUNTIME_ROOT}/.claude/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${_GSD_RUNTIME_ROOT}/.codex/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${_GSD_RUNTIME_ROOT}/.codex/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif command -v gsd-tools >/dev/null 2>&1; then GSD_TOOLS="$(command -v gsd-tools)"; gsd_run() { "$GSD_TOOLS" "$@"; }; elif [ -f "${CLAUDE_CONFIG_DIR:-$HOME/.claude}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${CLAUDE_CONFIG_DIR:-$HOME/.claude}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${HERMES_HOME:-$HOME/.hermes}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${HERMES_HOME:-$HOME/.hermes}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${CURSOR_CONFIG_DIR:-$HOME/.cursor}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${CURSOR_CONFIG_DIR:-$HOME/.cursor}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${CODEX_HOME:-$HOME/.codex}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${CODEX_HOME:-$HOME/.codex}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${GEMINI_CONFIG_DIR:-$HOME/.gemini}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${GEMINI_CONFIG_DIR:-$HOME/.gemini}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${COPILOT_CONFIG_DIR:-$HOME/.copilot}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${COPILOT_CONFIG_DIR:-$HOME/.copilot}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${WINDSURF_CONFIG_DIR:-$HOME/.codeium/windsurf}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${WINDSURF_CONFIG_DIR:-$HOME/.codeium/windsurf}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${AUGMENT_CONFIG_DIR:-$HOME/.augment}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${AUGMENT_CONFIG_DIR:-$HOME/.augment}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${TRAE_CONFIG_DIR:-$HOME/.trae}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${TRAE_CONFIG_DIR:-$HOME/.trae}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${QWEN_CONFIG_DIR:-$HOME/.qwen}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${QWEN_CONFIG_DIR:-$HOME/.qwen}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${CODEBUDDY_CONFIG_DIR:-$HOME/.codebuddy}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${CODEBUDDY_CONFIG_DIR:-$HOME/.codebuddy}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${CLINE_CONFIG_DIR:-$HOME/.cline}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${CLINE_CONFIG_DIR:-$HOME/.cline}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${GROK_AGENTS_HOME:-$HOME/.agents}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${GROK_AGENTS_HOME:-$HOME/.agents}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${ANTIGRAVITY_CONFIG_DIR:-$HOME/.gemini/antigravity}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${ANTIGRAVITY_CONFIG_DIR:-$HOME/.gemini/antigravity}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${OPENCODE_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/opencode}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${OPENCODE_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/opencode}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; elif [ -f "${KILO_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/kilo}/gsd-core/bin/${_GSD_SHIM_NAME}" ]; then GSD_TOOLS="${KILO_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/kilo}/gsd-core/bin/${_GSD_SHIM_NAME}"; gsd_run() { node "$GSD_TOOLS" "$@"; }; else echo "ERROR: gsd-tools.cjs not found at $GSD_TOOLS and gsd-tools is not on PATH. Run: npx -y @opengsd/gsd-core@latest --claude --local" >&2; exit 1; fi; if [ -n "${CLAUDE_ENV_FILE:-}" ] && [ -n "${GSD_TOOLS:-}" ]; then printf "export PATH='%s':\"\$PATH\"\n" "${GSD_TOOLS%/*}" >> "$CLAUDE_ENV_FILE" 2>/dev/null || true; fi
INIT=$(gsd_run query init.manager)
if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
Parse JSON for: milestone_version, milestone_name, phase_count, completed_count, in_progress_count, phases, recommended_actions, all_complete, waiting_signal, manager_flags, response_language, and the optional trio queued_milestone_version, queued_milestone_name, queued_phases (added in SDK fix 2495-2496-2497 — may be absent on older SDK versions, treat missing as empty).
If response_language is set: All user-facing questions, prompts, and explanations in this workflow MUST be presented in {response_language}. Technical terms, code, file paths, and subagent prompts stay in English — only user-facing output is translated. Subagent dispatches (discuss/plan/execute) stay in English at the prompt level; include response_language in their spawn args per the workflow being dispatched.
manager_flags contains per-step passthrough flags from config:
manager_flags.discuss— appended to/gsd:discuss-phaseargs (e.g."--auto --analyze")manager_flags.plan— appended to plan agent init commandmanager_flags.execute— appended to execute agent init command
These are empty strings by default. Set via: gsd_run query config-set manager.flags.discuss "--auto --analyze"
If error: Display the error message and exit.
Display startup banner:
### GSD ► MANAGER
{milestone_version} — {milestone_name}
{phase_count} phases · {completed_count} complete
✓ Discuss → inline ◆ Plan/Execute → inline (background when FLATTEN=false)
Dashboard auto-refreshes when background work is active.
---
Proceed to dashboard step.
2. Dashboard (Refresh Point)
Every time this step is reached, re-read state from disk to pick up changes from background agents:
INIT=$(gsd_run query init.manager)
if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
Parse the full JSON. Build the dashboard display.
Build dashboard from JSON. Symbols: ✓ done, ◆ active, ○ pending, · queued. Progress bar: 20-char █░.
Status mapping (disk_status → D P E Status):
complete→✓ ✓ ✓✓ Completeexecuted→✓ ✓ ◆◆ Verification requiredpartial→✓ ✓ ◆◆ Executing...planned→✓ ✓ ○○ Ready to executediscussed→✓ ○ ·○ Ready to planresearched→◆ · ·○ Ready to planempty/no_directory+is_next_to_discuss→○ · ·○ Ready to discussempty/no_directoryotherwise →· · ·· Up next- If
is_active, replace status icon with◆and append(active)
If any is_active phases, show: ◆ Background: {action} Phase {N}, ... above grid.
Use display_name (not name) for the Phase column — it's pre-truncated to 20 chars with … if clipped. Pad all phase names to the same width for alignment.
Use deps_display from init JSON for the Deps column — shows which phases this phase depends on (e.g. 1,3) or — for none.
Example output:
### GSD ► DASHBOARD
████████████░░░░░░░░ 60% (3/5 phases)
◆ Background: Planning Phase 4
| # | Phase | Deps | D | P | E | Status |
|---|----------------------|------|---|---|---|---------------------|
| 1 | Foundation | — | ✓ | ✓ | ✓ | ✓ Complete |
| 2 | API Layer | 1 | ✓ | ✓ | ◆ | ◆ Executing (active)|
| 3 | Auth System | 1 | ✓ | ✓ | ○ | ○ Ready to execute |
| 4 | Dashboard UI & Set… | 1,2 | ✓ | ◆ | · | ◆ Planning (active) |
| 5 | Notifications | — | ○ | · | · | ○ Ready to discuss |
| 6 | Polish & Final Mail… | 1-5 | · | · | · | · Up next |
Queued section (next milestone preview):
If queued_phases is present and non-empty, render a compact preview of the next milestone's phases directly below the main table. This surfaces upcoming work without cluttering the active-milestone grid. Skip this section entirely when queued_phases is empty or missing (e.g. the active milestone is the last one in the roadmap).
Use queued_milestone_version and queued_milestone_name for the header. Phases render without D/P/E columns since they aren't discussed yet — just number, name (pre-truncated display_name), dependencies (deps_display), and a fixed · Queued status. Phase-name padding should match the active-table column width for visual alignment.
Example:
### ◆ Queued — {queued_milestone_version} {queued_milestone_name} ({queued_phases.length} phases)
| # | Phase | Deps | Status |
|---|----------------------|------|--------------|
| 31| Email Logs | — | · Queued |
| 32| Today's Sheets | 31 | · Queued |
| 33| Resend Backfill | 31 | · Queued |
| 34| Business Day Audit | 31 | · Queued |
Queued phases are NOT eligible for the Continue action menu — they live in a future milestone and must wait for the current milestone to ship. The preview exists purely for situational awareness.
Recommendations section:
If all_complete is true:
### MILESTONE COMPLETE
All {phase_count} phases verified complete. Ready for final steps:
→ /gsd:verify-work — run acceptance testing
→ /gsd:complete-milestone — archive and wrap up
Text mode (workflow.text_mode: true in config or --text flag): Set TEXT_MODE=true if --text is present in $ARGUMENTS OR text_mode from init JSON is true. When TEXT_MODE is active, replace every AskUserQuestion call with a plain-text numbered list and ask the user to type their choice number. This is required for non-Claude runtimes (OpenAI Codex, Gemini CLI, etc.) where AskUserQuestion is not available.
Ask user via AskUserQuestion:
- question: "All phases complete. What next?"
- options: "Verify work" / "Complete milestone" / "Exit manager"
Handle responses:
- "Verify work":
Skill(skill="gsd-verify-work")then loop to dashboard. - "Complete milestone":
Skill(skill="gsd-complete-milestone")then exit. - "Exit manager": Go to exit step.
If NOT all_complete, build compound options from recommended_actions:
Compound option logic: Group background actions (plan/execute) together, and pair them with the single inline action (discuss) when one exists. The goal is to present the fewest options possible — one option can dispatch multiple background agents plus one inline action.
Building options:
-
Collect all background actions (execute and plan recommendations) — there can be multiple of each.
-
Collect verification actions (
verify) for implementation-complete phases whose canonical verification has not passed. -
Collect the inline action (discuss recommendation, if any — there will be at most one since discuss is sequential).
-
Build compound options:
If there are ANY recommended actions (background, inline, or both): Create ONE primary "Continue" option that dispatches ALL of them together:
- Label:
"Continue"— always this exact word - Below the label, list every action that will happen. Enumerate ALL recommended actions — do not cap or truncate:
Continue: → Execute Phase 32 (background) → Plan Phase 34 (background) → Verify Phase 33 → Discuss Phase 35 (inline) - This dispatches all background agents first, runs verification actions inline, then runs the inline discuss (if any).
- If there is no inline discuss, the dashboard refreshes after spawning background agents and inline verification.
Important: The Continue option must include EVERY action from
recommended_actions— not just 2. If there are 3 actions, list 3. If there are 5, list 5. - Label:
-
Always add:
"Refresh dashboard""Exit manager"
Display recommendations compactly:
### ▶ Next Steps
Continue:
→ Execute Phase 32 (background)
→ Plan Phase 34 (background)
→ Discuss Phase 35 (inline)
Auto-refresh: If background agents are running (is_active is true for any phase), set a 60-second auto-refresh cycle. After presenting the action menu, if no user input is received within 60 seconds, automatically refresh the dashboard. This interval is configurable via manager_refresh_interval in GSD config (default: 60 seconds, set to 0 to disable).
Present via AskUserQuestion:
- question: "What would you like to do?"
- options: (compound options as built above + refresh + exit, AskUserQuestion auto-adds "Other")
On "Other" (free text): Parse intent — if it mentions a phase number and action, dispatch accordingly. If unclear, display available actions and loop to action_menu.
Proceed to handle_action step with the selected action.
4. Handle Action
Refresh Dashboard
Loop back to dashboard step.
Exit Manager
Go to exit step.
Compound Action (background + inline)
When the user selects a compound option, behavior depends on whether the runtime supports background dispatch of nesting-capable orchestrators — the Plan Phase N / Execute Phase N handlers below resolve it via gsd_run query dispatch-should-flatten (#1708):
- If
FLATTENisfalse(the host can background a nesting-capable orchestrator — e.g. codex, cursor): Spawn all background agents first (plan/execute) — dispatch them in parallel using the Plan Phase N / Execute Phase N handlers below — then run verification actions, then run the inline discuss; the background agents continue while you verify/discuss. - Otherwise (
FLATTENistrue— run inline): run the chosen plan/execute step(s) inline via their handlers below (in order), then run verification actions, then run the inline discuss. There is no overlap.
Inline verification:
For each verification recommendation, dispatch by the recommended action's command:
- If
commandcontainsexecute-phase, runSkill(skill="gsd-execute-phase", args="{PHASE_NUM} {manager_flags.execute}"). - If
commandcontainsverify-work, runSkill(skill="gsd-verify-work", args="{PHASE_NUM}"). - If
commandis missing or unrecognized, stop and show the recommendation row instead of guessing.
Inline discuss:
Skill(skill="gsd-discuss-phase", args="{PHASE_NUM} {manager_flags.discuss}")
After discuss completes, loop back to dashboard step.
Discuss Phase N
Discussion is interactive — needs user input. Run inline with any configured flags:
Skill(skill="gsd-discuss-phase", args="{PHASE_NUM} {manager_flags.discuss}")
After discuss completes, loop back to dashboard step.
Plan Phase N
Planning runs autonomously. First resolve whether background dispatch is safe. Background dispatch is only safe on a runtime where a backgrounded agent can still nest the pipeline's subagents (plan-checker / worktree executors / verifier). This is determined from the documentation-sourced dispatch capability in the registry (#1708); Claude Code's backgrounded agents have no Agent/Task tool, and every other runtime either prohibits nested subagents or disables them by default. So run inline everywhere except where dispatch-should-flatten returns false.
FLATTEN=$(gsd_run query dispatch-should-flatten --raw 2>/dev/null || echo "true")
If FLATTEN is false: Spawn a background agent that delegates to the Skill pipeline with any configured flags:
Agent(
description="Plan phase {N}: {phase_name}",
run_in_background=true,
prompt="You are running the GSD plan-phase workflow for phase {N} of the project.
Working directory: {cwd}
Phase: {N} — {phase_name}
Goal: {goal}
Manager flags: {manager_flags.plan}
Run the plan-phase Skill with any configured manager flags:
Skill(skill=\"gsd-plan-phase\", args=\"{N} --auto {manager_flags.plan}\")
This delegates to the full plan-phase pipeline including local patches, research, plan-checker, and all quality gates.
Important: You are running in the background. Do NOT use AskUserQuestion — make autonomous decisions based on project context. If you hit a blocker, write it to STATE.md as a blocker and stop. Do NOT silently work around permission or file access errors — let them fail so the manager can surface them with resolution hints. Do NOT use --no-verify on git commits."
)
ORCHESTRATOR RULE — BACKGROUND DISPATCH: After calling Agent() above with
run_in_background=true, do NOT do any planning work for this phase independently. Return to the dashboard immediately and wait for the background agent to report back. Only resume planning-related work when the subagent result is available.
Display:
◆ Spawning planner for Phase {N}: {phase_name}... (runs in a subagent — no output until it returns, ~1–5 min; expected, not a freeze)
Loop back to dashboard step.
Otherwise (FLATTEN is true — run inline): Run plan inline so the plan-checker and quality gates actually run — do NOT wrap it in Agent(run_in_background=true, …):
Skill(skill="gsd-plan-phase", args="{N} --auto {manager_flags.plan}")
Display while it runs:
◆ Planning Phase {N}: {phase_name}... (runs inline so the plan-checker runs — the dashboard resumes when it returns, ~1–5 min; expected, not a freeze)
Then loop back to dashboard step.
Execute Phase N
Execution runs autonomously. First resolve whether background dispatch is safe. Background dispatch is only safe on a runtime where a backgrounded agent can still nest the pipeline's subagents (plan-checker / worktree executors / verifier). This is determined from the documentation-sourced dispatch capability in the registry (#1708); Claude Code's backgrounded agents have no Agent/Task tool, and every other runtime either prohibits nested subagents or disables them by default. So run inline everywhere except where dispatch-should-flatten returns false.
FLATTEN=$(gsd_run query dispatch-should-flatten --raw 2>/dev/null || echo "true")
If FLATTEN is false: Spawn a background agent that delegates to the Skill pipeline with any configured flags:
Agent(
description="Execute phase {N}: {phase_name}",
run_in_background=true,
prompt="You are running the GSD execute-phase workflow for phase {N} of the project.
Working directory: {cwd}
Phase: {N} — {phase_name}
Goal: {goal}
Manager flags: {manager_flags.execute}
Run the execute-phase Skill with any configured manager flags:
Skill(skill=\"gsd-execute-phase\", args=\"{N} {manager_flags.execute}\")
This delegates to the full execute-phase pipeline including local patches, branching, wave-based execution, verification, and all quality gates.
Important: You are running in the background. Do NOT use AskUserQuestion — make autonomous decisions. Do NOT use --no-verify on git commits — let pre-commit hooks run normally. If you hit a permission error, file lock, or any access issue, do NOT work around it — let it fail and write the error to STATE.md as a blocker so the manager can surface it with resolution guidance."
)
ORCHESTRATOR RULE — BACKGROUND DISPATCH: After calling Agent() above with
run_in_background=true, do NOT do any execution work for this phase independently. Return to the dashboard immediately and wait for the background agent to report back. Only resume execution-related work when the subagent result is available.
Display:
◆ Spawning executor for Phase {N}: {phase_name}... (runs in a subagent — no output until it returns, ~1–5 min; expected, not a freeze)
Loop back to dashboard step.
Otherwise (FLATTEN is true — run inline): Run execute inline so worktree isolation and the verifier actually run — do NOT wrap it in Agent(run_in_background=true, …):
Skill(skill="gsd-execute-phase", args="{N} {manager_flags.execute}")
Display while it runs:
◆ Executing Phase {N}: {phase_name}... (runs inline so worktree isolation and verification run — the dashboard resumes when it returns; expected, not a freeze)
Then loop back to dashboard step.
5. Background Agent Completion
When notified that a background agent completed:
- Read the result message from the agent.
- Display a brief notification:
✓ {description}
{brief summary from agent result}
- Loop back to dashboard step.
If the agent reported an error or blocker:
Classify the error:
Permission / tool access error (e.g. tool not allowed, permission denied, sandbox restriction):
- Parse the error to identify which tool or command was blocked.
- Display the error clearly, then offer to fix it:
- question: "Phase {N} failed — permission denied for
{tool_or_command}. Want me to add it to settings.local.json so it's allowed?" - options: "Add permission and retry" / "Run this phase inline instead" / "Skip and continue"
- "Add permission and retry": Use
Skill(skill="update-config")to add the permission tosettings.local.json, then re-spawn the background agent. Loop to dashboard. - "Run this phase inline instead": Dispatch the same action inline via the appropriate Skill — use
Skill(skill="gsd-plan-phase", args="{N}")if the failed action was planning, orSkill(skill="gsd-execute-phase", args="{N}")if the failed action was execution. Loop to dashboard after. - "Skip and continue": Loop to dashboard (phase stays in current state).
- question: "Phase {N} failed — permission denied for
Other errors (git lock, file conflict, logic error, etc.):
- Display the error, then offer options via AskUserQuestion:
- question: "Background agent for Phase {N} encountered an issue: {error}. What next?"
- options: "Retry" / "Run inline instead" / "Skip and continue" / "View details"
- "Retry": Re-spawn the same background agent. Loop to dashboard.
- "Run inline instead": Dispatch the action inline via the appropriate Skill — use
Skill(skill="gsd-plan-phase", args="{N}")if the failed action was planning, orSkill(skill="gsd-execute-phase", args="{N}")if the failed action was execution. Loop to dashboard after. - "Skip and continue": Loop to dashboard (phase stays in current state).
- "View details": Read STATE.md blockers section, display, then re-present options.
6. Exit
Display final status with progress bar:
### GSD ► SESSION END
{milestone_version} — {milestone_name}
{PROGRESS_BAR} {progress_pct}% ({completed_count}/{phase_count} phases)
Resume anytime: /gsd:manager
---
Note: Any background agents still running will continue to completion. Their results will be visible on next /gsd:manager or /gsd:progress invocation.
<success_criteria>
- Dashboard displays all phases with correct status indicators (D/P/E/V columns)
- Progress bar shows accurate completion percentage
- Dependency resolution: blocked phases show which deps are missing
- Recommendations prioritize: execute > plan > discuss
- Discuss phases run inline via Skill() — interactive questions work
- Plan phases run inline (or as background Task agents on Codex) — dashboard resumes when complete
- Execute phases run inline (or as background Task agents on Codex) — dashboard resumes when complete
- Dashboard refreshes pick up changes from background agents via disk state
- Background agent completion triggers notification and dashboard refresh
- Background agent errors present retry/skip options
- All-complete state offers verify-work and complete-milestone
- Exit shows final status with resume instructions
- "Other" free-text input parsed for phase number and action
- Manager loop continues until user exits or milestone completes
- Queued section renders when
queued_phasesis non-empty; skipped when absent or empty </success_criteria>