fix(integrations): dispatch goose commands via goose run (#2416) - #3781

Addresses the Goose item in #2416. (Not Fixes, since that issue also tracks a broader flag audit — see Scope below.)

Problem

YamlIntegration never overrode build_exec_args(), so GooseIntegration inherited the IntegrationBase no-op that returns None. Callers read None as "this CLI is unavailable", so a workflow command/prompt step targeting Goose reported CLI not found or not installed — even with goose present on PATH.

Reproduced with the CLI on PATH (shutil.which stubbed to a real path, subprocess.run stubbed), using the same command: speckit.specify form the shipped workflows/speckit/workflow.yml uses:

amp       -> completed  argv=['amp', '-p', '/speckit.specify']
opencode  -> completed  argv=['opencode', 'run', '--command', 'speckit.specify']
goose     -> FAILED     "Cannot dispatch command 'speckit.specify': integration
                         'goose' CLI not found or not installed."

The message is simply false — goose is installed. CommandStep swallows the NotImplementedError from dispatch_command and reports the not-installed result; PromptStep silently no-ops on a falsy exec_args.

Fix

Implement build_exec_args() for Goose. Per the goose CLI docs there is no -p flag; the non-interactive entry point is goose run:

Spec Kit already installs its commands as Goose recipes under .goose/recipes/, each declaring an optional args string parameter (enforced today by test_setup_declares_args_parameter_for_args_prompt), so a /speckit.<name> <rest> invocation maps exactly onto --recipe <path> --params args=<rest>. This mirrors OpencodeIntegration, which maps the same leading slash-command onto opencode's native --command.

'/speckit.specify add auth' -> goose run --output-format json --recipe .goose/recipes/speckit.specify.yaml --params args=add auth
'/speckit.plan'             -> goose run --output-format json --recipe .goose/recipes/speckit.plan.yaml
'/speckit.git.commit msg'   -> goose run --output-format json --recipe .goose/recipes/speckit.git.commit.yaml --params args=msg
'just do it'                -> goose run --output-format json -t just do it

Anti-drift: the recipe path is derived from the same two sources setup() uses — config["folder"] + config["commands_subdir"] (as commands_dest() does) and command_filename() — rather than registrar_config["extension"], so the dispatch target cannot diverge from the file that was actually installed. A test runs setup() and asserts the resolved --recipe path is a real file on disk.

Note on #2424

#2424 proposes the opposite — exec_mode = "none" for goose, on the grounds that it is a "recipe-based workflow". Respectfully, recipe-based execution is precisely what goose run is built for: --recipe and --params KEY=VALUE are first-class flags, and Spec Kit already generates recipes declaring the matching args parameter, so the mapping is exact rather than approximate. Happy to defer if you prefer that direction — this PR is deliberately narrow so either can land independently.

Verification

• 7 new dispatch tests + 3 extra-args/executable parity tests: all fail before this change, pass after.
• tests/integrations/test_integration_goose.py: 35 passed (28 pre-existing untouched).
• tests/test_agent_config_consistency.py: 27 passed — requires_cli is deliberately not touched.
• uvx [email protected] check clean.
• Flags cross-checked against the official goose CLI docs (confirmed -t/--text, --recipe, --params, --model, --output-format; confirmed no -p).

Scope

Only the Goose dispatch gap. The issue's headline opencode item was already fixed by c079b2c, and the broader "audit CLI flags for 11+ integrations" / declarative-exec_* refactor is intentionally left out — that is a larger change needing a maintainer design call.

AI-assisted: authored with Claude Code. I reproduced the false "CLI not found" result on main, verified the goose flags against the vendor docs, and added the anti-drift test tying dispatch to what setup() writes.