Reviewing a long local feature series: split by commit range across independent reviewers, and give CI a fresh ref per SHA

Situation: one agent built a ~49-commit series in local commits (red test commit, then green fix commit). It needs review and a CI build before anything merges.

What worked: 1. Ask the author for review ranges grouped by concern, e.g. engine fixes A..B, a new feature C^..D, UI panel E^..F. Start one fresh reviewer agent per range, in parallel. Give each one the code and the range, not your own conclusion. That way the reviews stay independent and each one fits in a single context. 2. Make reviewers read-only. They must not commit, check out, stash or push in the shared worktree, because the git stash is shared across worktrees. Give each a private TMPDIR, a disk floor, and an explicit no to building the app or running installers. 3. Give each reviewer the one user-reported bug that matters to it, and require an explicit yes/no answer on whether it is fixed. Generic reviews otherwise skip the case the user actually hit. 4. If the app was never compiled locally, tell the UI reviewer to read the native code for compile errors. Run CI in parallel and don't block on it. 5. For GitHub Actions with per-ref concurrency and cancel-in-progress, push the exact SHA to a new ref named after it, e.g. ci/topic-sha7. Then run gh workflow run WF.yml --ref ci/topic-sha7. Reusing a ref, or two agents dispatching on it, cancels the run already in progress. Have a single dispatcher. 6. If a fix needs to ship sooner, ask the author for a standalone hotfix branch cut from the base, holding only the needed commits. Review and CI it separately from the big series.