Code Bugfix Workflow

Proactively review recent author-owned diffs, fix confirmed regressions minimally, and leave reproducible proof for every fix or no-op.

The code-bugfix automation implements the "bugs in your own diffs" discipline on a daily cadence. It is not a general cleanup loop. A finding belongs here only when the root cause maps directly to Kevin's recent changes. Source: automations/code-bugfix.md, 2026-05-31

Routing

Use this workflow when the question is "did my recent changes introduce a bug?" Use normal feature/refactor workflow for planned work, Security Scan Workflow for vulnerability hunting, and Daily Work Summary Workflow for summarizing shipped work.

Trigger

  • Daily automation from automations/code-bugfix.md.
  • Manual request after a risky merge, production report, test failure, or "review my last commits."
  • A target repo must be explicit or discoverable from the current workspace.

Inputs

  • Target repo and author identity.
  • Recent commits, usually last 24-48 hours: git log --author=... --since=....
  • Diffs for those commits and surrounding code for touched files.
  • Existing tests, reproduction steps, CI failures, or production symptoms when available.

Scope Invariant

Every bug candidate must identify:

  • the commit or diff hunk that introduced it
  • the affected behavior
  • a reachable execution path
  • the smallest honest verification

If the issue is pre-existing, speculative, cosmetic, or unrelated to the recent author-owned diff, report it as out of scope instead of fixing it here.

Runbook

  1. Inspect the target repo status and recent commits without discarding anyone's work.
  2. Read each author-owned diff and the relevant surrounding code.
  3. Prioritize auth, billing, webhooks, data integrity, agent harnesses, migrations, generated outputs, and externally visible behavior.
  4. For each confirmed bug, write the reproduction in plain language before editing.
  5. Implement the minimal fix. Avoid drive-by refactors and style churn.
  6. Add or update the smallest useful regression test when the harness supports it.
  7. Run the targeted verification, then record command output and any remaining risk.

Output

For each finding, report root cause, commit/file, fix, verification, and follow-up risk. If no bugs are found, name the commits and risk areas reviewed. Significant incidents should draft or update a postmortem under wiki/postmortems/.

Validation

The workflow is complete only when each fixed bug has a reproducible check. "Looks right" is not enough. If verification cannot run, state the exact blocker and leave the fix unclaimed as unverified.

Run Contract

This workflow follows Workflow Run Contract: name the sources, write output or no-op proof, promote only durable facts, update state only when the run really completed, refresh generated surfaces when durable pages or skills change, and log user-visible work.


Timeline