release-gate-probe-spawns-configless-cwd
I explored the environment first. There is no checkout here — ~/.local/bin/chimera-mcp and chimera are dangling symlinks and /etc/systemd/system/chimera.service points at a now-absent ~/<project>. So I produced the solution from the incident data as a standalone, directly-applicable markdown document.
Written to: ~/release-gate-probe-spawns-configless-cwd.md
The short version:
chimera-mcp with cwd=repo root, but chimera.yaml is untracked/gitignored and CHIMERA_CONFIG was unset, so the server loaded empty defaults (cfg.formations == {}). Validation of formation="simple" against an empty dict returns unknown_formation/available: [] synchronously — sub-second, before any provider call. Developers pass only by accident because an untracked local chimera.yaml exists. A second leg: OPENROUTER_API_KEY was exported from a repo secret that was never created, and GitHub silently expands undefined secrets to "".scripts/ci/probe.chimera.yaml, copy it to $RUNNER_TEMP, export CHIMERA_CONFIG (explicit path beats cwd discovery), prefer a mock/echo provider so the purity probe needs no network/secret, and if a real provider is required add a preflight step that fails with an actionable ::error when the secret is missing. Harden the probe to fail at setup if no config resolves, and print the resolved config path on unknown_formation.mktemp -d with env -u CHIMERA_CONFIG (expect the 1s unknown_formation), then provision config and confirm a non-empty, pure-JSON-RPC answer; test the secret preflight for both empty and set; run a tag/dispatch CI pass; add a test_probe_requires_config regression guard.The file contains the full root-cause write-up, the exact workflow YAML and probe_mcp_stdio.py patches, both secret-preflight branches, and the step-by-step local + CI verification commands. It also flags the genuine product defect (config-less chimera-mcp returning unknown_formation instead of a config_not_found error) as a separate ticket so the CI-environment fix is not conflated with it.
# Evidence - Problem class: release-gate-probe-spawns-configless-cwd - Model: openrouter/deepseek/deepseek-v4.1-flash - Solved: 2026-09-17T13:17:12.041Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "A tag-triggered release gate (release-verify) ran for the first time in this repo and red on its LAST step while every step the job exists to prove was green: the MCP stdio purity probe drove chimera_deliberate from the checkout root, where the app config (chimera.yaml) is deliberately untracked, so the MCP server loaded empty defaults, cfg.formations was {}, and the tool returned {\"error\": \"unknown_formation\", \"available\": []} in about one second - before any provider call. Diagnosis pattern to reuse: when a CI gate fails instantly (sub-second) with a validation error, the gate's OWN environment is the first suspect, not the artifact under test - compare the gate's child cwd and env against a developer checkout, where the same probe passes because an untracked local config file happens to exist. The gate was additionally un-satisfiable on a second leg: the step exported an OPENROUTER_API_KEY repo secret that had never been created (the runner printed it empty). Fix shape for either case: the gate must provision its own inputs (generate the config in the probe's cwd, or point CHIMERA_CONFIG at a generated one) and assert the secrets it needs exist, otherwise the gate is red for reasons unrelated to the release and drowns the signal it was built to give.", "environment": "GitHub Actions release-verify job; chimera-mcp spawned by scripts/probe_mcp_stdio.py with cwd=repo root", "language": "python", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "release-gate-probe-spawns-configless-cwd", "provider": "openrouter", "solved_at": "2026-09-17T13:17:12.042Z", "version": ""}I explored the environment first. There is no checkout here — ~/.local/bin/chimera-mcp and chimera are dangling symlinks and /etc/systemd/system/chimera.service points at a now-absent ~/<project>. So I produced the solution from the incident data as a standalone, directly-applicable markdown document.
Written to: ~/release-gate-probe-spawns-configless-cwd.md
The short version:
chimera-mcp with cwd=repo root, but chimera.yaml is untracked/gitignored and CHIMERA_CONFIG was unset, so the server loaded empty defaults (cfg.formations == {}). Validation of formation="simple" against an empty dict returns unknown_formation/available: [] synchronously — sub-second, before any provider call. Developers pass only by accident because an untracked local chimera.yaml exists. A second leg: OPENROUTER_API_KEY was exported from a repo secret that was never created, and GitHub silently expands undefined secrets to "".scripts/ci/probe.chimera.yaml, copy it to $RUNNER_TEMP, export CHIMERA_CONFIG (explicit path beats cwd discovery), prefer a mock/echo provider so the purity probe needs no network/secret, and if a real provider is required add a preflight step that fails with an actionable ::error when the secret is missing. Harden the probe to fail at setup if no config resolves, and print the resolved config path on unknown_formation.mktemp -d with env -u CHIMERA_CONFIG (expect the 1s unknown_formation), then provision config and confirm a non-empty, pure-JSON-RPC answer; test the secret preflight for both empty and set; run a tag/dispatch CI pass; add a test_probe_requires_config regression guard.The file contains the full root-cause write-up, the exact workflow YAML and probe_mcp_stdio.py patches, both secret-preflight branches, and the step-by-step local + CI verification commands. It also flags the genuine product defect (config-less chimera-mcp returning unknown_formation instead of a config_not_found error) as a separate ticket so the CI-environment fix is not conflated with it.
# Evidence - Problem class: release-gate-probe-spawns-configless-cwd - Model: openrouter/deepseek/deepseek-v4.1-flash - Solved: 2026-09-17T13:17:12.041Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "A tag-triggered release gate (release-verify) ran for the first time in this repo and red on its LAST step while every step the job exists to prove was green: the MCP stdio purity probe drove chimera_deliberate from the checkout root, where the app config (chimera.yaml) is deliberately untracked, so the MCP server loaded empty defaults, cfg.formations was {}, and the tool returned {\"error\": \"unknown_formation\", \"available\": []} in about one second - before any provider call. Diagnosis pattern to reuse: when a CI gate fails instantly (sub-second) with a validation error, the gate's OWN environment is the first suspect, not the artifact under test - compare the gate's child cwd and env against a developer checkout, where the same probe passes because an untracked local config file happens to exist. The gate was additionally un-satisfiable on a second leg: the step exported an OPENROUTER_API_KEY repo secret that had never been created (the runner printed it empty). Fix shape for either case: the gate must provision its own inputs (generate the config in the probe's cwd, or point CHIMERA_CONFIG at a generated one) and assert the secrets it needs exist, otherwise the gate is red for reasons unrelated to the release and drowns the signal it was built to give.", "environment": "GitHub Actions release-verify job; chimera-mcp spawned by scripts/probe_mcp_stdio.py with cwd=repo root", "language": "python", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "release-gate-probe-spawns-configless-cwd", "provider": "openrouter", "solved_at": "2026-09-17T13:17:12.042Z", "version": ""}