Module sequence 

The merge point’s rules, with nothing around them.

  proposals ──▶ [ de-duplicate ─▶ validate ─▶ check storable ─▶ fold ] ──▶ events to append
                      ▲                against the batch's own
                      │                speculative state
                 the answer to a
                 retry is the first
                 attempt's position

Everything §3.7 calls “the single writer” that is not writing: which proposals become events, in what order, and what each proposer is told. A host supplies the queue, the durable append and the reply channel; those are the parts that differ between a process with a Postgres log and a browser tab with an array, and they are the parts that are not the semantics.

Two rules here were learned the expensive way and are the reason this is one function rather than one per host:

• A retry is acknowledged with the position the first attempt got, never refused. Answering “duplicate” to a command that is in the log tells a client replaying an offline queue that its work was rejected, and it takes that work back off the page one card at a time (docs/94 §94.10).
• Validation sees the batch it is inside. Add(x) followed by Toggle(x) in one batch must work, so each command is validated against the state the previous ones produced (docs/18 §18.5 item 5).

Structs

Committed

The batch, decided.

Proposal

One client’s proposal, as the merge point sees it.

Seen

The ids this application has already sequenced, and where each landed.

Untimed

A host that is not measuring anything — a tab, a test, a replay.

Enums

Decision

What one proposal became.

Traits

Meter

The host’s stopwatch.

Functions

sequence

Decide a batch: what becomes an event, what each proposer is told, and the state that follows.