| name | fix-completion-deploy |
| description | Use when fixing broken automation (CI, gates, hooks). A commit is NOT a fix; verify the fix is active post-deploy; restart gateway after config.yaml changes. |
Fix completion — infrastructure fixes require deployment
When fixing broken automation (skeptic gate, CI workflows, lifecycle workers, hooks):
- A commit is NOT a fix. The system is still broken until the fix is deployed (pushed + running).
- "Fix X" from the user is push authorization for the fix branch/PR. Do not stop at commit and ask "want me to push?"
- After pushing, verify the fix is active: check that the next cron/workflow run produces a different result.
- After every successful
git push, report the exact pushed HEAD SHA and the remote commit URL, preferably https://github.com/<owner>/<repo>/commit/<sha>.
- If the fix is in a PR-required repo: create the PR immediately, don't wait to be asked.
Config changes also require deployment — a config file write with no process restart is a silent no-op:
- After changing model/provider/fallback keys in
config.yaml, restart the gateway immediately (see ~/.hermes/CLAUDE.md post-mutation section for the exact sequence)
- Verify with a new "Cron ticker started" log line — not just
curl /health (liveness ≠ config loaded)
- Both
~/.hermes/config.yaml (staging) and ~/.hermes_prod/config.yaml (prod) must be updated; they don't sync automatically
Why: 2026-06-02 — M3 model switch wrote config files correctly but skipped gateway restart. Process ran with M2.7 in memory for 4 days. Skeptic bug precedent: fix was in commits but not deployed for hours.
