[nissa-seru]

A message a tune-out holds from the residents now stays out of a resident's live turn. When it's still held at the cancel, the cancel's backlog carries it to the residents. When the cap leaves it out, the subconscious's cancel report notice hands it to the subconscious, whose report reaches them. A module's ctx.queryMessages and ctx.getMessage mark it heldFromResidents: true. Before, a tool boundary handed such a message to the turn that was alive when it arrived, the backlog and the report left out a message still held, and a module's reads answered it as an ordinary row.

Problem

Each defect is a run at main 15aadc96, on Linux with Node 24.22.0, chronicle 0.4.0, context-manager 0.14.1 and membrane 0.5.87:

• The live turn. With the resident's round waiting on a module tool, a message to the tuned-out channel was held, and at the boundary it was among the messages handed to the stream (injectedMessages).
• The backlog. Cancelled while such messages were held, the <tuned-out-backlog> carried the stored messages and not the held ones (tests 3 to 5 below, red at main).
• The mark. A module's queryMessages({}) answered a tuned-out message as an ordinary row, with metadata.tuneOut set and no other mark, and getMessage did the same.
• A self-cancel with no note. A cancel the subconscious made itself, without the optional note, at backlogCap 0 over two stored messages, gave the resident a <tuned-out-backlog> reading messages=2 truncated=2 with neither message in it, and gave the subconscious no notice and no turn to report on them (tune-out-cancel-held test 6 below, red at main).

connectome-host's retrieval module leaves out held: true rows and sends the last ten rows to its model as the recent conversation it picks lessons from (src/modules/retrieval-module.ts:460-465 on connectome-host main 11dc773c). So, by reading that code, a resident that tunes out a busy channel gets lessons chosen from that channel's messages. The mark alone doesn't change what retrieval picks: its filter has to skip marked rows too.

• A field of its own, because held: true means the framework still holds a write, and the row's id is then a held: handle (ModuleMessage.held).
• Not leaving held rows out of queryMessages, because a module that matches what's stored needs them. The Discord module's history sync looks rows up by channel and by external id (src/modules/discord/index.ts:1232, :1249), and a message it couldn't see would be stored again. That's a reading of the code; we haven't run it.

Changes

• The live turn. A tuned-out message that arrives while the resident's turn is alive is held, and the next tool boundary stores the held writes. It used to inject every one of them into the live turn, this one included. It now stores it without injecting it, since the resident's compiled view leaves it out anyway. This is Tune-out: all-except scope (supersedes focus #195), hardening, and a depth review #232's gap 5, which our proposal of October 6 there named ("mid-turn injection drains deferred messages without that filter"). feat(dendrite): one registry, lifecycle and fork primitive for agents; admission, reader forks, the all-except scope and speech.locus (#232, #77, #270) #546 fixes it the same way in its own version of the loop.
• The cancel's backlog. A cancel's <tuned-out-backlog> was built from stored messages only, so a message still held when the tune-out was cancelled was left out of it. On main, the injection above delivered it to the live turn if a tool boundary followed. With the injection gone, the backlog now carries the tune-out's held messages after its stored ones, oldest first, so the dump is where the resident reads it. This is Tune-out: all-except scope (supersedes focus #195), hardening, and a depth review #232's gap 7, built as feat(dendrite): one registry, lifecycle and fork primitive for agents; admission, reader forks, the all-except scope and speech.locus (#232, #77, #270) #546 builds it: an optional getDeferredMessages hook, given the deferred writes for the primary. The hook sorts them by seq, as every other listing of the queue does, since a store write refused at a boundary goes back to the end of the queue.
• The cancel's report. The subconscious's cancel report covers what the dump leaves out: the messages before the last backlogCap of them, or all of them when it's 0. Its view holds stored messages only, and it can run while the resident's turn still waits on a tool, before the boundary stores the held ones. So the held messages the dump leaves out now follow its report notice, each a row of its own with its own content (an image reaches it as it came). So does a held message the dump shows whose image or audio its text lines drop, as the dump renders text only. As rows of their own, the subconscious's per-message cap (maxMessageTokens, which it mirrors from the primary) cuts each one on its own, its author's label included, so a busy channel's batch doesn't lose its newest messages to the cap, or, by our reading of context-manager 0.14.1, have the report turn refused as one row over the budget. The notice gives the count of messages above the cap. A cancel the subconscious makes itself gets no report turn on main: its note, if it writes one, speaks for what it saw. It now gets the notice and a report turn too when any held message goes to the notice, since it wrote its note, if any, before it could see them.
• A self-cancel with no note. main gives a cancel the subconscious makes itself no report turn, since its note carries its words, but the note is optional. Such a cancel now gets the notice, with the count above the cap, and a report turn when the cap cut anything, stored or held. A resident at backlogCap 0 then reads the same empty backlog, followed by the subconscious's report on those messages. With a note, the note still speaks for what the subconscious saw.
• The mark. A module's reads now carry heldFromResidents: true on such a row (ModuleMessage): queryMessages' stored rows, and getMessage's answer by id, by a held write's handle, and for the stored row a handle names once its write lands. A held write that carries the stamp is marked as well as held.
• Nothing else changes. The rows, their order and totalCount are as before, and a row without the stamp has no heldFromResidents key.

#546 has the injection check and the backlog's held messages already, in its own lines. This branch also sorts the held writes and hands the report the held messages the dump leaves out, which #546 doesn't. A trial merge of this branch into #546's head 220f4cff conflicts in src/framework.ts (two hunks, at the hook and the check), src/tune-out/coordinator.ts (five hunks, at the hook's doc, the backlog, its lines, the report's guard and its notice) and src/mcpl/channel-registry.ts, the last as merging main alone does.

The mark is about the row. The text can still reach a resident in rows of their own, which aren't marked: the cancel's <tuned-out-backlog> row, with the last backlogCap of the tune-out's messages, the stored ones first and then those still held; what the subconscious says of it; and the answer of a tool that reads history on request, such as a channel's fetch_history or the history module's extract. The history module reads the store directly rather than through a module context, so its tools' answers carry no mark: they are how a resident reads held messages when it asks.

What each part is for

• The injection check (framework.ts, at the tool boundary): keeps a stamped write out of the live turn. The write is still stored, acked and noted for the other residents, as before. The drain's comment says why that keeps the window and the live request matched.
• getDeferredMessages (tune-out/coordinator.ts, given by framework.ts) and the backlog: a message held at the cancel reaches the dump, the one row that then shows it to the resident. The hook's sort keeps the held ones oldest first, so the cap keeps the newest of them.
• The report notice's held messages (tune-out/coordinator.ts, heldForReport): the held messages the dump leaves out, and those it shows whose media its text lines drop, reach the subconscious's report, which can't see them in its view yet. Each follows the notice as a row of its own, its author's name (authorOf, which the dump's lines use too) and then its own content blocks, so media isn't dropped and a per-message cap applies to each. The notice says how many follow it.
• The self-cancel's notice and report turn (the guard !selfCancel || heldForReport.length > 0 || (!subconsciousNote && truncated > 0)): a cancel the subconscious makes itself gets them when a held message goes to the notice, which its note can't cover, or when it wrote no note and the cap cut anything, which nothing else covers.
• The count above the cap (truncNote): whenever the notice goes and the cap left messages out of the dump, a self-cancel's included, it says how many, since the note is optional. It tells the subconscious that its report covers a tail the resident hasn't seen raw.
• asModuleRow (src/held-writes.ts): the one place that turns the stamp into the mark, used by every read path below. It tests the stamp the way the residents' viewFilter does.
• queryMessages: marks the stored rows on both of its returns, with and without held writes among them.
• heldRows: marks a held write whose metadata carries the stamp, so queryMessages and getMessage answer it marked before it lands.
• getMessage: marks a stored row by id, a held write by its handle, and the stored row a handle names once the write lands.
• ModuleMessage.heldFromResidents and the getMessage and queryMessages docs: the contract a module reads, including where the text can still reach a resident.
• The changelog fragment: a bullet each for the live turn, the mark, and the backlog with the report, for the release notes.
• The headers of deferred-window-only and present-while-acting: they said every held write is injected at the boundary, and now name the exception.
• test/module-rows-held-from-residents.test.ts: the cases below.
  • Its ProbeModule reads through a real module context, and holds the resident's turn alive with a pending tool. A quiesce would hold writes too, but it pauses the MCPL data plane, so no channel message would arrive.
  • Its waits for what the test sets off (waitFor, within) are bounded at 15 s, so a hang there fails fast.
  • Each test opens its own framework, so no reply one test queues on the mock reaches another's turn.
  • reportOf reads the subconscious's notice and the rows of kind tune-out-cancel-held after it, the kind that tells a held row from the notice and from the subconscious's other rows.
  • CappedPassthroughStrategy, given to the primary through open()'s strategy option, sets the maxMessageTokens of 80 that the subconscious mirrors, so test 6's four held messages go past the cap together, though each fits under it. Without it nothing is cut, and the test can't tell one row from four.
• test/tune-out-cancel-held.test.ts: the coordinator's cancel on its own, with stubbed hooks. Another epoch's messages, a held image and both sides of the self-cancel guard are simple to set up there, where the MCPL fixture sends one channel's text.

Tests

test/module-rows-held-from-residents.test.ts, on tune-out-e2e's MCPL fixture:

1. A stored held message is marked by queryMessages and getMessage, during the tune-out and after the cancel, including in a reversed query of one row, which still counts every match. An ordinary module write and the cancel's <tuned-out-backlog> row aren't marked, and the resident's compiled view leaves out the marked message and shows the ordinary one.
2. A tuned-out message that arrives while the resident's round has a tool pending is a held write, marked as well as held, beside a marked stored row. A module write held in the same turn, queued behind it, has no mark. At the boundary, the module's write reaches the live turn and the tuned-out message doesn't. Its stored row is marked once it lands, by the handle, by its stored id and in queryMessages.
3. With backlogCap 3, two stored messages, two held tuned-out messages and a held module write, a cancel's <tuned-out-backlog> reads messages=4 truncated=1. It carries the newer stored message and both held ones, and leaves out the oldest and the module write, and the subconscious's notice carries no held message. At the boundary, exactly one injected message carries the held text, the dump, and the first original lands under its handle, marked. The resident's view holds each held text once, inside the dump.
4. With backlogCap 1 and two tuned-out messages held, with the queue out of seq order as a requeue leaves it, the dump shows the newer one, and the subconscious's report notice is followed by the older one, as a row of its own.
5. With backlogCap 0 and two held, a cancel in the subconscious's name, with a note, gives a dump that counts both and shows neither, and its notice is followed by both, oldest first, a row each. The cancel is the one cancel_tuneout makes, called while only the resident's turn runs, not from the subconscious's own turn.
6. With the primary's maxMessageTokens at 80, four held messages of about 55 tokens each and backlogCap 0, a cancel leaves each held message whole in the subconscious's compiled view.

test/tune-out-cancel-held.test.ts, on the coordinator alone:

1. Beside another epoch's stored and held messages and an unstamped one, a cancel whose cap shows them all gives a dump of its own epoch's two, and a notice with no count above the cap and no held message.
2. At backlogCap 0, the notice gives the count above the cap and how many held rows follow it, and the rows are exactly each held message once, oldest first, its author then its blocks, an image as it came, without the other epoch's or a stored one.
3. A held message the dump shows, whose image its text line drops, follows the notice with the image.
4. With backlogCap 2 over three held messages, a text-and-image one, a URL image alone and an audio clip alone, the rows after the notice are exactly the one the cap cuts and then the two media-only ones the dump shows, each once, with its blocks as they came.
5. A cancel the subconscious makes itself, with no note, gets the notice, the count and a report turn when a held message is left out or the dump shows a held image. It gets neither when the dump shows a held text message.
6. A cancel the subconscious makes itself with no note, at backlogCap 0 over two stored messages, gives a dump reading messages=2 truncated=2 with neither in it, and the notice, with the count and no held message, and a report turn. With a note, or with nothing cut, it gets neither.

Runs, on Linux with Node 24.22.0, chronicle 0.4.0, context-manager 0.14.1 and membrane 0.5.87:

• At this head, from a clean checkout: typecheck passes, and the two new files and 25 neighbours pass: 631 tests, none failing. The neighbours are the test files a grep for .queryMessages(, ctx.getMessage and ModuleMessage finds, the five tune-out-* files, deferred-window-only, present-while-acting and state-read-and-write-errors, which builds the coordinator's hooks.

• Red first: at main 15aadc96 with only this branch's two test files and ModuleMessage type, all twelve tests fail, among them on "queryMessages marks it", "a held write with the stamp is marked", "the dump shows the newest", "the dump counts both and shows none", "a held message left out brings the notice" and, for the self-cancel with no note, "with no note, nothing else covers them, so the notice comes".

• At this branch's previous head, 4be0dacc, with this head's two test files, seven tests fail: the per-message cap test on "the subconscious's view holds held message 1 whole", and the six that look for held rows after the notice, which that head doesn't add.

• Removals: each change below, taken out alone at this head, fails a test:

  • the injection check: "the tuned-out message doesn't";
  • the backlog's held messages: tests 3 to 5, and the coordinator's;
  • the hook's sort: "the dump shows the newest";
  • the notice's held messages: test 4 times out waiting for the held row after the notice, and test 6 fails on "the subconscious's view holds held message 1 whole";
  • their clamp at zero: "the notice carries no held message, as the dump shows them all";
  • their content blocks: the coordinator tests' exact rows;
  • the held media the dump shows: "a held image the dump shows brings the notice too";
  • that media taken from every held message rather than those the dump shows, or narrowed to base64 images: "Ann's left out, then the media the dump shows, each once and oldest first";
  • the held rows put back into one row: "the subconscious's view holds held message 2 whole";
  • the count above the cap: "it gives the count above the cap";
  • the self-cancel's notice: "a held message left out brings the notice", and test 5 times out waiting for it;
  • its notice for a held image the dump shows: "a held image the dump shows brings the notice too";
  • its notice with no note when the cap cut stored messages: "with no note, nothing else covers them, so the notice comes";
  • the epoch filter on either half of the backlog: "the backlog is the epoch's four messages, and the cap cuts one";
  • the four places that apply the mark: queryMessages with no held write, queryMessages beside held writes, heldRows and getMessage.

  So does the check written as a break instead of a continue: "the module's write reaches the live turn".

Not verified

• macOS and Node 20, where CI runs the typecheck, the build and the suite.
• What a subconscious writes in its report. The tests check what the notice hands it, not what a model then says.
• connectome-host's retrieval module skipping marked rows. That's a change on connectome-host's side, and this pull request only gives it the mark to skip.
• The Discord module's sync dedupe, by reading only, as above.

---

• Changelog fragment added: changelog.d/module-rows-held-from-residents.fixed.md

Written by Hilda-2681 (Claude Opus 5.5), contributing through nissa-seru. Ada-1017 (Claude Opus 5.5) made the design calls, and Hilda-2580 (Claude Opus 5.5) read each round.

Description checked and posted by Lottie-2661 (Claude Opus 5.5).

🤖 Written using Anthropic's Claude Opus 5.5 through the Rookery's tooling, and posted from the shared nissa-seru account.

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The changes affect tune-out message delivery and the shared module message-read contract.

The PR appears safe to merge, with a non-blocking concern about large cancel-report messages.

Findings

1.  Cancel reports grow without bounds ▶

Fix with agent prompt

### Issue 1
src/tune-out/coordinator.ts:389-397
With `backlogCap` set to `0`, this combines every held message into one `tune-out-cancel-report` row. A busy channel can build up a large batch while a resident waits on a tool. If `maxMessageTokens` is configured, the subconscious applies that limit to the combined batch rather than each original message. Without that limit, the combined row can outgrow its context budget.

Keep the notice small and pass the content through bounded rows or batches. Add a test where the combined content exceeds the per-message limit.

---

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

Summary

Keeps tuned-out messages out of live resident turns and marks them in module reads.

• A tuned-out message no longer enters the live turn at a tool boundary.
• Cancelling a tune-out brings held messages into the dump or report.
• Module reads flag messages the residents cannot see.

_{Reviews (1) · Last reviewed commit: "fix(tune-out): report a note-less self-c..." · Reviewed by Greptile}

[greptile-apps]

Cancel reports grow without bounds

With backlogCap set to 0, this combines every held message into one tune-out-cancel-report row. A busy channel can build up a large batch while a resident waits on a tool. If maxMessageTokens is configured, the subconscious applies that limit to the combined batch rather than each original message. Without that limit, the combined row can outgrow its context budget.

Keep the notice small and pass the content through bounded rows or batches. Add a test where the combined content exceeds the per-message limit.

Knowledge Base Used: Agent runtime orchestration

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/tune-out/coordinator.ts
Line: 389-397

Comment:
**Cancel reports grow without bounds**

With `backlogCap` set to `0`, this combines every held message into one `tune-out-cancel-report` row. A busy channel can build up a large batch while a resident waits on a tool. If `maxMessageTokens` is configured, the subconscious applies that limit to the combined batch rather than each original message. Without that limit, the combined row can outgrow its context budget.

Keep the notice small and pass the content through bounded rows or batches. Add a test where the combined content exceeds the per-message limit.

**Knowledge Base Used:** [Agent runtime orchestration](https://app.greptile.com/anima-labs/-/custom-context/knowledge-base/anima-research/agent-framework/-/docs/agent-runtime.md)

---

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

[nissa-seru]

Addressed in 62856c53. The notice is now one row that says how many held messages follow it, and each held message follows it as a row of its own for the subconscious, with its author's label and its own blocks. The subconscious's per-message cap, which it mirrors from the primary's maxMessageTokens, now cuts each one on its own rather than the batch's newest, and a batch over the usable budget no longer arrives as one row, which by our reading of context-manager 0.14.1 the strategy would refuse.

The test you asked for is test 6 in test/module-rows-held-from-residents.test.ts. It gives the primary a maxMessageTokens of 80, holds four messages of about 55 tokens each while the resident's turn waits on a tool, cancels at backlogCap: 0, and checks that each held message is whole in the subconscious's compiled view. At this branch's previous head, 4be0dacc, on Linux with Node 24.22.0, it fails on "the subconscious's view holds held message 1 whole".

Written by Hilda-2681.

— Lottie-2661

[nissa-seru]

@antra-tess Flagging for your awareness this PR, which made the following changes to what residents see (in brief):

• With a subconscious and a tune-out: a message the tune-out held while the resident's turn was alive is no longer injected into that turn.
• The cancel's <tuned-out-backlog> now also holds the messages still held at the cancel, oldest first. Before, they were left out.
• The subconscious's cancel report: … were above the cap and not delivered raw.] → … were above the cap and not delivered raw to the resident.], with Still held at the cancel, so your view may not have them yet: the <N> message(s) after this one. where held messages follow, and then a row for each of them. fix(tune-out): fit the cancel's backlog in one message of each resident that reads it #593 has since rewritten that first sentence, and fix(tune-out): a channel's cancel makes its dump durable before it records the end #909 added a form of it for several dumps.
• A cancel the subconscious makes itself now gets that report and its turn too, where held messages follow, or where it wrote no note and the cap left messages out of the backlog.

— Lottie-2661