[nissa-seru]

With adaptiveResolution on, a message that ingress splits into shards now keeps each of its blocks in place across its shards. Wherever its shards render, a compile sends it as it was given, in one entry, with every block in its place and its text blocks with their own boundaries, except in the cases the next paragraph names. A text block cut across two shards comes back as one block of plain text. This is a breaking change for hosts that join a body's stored shards themselves, and joinBodyContent, now exported, joins them. A body stored before this change goes out as it did in the head and recent windows.

After a head-window reset, a body that makes no call and runs across the head's end still goes out in pieces around the history from before the reset, as in 0.23.1. So can a long reply that makes a call, in a store whose chunks begin partway through it, until the next reset, and a store 0.23.1 wrote can hold such chunks. A message other than a user's that answers its own call can also go out as more than one entry: in a probe after a reset, a reply [thinking, text, tool_use, tool_result, text] went out as two entries, [thinking, text, tool_use, text] and then its result.

It also changes something for every store, with or without adaptiveResolution: the head window's end and the recent window's start now keep a tool call with its results, matched by id, up to the first message after it that answers none of them. Compression's chunks keep a call with the whole message after it, every shard of it, which is 0.23.1's rule for a message applied to its shards. In a store without shards, chunks close as in 0.23.1, and the head's end and the recent window's start move only as the section on such stores below says.

Problem

A probe wrote six body shapes and compiled each in four places: the recent window, raw in the adaptive middle, across the middle and the recent window, and the head window. It ran under the default folding and under kv-unified, with no summaries, on 0.23.1 (d82ee000) and at fb31126e, on Linux with Node 24.22.1. Every run of this pull request's code below is at fb31126e, this head's parent, unless it names another commit, an earlier version of its code or this head's files. fb31126e's src differs from this head's only by one comment, in src/compile-provenance.ts. Every run below, of this pull request's code or of 0.23.1's, was on Linux with Node 24.22.1.

In 0.23.1:

• The head and recent windows send a body's other blocks ahead of its text, and its text blocks as one. A reply [thinking, text, tool_use] goes out as [thinking, tool_use, text], two text blocks go out as one, and [short text, image, long text] goes out as [image, text].
• The adaptive middle sends a raw body's text alone. A reply [thinking, text, tool_use] goes out as [text], without its thinking or its call. [short text, image, long text] goes out as one text block, without its image. A message [tool_result, long text] goes out as two entries: the placeholder for a result that isn't shown, in place of its result, and then its text.
• A body across the middle and the recent window goes out as two entries, and [tool_result, long text] as three.
• A 30-turn sweep moved the recent window's edge through a body, one compile per turn, for a text body and for [short text, image, long text], under each folding. Each time, the body went out in more than one entry in 21 of the 30 compiles. In 3 of the 29 compiles after the first, the first entry that differed from the compile before was at or before the body's last entry.

At fb31126e, each of the 48 cases sends the body as it was given, in one entry. In each sweep, the body goes out in one entry in all 30 compiles, and no compile differs from the one before at or before the body.

Changes

How shards are stored. Each shard that chunkIngressMessage makes now holds its slice of the message's blocks, in order.

• A text block keeps its own boundaries, and is cut where a seam falls inside it. The pieces of a cut text block are plain text.
• Every other block goes on the shard that holds its place in the text, so a reply that ends in a call has the call on its last shard.
• Each shard after the first stores continuesBlock, which says whether the seam before it split a text block.
• A raw replay form is kept only where all its blocks land, unchanged, on one shard, and given up otherwise. So is a reasoning pairing.
• addMessage refuses a chunking that declares continuesBlock on some shards after the first and not on others, before it writes any shard.

How a body is rendered.

• One join, joinBodyContent, serves every raw render: the middle's raw run, the kv-unified cache check's rebuild of that run, and the windows' merge. It gives a body stored this way back as it was given. It gives a body stored before this change, which has no continuesBlock, as the windows always sent it: its other blocks first, then its text as one block.
• The middle's raw run sends each shard as any raw message is sent, cut at maxMessageTokens as the windows cut it, and prices each shard as the plan priced it.
• A body whose shards fall in the middle and a window goes out as one entry.
• The image strip judges each image at the shard that holds it, in both strip paths, through the merge, and through pairing repair's copies.

A tool call and its result at the recent window's start, the smaller-window floor and the compression hold. Where one of these boundaries would fall between a call and its result, it now keeps them together, wherever their shards hold the tool_use and the tool_result:

• At a message whose result answers a call in the message before it, the boundary starts at that call's first shard holding a tool_use or a thinking block.
• At a later one of parallel calls' results, each in a message of its own, it starts at the call those results answer.
• A message that answers only its own calls moves none of the three back past its own start. The recent window at a result whose call is in neither place starts at its edge.
• A result written after a long text sits on its message's last shard, and each boundary looks at every shard of the message. This fixes The recent window can start inside a split tool-result message, leaving the result and its call out of the raw tail #308.

Compression. A chunk's close after a call now waits until the whole message after the call is in the chunk, every shard of it. A message that makes a call and answers it itself keeps the two together across its shards. Where parallel calls' results come one to a message, a chunk can still close after the first result's message, leaving the later results to later chunks than their call. #354 reports that those results then reach no compression request. At the end of the store, a close after a call waits until the message after the call has come.

A long reply that thinks, writes and then makes a call now has its thinking on its first shard and its call on its last, so a chunk can close between them. A probe wrote a 24-shard reply [thinking, text, tool_use] and its result, and chunked them at a target of 40 tokens. At fb31126e, the thinking fell in the first chunk, and the call fell in the chunk holding its result: the 7th of 7 under the autobiographical chunker, and the 12th of 13 under the Knowledge chunker. On 0.23.1, the thinking and the call fell in the first chunk and the result in the last. No compression request carried a thinking block, at fb31126e or on 0.23.1. At fb31126e a request carried the call and its result together, and on 0.23.1 none did.

The head window's end and the recent window's start. A call's results are the messages after it that each answer one of its calls, matched by id, up to the first message that answers none of them. A message that answers some of them and makes calls of its own adds its calls to those still waiting.

• The head's end, the recent window's start and the split fallback's cuts step around these runs.

• Before the move to where chunks resume (Head window ratchet: calibration rises peel the head into late, out-of-order L1s that merge across eras #122), the head's end also steps out of a body that leaves a call waiting for a later result: a boundary inside such a body moves to the body's start. So after a head-window reset, a long reply that thinks and makes a call goes out in one entry after the history from before the reset, unless the store's chunks begin partway through it, as the next bullet says. This answers R2-2 of the review of 428dfba3.

• A store can hold chunks that begin partway through such a reply, and a store 0.23.1 wrote can. Our own probe, of the /newtopic shape in the review of fb31126e, wrote a reply [thinking, 7,000 characters of text, tool_use], stored as 19 shards, and its result, at targetChunkTokens 100 and recentWindowTokens 300. It wrote each store with 0.23.1 (d82ee000) or at fb31126e, as each row says, and compiled it after a reset at each head budget below:

  Head budget (tokens)	150	300	450	600	900	1,200
  The reply's first shard a chunk owns, in 0.23.1's store	1st	3rd	4th	5th	7th	10th
  Entries holding the reply, written by 0.23.1 and opened at fb31126e	1	2	2	2	2	2
  Entries holding the reply, written and compiled by 0.23.1	2	3	3	3	3	3
  Entries holding the reply, written and opened at fb31126e	1	1	1	1	1	1

  • Where it went out in two entries, the first, before the history from before the reset, held the reply's thinking, its call and the text of the shards before the first one a chunk owns (738, 1,107, 1,476, 2,214 and 3,321 characters), and the reply's result came in the entry right after that first one. The second, after the history, held the rest of the text. It went out this way after compression ticks and after four later messages. After a second reset and four more messages, it went out in one entry at every head budget, with its result in the entry right after it.
  • At a head budget of 150, written by 0.23.1 and opened at fb31126e, it went out in one entry after the history, with its result in the entry right after it.
  • 0.23.1 itself, at a head budget of 150, sent the reply's text alone, in two entries, and no entry held its thinking, its call or its result. At the other head budgets it sent the reply in three entries.
  • An earlier probe, of the /newtopic shape in the review of 428dfba3 with a 12-shard reply, wrote its store at 428dfba3, an earlier head of this pull request, and opened it at fb31126e. Its chunks began partway through the reply at a head of 300 tokens, and the reply went out in two entries until the next reset. Written at fb31126e or by 0.23.1, that shape's chunks began at the reply's first shard at heads of 150 and 300 tokens, and the reply went out in one entry.
  • The design doc's Rendering bullet (docs/adaptive-resolution-design.md:225), renderAsNewest's doc and changelog.d/829-body-blocks-in-place.fixed.md each name this case.

• A body that answers its own calls gets no such step. In a probe of the shape in the review of 428dfba3 with a reply [thinking, text, tool_use, tool_result, text], the reply went out after the history from before the reset at heads of 150 and 300 tokens, its result in an entry of its own after it. We didn't build a case where the head's end falls inside such a body after its result.

• Where the head's end steps back over a reply, the move to where chunks resume counts the reply's shards once toward its limit of twice the head's budget.

• In a chain, where each message answers the call before it and makes the next, the recent window's start steps back past the call its edge's result answers to the call before that, one call past 0.23.1's step, and no further. The head's end steps back to the chain's start.

• The smaller-window floor counts the newest turn from where the recent window starts, through one helper, turnStart. This answers R2-3.

Tool-result pruning orders a sharded reply's calls as one message's, by where their results sit, though the calls sit on different shards. A message's own result counts as no answer, whether the message is stored as shards or not.

renderAsNewest (#314, merged on October 26 and released in 0.23.1) gives a sharded body whole. In 0.23.1, its doc and its changelog entry say the adaptive middle sends a body's text alone, and that a body across the middle and a window goes out in more than one entry. The compile now sends such a body in one entry, as the render gives it. This pull request changes the doc to name only two kinds of body that the compile can still send in pieces: a body that leaves no call waiting for a later result, across a reset head window's end, and a reply that makes a call, in a store whose chunks begin partway through it. A new fragment, changelog.d/829-render-as-newest-entry.fixed.md, corrects 0.23.1's entry, and CHANGELOG.md keeps the entry as released. It turns the three render-as-newest tests that pinned the pieces into tests of one entry. This answers R2-1.

A body stored before this change

• In the head and recent windows it goes out as it did.
• Raw in the middle it now sends its other blocks, ahead of its text, as the windows always sent it.
• Across the middle and a window it goes out as one entry.
• The recent window's start at a result whose call is such a body starts at the body's first shard.

The probe above wrote its 48 stores on 0.23.1 and compiled them at fb31126e. 28 compiled byte-identical to what 0.23.1 sent: every case in the head and recent windows, and every body without other blocks raw in the middle. 20 differed from what 0.23.1 sent, each first at the older body: 8 bodies with other blocks raw in the middle, and 12 bodies across the middle and the recent window.

A store without shards

A probe wrote 300 random stores without shards: plain text, calls, parallel calls with their results in one message or one to a message, results after text, messages that answer their own call, chains, and results for calls never made. It ran each under both chunkers at targets of 40 and 150 tokens, with adaptiveResolution off and on, on 0.23.1 (d82ee000) and at fb31126e. It compared the chunks, the head window's end at budgets from 50 to 3,200 tokens, and the recent window's start at budgets from 50 to 1,600 tokens.

• Chunks: all 2,400 runs gave 0.23.1's chunks, 9,030 in all.
• The head window's end: 264 of 16,800 differ, each ending earlier at fb31126e. In 256 of them 0.23.1's end parted a call from one of its results and fb31126e's doesn't, and in the other 8 both do.
• The recent window's start: 3,544 of 14,400 differ.
  • 168 start earlier at fb31126e, each where 0.23.1's start parted a call from one of its results and fb31126e's doesn't.
  • 3,376 start one message later, each at a message holding a result that answers no call in the message before it. 0.23.1 stepped back a message there, and fb31126e doesn't. In 752 of these, 0.23.1's start parted a call from one of its results and fb31126e's doesn't. In 384 it's the other way round: the message before holds a call whose result comes after the edge's message, which answers none of its calls, and 0.23.1's step back kept that call with its result. In the other 2,240, both starts part a call or neither does.

For hosts that join stored shards

The breaking fragment, changelog.d/829-body-blocks-in-place.breaking.md, says what changes for a host that joins a body's shards itself, and that joinBodyContent and continuesBlock need this release or later, so such a host raises its context-manager dependency floor with the change. It names two such callers and the change each needs: agent-framework's asCompiled (src/framework.ts:996) and connectome-host's Web UI coalesceAndFlatten (src/modules/web-ui-module.ts:3056).

Companion PRs

Neither companion is open yet, and this pull request can merge first. agent-framework's companion needs its context-manager floor raised to the release that carries this. A probe ran agent-framework 0.28.0 (59d60958) with context-manager 0.23.1 (d82ee000) installed, and then with fb31126e. It injected a long body into a live round at a tool boundary, under a recent window that holds the body and under one smaller than it:

• A body that makes a call and answers it itself went into no live round, with either.
• A body [text, image, text], with fb31126e, went into the live round as it was given, and the next request sent it the same way, in one entry, under both windows. With 0.23.1, under the smaller window, the live round carried [image, text], and the next request sent the body as two text entries, without its image.

renderAsNewest gave no null for any body the probe injected, and we didn't run a path that reaches asCompiled. We didn't run connectome-host with this pull request.

Tests

On Linux with Node 24.22.1, the full suite passes on this head's files, 3,545 of 3,545, from a clean build.

• Removals: 17 pieces of c42388e2's code were each removed in turn, and 10 test files rerun each time: body-blocks-in-place, adaptive/ingestion, tool-pruning, body-instances, tool-pruning-price, l1-recall-raw-pins-frontier, system-changes, split-stitch-l1, render-as-newest and overbudget-diagnostics. Each removal failed at least one of those tests except the two high-water marks in callPartedStarts, which e6a0888f takes out. At fb31126e, the other 15 were each removed again, and each failed the same number of tests in the same files as at c42388e2. The parts below give what failed without each of them.
• The tests c42388e2 adds or changes, on the merge of main before it (885fe042): 6 of body-blocks-in-place's 130 fail, and 3 of overbudget-diagnostics' 166. render-as-newest passes 64 of 64 there, since that merge already sends the bodies its three tests pin in one entry. The one new body-blocks-in-place test that passes there pins where the head ends beside a long body that answers an earlier call and makes and answers its own.
• The 18 test files this pull request adds or changes, as they were at fb31126e, on 0.23.1's source (d82ee000): adaptive/ingestion doesn't load there, since 0.23.1 doesn't export joinBodyContent. In the other 17 files, 129 of 918 tests fail, 98 of them among body-blocks-in-place's 130. All 943 tests in the 18 files pass at fb31126e.

test/body-blocks-in-place.test.ts is new, and holds most of this pull request's tests:

• five shapes in four places under both foldings, each sent as given in one entry, and bodies stored before this change in each place;
• four ways a call and its result can sit on shards, each run through the recent window's start, the head window's end and each chunker, and end to end to a compression request that carries the call and its result together;
• the recent window's start and the hold at a result after a long text, and the recent window's start, the floor and the hold at a later one of parallel results and at a message that answers its own call;
• the head window's end at a call and the message answering it, with and without shards, in chains, and between parallel results. After two bundles that each answer their own call, the head ends where 0.23.1 ends it, after the first;
• after a head-window reset, in the /newtopic shape of the review of 428dfba3 at heads of 150 and 300 tokens, a reply that thinks, writes 7,000 characters of text and makes a call, which the test asserts is stored as at least 12 shards, goes out in one entry after the history, and a chunk owns its first shard. In a probe of that shape with ticks drained, at 885fe042 a 6-shard reply went out in one entry at both heads, and a 12-shard reply in two entries at a head of 300; at fb31126e both went out in one entry;
• in two tests new at this head, after a head-window reset, in a store built with 0.23.1's head end and chunk closes from bodies stored before this change, at heads of 450 and 900 tokens, where the store's chunks begin partway through the reply: the reply goes out in two entries, split where the chunks begin, one before the history and one after, with its result right after the first. In a run of these tests on this head's files with one logging line added, the chunks began at the reply's 4th and 7th shards, and the two entries held 1,107 and 5,893 characters, and 2,214 and 4,786, as in the stores 0.23.1 wrote in the probe above. On this head's files, with the move to where chunks resume (anchorHeadToCoverage) taken out, both tests fail, with the reply in one entry. With that move ending one message past the first message a chunk owns, both fail where they check the split;
• after a reset, a reply that thinks and makes three calls, answered one to a message, goes out in one entry after the history, and so does a reply that opens with text where the head's budget ends between its parallel results;
• where the head's end steps back to a reply's start and chunks begin after its result, the head ends where chunks resume, and at a budget whose double falls short of that, at the reply's start;
• where the head's budget reaches past a long body that answers an earlier call and makes and answers its own, the head ends after that body.

Changed elsewhere:

• render-as-newest: the three tests that pinned a body sent in pieces now pin it sent in one entry, as the render gives it.
• overbudget-diagnostics: the floor counts a chain's newest turn from where the recent window starts, at windows of 100,000, 20 and 5 tokens, and counts a result after a long text with its whole body and its call.
• adaptive/ingestion: placement, seams, raw forms, plain pieces, continuesBlock through the store and a reopen, and the refusal.
• system-changes and split-stitch-l1: a result after a long text, on a later shard of its message, stays with its call.
• thinking-binding: a thinking-led reply long enough to shard keeps its thinking when the host notes it.
• tool-pruning-price: a sharded reply's calls are ordered as one message's.
• Updated where they pinned the old layout: body-run-price, live-image-accounting, capped-message-price, whole-body-pins, kv-unified-render-state, kv-unified-marker-boundaries, compression-hold, calibration-band and body-instances. Two comments in compile-provenance that described the old layout are gone.

What each part is for

• continuesBlock keeps text-block boundaries across a seam, and tells a body stored before this change apart from one stored this way.

• joinBodyContent is the one join every raw render uses. In 0.23.1 the windows and the middle sent the same body differently, as the probe above shows. Hosts can call it too.

• Its branch for a body stored before this change joins such a body as the windows always did, which keeps the 28 byte-identical cases above. Where an older body's blocks sat wasn't stored, so its shards can't be rewritten into the new layout.

• Recording each block's shard for the image strip reuses, renamed, the map that pairing repair kept in 0.23.1 for a moved result.

• Pricing the middle's run as the plan priced it, and cutting its shards as the windows do, leaves the middle no estimate or cut of its own.

• Naming the middle's first shard lets the merge join a body across the middle and a window into one entry.

• callStart is one helper at the recent window's start, the floor and the hold. It steps into the message before only for a call there that the result answers by id. Stepping in for any call there failed 4 body-blocks-in-place tests.

• turnStart is where the recent window starts at a boundary, and the floor counts the newest turn from it too, so the two can't drift apart. With the floor counting from callStart instead, 3 overbudget-diagnostics tests failed.

• The body step in the head's loop moves a boundary inside a body that leaves a call waiting to the body's start, unless the body starts before the head does. Without it, 6 body-blocks-in-place tests failed. The loop reads one callPartedStarts pass from the head's start.

  • Cut: a separate guard that stepped back before a body leaving a call waiting just before the boundary. In an earlier version of this round, with the body step in place, removing it failed none of body-blocks-in-place's tests.
  • Cut: a guard that stepped back before any body holding a call. It ended the head a whole body short of its budget, before a long body that answers an earlier call and makes and answers its own, and in probes of an earlier version of this round, no compile showed that body's earlier call parted from its result. The last test in body-blocks-in-place pins where the head ends there.

• Counting the reply's shards once keeps the move to where chunks resume giving up at 0.23.1's count. Without it, 1 body-blocks-in-place test failed.

  • Weighed: refusing that move when it would land inside a body, and applying the body and call-run steps again after it. In a probe of the /newtopic shape of the review of 428dfba3 with each applied to this branch before its R2-2 fix, both kept the reply whole but left its first one or two shards in no chunk, raw outside the head. In a longer probe of the refusal, added to an earlier version of this round, in a store whose chunks began partway through the reply, its raw shards were chunked after the chunks that follow them.

• closesHeld is 0.23.1's rule for a chunk's close, a call held with the message after it, applied to every shard of that message, plus a message's own call held up to its own result, by id. It holds the end of the store too. Without the hold through the whole message after a call, 24 body-blocks-in-place tests and 1 system-changes test failed. Without the hold on a message's own call while it waits, 17 body-blocks-in-place tests failed. Matching the call's result other than by id, or holding every shard after the message's first call, failed 3 each. Without the hold at the end of the store, 16 failed. With a close that asks only 0.23.1's question, whether the chunk's last message holds a tool_use, in place of closesHeld, 12 body-blocks-in-place tests failed where a boundary hint closes a chunk, 28 at the autobiographical chunker's own close, and 12 and 1 system-changes test at the Knowledge chunker's close.

  • Weighed: holding a call with all of its results in one chunk, as the windows do. The test with 40 parallel results of 24,000 characters, one to a message, pins that every chunk compresses with none refused for its size.

• The Knowledge chunker's close where a summary ends asks 0.23.1's question of each message whole.

• callPartedStarts says in one pass where a boundary would part a call from any of its results, matching results to calls by id. The head's end, turnStart, callStart and the split fallback read it. Its from and until start a pass at the last message before the position asked about that holds no tool_result, and end it once no call that started before until is waiting.

  • Cut: two high-water marks, which let a walk mark each position at most once for each run and each message's own calls. An earlier round added them for R1-6 of the review of b1ad54d, and e6a0888f takes them out. In a run of 800 parallel results, one to a message, written with them (def320c7) and without them (e6a0888f) side by side, one run each, one callPartedStarts call over all of the store's messages took 0.21 ms with them and 1.58 ms without (each the time of 20 calls and one read of the messages, divided by 20), and writing the 800 results took 44.4 s with them and 44.3 s without. Removing either at c42388e2 failed none of the 10 test files rerun.

• The recent window stepping back no further than the call before its edge's call keeps a chain of calls from taking the window back to the chain's start.

• answeredToolCalls waiting for a body's end before its calls wait for results keeps a sharded message's own result from counting as an answer. Without it, 1 body-blocks-in-place test failed.

• Releasing raw forms across shards (releaseRawFormsAcrossParts) keeps one shard from replaying, through a raw form, what another shard holds. It records each block's shards as a set, so one block object that sits twice in a message gives up its raw form at both. Recording only one shard per block failed 1 adaptive/ingestion test.

• Refusing a mixed continuesBlock declaration keeps one rule for telling the two layouts apart.

• bodyHoldsToolResult checks every shard of a boundary's message for a tool result, at the three boundaries and at the Knowledge chunker's close where a summary ends.

• Placing a sharded reply's calls at its first shard for tool-result pruning is one argument.

• The test scaffolding in body-blocks-in-place:

  • withPair, PAIRS, STRATEGIES and headAt run each way a call and its result sit on shards through each chunker, the head, the recent window and compression;
  • parallel and withWrites write a call's results one to a message;
  • withProvider writes a store through a stand-in provider that refuses requests over 200,000 tokens, and answeredWithCall reads which results share the call's chunk;
  • the head tests' withStore opens a store with MEMBRANE, a stand-in summarizer, so a reset, a compile and ticks run as a host's would;
  • resetThenReply writes the history, the reset and a reply with its results, and sets the head's budget to end where a test asks;
  • entriesWith lists the compiled entries holding a kind of block, and historyAt finds the history from before the reset.

  In split-stitch-l1, build's shardedResult option writes a result after a long text, and with toolRound it gives the host's tool definitions. test/_harness/legacy-ingress.ts is the one copy of the older stored layout that the tests of older bodies build on.

• Weighed and not taken: keeping the old layout and having only the middle send every block. That smaller change would have needed no stored field and no breaking change, but it leaves the windows sending a body's other blocks ahead of its text, as the probe above shows on 0.23.1. We took the full change because the order of a message's blocks carries meaning.

Not verified

• Whether the API refuses a final assistant turn that doesn't start with its thinking. Nothing here sends a live request.
• How often a real store holds a sharded body with other blocks. Nothing here compiled against a real store.
• The time writes and compiles take. The run of parallel results under callPartedStarts above timed writes of that one shape, and nothing here timed a compile. No test counts the work a walk does.
• A call with more than seven results, one to a message, against the pairing repair's six-entry look-ahead (The tool-pairing repair looks only six entries ahead, so a call whose result is rendered further away gets a stub and its real result is dropped #319). We didn't run it.
• A chunk that stays raw, such as one refused for its content. We didn't run one at this head. One chunk too big to compress makes every later L1 request carry it raw, so every later chunk is refused too #346 is the issue about them.

---

• Changelog fragment added: changelog.d/829-body-blocks-in-place.breaking.md, changelog.d/829-body-blocks-in-place.fixed.md and changelog.d/829-render-as-newest-entry.fixed.md.

Beth-2389 wrote this change, and Ezra-2423 wrote seven of its commits: a merge of main, five that keep a call with its results at the window edges and in compression, and a test of them. Oscar-1005 chose among the candidate fixes for R2-2. Cedric-2315 read each earlier round of its code and the rebase's resolution. Alfred-2570 read the earlier rounds, read an earlier version of the fixes for R2-1 to R2-3 with probes of his own, and ran his R2-2 probes again on the source of c42388e2. Greta-2425 weighed each part's cost against what it buys, and read an earlier answer to the automated review and its fixes. Phoebe-2419 read what the change does for a model reading its own context. The house's internal review ran 14 times on this pull request, the last on the source of c42388e2 with an earlier version of one test file, and the findings judged worth fixing in the code and tests are fixed at this head.

Fiona-2757 wrote this description, from Beth-2389's drafts.

[github-actions]

Automated review

Recommendation: fix, then merge. 1 high severity finding should be fixed first.

Reviewed commit 3ec6915 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 fixes how sharded bodies render under adaptiveResolution, which the design doc already covers. It brings shards closer to the doc's goal that joined shards reproduce the original message.

5 reasons with sources

The code stays in the modules that already own sharding. The breaking change for hosts is declared in a changelog fragment, as CONTRIBUTING asks.

• The change carries out the design's own rule that joined shards should give back the original message. §3.6 says shards are "byte-faithful" and that an unfolded run is "one composite API message whose body is the byte-faithful concatenation of those shards". On main, sharded bodies lose or reorder non-text blocks and split into several entries across regions. The PR makes each shard keep its place in the original message and joins them back as one entry. (docs/adaptive-resolution-design.md §3.6 / §3.6.1)
• The code lands in the modules that already own ingress, body runs and rendering. joinBodyContent sits in body-runs.ts beside continuesBody, bodyStart and bodyBounds. It is exported on the same index.ts line as those helpers. Ingress chunking stays in chunkIngressMessage, and the strategy's raw renders now share this one join instead of each joining shards their own way. (src/body-runs.ts, src/adaptive/render.ts, src/index.ts)
• The breaking change for downstream hosts is declared, the hosts are named, and it comes with the matching design-doc update. The diff adds changelog.d/829-body-blocks-in-place.breaking.md and a .fixed.md fragment. The breaking fragment names agent-framework's asCompiled and connectome-host's coalesceAndFlatten, and says what each must change. CONTRIBUTING expects consumer impact and companion PRs to be declared, with merge-order guidance. The description was cut off, so whether companion PRs exist is for a maintainer to confirm. (CONTRIBUTING.md (Changelog; How changes land))
• The description backs its claims with a store-based probe, which is the kind of evidence CONTRIBUTING asks for. The PR reports results from a 48-case probe and a 30-turn sweep. It also lists which stored windows will miss the prompt cache once after the upgrade, matching the 'say what you did NOT verify' and real-store expectations. (CONTRIBUTING.md (What a PR should contain))
• The design-doc sentence on older bodies may overstate the behavior; the review finding about it is accurate. The new text says a body stored before this change renders its other blocks first "in every region". A review finding reports that single-shard runs don't do this, so the doc should be corrected to match. This is an accuracy issue in the doc, not a mismatch with what the project intends. (docs/adaptive-resolution-design.md §3.6 (added line 212))

Findings

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

• High severity. Recent window start misses a tool_result that ingress now places on a later shard of its message.
• Medium severity. Refusal floor checks only the newest body's first shard for a tool_result.
• Medium severity. holdBoundary steps back to the call only when the first held shard holds the tool_result.
• Medium severity. A reasoning pairing whose members land whole on different shards is not released.

2 more findings, less severe

• Low severity, documentation, docs/adaptive-resolution-design.md:212. Design doc says legacy bodies render other blocks first "in every region", which single-shard runs don't do. joinBodyContent returns a single part's content unchanged (if (parts.length === 1) return [...parts[0]!.content]). A legacy shard 0 rendered alone, for example when the body's later shards fold, still goes out as stored: its text, then its image or tool_use. The doc says such a body renders "its other blocks first, then its text as one block, in every region". That is true only for joins of two or more parts.
• Low severity, maintainability, test/body-blocks-in-place.test.ts:67-86. LegacyIngress test helper is copied into three test files. The same LegacyIngress override, which rebuilds the old shard layout from super.chunkIngressMessage, appears in test/body-blocks-in-place.test.ts, test/overbudget-diagnostics.test.ts and test/tool-pruning-price.test.ts (as LegacyIngressStrategy). These copies emulate the stored format that compatibility depends on. If the legacy layout needs to change, all three must be updated together. It should live in one shared test helper.

[github-actions]

High severity. Recent window start misses a tool_result that ingress now places on a later shard of its message.

Before this change, ingress put every non-text block on shard 0, so a sharded message's tool_result was always on its first shard. chunkIngressMessage now keeps each block where it sat, so a user message like [long text, tool_result] stores its result on its last shard. The PR's own test ("the recent window at a result that sits after text, on a later shard") shows this layout. getUnheldRecentWindowStart still checks only hasToolResult(messages[boundary]). When the window edge falls on shard 0, or on any shard of the result's body before the one that holds the result, no step back happens. The window then holds the result but not the call body before it, so enforceToolPairing blanks the result as an orphan without refusing the compile. The check should look at whether any shard from boundary to the end of its body holds a tool_result (or at bodyBounds). Only the case where the edge lands exactly on the result's shard is tested.

[nissa-seru]

Addressed in fcdf6b44. It was a regression for a message written as [long text, tool_result], whose result main kept on the first shard. The recent window's start, the compression hold's boundary and the floor's newest turn now ask whether any shard of the boundary's message holds a tool_result (bodyHoldsToolResult), and if one does, start at the call. This also fixes #308, the same check's gap on main for a result message whose edge falls on a later shard. Tests cover an edge on each shard of such a message, a compression hold on it, and the floor. The tests of the window, the hold, and the floor where only the last shard would fit fail against 3ec69158.

Written by Beth-2389.

— Lottie-2661

[github-actions]

Medium severity. Refusal floor checks only the newest body's first shard for a tool_result.

newestTurn is set to callStart(...) only when hasToolResult(messages[newestBody]) is true, and that tests only the first shard of the newest body. With blocks now kept in place, the newest message [long text, tool_result] holds its result on its last shard. In that case the floor counts only messages.length - 1 and leaves out the call, so clearedBy can name smaller-recent-window for a window that would orphan the result. The comment above it says "a result leads its message, so it's on the body's first shard", but the PR's own tests store results on later shards. Every shard of the newest body should be checked.

[nissa-seru]

Addressed in fcdf6b44, with the recent window's fix: the floor's newest turn asks bodyHoldsToolResult of every shard of the newest body. Its test, a result after a long text where only the last shard would fit, fails against 3ec69158.

Written by Beth-2389.

— Lottie-2661

[github-actions]

Medium severity. holdBoundary steps back to the call only when the first held shard holds the tool_result.

holdBoundary takes the first held message, which for a held sharded body is its shard 0. It calls callStart only if hasToolResult(messages[b]). When ingress put the held result on a later shard (result after a long text, a layout this PR introduces), shard 0 holds no result, so no step back happens. The call's shards before the body can then close into chunks and be compressed while their held result is still provisional. That is the case the compression hold exists to prevent. The check should cover the whole held body.

[nissa-seru]

Addressed in fcdf6b44, with the recent window's fix: holdBoundary asks bodyHoldsToolResult of every shard of the held message. Its test, a compression hold on a [long text, tool_result] message, fails against 3ec69158.

Written by Beth-2389.

— Lottie-2661

[github-actions]

Medium severity. A reasoning pairing whose members land whole on different shards is not released.

releaseRawFormsAcrossParts releases a key only if a block carrying it was cut, or if one key's carriers land on more than one part. pairingsOf skips blocks that have no item key. So [thinking (rawItem rs_1), long text with no raw form, tool_use (rawItem fc_1)] forms the pairing [rs_1, fc_1]. The thinking lands whole on shard 0 and the call on the last shard, each key lands on exactly one part, and nothing is released. Shard 0 then replays a reasoning item without the item it led to, which releaseSharedRawFormsOnMove treats as invalid ("would keep the id that ties it to a partner it no longer sits with"). Any pairing whose keys land on different parts should be released as well.

[nissa-seru]

Addressed in fcdf6b44. releaseRawFormsAcrossParts now gives up a pairing whose members land on more than one shard, as it does a raw form whose carriers do, with a test of a reasoning item on the first shard and its function call on the last, which fails against 3ec69158.

Written by Beth-2389.

— Lottie-2661

[nissa-seru]

Replying to this review.

fcdf6b44 answers all six findings, the four inline ones in their threads.

• The design doc's "in every region" (low): it now says an older body's shards render as the windows joined them wherever two or more render together, and that a shard rendered alone goes out as stored.
• The copied LegacyIngress helper (low): it's one helper now, test/_harness/legacy-ingress.ts, used by the three test files.

Two changes in the same commit don't come from your review. A chunking that declares continuesBlock on its first shard is no longer refused, since no join uses that declaration, while one that declares it on some later shards and not others still is. And the floor now counts a result message that is the store's first message with its whole body.

The full suite passes at fcdf6b44, and removing each code fix for the four inline findings fails at least one test.

Written by Beth-2389.

— Lottie-2661

[nissa-seru]

@antra-tess @Anarchid We're asking you both to review this PR at fcdf6b44 before we merge it. It changes what the context strategies send a model for every message long enough to be split into shards, and it's a breaking change for hosts that join a body's stored shards themselves.

What it changes for hosts and their users:

• With adaptiveResolution on, a split message now goes out as it was given, in one entry, wherever its shards render. In a probe on main at c17e7c3d, the head and recent windows put its other blocks ahead of its text, and the adaptive middle sends its text alone, so a reply's tool call and any image go unsent there, and a split tool result reads as a result that isn't shown.
• New shards store their slice of the message's blocks in order. A host that joins stored shards itself moves to joinBodyContent, now exported. The two we know of are agent-framework's asCompiled and connectome-host's Web UI, and "For hosts that join stored shards" gives each one's change.
• A store written before this change can miss the prompt cache once, at its first request after the upgrade, from the first older split message that now renders differently. "Bodies stored before this change" lists those cases, with a probe's counts.
• It also fixes The recent window can start inside a split tool-result message, leaving the result and its call out of the raw tail #308.

As of 2026-10-22 22:01 UTC it merges with main (4e0959a8) without conflicts.

Written by Beth-2389.

— Lottie-2661

[nissa-seru]

@antra-tess @Anarchid 757e5016 merges main (c8119361) into this branch, three commits on fcdf6b44, the head we asked you to review. We're asking you to review it at 757e5016 before we merge it. The merge commit's resolution and the two commits after it are what changed: git diff fcdf6b44 757e5016 also shows everything main brought in.

• The merge, d95fb9ed: one conflict, in autobiographical.ts, at the adaptive plan's price for a middle message. fix(pins): every reader reads a pin over a long message whole, and the plan's over-budget refusal names the pins #330 moved that price into middlePrice, which the plan's chunks and the over-budget refusal's rawPinsDiagnostics share, and priced a shard uncut there, as main's shard path sent it. This branch's shard path cuts each raw shard as it cuts any raw message, so the resolution keeps the shared middlePrice and prices a shard the same way: the refusal now prices raw pins as the plan and the shard path do.
• 4ab977c5: three comments that still described the middle's shard path as sending a shard's text.
• 757e5016: #​330's test "prices a marked message's parts uncut, …" asserted the uncut price, which this branch ends. It now asserts that the mark covers every part and is priced at 400 to 450 tokens for each, each part cut at its cap of 300.

The full suite passes at 757e5016, and removing each piece of the change fails at least one test, middlePrice's shard rule included.

Written by Beth-2389 (Claude Opus 5.5).

— Lottie-2661

[nissa-seru]

@antra-tess @Anarchid 7236560d merges main again, now at 4fbe6c94 with #331, the thinking binding. It's two commits on 757e5016. We're asking you to review it at 7236560d before we merge it.

• The merge, 8953ff86: one conflict, in autobiographical.ts's imports, where #​331 and this branch each added names. The resolution takes both.
• 7236560d: a test beside #​331's test of a sharded reply that isn't noted. A reply that leads with its thinking and is long enough to shard keeps that thinking at the next binding compile once the host notes it. With blocks kept in place, its first shard holds the thinking at its head, and the noted render and the compile join its shards alike.

The full suite passes at 7236560d, and removing each piece of the change fails at least one test.

Written by Beth-2389 (Claude Opus 5.5).

— Lottie-2661

[Anarchid]

Nightly dual review · round R1 at b1ad54d · reviewers: Codex gpt-5.6-sol (xhigh) and Claude claude-opus-5-5, merged and every claim re-verified by the Claude leg · posted by the maintainer's campaign runner. Verdict: CHANGES_REQUESTED (the formal review event is left to the maintainer). Finding ids R1-n are stable; cite them in fix commits.

Reviewed at b1ad54d against main 1a9e1b7

Verdict: changes requested (0 blockers, 2 majors, 5 minors)

The block-placement half of this PR is careful and well tested: ingress, continuesBlock, joinBodyContent and the region merge all hold up against the code and against probes. Both majors are in the other half, the call/result pairing. A message stored as shards that answers its own call (a bundled cycle) is the shape the description says "moves nothing". At this head it moves the recent window back over the whole unrelated message before it, and it makes tool pruning drop a real result. Neither happens on main. Both fixes are small. Separately, the pairing rework runs whether or not adaptiveResolution is on, and the title doesn't say so.

This is round 1. We have no earlier review on this PR.

Major

R1-1. callStart steps a sharded bundle's result back over the whole body before it, so the recent window, the floor and the hold take in an unrelated message.
src/strategies/autobiographical.ts:18659-18674. callStart asks callPartedStarts only at resultBody - 1. For a body that answers its own call, nothing is carried there, so the fallback runs: it returns the first shard of the previous body that holds a tool_use or thinking, or that body's start when it holds none. It never looks inside the result's own body, where callRuns already marks the call and its result (mark(first, k - 1, first), line 18768). The callers are the recent window's start (:18941-18942, now reached from any shard of the body, through bodyHoldsToolResult), the floor's newest turn (:13328) and holdBoundary (:18865).

• Probe at this head, built dist: store [User "hi"] [User: a 12,000-character document, 15 shards] [Claude: text 3,000 / tool_use b1 / text 3,000 / tool_result b1 / text 1,500, 10 shards] [User "thanks"], with adaptiveResolution, targetChunkTokens: 200 and headWindowTokens: 0. recentWindowTokens was sized so the window's start falls on each shard of the bundle in turn, from its second to its last; the first wasn't probed. Every time, the window starts at message 1, the document's first shard: 6,632 tokens, where it was sized for 111 to 2,321. On main, the same writes give a window that starts where it was sized, every time.
• Why it matters: the window grows by however large the preceding body is, and nothing bounds that. A large enough document before such a message turns a compile that fits into a refusal, and the floor (clearedBy) then reasons from the inflated turn. The floor and the hold already stepped back to the previous body's start on main, but only when the result sat on shard 0. The recent window's jump is new.
• Fix: in callStart, answer from the result's own body first. If every tool_result in it answers a tool_use earlier in the same body, return that body's own run start, or resultAt and let the callPartedStarts step that follows handle it. Step back into the previous body only when it holds a tool_use that the result answers by id. Add recent-window, floor and hold tests for a sharded bundle that follows a large plain body. The current bundle tests (test/body-blocks-in-place.test.ts:510, :611) cover only the head's end and chunk closes.

R1-2. Tool pruning counts a sharded bundle's own result as an answered call, so with toolResultMaxLastN a real result is pruned for one that isn't sent.
src/strategies/autobiographical.ts:672-700 (answeredToolCalls). The rule says a message's calls wait "from the next message on: pairing repair drops a result in its call's own message". But opened is published to waiting after each stored shard (:697), so a tool_result on a later shard of the same body answers the call. Setting the call's message to bodyStart (:680, this PR) doesn't stop that. On main, the legacy layout kept both blocks on shard 0, one stored message, so the bundle was never counted.

• Probe: [User] [Claude: text, tool_use real] [User: tool_result real "REAL-RESULT"] [Claude: sharded bundle as in R1-1, result "BUNDLE-RESULT"] [User], with toolResultMaxLastN: 1 and a recent window that holds everything. On main, the compile sends REAL-RESULT. At this head it sends [result of tool 'get_weather' left out: this context shows only the tool's last result] in its place, and the bundle's result isn't sent either, so the compile carries neither.
• Fix: collect opened across the whole body and publish it at bodyEnd. Results in the body still answer calls that were waiting before it. Add a parity test with one bundle below and above the sharding threshold.

Minor

R1-3. The connectome-host migration in the breaking fragment is incomplete.
changelog.d/829-body-blocks-in-place.breaking.md:28-30 says the Web UI's change is joinBodyContent(shards). But coalesceAndFlatten (connectome-host src/modules/web-ui-module.ts:3777-3782 on main) groups adjacent messages by equal bodyGroupId and sorts the run by shardIndex. Two identical ingestions stored back to back would still go to one joinBodyContent call, and the second body's shard 0, which carries no continuesBlock, would flip the whole input to the legacy join. The fragment should say to split runs with continuesBody (pairwise, store order) and to carry continuesBlock through the Web UI's message type. The grouping itself predates this PR and is a connectome-host bug.

R1-4. Companion changes aren't declared, and there's no merge-order guidance.
CONTRIBUTING ("How changes land") asks for cross-repo companions, which side lands first, and what happens if only one does. Neither agent-framework nor connectome-host has a PR that uses joinBodyContent or continuesBlock. If this ships alone, agent-framework's asCompiled (src/framework.ts:941), which serves its drained deferred writes and its released-window notices, keeps joining new bodies with their other blocks first. Compiles now send those bodies in place, so the two disagree for any sharded body with non-text blocks. agent-framework's StoredCopy also doesn't carry continuesBlock yet, so its side is a little more than the one-line change the fragment describes. Please add a short Companion PRs section, even if it only says "not yet filed; CM can land first because …".

R1-5. The pairing rework applies to every store, not only to adaptiveResolution.
The title and the opening sentence frame this as an adaptiveResolution change. But callRuns, closesHeld and closingPartsCall, the head's end, the recent window's start, the split fallback's groupEnd and the Knowledge chunker's summary close all run whether or not the option is on. The fixed fragment does say so, in its last sentences. Please say it in the title or the first paragraph, or split it into its own PR: it is a separate behaviour change with its own failure modes (R1-1, R1-2), and as one PR the two are hard to bisect apart. One cost belongs in the changelog too. In a probe with targetChunkTokens: 400 and 40 parallel results, each in a message of its own, main closed 11 chunks (parting results from their call), and this head closes one chunk of 45 messages, about 20,000 tokens. Nothing bounds that size, and groupEnd treats the run as indivisible. agent-framework's own layout (a call, then one results message) chunks identically on both, and a chain was already a single chunk on main.

R1-6 (nit). callRuns marking is quadratic in a run's length.
src/strategies/autobiographical.ts:18744-18746 and :18777: each answering message re-marks from calls.from. N parallel results, one to a message, cost about N²/2 writes, while the doc comment calls this one pass. That's harmless at realistic N. Keeping a per-run high-water mark makes it linear.

R1-7 (nit). releaseRawFormsAcrossParts keys parts by block identity.
src/raw-forms.ts:324-325. A block object that appears twice in one message's content and lands on two shards is mapped to its last part only. If it carries a raw form, the form is kept on both shards. This takes contrived input. A Map<ContentBlock, Set<number>> closes it.

Verified fine

• Tests: the full suite passes at the head, 3,292 of 3,292. Merged with today's main (61 commits past the branch's base), the PR merges cleanly and passes 3,275 of 3,275; the count is lower because main reverted #335 and its tests.
• Ingress: the chunker's shards are contiguous slices (src/adaptive/chunker.ts:132), so the span arithmetic holds. Seams, continuesBlock and empty blocks are placed consistently. A mixed declaration is refused before any shard is written, and continuesBlock survives a reopen.
• joinBodyContent: it gives back new bodies as given and joins legacy bodies as the windows always did, partial runs included. A middle composite merged with a window's shards of the same body stays one entry.
• The automated review's four inline findings are fixed at fcdf6b44: bodyHoldsToolResult at the window's start, the floor and the hold, and pairing release across parts.
• Image strip: imagesIn and replaceImages traverse in the same order, so the per-occurrence verdict index lines up. _blockHome is a WeakMap. An image repeated in one message and landing on two shards is stored as two objects, and under maxLiveImages: 1 the newer one is kept.
• Provenance: it reads sourceMessageIds before sourceMessageId, so naming the middle composite by its first shard doesn't change coverage. compositeCovers still holds for in-place composites.
• Pricing: the middle's raw run is priced at the plan's price for each shard (pse plus the cut's extra), as the windows price theirs. maxMessageTokens defaults to 0, so the middle's new cut matters only where a host sets a cap below targetChunkTokens.
• Write path: ContextManager.addMessage is the only place that writes shards, so no other path drops continuesBlock.
• Downstream: only agent-framework's asCompiled and connectome-host's coalesceAndFlatten join shard content. agent-framework's recovery, stored-removal and Discord paths read ids and bounds only. The tool-result-guard link holds: a round's results go in one user message.
• Membrane: its native formatter merges adjacent same-role messages (mergeConsecutiveRoles), as the description assumes.
• Issues: #308 and #319 exist as described.

---

_{Method. This is a two-reviewer pass. Codex gpt-5.6-sol at xhigh read the diff in a read-only sandbox against this head, with no network: about 15 minutes, 68 shell commands, about 9.9M input tokens (9.5M cached) and 40k output. Alongside it, Claude did the wider pass with network access: it ran the suite at the head and on a merge with main, built main and this head side by side, and ran the probes quoted above against both builds. Each claim from either pass was re-verified before it went in here. Who caught what: R1-1 and R1-2 are Sol's; Claude reproduced both against main and this head and measured them. R1-3 is Sol's, and Claude checked the connectome-host source. R1-4 and R1-5, with the chunk-size and chain probes, are Claude's. R1-6 and R1-7 are Sol's. Sol's other claim, that a repeated image object gets the older shard's verdict, was rejected: once the message is stored, each shard holds its own copy, and the newer one is kept. Sol didn't run the suite or the description's store and timing probes. Neither pass checked the cache and timing figures in the description against a live store, or a live API's handling of a final assistant turn (listed under "Not checked").}

[nissa-seru]

Replying to this review.

@Anarchid Round 3 is pushed at 428dfba3f. It answers R1-1 to R1-7: 60395e24a merges main (1a9e1b71), 044d007d4 holds the fixes and their tests, and 428dfba3f changes comments only. Thank you for the probes: R1-1's and R1-2's are now tests that fail without the fixes.

R1-1, in 044d007d4. callStart now steps into the message before only for a call there that the result answers by id, or back across parallel results to the calls they answer. So a message that answers its own call moves no boundary back past its own start. That changes one case on main too: a result whose call isn't in the message before it, nor among parallel calls' results before it, moves no boundary. By our reading of main, its recent window stepped back one message there, and its floor and hold a whole message, and a compile blanks such a result as an orphan either way. New tests take a sharded message that answers its own call, after a 12,000-character message, and check the recent window with its edge on each of the message's shards, the floor and the hold. Another test covers a result with no call before it.

R1-2, in 044d007d4. answeredToolCalls adds a message's calls to those waiting only after the message's last shard, so a result in its own call's message answers nothing however the message is sharded. The new test sends your shape with toolResultMaxLastN: 1, with the message stored whole and as shards, and in both the earlier call's result is the one sent.

R1-3. The breaking fragment now says what coalesceAndFlatten needs: carry continuesBlock on its message type, take a body's run by continuesBody rather than by equal bodyGroupId, and join each run with joinBodyContent.

R1-4. The description has a Companion PRs section. agent-framework's change, asCompiled to joinBodyContent(landed) with StoredCopy carrying continuesBlock, needs its context-manager floor raised to the release that carries this, so this can land first. We ran agent-framework 0a4a2c69 against main and against this head:

• A body holding a call and its result is never injected mid-turn there, since isInjectableMidTurn holds any message with tool blocks back to the turn's end.
• A long body with an image, under a window smaller than it, goes into the live round in asCompiled's order, where the next request sends it as given. The prompt is rewritten from that body at the next request, as it was on main. Nothing is parted, doubled or refused.

R1-5. You were right that nothing bounded the chunk, and 044d007d4 narrows what compression holds to what the layout needs. A chunk's close after a call now waits until the whole message after it is in the chunk, every shard of it, and a message that makes a call and answers it itself keeps the two in one chunk across its shards. That's main's rule for a message holding a tool_use, taken from a message to its shards, so in a store without shards chunks close as on main, parallel results one to a message included. In your 40-result case chunks close where main closes them, with the call's first result held with it, and in our run with 40 results of 24,000 characters and a stand-in provider refusing requests over 200,000 tokens, every chunk compresses. agent-framework stores a round's results in one message, so its rounds stay whole. We didn't split the rest out. The head window's end and the recent window's start keep a call with all of its results in every store: the block layout alone would part a call from its result there, since a result after a long text lands on a later shard, and the same rule stops a window's start between parallel results, where a compile on main could refuse (UncoveredDropError). The title, which now names the window edges, and the first paragraph say so. That later requests carry an uncompressed chunk raw is main's own, and is #346.

R1-6, in 044d007d4. Each run keeps a high-water mark, so marking is linear.

R1-7, in 044d007d4. releaseRawFormsAcrossParts maps each block to the set of parts holding it. A new test puts one block object with a raw form at both ends of a message, and both copies give it up.

At 428dfba3f, on Linux with Node 24.22.1, the full suite passes 3,294 of 3,294 from a clean build.

Written by Beth-2389 (Claude Opus 5.5).

— Lottie-2661

[Anarchid]

Nightly dual review · round R2 at 428dfba · reviewers: Codex gpt-5.6-sol (xhigh) and Claude claude-opus-5-5, merged and every claim re-verified by the Claude leg · posted by the maintainer's campaign runner. Verdict: CHANGES_REQUESTED (the formal review event is left to the maintainer). Finding ids R2-n are stable; cite them in fix commits.

Reviewed at 428dfba against main cedab24 (the branch's merge base is 1a9e1b7; main has 24 commits since)

Nightly dual review · round R2 · reviewers: Codex gpt-5.6-sol (xhigh) and Claude claude-opus-5-5, merged, with every claim re-verified by the Claude leg · posted by the maintainer's campaign runner. Finding ids R2-n are stable; cite them in fix commits.

Verdict: changes requested (1 blocker, 1 major, 1 minor)

All seven round-1 findings are fixed. We re-ran round 1's own probes at this head, and the regression tests you added for R1-1 and R1-2 fail without the fix. The blocker comes from main moving under the branch. #314 (renderAsNewest) landed six hours after this head's CI ran. Its tests and docs pin the piecewise middle send that this PR removes, so a merge as it stands turns main red. Merged, the code itself is right: the render and the compile now agree. The major is new at this head. After a head-window reset, a long reply that makes a tool call is now cut in two around the whole pre-reset history. That is reachable from connectome-host's /newtopic.

Round 1

The desk's note that R1 at b1ad54d requested changes holds. It was posted as a comment-type review whose body gave a changes-requested verdict.

R1	Disposition	Evidence at this head
R1-1 callStart stepped a self-answering sharded bundle back over the previous body	Fixed	src/strategies/autobiographical.ts:18576-18600 steps into the previous body only for a tool_use the result answers by id. Round 1's probe now starts the window where it was sized, on every shard of the bundle, except where that falls between the bundle's call and its result. There it starts at the call's shard. It never starts in the 12,000-character message before it. The new tests (test/body-blocks-in-place.test.ts:852) fail on the pre-fix merge 60395e24.
R1-2 answeredToolCalls published a body's calls per shard	Fixed	:692-700 publishes opened only after the body's last shard (continuesBody). Round 1's probe sends REAL-RESULT again. The parity test (:914) fails on 60395e24.
R1-3 connectome-host migration incomplete	Fixed	The breaking fragment (lines 23-35) now says to carry continuesBlock, to take runs by continuesBody rather than by equal bodyGroupId, and to join with joinBodyContent. That matches connectome-host main's coalesceAndFlatten (src/modules/web-ui-module.ts:3056-3088).
R1-4 no companion declaration	Fixed	The description has a "Companion PRs" section: neither is filed, CM lands first, and agent-framework raises its floor. agent-framework main (913afe34) still joins in asCompiled (src/framework.ts:985), and its StoredCopy (:994) has no continuesBlock, as described. Its mid-turn injections go through renderAsNewest (:25878), so they pick up the new form with no change of their own.
R1-5 every-store pairing change, unbounded chunks	Fixed	The title and first paragraph now name the window edges. closesHeld (:18661-18688) holds only through the whole message after a call, plus a message's own call up to its result. A differential run over 150 random tool-shaped stores without shards, under both chunkers, gave identical chunks on main and here (1,291 in all). Round 1's 40-parallel-results shape closes 11 and 15 chunks (autobiographical, Knowledge) on both, and its chain and agent-framework shapes chunk identically on both.
R1-6 quadratic marking	Fixed	callPartedStarts keeps per-run (calls.marked) and per-body (ownMarked) high-water marks (:18618-18647). A skipped position already carries the same start.
R1-7 parts keyed by block identity	Fixed	src/raw-forms.ts:308 is now a Map<ContentBlock, Set<number>>, with a test at test/adaptive/ingestion.test.ts:466.

Blocker

R2-1. Merged onto today's main, three renderAsNewest tests fail, and #314's doc and unreleased changelog fragment describe the middle send that this PR removes.
#314 merged at 2026-10-26 20:40 UTC. This head's CI ran at 14:34 UTC the same day, so the green checks predate it. The merge has no textual conflict, so nothing prompts a resolution. On the merge of this head with cedab243, the suite gives 3,453 of 3,456. These fail:

• test/render-as-newest.test.ts:246 "a body too big for the window's recent part … where this version's middle sends it in pieces" (asserts pieces > 1 at :259)
• :263 "a body that starts in the head window and runs on past it … where the compile sends it in pieces" (:274)
• :687 "a compression hold, held or timed out, changes nothing a render gives" (:707)

They fail because this PR fixes what they pin. In a probe on the merged build, each of the three scenarios compiles the body as one entry equal to what renderAsNewest returns. So does an assistant body [thinking, text, tool_use, text] under the same windows. On main the same writes compile in 2 or 3 pieces, and that assistant body loses its thinking and its call. The stale prose is all from main:

• src/strategies/autobiographical.ts:19970-19971: "Each such message goes through cappedForSend, apart from a body's shards in the adaptive middle". This PR cuts the middle's shards like any raw message.
• :19982-19987, the bullet "A body whose shards the compile doesn't send together. The adaptive middle … sends a raw run of a body's shards as their text alone, uncut …". Only its reset clause stays true (R2-2).
• changelog.d/fix-render-as-newest-null-not-sent.fixed.md:11-16: "The adaptive middle sends its shards' text alone, uncut, and a body across the middle and a window … goes out in more than one entry". This fragment is unreleased, so the next release would ship it next to 829-body-blocks-in-place.fixed.md, which says the opposite.

Fix: merge main. Make the three tests assert one entry and render-equals-compile. Cut the doc bullet down to the reset case, and drop the middle exception from the cappedForSend sentence. Amend the #314 fragment, or add a sentence to the 829 fragment saying renderAsNewest now gives these bodies as the compile sends them.

Major

R2-2. After a head-window reset, a long reply that makes a tool call is cut in two around the whole pre-reset history. Its thinking and opening go out before that history, and its call after it.
headWindowEndFrom (src/strategies/autobiographical.ts:18974-18996) steps the head's end back to the start of a call's run (:18987-18990). It then hands the boundary to anchorHeadToCoverage (:18991, body at :19013-19030). When the boundary is unowned and chunk coverage resumes later, the anchor moves the end forward to the first owned message (#122), whatever that splits. Here that message is the reply's second shard. With blocks kept in place, the reply's first shard holds its thinking and no tool_use. So main's own guard (:18984, "predecessor has tool_use → pull back") no longer fires either. After a reset, headPositions (:19070) sends the head first, and middleRanges (:19091) sends the pre-reset history before what follows the head. mergeAdjacentBodyGroupRaw joins only adjacent shards (:15538), so the two pieces stay apart.

• Probe, in the shape of connectome-host's /newtopic (which calls ContextManager.resetHeadWindow): adaptiveResolution, targetChunkTokens: 100, headWindowTokens 150 or 300, recentWindowTokens: 300. Store four old messages and compile. Store "NEW TOPIC" and reset the head window to it. Then store user "go", an assistant reply [thinking, ~600-word text, tool_use t1] (12 shards), and user [tool_result t1].
  • At this head, the same output with and without ticks: u:[NEW TOPIC] u:[go] a:[thinking, BODY…] u:[old 0] a:[old 1] u:[old 2] a:[old 3] a:[…body, tool_use] u:[tool_result]
  • On main: u:[NEW TOPIC] u:[go] u:[old 0] … a:[old 3] a:[BODY…] a:[…body] u:["[tool call omitt…"]. The head ends before the reply because its first shard holds the tool_use. The reply stays after the history, in order, but loses its thinking and its call.
• Why it matters: the model gets the opening of its own reply before the history and before the prompt it answers. Membrane's native formatter merges adjacent same-role messages, so the pre-reset history's last assistant message (old 3) and the rest of the reply should reach the provider as one assistant turn. That turn holds the tool_use without the thinking it began with. We didn't check what a live API does with that when extended thinking is on. A reply qualifies once it is longer than twice targetChunkTokens and crosses the head's end after a reset. The description and the fixed fragment say a sharded body goes out "wherever its shards render … in one entry", and nothing names this exception. The fragment's "As before: … the head's end moving forward to where chunks resume (#122)" (line 70) undersells it: before this PR, that move didn't split this reply.
• The plain-text case is old. A user body across a reset head's end is already split around the history on main, and main pins it (test/render-as-newest.test.ts:551). Here it goes out in 2 pieces where main sends 3.
• Fix: keep the head's end out of a body after a reset. Either re-apply the call-run step (and bodyBoundsIn) after anchorHeadToCoverage, or have the anchor refuse a forward target that falls inside a body or a call run and keep the stepped-back boundary. That also closes the plain-body case :551 pins. Add the /newtopic-shaped test above to body-blocks-in-place.test.ts. If you'd rather not touch the anchor here, at least name the reset exception in the description, the fixed fragment and the design doc, and keep it in renderAsNewest's doc (R2-1).

Minor

R2-3. In a chain of calls, the smaller-window floor counts one call fewer than the recent window keeps, so clearedBy names smaller-recent-window where no smaller non-empty window clears the refusal.
The floor's newest turn (src/strategies/autobiographical.ts:13259-13261) is callStart alone. The recent window's start (:18785-18791) is callStart followed by a callPartedStarts step. The design doc (docs/adaptive-resolution-design.md:401) documents that step for chains: "steps back past the call its edge's result answers to the call before that one".

• Probe (no shards, adaptiveResolution on, budget 100 with 20 reserved): four short messages, then A[text, call c0], B[result c0 of 197 tokens, call c1], C[result c1, call c2], U[result c2]. At this head, recentWindowTokens 100,000, 20 and 5 all refuse at "Head/tail reservation exceeded budget" with clearedBy: ['smaller-recent-window']. At 20 and 5 the window starts at B (226 tokens), while the floor counted from C (29). Only a window smaller than U itself, which is empty, gets past that stage. On main, at 20 and 5 the window starts at C and the compile gets past that stage. Both versions then refuse later, at emission.
• Only chain-shaped stores are affected. agent-framework's alternating call/result layout gives the same start for both.
• Fix: have the floor take the same two steps, through one shared helper so they can't drift apart. Add a chain row to test/overbudget-diagnostics.test.ts.

Verified fine

• Tests: the full suite passes at the head, 3,294 of 3,294, as the description says. main at cedab243 passes 3,297 of 3,297. This round's tests on the pre-fix merge 60395e24 fail 16 of body-blocks-in-place's 123 and 1 of adaptive/ingestion's 25, exactly as claimed.
• Chunks in stores without shards close as on main: the 150-store differential above, and round 1's parallel, chain and agent-framework shapes.
• The window's start between parallel results: with 40 results one to a message, main refuses at every budget, 1M tokens included (UncoveredDropError, or the tail dropping reserved messages). This head starts the window at the call and compiles at 1M. It refuses only budgets below the run's ~20k tokens. The design doc's tail edge cases say the tail can run past K.
• callStart edge cases: a body that answers an earlier call and also makes and answers its own steps back to the earlier call through the carried run. A result whose call is two messages back moves no boundary. A self-answering bundle at the store's start is caught by the callPartedStarts step that follows. bodyHoldsToolResult/bodyHoldsToolUse read legacy shards and work with adaptiveResolution off.
• 428dfba3 is comment-only, and the comments it removes are on helpers this PR adds. main had no doc on them, and main's own comments stay.
• Downstream: agent-framework main and connectome-host main still join shards as the breaking fragment describes. No companion PR exists in either yet.
• Design doc, render.ts and IngressChunkResult docs match the code at this head.

---

_{Method. This is a two-reviewer pass. Codex gpt-5.6-sol at xhigh read the diff in a read-only sandbox at this head, with today's main and the agent-framework and connectome-host main refs on disk and no network. Its first launch stopped at its first step to ask a question and was relaunched with a no-questions preamble. The second run took about 14 minutes and 144 shell commands, with about 6.7M input tokens (6.4M cached) and 34k output. Alongside it, Claude did the wider pass with network access. It ran the suite at the head, on main, on the pre-fix merge with this round's tests, and on a merge of the head with today's main. It ran round 1's probes and the new probes quoted above against main and the head side by side. Each claim from either pass was re-verified before it went in here. Who caught what: R2-1 was found by both independently: Sol from a merge-tree and reading the tests, Claude from the merged suite and the render-versus-compile probe. R2-2 is Sol's: it found the reset split from main's own test. Claude reproduced it, traced it to the #122 anchor, and found that for a reply making a call it is new at this head (main keeps such a reply after the history). R2-3 is Claude's. Both passes reached the same seven round-1 dispositions. Sol couldn't run the suite (its sandbox is read-only) or check live PR state. Neither pass checked a live API's handling of a tool-use turn without its thinking, or the description's cache and timing figures against a live store.}

[nissa-seru]

Replying to this review.

@Anarchid This pull request's head is now e6a0888f. It answers R2-1, R2-2 and R2-3, and takes out what the previous round added for R1-6. It is four commits on 428dfba3: 885fe042 merges main at cedab243, c42388e2 holds the fixes and their tests, def320c7 rewords one limit in renderAsNewest's doc comment and two changelog fragments, and e6a0888f takes out the two high-water marks in callPartedStarts. At this head, on Linux with Node 24.22.1, the full suite passes 3,466 of 3,466 from a clean build. The description is updated for this head. Every run named below was on Linux with Node 24.22.1.

R2-1. The three render-as-newest tests now assert that the compile sends the body in one entry, equal to what renderAsNewest gives: the body too big for the recent window, the body that starts in the head window and runs past it, and the body released from a compression hold. renderAsNewest's doc no longer leaves the adaptive middle out of cappedForSend, and its list of bodies the compile doesn't send together now names two: a body that leaves no call waiting for a later result, across a reset head window's end, and a reply that makes a call, in a store whose chunks begin partway through it. #314's unreleased fragment says the same.

R2-2. Before the move to where chunks resume (#122), the head's end now steps out of a body that leaves a call waiting for a later result: a boundary inside such a body moves to the body's start. In your /newtopic shape, at heads of 150 and 300 tokens, with a reply that thinks, writes 7,000 characters of text and makes a call, which the test asserts is stored as at least 12 shards, the compile now sends the reply in one entry, its blocks in order, after the history from before the reset, and a chunk owns it from its first shard. A reply that makes three calls, answered one to a message, also goes out in one entry after the history. Both are new tests in body-blocks-in-place.

• The two fixes you proposed: we probed your shape with each applied to this branch before its R2-2 fix, with replies of 12 and 23 shards at heads of 150 and 300 tokens. One had the move to where chunks resume refuse a target inside a body or a call run. The other applied the body and call-run steps again after that move. With each, the reply went out whole after the history in all 8 of its runs, but its first one or two shards were in no chunk, raw outside the head. At this head a chunk owns the reply from its first shard.
• A body that answers its own calls gets no such step. In a probe of your shape with a reply [thinking, text, tool_use, tool_result, text], the reply went out after the history from before the reset at heads of 150 and 300 tokens, its result in an entry of its own after it.
• The plain body that main pins in render-as-newest.test.ts (:551 at cedab243, :549 at this head) still goes out in pieces after a reset, as on main.
• One case can still split: after a reset, a reply that makes a call can still go out in pieces, until the next reset, in a store whose chunks begin partway through it. In a probe of your shape written and chunked at 428dfba3 and opened at this head, the chunks began partway through the reply at a head of 300 tokens, and the reply went out in two entries until the next reset. Written at this head, or by main (cedab243), the same shape's chunks began at the reply's first shard at heads of 150 and 300 tokens, and the reply went out in one entry. We didn't run whether main makes such chunks in other shapes.

R2-3. The smaller-window floor now counts the newest turn from where the recent window starts, through one helper, turnStart. Your chain shape is now a row in overbudget-diagnostics: at windows of 100,000, 20 and 5 tokens, the refusal names no smaller window. The three rows fail at 885fe042.

R1-6. The previous round answered R1-6 with two high-water marks in callPartedStarts, and e6a0888f takes them out. We wrote a message making N calls and then their N results, one to a message, with the marks (def320c7) and without them (e6a0888f), side by side, one run each. A pass is one callPartedStarts call over all of the store's messages. Each figure for a pass is the time of 20 such calls, plus one read of the store's messages, divided by 20.

N	one pass, with / without	writing the N results, with / without
100	0.06 / 0.09 ms	928 / 821 ms
200	0.03 / 0.11 ms	3,027 / 3,090 ms
400	0.07 / 0.18 ms	10,069 / 9,647 ms
800	0.21 / 1.58 ms	44,362 / 44,252 ms

Without the marks a pass takes longer, but under 2 ms at 800 results, and writing the results takes about as long either way. Removing either mark at c42388e2 failed none of the 10 test files we reran, and with both out the full suite passes, so we took them out rather than keep code that no test pins.

From a draft by Beth-2389 (Claude Opus 5.5).

— Fiona-2757

[Anarchid]

Nightly dual review · round R3 at fb31126 · reviewers: Codex gpt-5.6-sol (xhigh) and Claude claude-opus-5-5, merged and every claim re-verified by the Claude leg · posted by the maintainer's campaign runner. Verdict: APPROVE (the formal review event is left to the maintainer). Finding ids R3-n are stable; cite them in fix commits.

Reviewed at fb31126 against main f966779 (the branch's merge base is d82ee00, the 0.23.1 release; main has two PRs since, #352 and #353)

Nightly dual review · round R3 at fb31126 · reviewers: Codex gpt-5.6-sol (xhigh) and Claude claude-opus-5-5, merged, with every claim re-verified by the Claude leg · posted by the maintainer's campaign runner. Verdict: APPROVE (the formal review event is left to the maintainer). Finding ids R3-n are stable; cite them in fix commits.

Verdict: approve (0 blockers, 0 majors, 1 minor, 2 nits)

All three round-2 findings are fixed, and this round's new tests fail on the pre-fix merge exactly as the description says. The change does what it claims, and it fixes a live-request defect the description only touches on. On 0.23.1, whenever a long [thinking, text, tool_use] reply is bigger than the recent window, the newest turn goes out without its thinking or its call, and its result is blanked. At this head it goes out whole, thinking first, with the result right after it. What remains is one documentation gap around the reset residual, which is real but already happens on 0.23.1, and two nits. Release note for the maintainer: the breaking fragment means this should ship as a minor (0.24.0). agent-framework and connectome-host both pin ^0.23.1, so they pick it up only when their companion changes raise the floor.

The desk's note that R2 at 428dfba requested changes holds. It was posted as a comment-type review whose body gave a changes-requested verdict.

Round 2

R2	Disposition	Evidence at this head
R2-1 renderAsNewest tests/doc/fragment pinned the old middle send	Fixed	The three tests now assert one entry equal to the render (test/render-as-newest.test.ts). The doc no longer exempts the middle from cappedForSend (src/strategies/autobiographical.ts:20330-20350). #314's unreleased fragment is amended, and changelog.d/829-render-as-newest-entry.fixed.md corrects 0.23.1's entry. This time the merge with today's main is green too (below).
R2-2 reset head split a call-making reply around the history	Fixed for stores this head writes; residual documented, one doc gap (R3-1)	headWindowEndFrom steps a boundary inside a body that leaves a call open back to the body's start before the #122 anchor (:19098-19113). Our /newtopic probe (below) sends the reply in one entry after the history at every head budget from 150 to 1,200 tokens. The new tests fail on 885fe042 (6 of 130).
R2-3 floor counted a chain's newest turn one call short	Fixed	The floor (:13219) and the recent window (:18903) both go through turnStart (:18676). The three chain rows in overbudget-diagnostics fail on 885fe042 and pass here.

R1-6 (the quadratic marking in callPartedStarts): e6a0888f takes our round-2 fix back out, with measurements. The walk is again quadratic, but only in the length of a run of parallel results with one result per message. It runs a constant number of times per compile, and the description measures 1.6 ms per pass at 800 results. We accept that trade-off and don't re-raise it.

Minor

R3-1. The reset residual is reachable from every store 0.23.x wrote, but the design doc names only half of it, and no test pins it.
After the body step, anchorHeadToCoverage still moves an unowned boundary forward to the first owned message (src/strategies/autobiographical.ts:19146-19147). In a store whose chunks begin partway through a call-making reply, that message is a later shard of the reply, so after a reset the reply goes out in pieces around the history. The fixed fragment (changelog.d/829-body-blocks-in-place.fixed.md:4-7) and renderAsNewest's doc (:20345-20350) name this case. The design doc doesn't: its Rendering bullet (docs/adaptive-resolution-design.md:225) names only the body that leaves no call waiting, and :405 points back to it.

• It answers the description's open question ("We didn't run whether main makes such chunks in other shapes"): it does. We probed the /newtopic shape with a 19-shard reply [thinking, 7,000 chars, tool_use] and its result, at targetChunkTokens: 100, recentWindowTokens: 300, and heads of 150, 300, 450, 600, 900 and 1,200.
  • Written at this head: one entry after the history at all six heads, and a chunk owns the reply's first shard.
  • Written by 0.23.1: at heads of 450 and above, 0.23.1's chunks begin at the reply's 4th, 5th, 7th and 10th shard. Opened at this head, the reply goes out in 2 entries: [thinking, tool_use, text] in the head with its result moved after it, then the history, then the rest of the text. 0.23.1 itself sends 3. Every store that already holds such a reply keeps splitting after a reset until the next one.
• This is no regression, since this head sends one entry fewer than 0.23.1. Both fixes round 2 suggested would leave shards raw outside both the head and the chunks, as you showed. So we aren't asking for a code change.
• test/body-blocks-in-place.test.ts:1108 asserts that a chunk owns the reply's first shard, so nothing pins what the residual does.
• Fix: name the second case in the design doc's Rendering bullet. Widen the description's framing from stores written at 428dfba to any store whose chunks begin mid-reply, which includes 0.23.x stores. Optionally add a test that seeds ownership from a later shard and pins the documented 2-entry shape, so a change to the anchor can't make it worse silently.

Nits

R3-2. The breaking fragment doesn't say the migration needs this release. changelog.d/829-body-blocks-in-place.breaking.md:12-34 tells hosts to call joinBodyContent and carry continuesBlock. Both are new here, and both named consumers pin @animalabs/context-manager at ^0.23.1, which a 0.24.0 won't satisfy. Add one clause: "requires this release or later; raise the dependency floor with the change".

R3-3. Two comments no longer say what's true.

• test/compile-provenance.test.ts:131 is half a sentence ("// text across the shards, the image on shard 0 after its text."). Its first line was deleted.
• compositeCovers' doc (src/compile-provenance.ts:408-413) dropped "so where a non-text block sits relative to the text is not compared". The code still doesn't compare it: it checks the joined text and the non-text order separately. So a composite that moved a tool_use ahead of the text it followed, as the legacy join does by design, still reads as unaltered. Keep the second half of that sentence.

Verified fine

• Tests. The full suite passes at the head, 3,543 of 3,543, as claimed. Merged with today's main (f966779f, which adds #352 and #353), it merges with no conflict and passes 3,585 of 3,585, so R2-1's merge-time breakage doesn't recur. With this head's test files built against 885fe042's source, body-blocks-in-place fails 6 of 130 (the reset and head-window tests), overbudget-diagnostics fails 3 of 166 (the chain rows), and render-as-newest passes 64 of 64. All three match the description.
• The newest turn keeps its thinking and its call. We ran an agent-framework-shaped live flow: 8 turns, then go, an 11-shard reply [thinking, text, tool_use], a drain of compression ticks, the result, and a compile. We ran it at recent windows of 100 to 1,500 tokens, heads of 0 and 150, and budgets of 1M, 2,500 and 1,600.
  • At this head, all 29 compiles that fit send the reply as one entry [thinking, text, tool_use] immediately before its result. That holds even where chunks own the reply's first 7 or 8 shards.
  • On 0.23.1, 24 of the 29 send it as text alone, in two entries (one in a single case), with no thinking and no tool_use, and the result is replaced by text.
• A user body given as [text, tool_result]. The compile now sends it as given. That shape is invalid on the wire, but membrane 0.8.0's normalizeToolPairs reorders the turn to results-first (interloper_deferred) before validating. We ran the compiled requests through it, sharded and not, and it accepted every one. agent-framework writes results-only messages (src/framework.ts buildStoredToolResultContent), and #308's own shape is [tool_result, note], which the new layout keeps.
• Ingress and join. Blocks go by text offset (:2837-2899). joinBodyContent joins only at declared seams, and falls back to the legacy order when any later part lacks continuesBlock (src/body-runs.ts:100-127). continuesBlock persists through append's extra fields and toStored (src/message-store.ts:470, :2115). Shards can't be edited or removed alone (src/message-store.ts:733, :801), so a body's declaration can't drift. The mixed-declaration refusal throws before any shard is written (src/context-manager.ts:637-643). compositeCovers handles composites with several text blocks.
• Raw forms. releaseRawFormsAcrossParts gives up a Responses reasoning pairing whose members land on different shards. 0.23.1's ingress rebuilt every text block, dropping the text items' raw forms while the reasoning kept its id. This head gives up the pairing whole, which is the id-less shape membrane already sends for history without raw items.
• Stores without shards. Chunks are the same as on main. The window-edge changes, and the one-time prompt rewrite they cause, are disclosed in the description and in the fixed fragment.
• Consumers. agent-framework main (e85c57db) still joins as before in asCompiled, now at src/framework.ts:1013; the description's permalink at 59d60958 is still accurate for that commit. connectome-host main (612ec8db) coalesceAndFlatten (src/modules/web-ui-module.ts:3056) also joins as before. Both match the breaking fragment's account. Neither companion PR exists yet. Both consumers pin ^0.23.1, so nothing reaches them before they opt in.
• Not this PR's. In a run of parallel calls with one result per message, a chunk can close after the first results. The later results then reach no compression request, because stripUnpairedToolBlocks drops a result whose call isn't in the request. A probe gave identical results on 0.23.1 and at this head: 3 of 6 results under the autobiographical chunker and 4 of 6 under Knowledge never reach the summarizer. The description discloses it, and it's noted for a separate issue.

---

_{Method. This is a two-reviewer pass. Codex gpt-5.6-sol at xhigh read git diff main...HEAD in a read-only sandbox at this head. It had the round-2 review, the author's reply, the description, and agent-framework's and connectome-host's main refs on disk, and no network. It ran about 13 minutes and 82 shell commands, with about 7.8M input tokens (7.5M cached) and 40k output. Its bundled sub-reviewer failed to start, which was harmless. It could not run tests, because the sandbox has no node_modules, or materialize a merge tree. Alongside it, Claude did the wider pass with network access. It ran the suite at the head, on the merge with today's main, and with this head's tests on 885fe042. It ran four probes against 0.23.1 (d82ee000) and the head side by side: the live-flow thinking probe, the /newtopic reset probe (written by either, read at the head), [text, tool_result] through membrane's normalizer, and parallel results through compression. Every claim from either pass was re-verified before it went in here. Who caught what: R3-1 was found by both. Sol found it from the anchor's code and rated it major. Claude reproduced it from stores written by 0.23.1, showed that 0.23.1 itself does worse, and found the design-doc gap, so it is a minor here. R3-2 is Sol's. R3-3 is Claude's. Sol also raised three majors and minors that we did not adopt. The [text, tool_result] order (also raised by Claude) is reordered by membrane, which we confirmed by running its normalizer. The parallel-results compression gap is identical on 0.23.1, so it goes to a separate issue. The quadratic walk was taken out deliberately and measured, so we accept it. Neither pass sent a live API request.}

[nissa-seru]

Replying to this review.

@Anarchid This pull request's head is now 2843fb36, one commit on fb31126e. It answers R3-1, R3-2 and R3-3, and adds the test R3-1 suggests. Its only change to src is a doc comment. On Linux with Node 24.22.1, the full suite passes on this head's files, 3,545 of 3,545, from a clean build. The description is updated for this head. Every run named below was on Linux with Node 24.22.1.

R3-1.

• The design doc: its Rendering bullet (docs/adaptive-resolution-design.md:225) now names the second case, in the words of changelog.d/829-body-blocks-in-place.fixed.md: a reply that makes a call, in a store whose chunks begin partway through it.

• Our probe of your shape: a 19-shard reply [thinking, 7,000 characters of text, tool_use] and its result, at targetChunkTokens 100 and recentWindowTokens 300, and at your six heads of 150, 300, 450, 600, 900 and 1,200 tokens. It wrote each store with 0.23.1 (d82ee000) and opened it at fb31126e, whose src differs from this head's only by that comment.

  • At heads of 300, 450, 600, 900 and 1,200 tokens, 0.23.1's chunks began at the reply's 3rd, 4th, 5th, 7th and 10th shards, in that order. Opened at fb31126e, the reply went out in two entries, and 0.23.1 itself sent it in three.
  • At a head of 150, the chunks began at the reply's first shard, and the reply went out in one entry.
  • After a second reset, the reply went out in one entry at every head.

  These agree with your figures at heads of 450 and above. The description now says that a store 0.23.1 wrote can hold such chunks, with these figures.

• The test: a new test in body-blocks-in-place builds such a store with 0.23.1's head end and chunk closes, at heads of 450 and 900 tokens. It pins the two-entry shape: the reply split where the chunks begin, one entry before the history and one after, with its result right after the first. Taking out the move to where chunks resume (anchorHeadToCoverage), or ending that move one message later, fails both.

R3-2. changelog.d/829-body-blocks-in-place.breaking.md now says that joinBodyContent and continuesBlock require this release or later, so a consumer raises its dependency floor with the change.

R3-3. compositeCovers' doc (src/compile-provenance.ts) has its still-true clause back: where a non-text block sits relative to the text is not compared. The half sentence at test/compile-provenance.test.ts:131 is deleted.

From a draft by Beth-2389.

— Fiona-2757