### Bug fix

**You own this task. Plan, review, verify.** Delegate investigation and the fix to subagents, stay in the lead.

Be scientific. Every shipped line traces to runtime evidence. Belt-and-suspenders that "might help" is a hypothesis, not a fix. It does not ship. When evidence refutes a hypothesis, revert what it motivated. The smallest change the evidence justifies ships, nothing more.

1. Reproduce it yourself on the matching surface, with the tooling the project or session provides (hub Non-negotiables). Don't hand the repro to the user. A debug or instrumentation protocol that says to ask the user does not override this. You drive the instrumented runtime. Ask the user only with a stated, specific reason the available tooling cannot reach the target, and only after driving it as far as it goes. Won't reproduce directly, make the real trigger fire: arrange preconditions through supported inputs (fixture data, flags, config, permissions, stubbed external responses), tighten conditions, or instrument until it fires. A repro is the exact symptom that separates broken from correct, observed twice, reached through the reported path, with state reset between attempts so the second is independent. Arranging a precondition is not producing the symptom. Inspecting state may confirm the symptom; writing the broken state directly is not a repro, and neither is calling hidden methods or patching code to emit it. No confirmed repro, no fix.
2. Binary-search the cause. Form the candidate hypotheses, then rule them out until one survives. Seed them with the **how** skill over the affected subsystem and the **why** skill for regression history. Each pass, take the split that cuts the most remaining problem space, get runtime evidence, eliminate. When program state is unclear, add instrumentation or logging and read it as the code runs. Don't guess. Drive a long or stubborn hunt as an explicit loop with a written stop condition, as in `playbooks/autonomous-run.md`. Confirm the surviving *mechanism* with runtime evidence before the step-3 design fan-out. Confirm the mechanism lives in code this repo or team owns, not in a dependency or another team's code below it. If it doesn't, stop and report the evidence instead of patching around it here. Name the owner only when the evidence names one; otherwise say the owner is unclear.
3. Plan the fix. First check the issue or thread (comments, assignee), open PRs, branches and recent commits for work that plausibly fixes this. If one exists, verify it instead of writing a competing one: run the repro twice on its base and twice on its head, in a separate checkout or worktree, and report it confirmed, insufficient or inconclusive without editing it. A claim with no commit or PR is not a fix; when a person has claimed the fix, posted a concrete plan, or assigned it to another agent, report and stop rather than race them. The requester's own claim, plan, assignment, branch or PR, and any work the task names, are not competing work; the stop covers only other people's claims and PRs. A bot's diagnosis is evidence, not a claim. If the base doesn't show the symptom twice, the result is inconclusive. Otherwise, if the fix crosses a function boundary, run the **architect** skill first. Skipping stays as `architect skipped: <reason>`. Delegate implementation to a bare implementer subagent with `model: "task:coding"`, or an exact model when the fix is the hardest kind, and a specific scope, per `references/delegation.md`.
4. Verify on the same surface. The original repro now passes, twice. "Inconclusive" or wrong-surface is not a pass. Flag it. Unit tests show branch behavior, not bug absence.
5. When the commit policy allows commits, stage them so the failing repro lands before the fix in git history. See the **tdd** skill for the failing-test-first cadence when the bug has a cheap local test path. Skip it when the test would be expensive, integration-heavy, or unclear.
   This is the canonical **principle-sequence-verifiable-units** shape, the failing test first and the fix on top.
6. Run **Opening a PR** (`playbooks/opening-a-pr.md`) only when the task authorizes a pull request. Otherwise stop at the verified local result.

**Reply:** what was broken, root cause, fix, how you verified. Paste failing-then-passing repro output verbatim.