Files
xarmian 736a8c48f7 docs: thirteen claims about code that had moved under them (BUG-2736)
Codex round 5, cross-artifact consistency. Every one was a claim in a comment,
help string, doc, or test name that the code no longer supported — and this
diff created most of them by moving the code.

The ones that would have misled an operator:

- pad_event_sequence_resets_total documented ONE reason in both the Go doc
  comment and the Prometheus help text, and the deployment table said the same.
  It has emitted three since this branch. An operator reading the help string
  to build an alert would have alerted on a third of the signal.
- deployment.md said every published message carries an epoch prefix. Phase 1
  publishes bare JSON — which is the entire point of having two phases.
- deployment.md said the first flipped message reaches each replica and every
  resuming client gets sync_required. A replica learns the epoch only from a
  message it RECEIVES, so only replicas subscribed to a workspace with traffic
  see it; and a replica with empty buffers adopts without dropping or
  counting, deliberately.
- deployment.md said a restart's IDs cannot collide. internal/idspace documents
  a bounded case — the earlier process publishing more than 2^20 events per
  millisecond of its life. Stated as the bound it is, with the
  backwards-clock direction named as the safe one.
- cmd_watch.go described sync_required as eviction-only. It has had four other
  causes since BUG-2731 and gained a fifth here.

The ones that would have misled the next person editing this code:

- bus.go said the Redis half was unwritten and a reset counter could still
  merge two ID spaces. It is written, three commits back on this branch.
- bus.go and watchevents.go said in-memory IDs restart from 1. They count from
  an incarnation base.
- redis_bus.go described this bus's epoch as an opaque uuid equivalent to the
  watch bus's, twice, after round 3 made it a Redis-minted generation. Only
  the watch bus still uses uuids.
- observer.go said counter_backward happens only during mixed-version rolls.
  Phase 1's two-call publish produces it in steady state too.
- redisns.go said the publish script spans four keys (it is five here now, plus
  a two-key assign script), and its hand-kept reserved-name inventory never
  gained event_epoch or event_epoch_gen — so a namespace equal to either would
  have nested one installation inside another's keyspace unrefused.
- A test comment referenced idIncarnationShift, which moved to
  internal/idspace.Shift when the package was extracted.
- Two tests called themselves process-restart tests while constructing
  successive buses in one process. They test bus incarnations; the comment now
  says so and says why that is the equivalent thing.

And one reasoning error rather than a stale fact: the counter-backwards branch
justified raising the floor by asserting the arriving ID is necessarily in the
SAME numeric space. It is not — a phase-1 counter reset publishes low IDs with
no epoch to explain them, which is a NEW space we cannot see. The behaviour is
unchanged and still correct (the lead's day-52 ruling: raise unconditionally,
prefer a loud bounded resync loop to a silent skip), but it now says what it
actually knows, which is nothing, and names the cost on a real phase-1 reset.

Claude-Session: https://claude.ai/code/session_01JVDBKbgn3Xt7ndW1YoYd8X
2026-08-22 19:28:17 +00:00
..