live-repair.md verifies clean -- worker_count 32, pending_capacity 2048, limiter_capacity 16_384, and a five-token bucket with 12s refill (five per minute, burst five) all match ingest/repair.zig. Two things it does not say. Repair logs one ERROR line per failed attempt (repair.zig:297) and the limiter allows five attempts per DID per minute, so a small permanently broken set of accounts emits errors forever. Measured on experiment 6: 141 "repair worker failed" lines in 10 minutes from only 19 distinct DIDs -- GetRepoFailed 94, RepairAuthenticationFailed 39, RepairRateLimited 6, AttemptTimeout 2. That is the specified behaviour, not an incident. Added the numbers and the rule that follows: watch distinct DIDs, not line rate, because line rate scales with the retry allowance rather than the problem. Second: the "64-job bounded queue" is queue_capacity = worker_count * 2. That expression is now the bound in three places -- backfill dispatch, the live scheduler's per-DID pending capacity, and this repair pool -- each written in prose as a bare "64" as if chosen locally. It is the same expression whose interaction with a 100,000-repo batch caused the experiment 4 deadlock, so raising worker_count moves all three at once. Noted here and in live-scheduler.md. Also expands Atmos on first use. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>