* fix(#373): replace unquoted $GSD_SDK with space-safe gsd_run launcher Workflow bash blocks resolved the runtime as GSD_SDK="node $GSD_TOOLS" and invoked it unquoted ($GSD_SDK query ...). On install paths containing spaces (e.g. /Volumes/Mini Me/...) the unquoted expansion word-split into `node /Volumes/Mini gsd-tools.cjs ...`, failing with "Cannot find module '/Volumes/Mini'" and getting masked by `2>/dev/null || echo "{}"` into a silent empty state. Replace the string variable with a single-line shell launcher that defines a gsd_run function, invokes the runtime with a fully-quoted path and "$@", and preserves the local-cjs / installed-gsd-tools-on-PATH fallback (#3668) plus the loud not-found error and install hint. The launcher uses _GSD_SHIM_NAME indirection so no workflow emits the /gsd-tools substring that the do.md dispatcher-parity scanner would misread, and is single-line to stay within the per-file progressive-disclosure line budgets (#2551). The canonical launcher lives in get-shit-done/workflows/_runtime-launcher.snippet.sh, is propagated once per file by scripts/sync-runtime-launcher.cjs, and is locked by tests/runtime-launcher-parity.test.cjs (fails CI on drift, on a reappearing $GSD_SDK token, or on a /gsd-tools substring). Dependent workflow-assertion tests are updated from $GSD_SDK to gsd_run, and the runtime launcher is registered in CONTEXT.md. Fixes #373 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * ci(#373): add changeset fragment and allow-test-rule for parity guard The runtime-launcher parity test is a structural drift guard that reads workflow markdown to assert the canonical launcher is present and the retired $GSD_SDK / /gsd-tools tokens are absent; annotate it with allow-test-rule per the no-source-grep lint escape hatch. Add the required .changeset fragment for this user-facing fix. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(#373): make parity PATH-fallback assertion cross-platform (Windows) Subtest (E) compared GSD_TOOLS against the Node-side absolute temp path, but the value originates from git-bash which reports the POSIX form, so the prefix comparison failed on windows-latest while the launcher itself worked (the installed stub was invoked). Assert the resolved binary by normalized suffix (/bin/gsd-tools, not .cjs) instead of the absolute prefix; the behavioral stub-invocation assertion is unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4.9 KiB
<required_reading> Read all files referenced by the invoking prompt's execution_context before starting. </required_reading>
Parse the command arguments: - First argument: integer phase number to insert after - Remaining arguments: phase descriptionExample: /gsd:phase --insert 72 Fix critical auth bug
-> after = 72
-> description = "Fix critical auth bug"
If arguments missing:
ERROR: Both phase number and description required
Usage: /gsd:phase --insert <after> <description>
Example: /gsd:phase --insert 72 Fix critical auth bug
Exit.
Validate first argument is an integer.
Load phase operation context:_GSD_SHIM_NAME="gsd-tools.cjs"; GSD_TOOLS="${RUNTIME_DIR:-$(git rev-parse --show-toplevel 2>/dev/null || pwd)}/get-shit-done/bin/${_GSD_SHIM_NAME}"; if [ -f "$GSD_TOOLS" ]; then 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" "$@"; }; else echo "ERROR: gsd-tools.cjs not found at $GSD_TOOLS and gsd-tools is not on PATH. Run: npx -y @opengsd/get-shit-done-redux@latest --claude --local" >&2; exit 1; fi
INIT=$(gsd_run query init.phase-op "${after_phase}")
if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
Check roadmap_exists from init JSON. If false:
ERROR: No roadmap found (.planning/ROADMAP.md)
Exit.
**Delegate the phase insertion to `gsd-tools.cjs query phase.insert`:**RESULT=$(gsd_run query phase.insert "${after_phase}" "${description}")
The CLI handles:
- Verifying target phase exists in ROADMAP.md
- Calculating next decimal phase number (checking existing decimals on disk)
- Generating slug from description
- Creating the phase directory (
.planning/phases/{N.M}-{slug}/) - Inserting the phase entry into ROADMAP.md after the target phase with (INSERTED) marker
Extract from result: phase_number, after_phase, name, slug, directory.
-
Update STATE.md's next-phase pointer(s) to the newly inserted phase
{decimal_phase}:gsd_run query state.patch '{"Current Phase":"{decimal_phase}","Next recommended run":"/gsd:plan-phase {decimal_phase}"}'(Adjust field names to whatever pointers STATE.md exposes — the handler reports which fields it matched.)
-
Append a Roadmap Evolution entry via the dedicated handler. It creates the
### Roadmap Evolutionsubsection under## Accumulated Contextif missing and dedupes identical entries:gsd_run query state.add-roadmap-evolution \ --phase {decimal_phase} \ --action inserted \ --after {after_phase} \ --note "{description}" \ --urgentExpected response shape:
{ added: true, entry: "- Phase ... (URGENT)" }(or{ added: false, reason: "duplicate", entry: ... }on replay).
Phase {decimal_phase} inserted after Phase {after_phase}:
- Description: {description}
- Directory: .planning/phases/{decimal-phase}-{slug}/
- Status: Not planned yet
- Marker: (INSERTED) - indicates urgent work
Roadmap updated: .planning/ROADMAP.md
Project state updated: .planning/STATE.md
---
## Next Up
**Phase {decimal_phase}: {description}** -- urgent insertion
`/clear` then:
`/gsd:plan-phase {decimal_phase}`
---
**Also available:**
- Review insertion impact: Check if Phase {next_integer} dependencies still make sense
- Review roadmap
---
<anti_patterns>
- Don't use this for planned work at end of milestone (use /gsd-add-phase)
- Don't insert before Phase 1 (decimal 0.1 makes no sense)
- Don't renumber existing phases
- Don't modify the target phase content
- Don't create plans yet (that's /gsd:plan-phase)
- Don't commit changes (user decides when to commit) </anti_patterns>
<success_criteria> Phase insertion is complete when:
gsd-tools.cjs query phase.insertexecuted successfully- Phase directory created
- Roadmap updated with new phase entry (includes "(INSERTED)" marker)
gsd-tools.cjs query state.add-roadmap-evolution ...returned{ added: true }or{ added: false, reason: "duplicate" }gsd-tools.cjs query state.patchreturned matched next-phase pointer field(s)- User informed of next steps and dependency implications </success_criteria>