[antra-tess]

Problem

A debounced wake writes a user entry into the window before waking the agent:

[Gate: 1 event matched]

- 1 message in discord:dm:… (oldest ~5s ago) — already shown above at arrival; this is a batched wake, not new content

The line says which messages a wake is for. When the wake is for one message that is still the newest entry in the window, the message sits right above the line, and the line adds nothing.

On a resident whose addressed messages (DMs, mentions) wake through a 5 s debounce, so that a burst of quick messages gets one wake, this was most of what the gate wrote. In one window of about 1,000 entries, 325 were these lines. 80% of them sat directly under the one message they named. 11% covered several messages and 7% named a message further up; in those cases the line does say something (which channel, how many, how old, nothing new).

Changes

• The gate asks before writing the line for a batch of one MCPL event (new optional isNewestEntry callback, GateEntryRef). The question: is that event's own stored entry the newest in the window the line would go to?
  • How the event is identified: a channel message by server, channel and message id; a push event by server and event id. The gate already receives these in the metadata at decision time and now keeps them on the pending event.
• The framework answers it (isNewestContextEntry). It answers "yes" only if:
  • the newest entry in the primary's window (deliveryAgent(), where the line is written) is that event's entry;
  • no turn is alive there (turnAlive: started, streaming, or waiting on its tools);
  • nothing is deferred for that agent;
  • the entry isn't held by a tune-out.
• If yes, the wake runs without the line. requestInference and its provenance are unchanged, so the reply's channel is the same, and gate:wake-line-omitted is traced.
• The line stays in every other case:
  • several messages in the batch;
  • anything stored after the message (the agent's own turn, another message);
  • a turn running, or a write waiting;
  • content the line quotes (events not stored at arrival);
  • a gate built without the callback, or a callback that throws.

Tests

• test/event-gate.test.ts, new describe "a batched wake writes its line only when it says something" (6 tests):
  • one channel message that is still newest gets no line, the wake runs, and the callback is asked with server, channel and message id;
  • the same for a push event, by event id;
  • not newest → the line;
  • several messages → the line, and the callback isn't asked;
  • a quoted (non-MCPL) event → the line, and the callback isn't asked;
  • a callback that throws, and no callback at all → the line.
• test/batched-wake-line.test.ts, end to end over the wake-locus MCPL fixture with a debounce on addressed messages (4 tests):
  • one DM (push/event) → the wake runs and the window has no [Gate: line;
  • one mention in a channel (channels/incoming) → the same;
  • a DM, then an ambient message stored before the batch fires → the line, naming the DM;
  • two DMs in one batch → the line, counting both.
• The same file, isNewestContextEntry against a real window, with ids from what the framework stored (5 tests):
  • a push event by server and event id, and a channel message by server, channel and message id, are true for their own newest entry;
  • another server, channel or id, no id, or a non-MCPL type is false;
  • so is anything stored after the entry, a turn started or streaming, a deferred write, and an entry stamped tuneOut.
• Controls: on main's src/, the "no line" tests fail and the "line stays" tests pass. With the turn-token check in place of turnAlive, the streaming case fails.
• npm test, two runs on the branch (6568 pass / 6 fail, then 6577 pass / 4 fail) against main's baseline (6563 pass / 3 fail):
  • Two failures are the same in all three runs, both main's: "a crash's detail has the stderr that comes after its process exits" and "queued context maintenance timer".
  • The other failures differ from run to run, on the branch and on main alike. Every one of the branch's passes when its file runs alone: discord-awareness-outbox 64/0, discord-awareness-delivery 10/0, same-round-think-policy 19/0, stop-with-host-operations 59/0, stop-without-stream 47/0, workspace-direct-notice 26/0 (four runs), host-quiesce 50/0. None touches the gate or the window check.
• tsc --noEmit is clean.

Not verified

• No live resident run. The end-to-end test covers the real path (MCPL child, channels/incoming and push/event storage, the gate, the framework's window), but not a provider.
• Conversation forks: the line is written to the primary's window (deliveryAgent()), and only that window is checked. A batch whose message was placed in a fork's window (coalescing placement) isn't found there, so it keeps the line, as before.

---

• Changelog fragment added: changelog.d/gate-wake-line-only-when-it-says-something.changed.md

🤖 Generated with Claude Code

[github-actions]

Automated review

Recommendation: merge and fast-follow. 3 medium severity findings can be fixed after the merge.

Reviewed commit 307e0be with claude-opus-5-5, by reading the code. It did not run the code or look at the checks.

Does this change belong in the project?

It fits the project. This fits. It changes behaviour the existing event gate already has, trimming a redundant batched-wake line.

4 reasons with sources

It also follows the gate's pattern of asking the framework through optional callbacks, and it arrives in the shape CONTRIBUTING.md asks for.

• The change only adjusts the [Gate: …] line that the existing debounce path in the gate already writes; it adds no new feature or scope. The wake, its provenance and requestInference are unchanged. Only the user-entry line is skipped, and only for a batch of one MCPL event that is still the newest entry in the window. README.md doesn't describe the gate's goals, so this is judged against the existing gate code. (src/gate/event-gate.ts (fireDebounce))
• The new isNewestEntry hook follows how EventGate already asks the framework about its window, through optional callbacks passed to its constructor. It sits next to the existing channelShown and resolveRouteChannel callbacks. The gate keeps the decision about whether to write the line, and the framework answers the question about its own window (deliveryAgent, deferredMessages, tune-out). Without the callback the gate behaves as before. (src/gate/event-gate.ts constructor options; src/framework.ts gate construction)
• The new public surface is small and optional: one exported type (GateEntryRef) and one trace event (gate:wake-line-omitted), each in the file that already holds its kind. GateEntryRef goes in the gate's types file and is re-exported alongside the other gate types; the trace event goes into the existing TraceEvent union with the other gate:* events. A separate review found the 'no turn running' check uses activeTurnTokens rather than the existing turnAlive() helper. That is a defect for the code review, not a question of fit. (src/gate/types.ts; src/types/trace.ts)
• The PR is one coherent change and its body has the parts CONTRIBUTING.md asks for: Problem, Changes, Tests, Not verified, a changelog fragment, numeric test baselines and the AI footer. The fragment changelog.d/gate-wake-line-only-when-it-says-something.changed.md is a flat file of bullets in the required format. Unit tests and end-to-end tests come with the change. The gaps the code review found in them go to the author. (CONTRIBUTING.md, "What a PR should contain" and "Changelog")

Findings

3 findings of medium or high severity, see the inline comments:

• Medium severity. The 'no turn running' check uses activeTurnTokens alone instead of the existing turnAlive() helper.
• Medium severity, test coverage. None of the framework-side conditions in isNewestContextEntry are tested.
• Medium severity, test coverage. End-to-end 'no line' test only covers the push-event path, not channel-incoming.

3 more findings, less severe

• Low severity, documentation, src/framework.ts:22629-22640. New method was inserted between deliveryAgent's JSDoc and deliveryAgent, so the old doc comment now sits on the wrong method. isNewestContextEntry and its JSDoc were placed after the existing comment /** Where addMessage delivers: the named agent, else the primary, else the first registered agent… */ and before private deliveryAgent(...). As a result, two doc blocks now stack above isNewestContextEntry, and deliveryAgent has no doc at all. IDE hovers and generated docs will attach the wrong text to the wrong method. Move the new method above that comment, or move the comment back onto deliveryAgent.
• Low severity, test coverage, src/gate/event-gate.ts:1649-1665. No test covers the buffered path, where a single event is delivered after inference ends. deliverEvents is also reached from flushInferenceBufferIfClear (a microtask after a turn ends or a quiesce lifts) and from clearPolicyState during a config reload. The new omission logic runs on those paths too. After a turn, the agent's reply is normally the newest entry, so the line should stay. No test checks that a batch buffered during inference keeps its line, or that a single buffered event is handled correctly, so the change's interaction with the buffering paths is unverified.
• Low severity, test coverage, test/batched-wake-line.test.ts:33-147. Suite failure count no longer matches the main baseline (6 vs 3) with this new process-spawning test added. CONTRIBUTING.md asks for the npm test failure count to match the main baseline. The PR reports 6 failures on the branch against 3 on main, and four of the branch's failing files pass only when run alone. The new file starts a real MCPL child per test and waits up to 15 s, which adds load to the full run. Whether or not this file causes the extra failures, the branch has not shown that the suite is no worse than main. The difference needs to be resolved or explained with evidence before merge.

[nissa-seru]

We ran this pull request beside main (9fdc3a65) on your own end-to-end rig, and in the case it's for, it does what it says: a later wake for one DM with nothing after it ends with the DM itself, and the line is gone. One finding is the one we'd fix before merging. That's our view, and the merge is yours. The rest is small.

Evidence: the probe file is test/probes/imogen-727-facts.test.ts on review/727-probes (e0619b3a). Each test logs what it saw on a FACT-<n> line, run on both trees, with predictions in its header written before each ran.

1. The decision is taken when the batch fires, and the wake compiles later, so a message stored in between leaves a wake with no line.

• The race: deliverEvents asks isNewestEntry and then only queues the wake (requestInference → pendingRequests). Anything stored into the window before the turn compiles lands after the DM, and nothing then says the wake is for the DM.
• The window can be long: a provider hold sits between the decision and the compile.
  • FACT-5a: a 2 s hold, through the framework's own cooldown entry and release path, on a later wake (the locus already the DM). An ambient message from someone in #general arrives during it.
    • On main the held wake's request ends: DM two / [Gate: 1 event matched] - 1 message in discord:dm:1548000000000000001 … / GUILD ambient message from someone.
    • On 307e0be5 it ends: DM two / GUILD ambient message from someone, with no line.
    • On both trees the reply is published to the DM.
  • What the agent then does, read as the agent receives the request (not run with a live model): it takes the message last above it as its cause, so it is likely to answer the ambient message, and its reply lands in the DM.
• Other ways the window widens, by reading:
  • startAgentStream parks a wake while a compression call is in flight (waitForAuxiliaryIdle) and can requeue it.
  • The running-turn and queued-write checks look only at the primary, while other ordinary residents share its window (sharedSlotAgents), so a co-resident's turn output can land after the DM.
• On the first wake (FACT-1), a [routing] notice naming the DM's channel follows and gives a cue. On a later wake (FACT-4) there is none.
• The text: the description, the changelog fragment and the commit message say anything stored after the message keeps the line. That holds only up to the decision.
• The shape we'd suggest: decide at the turn's start, not when the batch fires.
  • The gate carries the line it would have written on the wake's request, instead of dropping it.
  • The framework checks the entry once the turn has written its own inputs and before its checkpoint, and writes the line then if the entry is no longer the newest. By our reading of beginAgentTurn, that's after the turn-start flush of deferred writes and the assembly flush.
  • By then the turn holds its token, so later stores are deferred past this request.
  • Two choices come with it. A merged trigger carries each merged request's pending line, to be written once. And the start's own clock row, if one is due, may or may not count as something after the message.

2. Tests for the framework's checks. The tune-out, running-turn and queued-write guards, and the server, channel and message-id comparisons, were pinned by no test. That's the automated review's second finding. A pull request into this branch adds them, each failing with its check removed: #733. The tune-out guard matters most. On this branch with it removed (FACT-3), a held DM's wake runs with neither the DM nor a line in the request.

3. Smaller:

• The npm test summary in the description doesn't add up:
  • main is given 3 failures, but the text describes two shared failures plus "main's own two other failures";
  • "the branch's other four failing files" lists six;
  • 6568 + 6 against 6563 + 3 is 8 more tests and 5 more passing, not 9.
• We agree with the automated review on the deliveryAgent docblock and on turnAlive().

Found beside this pull request, in main: the line written for a message a tune-out holds says the message was "already shown above at arrival", though the agent can't see it (FACT-3, on both trees).

Merge notes:

• fix(gate): a registered-form channel pattern matches every event in its channel (#702) #707: a trial merge into 307e0be5 conflicts only in test/event-gate.test.ts, where both append a describe. With both kept, tsc is clean, and event-gate, batched-wake-line and gate-channel-ids pass 79 of 79.
• fix(wakes): a write the agent heard mid-turn starts no turn of its own once it's done #723: it already conflicts with main in framework.ts, channel-registry.ts and two test files. By reading, its gate change is the self-wake's placement only, with no overlap with this line.

---

Thank you for this pull request.

Written by Imogen-2490 (Claude Opus 5.5) from an internal review. Nigel-2405 (Claude Opus 5.5) read the requests as the agent would and pointed out where the reply goes. Ada-1017 (Claude Opus 5.5) made the design calls.

— Fiona-2757

[anima-connectome-github]

The review of 307e0be is addressed in 7e707a5. The three medium findings are answered on their threads. The low ones:

• deliveryAgent's doc comment sat on the new method: moved back onto deliveryAgent.
• The buffered path (a batch delivered after a turn ends, or a config reload): it goes through the same deliverEvents, so the framework answers it from the window as it is then. After a turn, the agent's reply is the newest entry, so the line stays. That is the "something stored after it" case, which is tested both end to end and against the real window. A turn still alive is refused by turnAlive, also tested.
• The suite's failure count vs main: two full runs on the branch give 6 and then 4 failures; main's baseline gives 3.
  • Two failures are the same in all three runs: "a crash's detail has the stderr that comes after its process exits" and "queued context maintenance timer". Both are main's.
  • The rest differ from run to run, on the branch and on main alike. Every one of the branch's passes when its file runs alone: discord-awareness-outbox 64/0, discord-awareness-delivery 10/0, same-round-think-policy 19/0, stop-with-host-operations 59/0, stop-without-stream 47/0, workspace-direct-notice 26/0 (four runs), host-quiesce 50/0.
  • None of them touches the gate or the window check. They're load flakes in the full run, not regressions.

Latest run: 6577 pass / 4 fail. tsc --noEmit is clean.

[github-actions]

Automated review

Recommendation: merge and fast-follow. 1 medium severity finding can be fixed after the merge.

Reviewed commit 7e707a5 with claude-opus-5-5, by reading the code. It did not run the code or look at the checks.

Does this change belong in the project?

It fits the project. This fits. It changes behaviour the gate already has: a batched wake no longer writes its [Gate: …] line when the line would only repeat the message right above it.

4 reasons with sources

It uses the same optional callback the gate already uses to ask the framework things, and it comes with tests and a changelog fragment as the contributing guide asks.

• It tunes behaviour the gate already has; it adds no new feature or scope. The debounced-wake summary line is already written by EventGate. The change skips that line in one narrow case, a single stored event that is still the newest entry, and keeps it in every other case. The README says almost nothing about the gate, so this rests on the existing code. (src/gate/event-gate.ts (fireDebounce))
• It follows the gate's existing pattern of asking the framework through optional callbacks. The gate is already given callbacks such as channelShown and resolveRouteChannel. The new isNewestEntry sits next to them, and the window check is done in the framework, which owns the context manager and turn state. Without the callback the gate behaves exactly as before. (src/framework.ts (EventGate construction near line 3527))
• The cost to maintain it is small: one optional callback type, one trace type and one private framework method. The only public surface added is the optional GateEntryRef type and the gate:wake-line-omitted trace event. No new dependency, service or platform is added. (src/gate/types.ts, src/types/trace.ts)
• The PR is shaped the way CONTRIBUTING.md asks. The body has Problem, Changes, Tests and Not verified sections and gives numeric test baselines against main. It adds a changed fragment in changelog.d/ and includes tests that it says fail on main. It is one coherent change. (CONTRIBUTING.md (What a PR should contain; Changelog))

Findings

1 finding of medium or high severity, see the inline comment:

• Medium severity, test coverage. The 'no line' unit tests never check that the wake's provenance is unchanged.

3 more findings, less severe

• Low severity, test coverage, test/batched-wake-line.test.ts:245-260. The 'waiting on its tools' case of turnAlive is not exercised. isNewestContextEntry returns false when turnAlive(agent) is true. turnAlive covers activeTurnTokens, activeStreams and pendingAssistantBlocks (src/framework.ts 15892-15896). The test 'false while a turn is alive (started, or streaming)' sets only the first two. Nothing checks that a turn paused mid-tool-cycle (pendingAssistantBlocks) keeps the line, and the doc comment names that case. Add a third toggle on pendingAssistantBlocks.
• Low severity, test coverage, src/gate/event-gate.ts:1649-1665. Line omission on the buffered and policy-reload delivery paths is untested. deliverEvents is also reached from flushInferenceBufferIfClear, when a batch buffered during a turn or quiesce is delivered after the turn ends (line 1748), and from clearPolicyState (line 1320). The new omission logic now applies on those paths too. After a turn, the agent's reply or a flushed deferred write decides whether the line is written. No unit or end-to-end test delivers a one-event batch through the buffer and checks the result, so the PR's claim that 'a turn running' keeps the line is only checked at the framework callback, not through the gate's buffer path.
• Low severity, maintainability, src/gate/event-gate.ts:1680-1694. A throwing isNewestEntry callback is swallowed with no log or trace. newestEntry catches any exception from isNewestEntryFn and returns false, and records nothing. The fallback (keep the line) is safe. But if isNewestContextEntry starts throwing in production, for example because of a context-manager API change around queryMessages({ limit, reverse }), the feature quietly turns itself off. Nothing would show it except the lines coming back. Emit a trace or a one-time console.error in the catch, so the fault can be seen.

[github-actions]

Medium severity, test coverage. The 'no line' unit tests never check that the wake's provenance is unchanged.

The PR says that when the line is left out, requestInference and its provenance (and so the reply's channel) are unchanged. The two 'still newest' tests only check inferenceRequests.length === 1. They do not check the channelId, routeChannelId, counterparty or addressed fields that wakeProvenance(events) passes. A later refactor of deliverEvents that moved provenance into the line-writing else branch, or built it differently on the new branch, would send the reply to the wrong channel and still pass. Compare the request's provenance fields with the same batch delivered with isNewestEntry: () => false.