2815720aad
* fix(#621): route plan-phase post-planning-gaps through gsd_run launcher The post-planning-gaps step in gsd-core/workflows/plan-phase.md invoked gsd-tools via a hardcoded `node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs"` path twice on one line — for the gap-analysis call and its nested init.plan-phase phase_req_ids query — bypassing the gsd_run launcher that every other call in the workflow uses. On non-default install/runtime layouts (relocated/global installs, non-Claude runtimes) the hardcoded path does not resolve, so the assistant reported the gap-analysis tool as "not found" and fell back to a frontmatter-only coverage check even when a working install existed. #3668 fixed this class earlier in the file but missed this block. Route both invocations through gsd_run, matching the rest of the workflow. No hardcoded $HOME gsd-tools path remains in plan-phase.md. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * chore(#621): add changeset for plan-phase gsd_run gap-analysis fix Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * test(#621): update bug-2851 §13e guard for the gsd_run gap-analysis form The #621 fix migrates plan-phase.md's post-planning-gaps gap-analysis call from the hardcoded node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" form to the gsd_run launcher (the canonical resolvable form every other call in the file uses). bug-2851's §13e subtest pinned that line to the absolute-$HOME form and now asserts stale behavior. Update the §13e assertion to require `gsd_run gap-analysis` (still rejecting a regression to the hardcoded $HOME path), retitle it, and note the migration in the file header. The generic bare-`gsd-tools` sweeper test is unchanged — gsd_run is a resolvable launcher, not a bare gsd-tools call. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
3.1 KiB
3.1 KiB