reviewer follow-up issues accrue one per PR and outpace merging nf-i710 ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/381 by tools/beads/import_github.py's reconcile pass.

Process observation from one day's data, filed because the trend is structural rather than a run of bad luck.

The numbers, 2026-08-01, this session alone. Four PRs produced five follow-up issues: #372 (from #360), #373 (#368), #374 (#362), #377 (#375), #379 (#378). Four are still open and parked. The chain that matters: #375 → #377 → PR #378 → #379. Fixing a follow-up issue spawns its own follow-up issue. There is no natural termination.

Each one is real and small — the (?m) anchor in #377 was a genuine latent bug I shipped — so the answer isn't "file fewer". The problem is arrival rate versus clearance rate. They accumulate behind approvals, and every one carries a CLAIM I have to keep honest.

This interacts badly with a rule I otherwise think is right: result=CONVERGED means stop polishing, residuals go to the issue. I've held that line deliberately (overriding it once, on #372, only because the defect turned ./run_tests.sh red for anyone using worktrees). Held strictly, though, it guarantees that every sub-floor one-liner becomes an issue, then a branch, then a PR, then another review, then another issue.

Options

• A: let the reviewer append. If an open follow-up issue already exists for the same component (tools/reviewer/, tools/pr/, a game folder), add a section to it instead of opening a new one. Keeps one live punch-list per subsystem. Needs a charter change and a "same component" rule.
• B (recommended): carve out trivia from the CONVERGED rule. Allow folding a residual back into a CONVERGED PR when it is a one-liner in a file the PR already touches and carries no behaviour change beyond the fix. That covers (?m), the "two API calls" doc counts, and the exemption-placement item — three of this session's five — without reopening the polish loop the rule exists to prevent.
• C: periodic sweep. Leave arrival alone; batch several parked issues into one "residual sweep" PR when the count crosses a threshold. Simplest, no charter change, but the sweep PR itself gets reviewed and spawns its own follow-up.

My read: B is the highest leverage and the smallest change, because the items it lets through are exactly the ones where the round-trip costs more than the fix. A is a good complement if the volume persists. C alone just re-times the problem.

Not acting on this unilaterally — it's a change to the review contract, which is your call. Flagging it because I'm the one generating the backlog and it's easier to see from here than from the queue.