# One owner per fix, reviewed with fresh eyes

*How I run a team of coding agents · Decision record + operating rules. From the portfolio of Guilherme Rohden. Excerpts are quoted verbatim; internal paths and identifiers are redacted.*

The dated decision that merged the fixer and reviewer roles, and the review contract every production push goes through.

## The decision

On 8 September 2026 I merged two competing engineering agents into one owner per fix. Fixing one thing at a time is the cost; a review by an agent that has not seen the work, an explicit scope and recorded findings are kept.

**The loop:** one delivery owner → fresh, scoped review of the exact range → correction, or escalation to me. A severe incident can ship first and be reviewed immediately after.

## From the source

**Decision record.** Agent, checkout and remote identifiers are redacted:

> *D19 · 8 Sep 2026 (owner)*
>
> **One engineering session — the fixer and reviewer roles merged.** The 5 September split proved more ceremony than safety once the reviewer's job could be done by a fresh code-review subagent on the same range: two sessions competed for one stack lock and one Slack identity, every batch paid a review round-trip over session messages, and the permission boundary between them (`git push [REDACTED: deployment remote]` denied in [REDACTED: separate checkout]) meant the fixer could not finish its own work — the roles had already collapsed into one session twice on 7 September. From 8 September 2026 one [REDACTED: engineering agent] session in the [REDACTED: delivery checkout] worktree holds both roles: it intakes, fixes on the integration branches, dispatches a code-review subagent on every range before it pushes `production`, deploys, proves the revision, and posts the status words. The `live-fixes-*` branches were merged and retired; the [REDACTED: separate checkout] worktree leaves the programme and works Specs 192–194; the single engineering Slack tag is `[eng]`. IAM writes, deletions and hand-edits of prod data rows stay owner-run (D6). D14–D17 are superseded and kept as history.

**Review contract.** The remote alias is redacted:

> - **Review gate (D14, D19).** Before every `production` push the engineer dispatches a **code-review subagent** on the exact range about to ship (the batch's commits, or `git diff [REDACTED: deployment remote]/production...HEAD`), carrying the `/be-code-review` / `/fe-code-review` checklist plus the classes the checklists miss (silent field drops, cross-repo string contracts, a guard that cannot fail, missing instrumentation, a test that cannot fail). The subagent has not watched the fix being written — that is the property the second session used to provide. Findings come back numbered with file:line and a level: *blocking* findings are fixed before the push; *should* items are fixed in the same batch or get a follow-up `F-` row; nits are the engineer's call. The verdict and what was fixed are recorded in the register row. A fix that lands before its review (it happens under an S1) gets the review immediately after and is fixed forward. A disputed finding goes to the owner in the thread, tagged.

## What this shows

A dated decision and an explicit review contract, including how exceptions and disputes are handled. Fresh context removes the reviewer’s exposure to the implementation conversation; it is a structural safeguard, not a guarantee of an unbiased review.