Before and after, on the real thing

Two isolated Studio installs, both built fresh: BEFORE is this PR's own merge base 4f0d691cf, which is current main and includes #9038 and #9049, AFTER is head 3315ea60d. Each build serves its own frontend bundle, so the two halves are different code, not one Studio photographed twice.

One reply, one recorded SSE body, served to both from an out-of-page HTTP server. sent_reply_sha256 cb3c0313 and received_sse_bytes 6501 on both sides, so the two halves received the same 6,501 bytes in the same 43 arrivals. Everything downstream of the socket is the real thing: the real chat adapter, assistant-ui, React, Streamdown and Shiki.

The arrival boundaries are the point of the script. A completed ${...} is only cut if an arrival ends at its closing brace, so the splitter cuts after every }. Chunked any other way this same reply comes through whole, which is why the bug reads as intermittent from the outside.

Read out of the live DOM on the same servers that were photographed:

The code block, character for character:

// BEFORE
function greet(name) {
  return `Hi,!`;
}
const pair = ` and`;
const nest = `}`;

// AFTER
function greet(name) {
  return `Hi, ${name}!`;
}
const pair = `${x} and ${y}`;
const nest = `${a${b}}`;

And the two paragraphs below the fence. BEFORE renders On a shell the same text is written ; and nothing else. AFTER renders On a shell the same text is written ${HOME with no closing brace. and Windows note, sent with CRLF: const t = ${q};.

That second paragraph is worth naming, because it is worse than one deletion. On BEFORE the arrival that completed ${q} fired the strip, and [^}]* reaches back past the unterminated ${HOME to the previous }, so a single arrival took the CRLF line, the shell line and the paragraph break with it.

Replaying the same 43 arrivals through the shipped strip function prints every cut the old placement makes on this reply:

273 characters sent, 159 left. Only the last row is the artefact the strip exists for. The other five destroyed 102 characters of the model's own text, on a reply that finished normally.

Both halves show the leaked trailing ${answer} fragment absent, which is the check that a fix by deletion would fail. The scene raises rather than shooting if it is present, if the fence renders with zero Shiki tokens, or if the completions request was never intercepted.

Cases covered in the one reply: the reported reproduction, several placeholders in one line, nested placeholders, all three inside a fenced code block, an unterminated ${ with no closing brace, CRLF line endings (#9088 landed on this path), and a fragment genuinely at the end of the finished reply.

Two things that differ for reasons unrelated to the PR

• The footer duration reads 3.92s on BEFORE and 3.93s on AFTER. That is wall clock on a scripted stream, not content.
• highlighted_token_count differs because AFTER has more code on screen to highlight. It is asserted > 0 on both, not asserted equal.

Both homes had their threads zeroed before shooting, so the Recents list shows one thread on each side and a harness-caused difference cannot be read as a real one.

Not tested here

The composite is Chromium at 1500x1000. Cross-platform and cross-engine coverage is on the staging runs, not on this box.

Re-shot twice: once after the continuation gate went on, and again from two fresh installs after the rebase onto 4f0d691cf, since #9038 and #9049 merged and the old merge base no longer says anything about this PR. Every fact came back identical across all three runs, on both sides: same text_content_sha256, same inner_html_normalised_sha256, same cases_kept, same received_sse_bytes. Neither merge changes what the strip does or where it used to run.

Rebased onto 4f0d691cf, since #9049 and #9038 merged while this was open.

#9049 moved every append through appendCumulative and gated the strip on a placeholderWatch that answers from the deltas, so the branch point this was written against no longer exists. The fix is reapplied in terms of the new code rather than merged into it.

What changed in the reapplication:

• The watch stays. It now gates the one scan on the finished reply instead of a scan per arrival, which is strictly more of what it was written for: a reply that does not end in a brace is rejected without the buffer being read at all, so the whole reply is saved from being flattened rather than one arrival's worth.
• A cut still calls thinkTags.retract and placeholderWatch.retract, and still only when it cuts. The incremental parse repairs itself from the length mismatch, which is the path createSegmentedAssistantText documents for a removed suffix.
• Two of Studio: stop the streamed reply being flattened on every arrival #9049's adapter source pins described a strip that lives inside the loop, so both are updated in place. the arrival loop touches the reply only in ways that cannot flatten it loses the carve-out it had for the strip: with the strip out of the loop, nothing left on the arrival path can flatten the buffer, so the assertion is now that the loop mentions cumulativeText only as .length, with no exceptions. Its watch and reseed suites are untouched and still pass.

Re-verified after the rebase, not carried over:

• 3,628 passing, 0 failing. npm run typecheck clean.
• Ten broken trees, each one named in the description with which assertions go red.
• One of them, a strip whose result is never assigned back, initially survived: every other assertion in the new test passed against a strip that computes the right answer and throws it away. The missing assertion is now there and that tree fails. Worth stating rather than quietly fixing, because it is exactly the shape of a test that looks thorough and measures nothing.
• Also run with the adapter, the strip module and both test files converted to CRLF, since the Windows staging job checks out with core.autocrlf false and so does not cover it.

The before and after pair above was shot against the previous merge base. It is being re-shot against 4f0d691cf and I will replace it; the diagnosis and the local checks are unaffected, since neither merge changes what the strip does or where it ran.

CI is best-effort at the moment: GitHub reports Actions at degraded performance, so anything I quote from a run is provisional and the local runs are the evidence.

@codex review

Codex Review: Didn't find any major issues. More of your lovely PRs please.

Reviewed commit: 3315ea60da

Which assertion goes red, and on what

Two of the three files here are tests, so this is the load-bearing part. Fourteen broken trees, run against the five test files that touch this path. Per test, not in aggregate.

The trees:

The result, per assertion:

Every assertion added or rewritten here has at least one tree that turns it red. Unmutated: 31 passing, 0 failing.

Two of those rows exist because the first attempt at them measured nothing:

• B6 initially survived. Every other assertion in the trailing strip runs on the finished reply passed against a strip that computes the right answer and throws it away, because the gate regex it matched stopped at const stripped =. The assertion that the result is assigned back was missing and is now there.
• B4 kills nothing, and that is the right answer, not a gap. The bounded scan already requires the last non-whitespace character to be } and slices to just past the previous }, and [^}]* cannot cross a brace, so at most one } is ever in the region the pattern is run over. The end anchor is unreachable. Checked rather than argued: 0 differences between the two functions over 400,000 randomly generated strings drawn from an alphabet of a, space, backtick, $, {, }, newline, carriage return, ! and ${.

the finished reply does not depend on how the stream was split is the weakest row, red on one tree only. It is a self-consistency property of the strip rather than a claim about the adapter, and B11 is what it actually guards: a strip whose answer depends on its call history. Said plainly rather than left to look stronger than it is.

Cross-platform

Run on the owned staging replica rather than the org queue, against this PR's actual head 3315ea60d merged onto 4f0d691cf.

The Windows red is not this PR

3,628 tests, 3,615 passing, 13 failing. The 13 are tests/copy-to-clipboard.test.ts and tests/microphone-permission-reset.test.ts, neither of which this PR touches, and both of which fail the same way on plain main. #8980 is open against exactly this and measures the same 13 on main with 0 on its own branch, from an ERR_UNSUPPORTED_ESM_URL_SCHEME on a fileURLToPath import specifier that Node rejects on Windows. Its own staging run of frontend windows-latest is green, which is the control.

None of the three files in this PR appear in that list, and my two test files load their modules through a relative specifier, not fileURLToPath.

The Windows gap this does not close

The staging Windows job sets core.autocrlf false, so it checks out with LF and never exercises a CRLF working tree. Both new source pins read chat-adapter.ts off disk and match against it, so a CRLF checkout is a real risk for them specifically. Covered locally instead: chat-adapter.ts, trailing-template-placeholder.ts and both test files converted to CRLF, 16 passing and 0 failing.

Staging PRs are closed, never merged; they exist only to host the runs.

Org CI on this PR is not quoted anywhere here. GitHub Actions is degraded and the queue has not moved, so everything above is either the staging replica or a local run.