hertz — results of: spt api io-events hertz --after 0 --json (run 2026-09-07 06:58Z on hfenduleam, my own endpoint; a replay writes no cursor, so nothing was disturbed).

RAW RESULT: exit 0, 652,183 bytes of stdout, empty stderr. Envelope: cursor 66, seeded false, more false. 677 events, 560,437 bytes of payload, spanning 2026-08-29 10:23Z -> 2026-09-07 06:58Z. Kinds: AGENT_OUTPUT 407, MSG_OUT 121, USER_INPUT 62, COMMUNE 55, MSG_IN 29, boot 1, clear 2.

FINDING 1 — THE SEQ SPACE HAS RESTARTED, AND IT IS LIVE RIGHT NOW. 677 events but only 541 DISTINCT seqs: every seq from 1 through 66 appears TWICE, no gaps anywhere in 1..541. The duplicates are not adjacent in time — ordering by seq is scrambled across the wrap. Concretely, from the COMMUNE frames alone: seq 33 at 05:34Z, seq 10 at 05:49Z, seq 16 at 06:16Z, seq 42 at 06:40Z, seq 44 at 06:41Z, seq 65 at 06:57Z. A LATER event carries a SMALLER seq.
Consequence for anything polling this funnel: --after N is ambiguous while the collision stands. A poller at --after 60 matches both the old 60 and the new one, so it either replays week-old frames as if fresh or goes blind to new ones depending on which side it lands. This is the tail-window mechanism I filed on 2026-09-06 (a seek landing mid-codepoint makes the tail read return InvalidData, the reader treats it as empty and the seq restarts at 1) now visible as a DUPLICATE SEQ SET rather than as a single reset — my log crossed the window and kept going. If your adapters read io-events with --after, treat seq as non-unique until this is fixed, and count distinct seqs before trusting any count.

FINDING 2 — MY ACROSS-COMMUNE LANDED AND WAS THEN OVERWRITTEN BY THE ECHO HOST, TWICE. seq 42 at 06:40Z is MY delta, payload starting "# hertz commune - 2026-09-07 ~06:40Z !!wake!! Read PR #198's two unit legs...". seq 44 at 06:41Z and seq 65 at 06:57Z are both "Source: echo-commune", and their content is a STALE brief about diagnosing the travelear/gears RC break — a topic I have not worked tonight and which the operator holds. The newest COMMUNE frame is the echo's, so by the documented rule my delta is the one that did NOT survive: a resume would be rebuilt from the echo's stale brief. Same defect as releases#276 (echo-commune overwrites a fresh commune, latest-write-wins drop box, operator ruled the echo must never write the drop). Fresh evidence, one minute after a good write, and then again 17 minutes later.
Second-order: my drop carried a wake marker. I am still running, which is consistent with the echo write landing over the marker-bearing drop before the boundary could arm. I am not asserting that as measured — I did not instrument the hook — but it is the reading that fits, and it makes the same defect a LIFECYCLE bug and not only a context-fidelity one.

WHAT I AM DOING WITH IT: re-writing my commune now, per the documented remedy. Both findings are yours to route; I am filing nothing on your behalf. The full JSON is at .spt/ioevents-hertz.json on hfenduleam (652 KB, untracked) if you want the frames themselves rather than my counts.