Class ConvergenceClient

Corrections this client has reported since construction.

Whether a detected divergence is still being re-read.

The newest revision stamp received on any frame — test/observability surface.

The surface's honesty: can what is rendered be vouched for RIGHT NOW? nowMs defaults to the injected clock; the host polls this (or recomputes per tick) to drive the indicator.

One console-stream event — the ONE intake feeds every frame through here.

The board is now served by a DIFFERENT process — a new bootId under the same build, which only /console/build can say: the revision counter this client's own accounting watches is a plain commit count, not guaranteed lower on a fresh process than what this tab already saw, so heartbeat's own backwards-revision check misses exactly that case.

Forgets the ledger entirely — comparing it against the new process's rows would report the whole desk as "corrected", when nothing here was ever wrong, the process behind it is new — and heals through the SAME reconnect path streamOpened already falls back to: differences are adopted silently, never reported, and detect's "one heal at a time" gate still applies, so a caller that notices the same new boot twice heals once.

THIS client's own write, resolved: sent is exactly the delta it PATCHed, readback is the row's state exactly as THAT SAME request's own answer returned it — unambiguous, unlike a later frame off the stream, which might belong to a DIFFERENT commit (another client's concurrent write, or one of this client's own earlier writes still in flight) and which SSE gives no way to tell apart from this one. Call once the answer is known; never before.

sent's own fields are compared against readback: differ and the server clamped, dropped, or otherwise rewrote what this client sent — a correction it can vouch it caused, reported noticed: 'own-write', on the spot, no heal needed. Either way readback becomes the ledger's held state for the row, so a LATER heal never re-diffs the very divergence this call already reported (2026-09-01-http2-console-streams.md, amendment 2026-09-08). A row this client never calls this for is compared only by the general re-read arm below — or, on a reconnect, not at all.

The ledger — every row this surface holds, for whole-row-set equality assertions.

The transport dropped. Freshness is unconfirmable until a reopen completes.

The transport (re)opened. The first open's burst is the initial read; any later open — once a burst has actually landed clean at least once (hasSynced) — is a RE-read: rows that come back different from the ledger were wrong on screen and are reported as corrections (noticed as whatever triggered the heal, else reconnect).

An open that reopens the board BEFORE any read of this client's ever finished is never a re-read, whatever everOpened says: the ledger behind it was never confirmed truth, so a diff against it reports on the client's own unfinished homework, not a real gap (issue #824's boot storm — a race between the first burst still streaming and hardware settling right after fastify.listen, not a divergence any write path caused).