In the
Step

A Durable commit runs on the Session's line from start to end. Inside, #runCommit hands the batch to the storage with an adopt callback, waits for it, and only then publishes:

// session.ts, #runCommit, at HEAD (simplified)
const adopt = (seq: Seq): void => {
  adoption = { documents: tx.adopt(seq) };          // trackers swap to the new values
};
seq = await this.#storage.commit(writes, adopt, context);
// ... back in the Session, after R:
this.#publish(seq, writes, documents, context);      // telemetry events, internal observers, host listeners
return result;                                       // C

The SQLite storage calls adopt right after COMMIT returned. JSONL calls it and then still awaits its own cleanup of sidecar files before it resolves:

// jsonl/storage.ts
adopt(seq);                                           // A
await this.reclaimSidecars(reclamations, context);   // still inside Storage.commit
return seq;                                           // R

Two things follow. A host listener always runs before any watch listener of the same commit: the observers queue the watch deliveries as microtasks, and the host listeners run synchronously right after them. And nothing is published until the storage is completely done.

The tear

Chord follows a Durable view through its watch. Two views mean two watches, and each delivers in its own microtask:

const status = self.derive([conversationView, taskGraph], ([view, graph]) => ({
  last: view.entries.at(-1)?.kind,
  running: graph.tasks.filter((t) => t.status === "running").length,
}));

commit 41 (entry + task)
  microtask 1: view watch delivers 41   → derive: last "toolCall", running 0    ← never existed
  microtask 2: graph watch delivers 41  → derive: last "toolCall", running 1

The phone receives both. Chord's rule W1 says a commit changes its sources inside one step and the derives over them recompute once, right after. For Durable's views that means: they must change inside adopt, and Chord must follow them as sources marked there, not through watches.

Why after is not good enough for the store

In Chord's store, Durable's storage (StoreStorage) runs adopt inside the store's commit step, and the step lets the next owner's commit start as soon as adopt returned. Durable's #publish runs later, after its await. In between, a Chord object's commit can adopt, flush and recompute a derive that reads a Durable view still at 40. The owner ruled out the alternative, a store that waits for Durable's continuation: no Durable special cases in the store.

The first build moved Durable's internal observers into adopt and left the rest of #publish (host listeners, telemetry events) after R. To keep host code from waking too early, it added afterPublish(callback): observers queue what wakes a host (resolving a wait, aborting a run, onWake), and the queue runs after the host listeners.

const adopt = (seq: Seq): void => {
  const documents = tx.adopt(seq);
  this.#observeStored(seq, writes, documents);       // internal observers, inside A
};
seq = await this.#storage.commit(writes, adopt, context);
this.#publish(...);                                    // host listeners, after R
this.#settle();                                        // afterPublish callbacks

Durable's state (views, the scheduler's idle state, the metric counts) now changes at A. Hosts hear about it at H, after R. Everything that runs in between sees a commit that is half published. Four reviewers found four ways that shows, each reproduced with a probe.

HEAD:        A … R → H → watch
first build: A (watch queued) → watch → R → H

harness.subscribeCommits((p) => seen.push(p.seq));
// a task-graph watch listener runs in the gap:
await harness.waitForIdle(ctx);          // resolves before seen has the terminal commit

HEAD:        []        (nothing observed, net 0)
first build: [-1]      (net -1)

Fable found three more of the same kind: a host listener that closes the Harness makes resolved waits reject; scheduler line jobs queued in A jump ahead of a host listener's own commit; abort listeners moved after H. The patches each reviewer suggested were more afterPublish. The owner called it what it is: special-casing.

The gap is the bug. The first build created it by splitting the publication. The proposal moves all of it:

const adopt = (seq: Seq): void => {
  const documents = tx.adopt(seq);                              // trackers, as today
  const publication = this.#publication(seq, writes, documents);
  this.#events(writes);                                         // pi.durable.entry / .submission, contained
  this.#notifyInternal(publication);                            // views, graph, scheduler, submissions
  this.#notifyHosts(publication);                               // subscribeCommits
};
seq = await this.#storage.commit(writes, adopt, context);
// after R: touch documents, sweep, fail() for an error an observer threw; nothing is published here

The order inside is HEAD's: telemetry events, internal observers, host listeners. afterPublish disappears. Waits need nothing special: an observer resolves a promise in A, and the waiter's continuation runs later by nature, after the host listeners already ran synchronously. One rule replaces the special cases: adopt runs no task code. The only synchronous path into task code is AbortController.abort() of a newly marked run (abort listeners run inside abort()), so that one is queued with queueMicrotask. adopt never throws: every listener, every report and every telemetry call inside it is contained.

What this does to the regressions, verified by Opus and Fable with probes against HEAD:

HEAD's whole non-e2e Durable suite (73 files, 1404 tests) passes on a build of the proposal. The four tests the first build added that encode its split fail, as they should, and are replaced.

Nothing in the public API changes. These are the differences in behaviour the four checks found.

1. With JSONL, everything runs before the storage is done

HEAD:     marker → A → cleanup … → R → observers → H → watches, waits → C
proposal: marker → A { observers, H } → watches, waits, abort → cleanup … → R → C

Host and task code woken by a commit now runs while JSONL still cleans up its sidecars. It cannot reach the storage through the Session: the line is still held, so a commit or read it starts waits. The memory, SQLite and IndexedDB storages do no work after A, so for them only the microtask placement differs, and the order is HEAD's. No spec section promised "after Storage.commit resolved". Verdict: harmless; the spec gets one sentence.

2. Abort listeners fire after host listeners

runtime.signal.addEventListener("abort", () => log(hostSaw(id)));
// HEAD: false (abort before H)    proposal: true (abort after H)

At HEAD the scheduler aborted a newly marked run inside #publish, before the host listeners. Under the proposal the abort is a microtask after A, so after H. No contract fixes this order. Decision for the owner.

3. A commit the storage rejects after A is published

A host keeps a replica from subscribeCommits. JSONL wrote the marker (the commit is durable), called adopt, then failed while cleaning up and rejected.

HEAD:     durable, but no observer and no host listener ran → the replica misses it
          → replica ≠ storage; waits of that commit reject; the Session fails
proposal: published at A → the replica gets it → replica = storage
          → waits of that commit resolve; the Session fails after R

Durable's spec says a replica fed by subscribeCommits "stays equal to Storage"; HEAD breaks that, the proposal keeps it. Spec invariant 2 changes from "published only after its storage commit succeeds" to "published once it is durable, even when commit() then rejects". Decision for the owner; all four checks recommend it.

4. A subscriber that arrives late misses the commit

// host code that runs in the gap, between A and R:
harness.subscribeCommits(listener);   // HEAD: gets commit 41; proposal: does not, 41 was published at A

Consistent with the rule: a listener added after the publication misses it, as one added after #publish did at HEAD. Documented, nothing to decide.

5. An observer that throws fails the Session after the host listeners

At HEAD, a throwing internal observer failed the Session at once, inside #publish: close listeners and the session_failed report came before the host listeners. Under the proposal, adopt records the error, lets the other observers and the host listeners run, and the Session fails after R. The commit stands, as before. Failing inside A instead would make Durable's storage guard reject the caller of a durable commit with SessionFailed. Verdict: keep it so.

6. Telemetry that throws no longer breaks memory

At HEAD, #publish called context.telemetry.addEvent for each entry and submission without protection. A throwing adapter rejected a commit that was already durable and adopted, skipped every observer and host listener, and left the Session healthy: the scheduler and the views missed the commit for good. Inside adopt nothing may throw, so the proposal contains it and reports it; the commit resolves. This fixes a HEAD bug. The report needs a type (host_error with callback "telemetry" is the suggestion). The same containment must cover Durable's report path itself (safeReport records a metric and a span event outside its try), or adopt is not truly throw-free.

7. Host listeners would run inside Chord's batch

This is the one that matters. In Chord's store, StoreStorage runs Durable's adopt inside the store's commit step, inside Chord's batch, where Chord refuses reentrant calls (self.tx, get, watch, close throw invalid/reentrant). Under the proposal the host listeners run inside adopt, so inside that batch:

// p3 code that mirrors Durable's commits into a Chord object
harness.subscribeCommits((publication) =>
  chord((ctx) => audit.record(publication.seq, ctx), context));   // throws invalid/reentrant

The listener keeps every rule Durable states (synchronous, no Session calls) and still fails. Its error is reported; an onReport that itself uses Chord throws too, and a throwing onReport is dropped, so the work vanishes without a trace. And every host listener's run time is added to the store-wide commit step that every other object's commit waits for.

Opus proposed a variant that keeps every result of the proposal and moves only the host listeners out of the step. The publication is still built in A and the internal observers still run there. The host listeners are dispatched in one microtask that is queued before the internal observers run:

// inside adopt, after tx.adopt(seq)
this.#events(writes);                                            // contained
if (this.#commitListeners.size > 0) {
  const listeners = [...this.#commitListeners];
  queueMicrotask(() => {
    for (const listener of listeners)
      contained(() => listener(stored, context), (error) => this.report(error, LISTENER, context));
  });
}
for (const listener of [...this.#internalListeners])
  contained(() => listener(observed, context), (error) => { failure ??= { error }; });

Microtasks run first in, first out. The host dispatch is queued before anything the observers queue, so the host listeners still run before every watch delivery, every resolved wait, every abort and onWake. And it is a microtask, so it runs after the storage's synchronous step: after Chord's batch and flush, where Chord calls work.

Chord needs nothing Durable-specific: only that its commit step and its flush are synchronous, which its design already states. The store never knows Durable's continuation, as the owner required.

What the variant gives up compared with the proposal: host listeners are no longer called synchronously from inside adopt, but one microtask later, still on the Session line and still before C. Opus ran HEAD's full non-e2e suite against the variant (1404 of 1404) and all twelve probes: the same results as the proposal. One detail to settle while building: the listener list is copied at A, so a listener removed between A and the microtask is still called once; copying it inside the microtask avoids that, but then a listener added in between is called too.