Fix required-check shell executable selection so Windows and custom shell setups run Galley-owned required checks with the intended executable and invocation style.

[shinpr]

Goal

Fix required-check shell executable selection so Windows and custom shell setups run Galley-owned required checks with the intended executable and invocation style.

Acceptance Criteria

• AC1 When an environment profile sets required_checks.shell_path to a recognized shell executable path, Galley shall use that path as the required-check executable and infer the shell invocation style from the executable name.
  • Verification: go test ./internal/profile ./internal/result
  • Status: satisfied
• AC2 When both required_checks.shell and required_checks.shell_path are set, Galley shall treat shell_path as the more specific executable selection and shall not invoke that executable using an incompatible shell style from shell.
  • Verification: go test ./internal/result
  • Status: satisfied
• AC3 If required_checks.shell_path is set to an unrecognized executable name, then Galley shall use an explicit non-auto required_checks.shell as fallback shell kind metadata and shall fail profile validation when no usable shell kind can be determined.
  • Verification: go test ./internal/profile ./internal/result
  • Status: satisfied
• AC4 When Windows required checks request Bash through required_checks.shell: bash and no shell_path is set, Galley shall prefer standard Git for Windows Bash discovery over PATH-discovered WSL launchers, WindowsApps shims, or other non-standard Bash entries.
  • Verification: go test ./internal/result
  • Status: satisfied
• AC5 The environment profile schema, examples, docs, and Galley skill guidance shall describe required_checks.shell_path as an executable override that may stand alone when the executable name is recognized, takes precedence over required_checks.shell when both are present, and uses required_checks.shell only as fallback kind metadata for unrecognized executable names.
  • Verification: go run ./cmd/galley schema generate && go run ./cmd/galley schema check && go run ./cmd/galley profile validate --kind environment examples/environment-local.yaml && claude plugin validate plugins/galley
  • Status: satisfied
• AC6 Required-check run evidence and failure messages shall record the shell kind actually used for invocation and the executable path actually launched for shell_path-only, shell plus shell_path, and Windows Bash discovery cases.
  • Verification: go test ./internal/result
  • Status: satisfied

Final Verification

• claude plugin validate plugins/galley: passed
• go test ./internal/profile ./internal/result: passed
• go run ./cmd/galley schema generate: passed
• go run ./cmd/galley profile validate --kind environment examples/environment-local.yaml: passed
• python3 plugins/galley/skills/galley/scripts/test_create_task_skeleton.py and python3 -m json.tool over packaged plugin/schemas/marketplace JSONs: passed
• test -z "$(find . -name '*.go' -not -path './.git/*' -print | xargs gofmt -l)": passed
• go test ./...: passed
• go build -o /tmp/galley ./cmd/galley: passed
• go run ./cmd/galley schema check: passed
• go run ./cmd/galley task validate examples/afk-task.yaml: passed
• go run ./cmd/galley profile validate --kind quality examples/quality-default.yaml: passed
• python3 -m json.tool schemas/claude-result.schema.json >/dev/null: passed
• ./scripts/smoke-local.sh: passed

Key Decisions

• claude-decision-1 How to express the shell_path contract in a YAML example that must stay valid? -> Add YAML comments describing the precedence rule, the recognized-basename stand-alone rule, and the fallback metadata rule for unrecognized basenames, while setting shell: "auto" and shell_path: "/bin/bash" to keep validation passing and to illustrate the precedence concretely.
  • Rationale: A single example file cannot demonstrate both the recognized and unrecognized branches without two files; comments cover the unrecognized case while the chosen values stay structurally valid.
  • Reversibility: high
• claude-decision-2 When required_checks.shell is bash on Windows with no shell_path and no standard Git for Windows Bash is discoverable, should the resolver return an error or silently fall back to cmd.exe? -> Return a resolver error that names required_checks.shell_path as the explicit override.
  • Rationale: The task's preferred behavior is a clear resolver error requiring shell_path for non-standard Bash. Returning an error rather than silently switching to cmd.exe preserves the operator's explicit shell:bash intent (cmd.exe would silently change shell semantics and break POSIX commands), demonstrably avoids launching any rejected PATH entry (no argv is produced), and gives the operator a single, named knob (shell_path) to opt in to a specific non-standard Bash.
  • Reversibility: high

Risks

• R1 compatibility: Changing required_checks.shell_path validation and precedence affects the environment profile contract and required-check subprocess invocation semantics.
  • Mitigation: Keep existing valid explicit shell configurations working, update generated and bundled schemas/docs/examples together, and add focused profile/result tests for old and new precedence cases.