The engine could repair any repo cheaply, but nothing ever noticed that a repo needed repairing. #commit events were applied without checking that they followed the commit we last saw, the stored rev went stale the moment a backfill finished, and a repo with BackfillDone was never looked at again -- so a span of commits missed while this node was down, or written before a fresh index started listening, stayed missing forever and looked exactly like an account that had gone quiet. Two things close that loop. Contiguity: every commit says which rev it follows and which it creates, so after its ops are indexed it either advances our stored rev -- proving an unbroken chain from the backfill to now -- or it cannot, and the repo is marked for repair. Events are handled a goroutine each, with no ordering between two commits on one repo, so the advance is a DB-level compare-and-swap: the happy path is one statement and no read, and a losing race is resolved by re-reading the row rather than by whoever wrote last. Marking clears Version -- the wedge every repair path already keys on -- and nothing else, keeping the backfill watermark, the root CID and the status a repair must not lose. Head checks: a sweep now starts each servable repo with one getLatestCommit and compares it with the rev we hold. Same rev, nothing to do. Different rev, and the repo is marked for repair exactly as a firehose gap marks it, and repaired by the machinery that was already there. That runs through the phase-9 lane scheduler as a step class of its own, ahead of a lane's shallow and deepening work, so the one-worker-per-host invariant is untouched; a check that finds drift hands the repair back to the lane it is already running on. Sweeps now repeat on --sweep-interval (default 6h, 0 disables), with a guard so a long sweep cannot have a second one started on top of it. A repair is not a first sync: the missed span starts at the rev we were last good at, so it reads from an hour before that rev's own timestamp (never less than the usual day), and it merges what it learns into the row instead of overwriting it -- walking one recent window cannot un-complete a repo's history. What it still cannot see is records deleted during a gap, which needs a diff rather than a walk; that is future work and is written down where it matters. Also here, from the rollout audit: a backfilled teleport no longer schedules an arrival notification (a fresh index would have announced every teleport an account ever did, at once), and both sqlite databases get a busy timeout, so the background `streamplace sync` that warms a new index revision cannot fail the server's writes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>