Files
pad/cmd
xarmian 2e9ace4194 docs: nine overclaims across code, metrics, docs and the CLI (BUG-2739, codex round 5)
A cross-artifact pass, which is the angle that keeps paying on this family.
Every item below was a statement of mine that was false or unsupported; the
code did not change.

WRONG FACTS:
- Watch epochs are opaque UUIDs, not numeric generations. I had copied
  internal/events' wording, where they ARE numeric — the distinction is the
  subject of internal/idspace's package comment.
- undecodable_message was described as proof a notification was missed. The
  instance knows only that something it could not read arrived on its
  channel; it cannot tell whether that was ours. It stops vouching BECAUSE it
  cannot tell, which is a different and weaker claim. Corrected in four
  places.
- The failover-cost paragraph said every SSE client on the instance
  reconciles. Wrong twice: a watch-bus resubscription ends the WATCH stream's
  coverage (activity coverage is per-workspace), and the one client that uses
  that stream today — pad watch --stream — answers sync_required by clearing
  its cursor and keeping the connection open, so it issues no request at all.
  Verified in cmd_watch.go rather than assumed.
- The midstream/reset ratio is not fan-out in aggregate: the announcement
  counter also carries gaps and slow-subscriber drops and coalesces per
  connection. Only a reset observed in isolation reads that way.
- 'The watch stream's only signal was a later non-contiguous notification'
  is true for a client HOLDING A STREAM OPEN. A reconnecting client was
  always covered, because a resume asks the shared counter instead of local
  state. Scoped in the doc and in the test header.
- The dropped-confirmation fallback said coverage still ends. Usually, not
  necessarily: with no traffic during the outage nothing was lost, and if
  the drops continue through whatever would expose the hole and the stream
  goes quiet, nothing ever does — BUG-2727's boundary. Named both.
- The new Observer Close warning was overbroad: reports run on the receive
  goroutine only on the RedisBus receive path, while a ResumeGap runs on the
  caller's and MemoryBus has no such goroutine. The rule stays
  unconditional, since a callback cannot tell which case it is in, but it
  now says why.

STALE AFTER THIS BRANCH:
- metrics.go's WatchSequenceResetsTotal comment listed two reset reasons.
- observer_test.go said 'both reset reasons'.
- The constructor comment named Channel() after the loop moved to
  ChannelWithSubscriptions, and did not say the Receive beneath it is
  load-bearing for that loop having no skip-the-first flag. It does now, and
  names the test that fails if it goes away.
- cmd_watch.go's sync_required cause list predated BUG-2739 (and did not
  mention the mid-stream delivery BUG-2730 added).

Claude-Session: https://claude.ai/code/session_01JVDBKbgn3Xt7ndW1YoYd8X
2026-08-23 13:33:58 +00:00
..