Start a watch at its own start, not at HEY's cursor

AGENTS.md

@@ -679,13 +679,36 @@ says (`--box` picks the boxes whose changes are reported; every box is followed)
 posting recorded as soon as it is classified. The
 start is the Date header translated back to when the request was made (mail that lands while
 the server answers is later than the start), it is taken before the box list, and each
-box's cursor starts no later than it (`noLaterThan`): the server bakes the box's last posting
-activity into the cursor, so mail that landed in between would otherwise sit behind the
-cursor, read by nothing. That
+box's cursor starts at it (`watchStartSince`), keeping only the version from the box's
+`posting_changes_url`. The since HEY puts there is not its clock but the box's last posting
+activity (`Box#last_posting_activity_at`: unbundled postings only, the box's own `updated_at`
+when it has none), and the feed answers deletions and bundled postings later than that; and
+`/boxes.json` comes through the SDK's ETag cache with an ETag of the box rows alone, which
+posting activity does not touch, so a 304 serves the since as it was when the list was
+cached. A read from HEY's since reported history as news on every start, and a since later
+than the start would leave mail that landed in between behind it, read by nothing. A watch
+that cannot read HEY's clock does not start: the workstation's clock is no stand-in for a
+cutoff every feed and new mail are measured against, since a fast one would skip changes and
+a slow one would report history. That
 is HEY's semantics and state across events, so the CLI decides it once; what to do about
-it is the reader's. A 409 skip-ahead sets that box's floor at the cursor it skipped to
+it is the reader's. The Date header is whole seconds, so the start can be up to a second
+(plus the clock request's whole time, retries included) early and a change from that window
+is reported. Nothing HEY serves on demand says the time finer — Action Cable pings are
+whole seconds too; a posting doorbell's `at` and the feeds' cursors carry microseconds, but
+only once something has changed, never as a "now" before the watch starts — and rounding
+the other way would skip changes. A 409 skip-ahead moves the cursor to HEY's clock when it
+answered (`serverNowAnswered` — not taken back by the request's time, since a resync has
+no gap to catch and a slow request could leave a busy feed still behind), keeping the feed
+version from a list read past the SDK's cache (`newUncachedSDKClient`: the list's ETag is
+its rows, which neither posting activity nor a new feed version changes, and HEY answers
+409 for a version it no longer speaks), and sets that box's floor there
 (`newMail.skippedTo`): activity at or before it is never new there, known thread or not,
-because the watch never read the gap. `resync` is an event of its own — reported by default,
+because the watch never read the gap. The first skip is read from straight away; a 409
+after it is the same recovery (`feedRecovery`), and the next skip waits on the retry
+backoff rather than every doorbell. The recovery's one resync goes out with the clean read
+that ends it, at the last skip, so a reader that re-reads on it has missed nothing a later
+skip passed. A list or clock read that fails is retried on that backoff, and an
+interrupt during one ends quietly (`skipFailed`). A calendar's 409 skips the same way. `resync` is an event of its own — reported by default,
 left out by `--events new` — so a script for new mail never runs on one. The Omarchy bar plugin toasts from those lines itself (app-name, glyph,
 click-to-focus and the replace-not-stack id all live in the plugin), and nothing
 desktop-shaped lives in `watch*.go`.
@@ -785,11 +808,11 @@ watch that is down costs staleness, not a notice.
 `hey watch` follows the same streams on its own connection and reports the changes
 themselves (`internal/cmd/watch_calendar.go`). Rings are coalesced per calendar for
 `calendarCoalesceDelay`, then the calendar's recording feed is read from its cursor
-(`Calendars().AllRecordingChanges`, cursors capped at the watch's start like the boxes' —
-`calendarCursorNoLaterThan`) and each recording is a `recording_added`, `recording_updated`
+(`Calendars().AllRecordingChanges`, cursors starting at the watch's start like the boxes' —
+`calendarCursor`) and each recording is a `recording_added`, `recording_updated`
 or `recording_deleted` line naming its calendar where a mail line names its box. The poll
 reports `calendar_added`, `calendar_updated` and `calendar_deleted`, and a recording feed's
-409 is `calendar_resync` after skipping ahead to a fresh cursor from the list. The
+409 is `calendar_resync` after skipping ahead to HEY's clock, as a box does. The
 email-specific flags switch all of it off — `--box`, or an `--events` list naming only
 mail changes (`watchingCalendars` in watch_calendar.go) — and `ready` waits for the
 calendars' catch-up exactly as it waits for the boxes', on the same retry backoff and the

docs/cli.md

@@ -336,15 +336,22 @@ hey watch --box imbox --events new --run-async 'notify-send -a HEY "New mail in
 hey watch --run-sync ./triage.sh        # one at a time, waiting for each
 ```
 
-Runs until interrupted, printing changes as they happen, one line each:
+Runs until interrupted, printing changes as they happen, one line each. What changed before
+the watch began is not reported unless `--since` reads back to it first, so
+`--exit-on-first` waits for a change rather than stopping on an old one. When the watch began
+is read off HEY's clock, and a watch that cannot read it exits with an error rather than
+guess. That clock is read to the whole second and taken back by however long the request
+took (retries included), so a change from up to a second before the watch began, plus that
+request's time, can still be reported (and be new, and end `--exit-on-first`); its `at` says
+when it happened. Rounding the other way would skip changes that came after:
 
 ```json
 {"change":"added","at":"2026-08-18T09:14:22.031Z","box":{"id":24088,"kind":"imbox","name":"Imbox"},"posting_id":98765,"thread_id":54321,"new":true,"posting":{}}
 ```
 
 Every `added` and `updated` line says whether the posting is new mail: unseen, not muted,
 and active since the watch last saw the thread — or since the watch began, for a thread it
-has not seen, so a box's backlog is never new. Reading, muting or moving a thread is not new
+has not seen, so the backlog `--since` reads is never new. Reading, muting or moving a thread is not new
 activity; a reply on a known thread is. `--events new` selects the new ones, alone or in a
 union with `added`, `updated`, `deleted` and `resync` — the default is everything but `new`,
 and `new` alone leaves a `resync` out, so a script for new mail never runs on one. `--box`
@@ -359,7 +366,9 @@ calendar — `{"change":"recording_added","calendar":{"id":512,"name":"Household
 "recording_id":88001,"recording_type":"Calendar::Event","recording":{}}` — and a calendar
 arriving, changing or leaving is `calendar_added`, `calendar_updated` or
 `calendar_deleted`. A calendar whose feed fell too far behind is skipped ahead and says so
-with `calendar_resync`, the way a box says `resync`. The email-specific flags switch the
+with `calendar_resync`, the way a box says `resync`. Either is said once per catch-up, when
+the feed can be followed again: a feed still too busy after the skip is skipped again on the
+retry backoff, and the line's `at` is the last skip. The email-specific flags switch the
 calendars off: `--box` scopes the watch to mail, and an `--events` list naming only mail
 changes does the same.
 

docs/omarchy.md

@@ -191,15 +191,21 @@ and `--events new` selects the true ones. The rule:
   watch last recorded for the thread — or later than the watch's start, when it has no
   record. That start is read off HEY's own clock (the `Date` header of one request,
   translated back to the moment the request was made), the clock every `active_at` is on,
-  so a workstation running fast or slow neither calls the backlog new nor sits on new mail;
+  so a workstation running fast or slow neither calls the backlog new nor sits on new mail
+  (a watch that cannot read HEY's clock exits with an error rather than use its own);
   whole seconds, rounded down, so the doubt falls on the side of calling mail a moment old
-  new, and every box's cursor starts no later than that start, so mail that lands while the
+  new — mail from up to a second before the watch began, plus however long the clock request
+  took (retries included), can read as new — and every
+  box's cursor starts at that start, so mail that lands while the
   watch is starting up is read and is new. `active_at` moves on new mail only, not on a
   seen flip, a mute or a move, so reading a thread, marking it unseen again or moving it
-  into a box is never new, and a reply on a known thread is. A box's first read is its
-  catch-up from the server's cursor — the box's last activity, not this moment — so it
-  carries backlog, which the start-time rule keeps out, alongside anything that arrived
-  while the watch was starting, which is new.
+  into a box is never new, and a reply on a known thread is. A box's first read starts at
+  the watch's start, not at the server's cursor — the box's last posting activity, which a
+  deletion or a bundled posting can postdate, and which a cached box list can serve days
+  old — so it carries what arrived while the watch was starting, which is new, and at most
+  the whole-second window above: a change from just before the start that the start could
+  not be told apart from. `--since` reads backlog first, which the start-time rule keeps
+  out.
 - **Every posting the watch reads is recorded**, in every box and whatever `--events` or
   `--box` reports — `--box` picks what is reported, every box is followed — so a thread
   known from a filtered-out change, or from another box, is never mistaken for new when its
@@ -211,8 +217,8 @@ and `--events new` selects the true ones. The rule:
   is new. `hey watch --box imbox --events new --exit-on-first` is "block until new mail", and
   a `--run-*` script sees `HEY_NEW=1` or `HEY_NEW=0`.
 - **A skip-ahead sets a floor.** A box that answered 409 was never read across the gap, so
-  the cursor it skips to — the box's last posting activity — becomes that box's floor:
-  activity at or before it is never new there, on a thread the watch knows or one it does
+  the cursor it skips to — HEY's clock when the skip read it — becomes that
+  box's floor: activity at or before it is never new there, on a thread the watch knows or one it does
   not, so a reply the watch missed and then a move while still unseen is not new mail. Mail
   after the floor is. The floor is the box's own; a gap thread moved to another box is
   measured there and may read as new once — the `resync` line is the cue to re-read.

internal/cmd/sdk.go

@@ -136,6 +136,23 @@ func newSDKClient(extra ...hey.ClientOption) *hey.Client {
 	return hey.NewClient(sdkClientCfg, nil, opts...)
 }
 
+// newUncachedSDKClient builds a sibling of sdk — same configuration, same account —
+// without the response cache, for a read a 304 must not answer. The cache revalidates
+// on HEY's ETag, and an ETag can cover less than the body: /boxes.json's is the box
+// rows, so a box's posting_changes_url, feed version and all, can change under it.
+// The SDK has no per-request way past its cache, so this is a client of its own.
+func newUncachedSDKClient(ctx context.Context) (*hey.Client, error) {
+	uncached := *sdkClientCfg
+	uncached.CacheEnabled = false
+	uncached.CacheDir = ""
+	client := hey.NewClient(&uncached, nil, sdkClientOpts...)
+
+	if accountID, scoped := sdk.AccountID(); scoped {
+		return client.ForAccount(ctx, accountID)
+	}
+	return client, nil
+}
+
 func selectConfiguredAccount(ctx context.Context) error {
 	client, err := clientForAccountSelection(ctx, rootSDK, cfg.AccountID)
 	if err != nil {