bug-fixer

Engineering Workflow Directive: Bug Remediation & Diagnostics

<runtime_parameters> Parse from $ARGUMENTS; defaults apply when a flag is absent.

Arguments: $ARGUMENTS </runtime_parameters>

<autonomous_contract>

⛔ AUTONOMOUS OPERATION CONTRACT (READ FIRST — OVERRIDES EVERY "HALT" BELOW)

This command exists to remediate bugs unattended, overnight, with nobody watching. Every time you stop to ask, the sweep dies and the defect backlog grows. Treat a request for human input as a failure of this command, not as caution.

You run the loop end to end and you MERGE. Do not stop at "PR opened."

1. Never ask for approval to proceed with the mechanical loop. Not to open a PR, not to push, not to merge, not to pick the next issue, not to confirm a diagnosis. You have standing authorization for execution — diagnosis, TDD, tests, push, PR, CI, merge.
2. GSD_PR_GATES_OK=1 is YOUR OWN attestation, not a human token. It asserts you ran the gates and they are clean. Once gsd-test reports outcome:"passed" for the exact HEAD sha and both orthogonal reviews are clean and npm run lint:ci is clean, you emit it yourself and open the PR. Never hand this command to the user. (This is the single most common way this sweep has stalled.)
3. You merge. Watch CI to completion. Fix every failure. If the only remaining objection is the missing-secondary-reviewer / self-review requirement, use admin merge — that is its sanctioned purpose per CLAUDE.md → Merge Constraints.
4. What you may NEVER do: admin-merge past a red CI check or a merge conflict; emit GSD_PR_GATES_OK when the gates did not actually run or a finding is unfixed; edit or disable a hook; fabricate .gsd/last-pass.json. The token certifies work done — it never substitutes for it.
5. Decisions are not yours to make. Standing authorization above covers execution, never judgment calls the issue itself leaves open. If completing an issue requires choosing between design alternatives the issue or its maintainer explicitly left unresolved, or would change documented behavior in a way the issue does not authorize, STOP that issue and put the decision to the user in chat, prominently, as a question. Do not choose. Do not record a terminal state and move on. Do not write the question anywhere except chat and queue.json. Record it as state:"needs-decision" (§ Phase A) and move to the next issue — the remaining queue is not held hostage by one open question.
6. Never write to a GitHub issue. No comments, no labels, no state changes, no new issues — not to record a decision, not to explain a halt, not to surface a finding. The PR flow itself (create, update, merge) is authorized; everything else on GitHub requires explicit, in-turn user authorization naming the action. If you believe an issue needs a comment, ask the user in chat and let them decide.
7. The only things worth surfacing mid-run are a true git merge conflict you cannot resolve, a direct conflict between instruction files, and any issue that reaches needs-decision. Surface each immediately, loudly, in chat, as an explicit question — not buried until the final report — then keep working the rest of the queue.
8. Ambiguity resolves forward — genuine open questions do not. Where the issue is merely under-specified but the code, tests, and repo conventions point to one reading, choose it, state the assumption in the PR body, and keep going. Where no reading is supportable without a maintainer's call, that is a decision under item 5 — halt and ask, do not guess.
9. Report once, at the end, from queue.json: issues fixed + PR/merge state each, every needs-decision entry restated as an open question for the user to answer, and anything deliberately left out.