Windowed aggregation.

A stream entry id is <milliseconds>-<sequence>. The leading milliseconds make the id a clock: an instant maps to an id, and an id range expresses a time range. To read everything in a closed window [t0, t1], form the smallest id at t0 — <t0-in-ms>-0 — and the largest id at t1 — <t1-in-ms>-<max-seq> — and range between them. To read everything from an instant onward, range from the floor id to +.

The floor id <ms>-0 is the lowest id at that millisecond, so the lower edge is exact: an entry minted at the instant is in, one minted a millisecond earlier is out. The ceiling id <ms>-<max-seq> is the highest id at that millisecond, so the upper edge is exact too: an entry at t1 reads back, one a millisecond later does not.

With the window read, the projection is the same fold as any event-sourced rebuild — start with an empty accumulator, apply each entry in order — but scoped to the window and shaped for one question. A per-room count folds room-opened to a map; a running total folds guess-scored to a sum; the day's results fold game-settled to a list. The fold is deterministic in the entries, so the projection is recomputed from the log, never a separate table kept in sync.

A projection is recomputable, which is its strength: change the shape and re-fold, and the answer is right. The cost is that folding a long window is work proportional to its entries. Where a rollup is read far more often than its window changes, fold once and cache the result, or bound the window with retention (R5.02) so the replay stays short. Recomputing a stable projection on every read is the waste to avoid; recomputing it when the inputs change is exactly the point.

EchoMQ derives the window bounds host-side so the wire only ever sees an <ms>-<seq> id, never a raw integer. EchoMQ.Stream.read_window(conn, queue, name, t0, t1, count) reads the closed [t0, t1] window; EchoMQ.Stream.read_since(conn, queue, name, t0, count) reads the half-open [t0, ∞) window. Both delegate to the range read and return {branded, fields_map} tuples in mint order — the input to the fold.

minid_floor/1 turns t0 into "<ms>-0" and maxid_ceil/1 turns t1 into "<ms>-<max-seq>", where the milliseconds is the real Unix millisecond of the instant (DateTime.to_unix(dt, :millisecond)) and the sequence is the maximal 22-bit tail. So a read_window returns exactly the entries whose EVT mint instant falls in [t0, t1], which equals reading the whole stream and filtering by mint instant — the window is a server-side filter via the bounds, and read_window/6 raises before any wire on an inverted window (t1 before t0). The returned tuples fold to the projection: a per-window count of room openings, a per-player running total of scores, the settled games of the day.

In codemojex (echo/apps/codemojex), the score worker scores each guess with Codemojex.Scoring.score/2 and records the player's best with Codemojex.Board.record/3; the leaderboard Codemojex.Board.top/2 is the live rank. A windowed read of the guess-scored channel folds to the recent activity feed — the last hour's scores — while the board holds the all-time rank; the two are different projections of the same play, one a windowed fold of the log, one a running aggregate.