feat(mcpl): journal channel and push event coalescing

[antra-tess]

Problem

Unread edits and deletions need the same behavior across channels/incoming and push/event: replace or retract work until assembly, then preserve consumed history. Recovery must reconstruct those decisions consistently, including a crash between appending content to context and recording delivery completion.

Changes

• Make mcpl/coalescing-journal the single authoritative append-only operation log. Acceptance, replacement, retraction, render decisions, recovery, and publication receipts are appended facts. One pure reducer builds pending subjects, consumed-history knowledge, publication intents, and receipt-position indexes in live operation and replay. Replay performs no RPCs, context writes, or wakes.
• Persist and sync each operation before acknowledging admission or performing its effect. Assembly appends an intent that seals the occurrence against replacement, publishes with that intent's stable context delivery ID, then appends completion. An interrupted publication retries idempotently. Storage failures stop further mutations until a fresh replay resolves whether the append committed.
• Share subjects by host-owned server binding, explicit scope, and coalescing key across both lanes. Keep platform reply identity and conversation routing through mixed-lane updates. Reconnect changes authority, not occurrence identity; endpoint/command reassignment creates a separate binding namespace.
• Require current grants, authoritative channel registration, and optional allowedIncomingChannels patterns on both channel lanes. Channel-scoped pushes also require push authorization. Outbound placeholders inferred from origin cannot authorize inbound content.
• Keep pending content outside context until safe activation assembly. Shared contexts wait for other live readers; conversation forks receive their own events. Deferred rendering has a five-second deadline, bounded notices/content, authority rechecks, and observation-only late results. Recovery uses admitted fallback content without repeating an unfinished render.
• Re-evaluate wake eligibility on replacement and cancel obsolete immediate, debounced, and queued wakes. Coalesced subjects have independent deadlines so unrelated debounce behavior is preserved.
• Import older experimental snapshot/receipt stores once into the journal. Because the old context and snapshot writes were independent, imported pending deliveries are conservatively sealed and deduplicated against legacy context markers. Subsequent recovery ignores the old stores.

Startup currently replays the full journal and keeps occurrence-to-record positions in memory. Recovery time and receipt-index memory therefore grow with journal history; no separate authoritative snapshot or receipt database is maintained.

Tests

• npm run build: passes.
• npm run pretest then node --test --test-concurrency=4 dist/test/*.test.js: 1053 pass / 1 fail / 4 skipped. All 86 coalescing tests pass; the sole failure matches the upstream baseline.
• Upstream 5498805 baseline with the same command: 967 pass / 1 fail / 4 skipped. The existing failure is conversation-routing.test.js, which reports an asynchronous Queue is closed rejection after its final test.
• Focused coalescer, journal, and WebSocket integration run: 81 pass / 0 fail.
• New fault tests exercise failure before/after durable acceptance, prepared intent before publication, completion before/after append, unfinished-render recovery, and the actual framework restart after context publication without completion. Every live journal prefix reconstructs identically without replay effects. Real Chronicle compaction/reopen and one-time legacy import are covered.
• Existing coverage preserves mixed-lane edits/deletions, stable reply targets, permission changes, channel registration, conversation routing, shared-context isolation, restart/reconnect, duplicate receipts, and render/wake races.
• git diff --check: passes.

The full comparison omits --test-force-exit, which can stop reporting nested suites early and obscure the baseline cleanup failure. Wire integration uses a real loopback WebSocket and a mock model provider.

Compatibility

Servers that relied on outbound placeholders inferred from push origin must register channels through channels/register/channels/changed, or complete an authorized channels/open with a valid descriptor, before sending inbound channel content. This also applies to ordinary incoming messages. The breaking changelog fragment documents the migration.

Companion PRs

MCPL #5 now proposes revision 7 (9a319e2). The authoritative journal architecture remains valid. Current implementation 6352d47 still targets revision 6 and needs these revision 7 alignment changes:

• Handle coalesce.initial, including validation and establishing a fresh subject after lost history without resetting known consumed history.
• Accept empty channel-scoped withdrawal while retaining supplied deletion notices for consumed/unknown history.
• Degrade to ordinary delivery when coalescing slots are exhausted; deferred overflow uses its admitted fallback.
• Add regression coverage for channel subjects spanning different platform messages and their reply provenance.

Durable receipts already exceed the default one-hour retry guarantee. Conservative cross-context consumption and tail placement remain valid choices. The RFC can land independently; this PR does not yet claim revision 7 conformance. Producers must opt into advertised support, and the proposal remains Draft.

Not verified

No live provider or production Discord, Portal, or editor deployment was exercised. No production rollout, producer migration, or long-history performance benchmark is included. Pending coalesced events enter context at activation assembly; live tool-continuation injection is outside this implementation.

• Changelog fragments: mcpl-event-coalescing.added.md and mcpl-channel-registration.breaking.md.

AI-assisted implementation by Codex (GPT-6).

[greptile-apps]

Confidence Score: 0/5

[High risk] Adds push event coalescing with deferred rendering and persistence.

This PR is not ready to merge: admitted pushes can be lost or duplicated, and assembly and gate behavior can deliver them at the wrong time.

Findings

1.  Recovered pushes cannot be replaced ▶
2.  Transient disconnects erase pending pushes ▶
3.  Reconnect leaves recovered pushes asleep ▶
4.  Assembly bypasses turn deferral ▶
5.  Coalesced pushes lose channel routing ▶
6.  Replacement retains obsolete gate wake ▶
7.  Unrelated events wake too early ▶
8.  Retries can duplicate delivered events ▶
9.  Retraction leaves queued gate wake ▶

Fix with agent prompt

### Issue 1
src/mcpl/push-coalescer.ts:97
**Recovered pushes cannot be replaced.** After a restart, a pending fallback is stored under an event-ID key, but new pushes and retractions look up a key based on the feature set and coalescing key. If the producer updates or retracts that subject before assembly, the old fallback remains separate and is delivered alongside the update-or despite the retraction. The connection epoch also changes on restart, so matching only the old epoch would not resolve this.

### Issue 2
src/framework.ts:13253
**Transient disconnects erase pending pushes.** A temporary transport drop fires this close handler, which clears the coalescer's acknowledged pending pushes and saves the emptied snapshot. Reconnection registers the server again but does not restore those pushes. Unless the producer resends an event it was already told was accepted, its unread content is permanently lost.

### Issue 3
src/framework.ts:13135
**Reconnect leaves recovered pushes asleep.** If the host restarts while a producer is offline, it retains the pending fallback but cannot wake it until the server is connected and authorized. This reconnect handler re-registers the server without calling `wakeRecovered()`, so an otherwise idle host can leave that fallback undelivered indefinitely.

### Issue 4
src/framework.ts:8459-8463
**Assembly bypasses turn deferral.** Any resident agent can assemble a push, but publication writes directly into the primary agent's context. If another resident activates while the primary is mid-turn, this bypasses the primary's normal turn-alive deferral: its stored history gains content that its live tool continuation never saw, breaking their ordering.

### Issue 5
src/framework.ts:7284-7286
**Coalesced pushes lose channel routing.** When a feature-set push carries channel provenance, these wake requests omit the derived channel ID and addressed flag. Unlike ordinary pushes, materialization also does not qualify or register the channel. For a closed-channel DM forwarded through `push/event`, the reply can go to the global fallback or have no routable DM channel.

### Issue 6
src/mcpl/push-coalescer.ts:182
**Replacement retains obsolete gate wake.** If an immediate wake is already queued, replacing its push does not recheck whether the new content now matches a `skip` rule. Changing a debounced push to `skip` likewise leaves its old timer armed. In either case, an obsolete wake can start a turn and materialize content that the current gate policy would not have woken for.

### Issue 7
src/gate/event-gate.ts:1471-1475
**Unrelated events wake too early.** When a normal event joins a debounce batch containing a coalesced push, this return keeps the push's existing deadline for both. A normal event arriving just before that deadline therefore triggers inference early, rather than after its configured quiet period.

### Issue 8
src/mcpl/push-coalescer.ts:130-132
**Retries can duplicate delivered events.** Receipts are keyed to a connection epoch and kept only in a bounded memory map. If an acceptance receipt is lost and the producer retries the same `eventId` after reconnect, the new epoch treats it as a fresh occurrence and can append already consumed content again. The same can happen within one connection after 4,096 later receipts evict the original.

### Issue 9
src/framework.ts:7291-7295
**Retraction leaves queued gate wake.** Once a coalesced debounce timer fires, its inference request has left the gate timer and buffer, and it is not tracked in `coalescingWakes`. A retraction before assembly cannot cancel that request, so the host may spend a model turn on work withdrawn before it was shown. This is a non-blocking source of unnecessary inference.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR adds feature-set push coalescing, deferred rendering at activation assembly, gate integration, and durable fallback recovery.

• The new paths need correction for recovery across reconnect/restart, retry identity, multi-agent assembly, and gate wake transitions before the advertised behavior is reliable.
• Channel-origin routing and mixed debounce batches also diverge from existing behavior.

_{Reviews (1) · Last reviewed commit: "feat(mcpl): coalesce unread feature-set ..."}

[greptile-apps]

Recovered pushes cannot be replaced. After a restart, a pending fallback is stored under an event-ID key, but new pushes and retractions look up a key based on the feature set and coalescing key. If the producer updates or retracts that subject before assembly, the old fallback remains separate and is delivered alongside the update—or despite the retraction. The connection epoch also changes on restart, so matching only the old epoch would not resolve this.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/mcpl/push-coalescer.ts
Line: 97

Comment:
**Recovered pushes cannot be replaced.** After a restart, a pending fallback is stored under an event-ID key, but new pushes and retractions look up a key based on the feature set and coalescing key. If the producer updates or retracts that subject before assembly, the old fallback remains separate and is delivered alongside the update—or despite the retraction. The connection epoch also changes on restart, so matching only the old epoch would not resolve this.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Transient disconnects erase pending pushes. A temporary transport drop fires this close handler, which clears the coalescer's acknowledged pending pushes and saves the emptied snapshot. Reconnection registers the server again but does not restore those pushes. Unless the producer resends an event it was already told was accepted, its unread content is permanently lost.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/framework.ts
Line: 13253

Comment:
**Transient disconnects erase pending pushes.** A temporary transport drop fires this close handler, which clears the coalescer's acknowledged pending pushes and saves the emptied snapshot. Reconnection registers the server again but does not restore those pushes. Unless the producer resends an event it was already told was accepted, its unread content is permanently lost.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Reconnect leaves recovered pushes asleep. If the host restarts while a producer is offline, it retains the pending fallback but cannot wake it until the server is connected and authorized. This reconnect handler re-registers the server without calling wakeRecovered(), so an otherwise idle host can leave that fallback undelivered indefinitely.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/framework.ts
Line: 13135

Comment:
**Reconnect leaves recovered pushes asleep.** If the host restarts while a producer is offline, it retains the pending fallback but cannot wake it until the server is connected and authorized. This reconnect handler re-registers the server without calling `wakeRecovered()`, so an otherwise idle host can leave that fallback undelivered indefinitely.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Assembly bypasses turn deferral. Any resident agent can assemble a push, but publication writes directly into the primary agent's context. If another resident activates while the primary is mid-turn, this bypasses the primary's normal turn-alive deferral: its stored history gains content that its live tool continuation never saw, breaking their ordering.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/framework.ts
Line: 8459-8463

Comment:
**Assembly bypasses turn deferral.** Any resident agent can assemble a push, but publication writes directly into the primary agent's context. If another resident activates while the primary is mid-turn, this bypasses the primary's normal turn-alive deferral: its stored history gains content that its live tool continuation never saw, breaking their ordering.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Coalesced pushes lose channel routing. When a feature-set push carries channel provenance, these wake requests omit the derived channel ID and addressed flag. Unlike ordinary pushes, materialization also does not qualify or register the channel. For a closed-channel DM forwarded through push/event, the reply can go to the global fallback or have no routable DM channel.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/framework.ts
Line: 7284-7286

Comment:
**Coalesced pushes lose channel routing.** When a feature-set push carries channel provenance, these wake requests omit the derived channel ID and addressed flag. Unlike ordinary pushes, materialization also does not qualify or register the channel. For a closed-channel DM forwarded through `push/event`, the reply can go to the global fallback or have no routable DM channel.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Replacement retains obsolete gate wake. If an immediate wake is already queued, replacing its push does not recheck whether the new content now matches a skip rule. Changing a debounced push to skip likewise leaves its old timer armed. In either case, an obsolete wake can start a turn and materialize content that the current gate policy would not have woken for.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/mcpl/push-coalescer.ts
Line: 182

Comment:
**Replacement retains obsolete gate wake.** If an immediate wake is already queued, replacing its push does not recheck whether the new content now matches a `skip` rule. Changing a debounced push to `skip` likewise leaves its old timer armed. In either case, an obsolete wake can start a turn and materialize content that the current gate policy would not have woken for.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Unrelated events wake too early. When a normal event joins a debounce batch containing a coalesced push, this return keeps the push's existing deadline for both. A normal event arriving just before that deadline therefore triggers inference early, rather than after its configured quiet period.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/gate/event-gate.ts
Line: 1471-1475

Comment:
**Unrelated events wake too early.** When a normal event joins a debounce batch containing a coalesced push, this return keeps the push's existing deadline for both. A normal event arriving just before that deadline therefore triggers inference early, rather than after its configured quiet period.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Retries can duplicate delivered events. Receipts are keyed to a connection epoch and kept only in a bounded memory map. If an acceptance receipt is lost and the producer retries the same eventId after reconnect, the new epoch treats it as a fresh occurrence and can append already consumed content again. The same can happen within one connection after 4,096 later receipts evict the original.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/mcpl/push-coalescer.ts
Line: 130-132

Comment:
**Retries can duplicate delivered events.** Receipts are keyed to a connection epoch and kept only in a bounded memory map. If an acceptance receipt is lost and the producer retries the same `eventId` after reconnect, the new epoch treats it as a fresh occurrence and can append already consumed content again. The same can happen within one connection after 4,096 later receipts evict the original.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Retraction leaves queued gate wake. Once a coalesced debounce timer fires, its inference request has left the gate timer and buffer, and it is not tracked in coalescingWakes. A retraction before assembly cannot cancel that request, so the host may spend a model turn on work withdrawn before it was shown. This is a non-blocking source of unnecessary inference.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/framework.ts
Line: 7291-7295

Comment:
**Retraction leaves queued gate wake.** Once a coalesced debounce timer fires, its inference request has left the gate timer and buffer, and it is not tracked in `coalescingWakes`. A retraction before assembly cannot cancel that request, so the host may spend a model turn on work withdrawn before it was shown. This is a non-blocking source of unnecessary inference.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[slimepriestess]

Review at exact head a6e03f6, protocol read against MCPL#5 rev 6 as asked. APPROVE. Verified here: suite with your exact flags 1039/1044 (1 fail, 4 skipped), and I re-ran the baseline first-hand on a clean 5498805 worktree — the same single conversation-routing "Queue is closed" post-test rejection fails identically there, so the failure set is unchanged and all 72 coalescing tests pass.

The core of the machine held up under targeted reading and probing: subject identity (binding + explicit scope + key, never origin-inferred); the double authorizeCoalesced around the routing await; the receipt/dedup index bridging interrupted writes via the snapshot's latest receipt; restore-without-replaying-renders; the retract/replace/displace outcomes including noted-with-notice; mixed-lane reply identity via the stored previous identity; audience-branch filtering on restore; accept-during-assemble races (the selected snapshot re-reads the live slot, a replace cancels the render, a late render is audit-only); the occurrence filter dropping stale wakes while the boundary requeue — carrying no subject — is never filtered; conversation bind-predicate parity (metadata.mentioned on both paths, pinned by your test); disconnect-during-render collapsing a deferred batch to its self-contained fallback without notices, with the cancelled render's finally unable to clobber the rebuilt slot; and the recovered-delivery dedup honoring both the binding-keyed and the legacy epoch-keyed delivery ids. The fixed per-subject debounce deadline and the no-[Gate:]-trace choice for withdrawn work are both right.

Scheduling note — one README sentence wanted, not a blocker. The assembly-owner gate is assembly-scoped (released at the stream handoff, beginAgentTurn's return true), so shared readers' streams still overlap; what changes is that (a) shared readers can't overlap during context assembly itself, which mainly re-queues the async side entries onto the ~10 ms poll, and (b) while coalesced content is pending, a shared reader defers its whole turn until no other shared reader is mid-turn — a real, traffic-tied wait that looks intended ("shared-context publication waits for other live readers"). The README paragraph describes the publication rule but not the turn-deferral; one sentence there ("while coalesced content is pending for the shared context, a shared-context resident's turn waits for other residents' live turns to finish") would keep the next reader from rediscovering it in the scheduler.

Cross-PR seam with #195 (focus), for whichever lands second. Coalesced admission never passes through handleMcplChannelIncoming/handleMcplPushEvent, so FocusCoordinator.onIncoming never sees these messages: no focusHeld stamp, no autoreply, and materializeCoalescedPush writes to the context manager at any turn's assembly regardless of focus state. Composed as-is, a coalesced message from a held channel enters the resident's view mid-focus (the wake side is partially covered via the gate's trigger filter; materialization is the leak). Flagging it identically on both PRs so the second rebase owns it — the focus hold needs a seam at admission/materialization, or focus refuses while pending subjects exist. The two branches also edit adjacent regions of framework.ts and event-gate.ts, so the rebase conflict is real wherever the merge order falls.

Compatibility, half-verified for you. I read our discord-mcpl against the new registration requirement: it registers via channels/register + channels/changed (registerAndNotifyNew, idempotent) and sends channels/incoming only for open channels, so the breaking change should not bite it. Portal I could not check today (relay's down on my side) — worth the same one-look before rollout, since ensureChannelRegistered placeholders no longer admit inbound and the rejection is per-message and quiet.

Small notes, no action needed: gate policies see the registered/composite channel id for coalesced pushes but the bare origin.channelId for ordinary pushes — a pre-existing inconsistency this PR makes more visible; the inference/request-during-render refusal is per-server, so a second server can still request inference during another's render (seems fine, worth knowing); the in-memory receipts map evicts FIFO at 4096 while the durable tree grows append-forever (fine for an idempotency index); the orphaned-render audit path with its 4096 cap is good hygiene.

(Adversarially second-read by the Opus session per our usual split — including a catch that corrected my own first read of the owner gate's scope before this posted.)

[antra-tess]

Review of 6352d47 (journal rework), by running probes against the head in a scratch clone (npm run build, then node --test on added test files that reuse the PR's own WebSocket fixture). CI is green and the body is candid that revision 7 is not yet implemented; this is about what the head does today.

The findings from the previous head are unchanged

#	Probe	a6e03f6	6352d47
1	Transport drop + reconnect, server does not re-register; ordinary channels/incoming (no coalesce)	rejected unknown channel	rejected (on main it is accepted)
2	128 unread ambient coalesced messages, then a chat:mention	129th refused host pending-subject limit reached	refused
3	Create → retract of a never-read message, after restart	appended / noted, notice in context	fixed
3b	Same, after 130 consumed subjects (eviction)	—	appended / noted (forgotten sets uncertain permanently)
4	Pending content, then a turn started with a context_budget_restart trigger	assembled mid-logical-turn	assembled
5	Coalesced input consumed by a turn, then undoLastTurn	input rolled back with the turn; receipt blocks a retry	same (an ordinary push survives the same undo)

Finding 1 comes from the close handler calling removeServer, is a regression for hosts that never use coalescing, and is not in the Compatibility section. Finding 2 is the normal case for a busy channel, not an edge: unread subjects = backlog.

Two new problems from the journal

Per-message cost. 300 channel messages with 200-character bodies, same fixture, same gate, drained every 100 so the cap is not hit:

	ingest	per message	store size after
without coalesce	261 ms	0.9 ms	0.55 MB
with coalesce	25,574 ms	85 ms	3.4 MB

ChronicleCoalescingJournal.append does appendToStateJson + store.sync() on every operation, and one message costs three operations (accepted, prepared, delivered) with the full push body serialized twice. Startup replays the whole log; the body already notes it grows without bound. At channel volumes (Discord edits, world/presence churn are the stated targets) this is a ~100× slowdown on the ingest path and a store that grows ~10 KB per short message.

One storage fault halts all coalesced traffic until restart. I made store.sync() throw once. The message in flight was rejected with the error, and every coalesced message after it was rejected with Coalescing journal append failed; rebuild the controller from the journal before continuing, while plain channels/incoming and ordinary push/event kept flowing. Nothing re-creates the controller except a branch switch or a host restart, so a producer that has adopted coalesce goes deaf on a transient EIO while everyone else keeps working. If fail-closed is the intent, it needs an automatic rebuild path, or it needs to degrade to append-only delivery (RFC-006 principle 4, and the revision-7 capacity rule) rather than refuse.

Suggestion

The journal is a heavier mechanism than the guarantees need. Revision 7 deliberately asks only for outcomes — nothing accepted is silently lost, a retry inside the window is not a second occurrence, a changing subject is still heard — and permits a host to flush pending content as ordinary events on any interruption. That allows an implementation with no write-ahead log on the ingest path at all: keep pending content in memory, sync it at the same points the framework already syncs, and on any doubt (disconnect, restart, capacity, fault) deliver it as plain messages and mark history unknown. That would also remove findings 2 and 5 and the fault wedge, and leave 1, 3b and 4 as small fixes.

Probe sources available on request; they are ~120 lines on top of the existing integration fixture.

[antra-tess]

Superseded by #197 (merged as 03c31d9): the in-context implementation of RFC-006 revision 7. Closing without merge.