[nissa-seru]

TL;DR: fixes for the six findings of Anarchid's review of #352 (R1-1 to R1-6), two more that our internal review found beside them, the five points of Anarchid's first review of this PR, and the one point of his second. Each fix in code has a test that fails without it. A hide range takes what was stored between its two messages and every copy of both, and so do offline recovery's suppressed ranges. A conversation agent's maintenance call is withdrawn under a surgery's hold, as a resident's is. previewAgentRuntimeSettings() answers instead of throwing for a context manager that refuses its queries. The 0.21.1 operator note says which stores need its repair. A lasting maintenance failure is recorded in the history when it's reported, not on every pass, and an operator's maintain keeps the pass it ran. stop() waits for an over-budget drain kick, and none starts once stop() has begun. A maintenance call made once stop() has begun is withdrawn rather than failed, so a restart no longer raises a context-maintenance-failed alert, though one inside context-manager 0.14's compression fallback ladder is recorded there as a provider error and can quarantine its chunk, with context-manager's quarantine alert. The context-refusal alert says whether the drain breaker kicked.

We'll merge this no earlier than 2026-10-17 12:00 UTC, after our pre-merge checks pass on its merge with main as it is then, unless you ask for changes before then.

This PR carries the no-changelog label because the changelog check counts only added fragments. Its changelog entries are its edits to #352's pending fragments, so 0.22.2's notes describe each change once, as it ships.

What changes

• R1-1, hide's range form (src/framework.ts), and offline recovery's suppressed ranges (src/recovery/offline-branch.ts). A range names two messages. It takes what was stored after the earlier one began and before the later one began: from the earlier message's first stored copy through the later one's first, each widened to its whole body. It also takes every copy of both messages, each whole, as the single forms already take all of a message's copies. So a copy stored outside that span, such as a write cut short and retried later, is taken on its own, and nothing else stored after the later message began is taken. Before, hide's range ended at the later message's first copy, so a retry of it stayed in the agent's context while the reply listed the message as hidden. Offline recovery's range ran through the later message's last copy, so it took what was stored between that message's copies, and it left out a copy of the earlier message stored after the later one.
• R1-2, conversation agents' maintenance (conversationAuxiliaryMembraneFor). A provider call made while a surgery holds the store, or once stop() has closed provider admission, is withdrawn without being sent, as withAuxiliaryAdmission withdraws a resident's. That covers all of a conversation agent's compression, whatever starts it. Before, a conversation agent's tick that was running when the hold was taken could go on to make further provider calls, and the operator call waited for each. fix: what still assumed context-manager 0.13, and removing a message stored as a body #352's changelog line "Maintenance makes no provider call meanwhile" is now true for them.
• R1-3, previewAgentRuntimeSettings() keeps its contract (previewRuntimeSettingsFor, src/agent.ts). For an agent whose context manager refuses its queries, as after its strategy failed to initialize, it answers {available: false, reason} with the agent's live budget, the patch's path and its transition from the agent's own state, as it does for any preview it can't compute. A patch whose values the agent refuses still throws, whatever the manager's state. Whether the strategy takes live tail and pace settings is the manager's to say, so while it refuses, a patch that sets them gets no verdict either. Whatever stopped the preview is the reason it gives, as the code RuntimeSettingsPreview.reason documents when it's one of the strategy's known refusals, so a stale branch generation is branch_generation_changed here too (this PR's review, R1-3). When the manager answers, an error from planning the patch still throws, and one from the strategy's preview is still the reason it gives, as before.
  • resume() drops its own catch: a refusing manager's agent is a plain unavailable preview, warned about by name and reason, and any other error from planning a patch throws from resume(), as it did on 0.22.1.
  • updateAgentRuntimeSettings()'s budget preflight no longer logs that it's applying an update a refusing manager then refuses.
  • Three Agent methods serve the preview, marked @internal since they aren't a host API: runtimeBudgetPath(patch) (the budget and path from the agent alone, which planRuntimeSettings now uses too), contextManagerAnswers(), and checkRuntimeSettingsPatch(patch), the checks of a patch that need nothing from the manager.
• R1-4, the 0.21.1 operator note (CHANGELOG.md). One sentence: the reset is for a store that already opened on context-manager 0.14.0 and ran a committing compile, since ^0.14.0 now installs 0.14.1, which keeps a still-unstamped multiplier provisional and replaces or drops it on its own.
• R1-5, the maintenance history. A pass isn't added to the history if it took no tick and each of its records repeats a failure already reported, whose report the alert dedupe suppressed. A lasting failure used to fill all 50 entries in about four minutes at the default interval and push out the runs that did work. It's now recorded when it's reported: when first met, when its text changes, once per alert cooldown, and after the agent recovered. A pass that took a tick did work, so it stays, and so does the run of a pass an operator's maintain (maintenanceTick()) asked for, whatever it met, including a pass already running that the maintain joined (this PR's review, R1-2). A pass with nothing to run, such as one whose every agent is ready or busy with its own provider call, records no run, as before. No new field reaches hosts.
• R1-6, stop() and drain kicks. stop() settles the maintenance pass and any over-budget drain kick before it closes the store, so the tick in flight ends before the store closes. Once stop() has begun, no drain kick starts, and one already running starts no new tick. Before, stop() waited only for the maintenance pass, so a drain kick's tick could still be running when the store closed. Drain kicks now read whether stop() has begun, not whether the framework is running, so a framework that was never started, such as one run with runUntilIdle(), keeps them. A kick joins the drains stop(), the operator surgeries and switchBranch wait for before the refusal's alert is raised and before its body runs. So a stop(), a surgery or a switchBranch begun by an ops:alert listener, or a stop() made from inside the kick's first tick before that tick's first await, waits for the kick, which then starts no tick (this PR's review, R1-4).
• A stop withdraws a maintenance call, for residents too. A maintenance provider call made once stop() has begun is withdrawn, as one under a surgery's hold is, with a MaintenanceWithdrawnError naming the agent. That includes a call whose model a provider wait holds, since both membranes check for a withdrawal first. A resident's call parked at the provider gate when stop() begins is withdrawn too. A drain kick logs that it stopped. For a call outside context-manager 0.14's compression fallback ladder, a merge's or a chunk's canonical call with its retries after a tool_use stop, the pass logs that the agent's maintenance stopped and reports no failure, and context-manager counts no attempt. One inside the ladder, after a chunk's canonical call was refused or cut short, is caught by the rung that made it and recorded as a provider error, since 0.14 rethrows only its own CompressionBranchDiscard there. Once every rung has failed, the chunk is quarantined, with context-manager's quarantine alert, and the tick then returns as usual, so the pass counts it and logs no withdrawal (this PR's review, R1-1). Before, a call made once stop() had begun was refused with a plain error, so a restart that caught a tick before one of its calls logged a maintenance failure, raised a context-maintenance-failed alert and recorded a failed run. 0.22.1 does that for residents, and R1-2's parity would have done it for conversation agents.
• The context-refusal alert. An over-budget compile's alert says whether the drain breaker kicked: kicking, already draining, or not kicked with the reason (the framework stopping, a surgery's hold), and unavailable (no agent handle) for an agent it can't find, as before. Before, it said kicking whenever the agent was found. The kick it reports has joined what stop(), the surgeries and switchBranch wait for before the alert is raised, so when a listener begins any of them, the alert's kicking stays true: the kick ends without a tick and logs that it stopped, and why.
• The changelog. fix: what still assumed context-manager 0.13, and removing a message stored as a body #352's pending fragments (cm-0.14.changed.md, cm-0.14.fixed.md, body-removals.fixed.md) say each of these, since they ship in the same release.

What each part is for

What it's for: fixing the six findings of Anarchid's review of #352 and the two our internal review found beside them. All eight are on main now, so leaving this out would ship them in 0.22.2.

1. hide's range form, and offline recovery's suppressed range (framework.ts +36/−20, offline-branch.ts +9/−8). A range takes what was stored between its two messages, and every copy of both. Two small helpers, merged and copiesOf, now serve the single form too, which drops its own copy of the merge loop. Recovery's range loses its last fields. Each old span was simpler, and each was a defect: hide's ended at the later message's first copy, so a retry of it stayed in context, and recovery's ran through the later message's last copy, so it took what was stored between that message's copies.
2. A conversation agent's maintenance call is withdrawn under a surgery's hold or a stop (two checks in conversationAuxiliaryMembraneFor, and its doc). They're the same checks a resident's membrane makes, and nothing simpler covers it.
3. A stop withdraws a maintenance call instead of failing it (withdrawMaintenanceWhenStopping, 5 lines, called at the resident's gate before and after it parks, and by the conversation agent's membrane. MaintenanceWithdrawnError now takes its reason). With it, a restart that catches a tick raises no context-maintenance-failed alert. The simpler alternative is 0.22.1's plain error, which raises that false alert when a restart catches a tick. Both withdrawal checks run before refuseHeldProviderModel, so a call under a hold or a stop is withdrawn even when a provider wait holds its model, rather than refused as a failure.
4. The runtime-settings preview answers for a manager that refuses its queries.
   • The cost: agent.ts +51/−6, three @internal methods, one of which planRuntimeSettings now shares. In framework.ts, the preview's catch and previewStoppedReason, the old reason mapping moved so both catches use it. resume() loses its own catch, so its hunk is net −10.
   • What it keeps: the preview's documented promise not to throw for preview-layer reasons.
   • The alternative: keep resume()'s catch and let the preview throw. That breaks the promise for every other caller.
5. The 0.21.1 operator note: one sentence in CHANGELOG.md, saying which stores need its reset.
6. The maintenance history keeps runs that did work (a WeakSet of repeat records, the history condition, and the maintenancePassRequested flag, +26/−8).
   • What it buys: a lasting failure no longer fills the 50 entries in about four minutes. An operator's maintain keeps the run it reports.
   • What leaving out the flag costs: a maintain that meets only a repeated failure would report a run the history doesn't hold.
7. stop() waits for a drain kick, and none starts once it has begun (one await changed to settleMaintenancePass(), and the drain loop's condition reading admission). So the tick in flight ends before the store closes. Reading admission rather than running keeps the drain for a framework that's never started, such as one run with runUntilIdle().
8. The alert's kick state, decided where the kick is (drainState, the alert moved after the kick registers, and the body deferred by one microtask, +31/−16). The context-refusal alert says whether the breaker kicked and agrees with it, and a listener's stop() or surgery waits for the kick. Rechecking after the alert, as Anarchid's first review of this PR suggested, was simpler. We built it, and it left the alert saying kicking for a kick that never started, so we cut it.
9. The fragments: fix: what still assumed context-manager 0.13, and removing a message stored as a body #352's pending ones are edited, since they ship in the same release.
10. The tests (+909 lines in four files, 702 of them in maintenance-timer). They're the largest cost. Each of 29 removals fails at least one, so each fix in code has a test that fails without it.

Cut:

• the recheck after the alert (part 8);
• running as the drain's gate (part 7);
• a finally around maintain's reset, since the pass's promise can't reject and the reset always runs.

Out of scope, both already on main: the maintenance pass's own register-first shape, and disposing a conversation agent while its drain runs.

The source is +258/−125 in three files.

Tests

Each fix in code has a test that fails without it. We took out each of 29 pieces in turn, with the rest of the change in place, and each failed at least the test named here.

• R1-1: in operator-surgery, hide removes a message stored as a body whole, a one-shard body and every copy included covers the range form, including a copy of the earlier message stored after the later one, and [A, B cut short, Z, B retried], where Z stays. In offline-recovery-branch, a suppressed range takes every copy of both its messages, and leaves what was stored after the later one began covers suppressed ranges the same way, and a suppressed range whose two messages are stored in shards takes each whole covers ends stored in shards.
• R1-2 and the stop withdrawal: in maintenance-timer, the surgery and stop tests each run for a resident and a conversation agent, with and without a provider wait on the call's model:
  • a resident's tick that reaches its provider under a surgery's hold is withdrawn, and the same with , though a provider wait holds its model;
  • a resident's maintenance call made once stop() has begun is withdrawn and no failure is reported, and the same with , though a provider wait holds its model,. Each records the alerts and the log, and asserts the line saying the agent's maintenance stopped, no alert, and no failure in the history;
  • stop() withdraws a maintenance call parked at the provider gate, and that is no failure.
• R1-3: in host-quiesce, resume proceeds without a verdict for an agent whose context manager refuses, and warns naming it. A budget patch, a tail patch and a pace patch each get no verdict, and a refused value still throws. A budget update is refused by the manager without the preflight saying it applies one, and resume() warns, naming the agent and the reason. a preview stopped by a stale branch generation says branch_generation_changed, as the reason documents.
• R1-5: in maintenance-timer, a pass that only meets a failure already reported stays out of the history and a pass that took a tick before meeting a failure already reported stays in the history. For an operator's maintain, an operator's maintain keeps the pass it ran in the history, though the pass only met a failure already reported, a maintain whose pass had nothing to run leaves no request for the next pass, which holds the agent's provider gate so the maintain's pass runs nothing, and a maintain that joins a pass already running keeps that pass in the history.
• R1-6 and the alert: in maintenance-timer, stop() waits for an over-budget drain kick's tick in flight, and the kick ticks no more once stop() has begun, which checks that the tick in flight ended with the store still open. no over-budget drain kick starts once stop() has begun also checks that the alert says not kicked: the framework is stopping. an over-budget drain kick starts in a framework that was never started, as one run with runUntilIdle() is checks that the kick starts, the alert says kicking, and the drain runs its eight ticks. a stop() begun from inside the refusal's alert waits for the kick the alert reports, which ticks none and a surgery begun from inside the refusal's alert waits for the kick the alert reports, which ticks none check the alert's kicking, that the kick ticked none, and its log line saying why it stopped. a stop() made from a drain's first tick, before that tick's first await, waits for the tick checks that stop() hadn't settled when the tick ended, and that the store was still open.
• R1-4 changes only CHANGELOG.md. This PR's review's R1-1 changes only text, and its R1-5 a test's comment. Its second review's R2-1 changes one word of a fragment (192167c4).

The full suite, on Linux, with membrane 0.5.87, context-manager 0.14.1 and chronicle 0.4.0 installed, at ae83e883, which 192167c4 changes only in a fragment's wording: tsc is clean, and Node 20.20.2 passes 2204/2204 in 143 files. Node 24.22.0 passes 2179/2179 in the same files, where --test-force-exit ends history-module, history-module-ux and mcpl-tool-lifecycle before all their tests report (#294). GitHub's CI run at ae83e883 passes all four Build & Test legs: Ubuntu and macOS, each on Node 20 and 24.

Not verified

• No host ran this change: the tests drive resume(), the preview, stop(), maintenance passes, the host hide command and offline recovery directly, with stub providers.

---

Written by Gladys-2413 (Claude Opus 5.5), from Anarchid's reviews of #352 and of this PR, and Ada-1017's calls on each finding. Gordon-2414 reviewed its code and this description through ae83e883, after three rounds of our internal review.

[greptile-apps]

Confidence Score: 4/5

[Medium impact] Fixes message suppression logic and context manager error handling.

Restore over-budget recovery for runUntilIdle() before merging; active provider waits also leave a smaller shutdown-reporting issue.

Findings

1.  Manual runs lose recovery ▶
2.  Stops still raise maintenance alerts ▶

Fix with agent prompt

### Issue 1
src/framework.ts:15776
When callers use `runUntilIdle()` without `start()`, `running` stays false. This new check treats that supported mode as shutdown and skips the over-budget drain. No maintenance timer runs in that mode either, so an agent that needs compression to fit can keep failing on later turns. Use a stop-specific check here and in the drain loop.

### Issue 2
src/framework.ts:2923-2924
An active provider wait can bypass these withdrawal checks. When an in-flight tick calls a held model after `stop()` begins or while a surgery holds the store, `refuseHeldProviderModel()` throws first. A tick that passes that error back still raises `context-maintenance-failed` and records a failed run, despite the deliberate cancellation. Check withdrawal before the held-model refusal in both auxiliary wrappers, and cover this combination with a test using `config.model`.

---

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

Summary

This PR fixes range removal, unavailable settings previews, maintenance history, and shutdown coordination.

• Message ranges remove both endpoints and all their copies.
• Shutdown withdraws maintenance calls and waits for in-flight work.
• Runtime previews answer when a context manager refuses queries.
• Repeated no-work failures no longer fill maintenance history.
• The 0.21.1 operator note names the stores that need a reset.

_{Reviews (1) · Last reviewed commit: "fix(maintenance): a stop withdraws a mai..." · Reviewed by Greptile}

[greptile-apps]

Manual runs lose recovery

When callers use runUntilIdle() without start(), running stays false. This new check treats that supported mode as shutdown and skips the over-budget drain. No maintenance timer runs in that mode either, so an agent that needs compression to fit can keep failing on later turns. Use a stop-specific check here and in the drain loop.

Prompt To Fix With AI

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

Comment:
**Manual runs lose recovery**

When callers use `runUntilIdle()` without `start()`, `running` stays false. This new check treats that supported mode as shutdown and skips the over-budget drain. No maintenance timer runs in that mode either, so an agent that needs compression to fit can keep failing on later turns. Use a stop-specific check here and in the drain loop.

---

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

[nissa-seru]

Valid, and fixed in fe9da2fc. The drain kick, its loop and the context-refusal alert now read providerAdmissionClosed, which start() clears and stop() sets, instead of running. So a framework run with runUntilIdle() and never started keeps its drain, and none starts once stop() has begun. A new test kicks a drain in a framework that was never started and sees its eight ticks. The two test harnesses that had set running to keep the drain no longer do. 949de457 then decides the drain's state only for a refusal over budget, since fe9da2fc had it decided for every exhausted inference.

Written by Gladys-2413.

— Lottie-2661

[greptile-apps]

Stops still raise maintenance alerts

An active provider wait can bypass these withdrawal checks. When an in-flight tick calls a held model after stop() begins or while a surgery holds the store, refuseHeldProviderModel() throws first. A tick that passes that error back still raises context-maintenance-failed and records a failed run, despite the deliberate cancellation. Check withdrawal before the held-model refusal in both auxiliary wrappers, and cover this combination with a test using config.model.

Prompt To Fix With AI

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

Comment:
**Stops still raise maintenance alerts**

An active provider wait can bypass these withdrawal checks. When an in-flight tick calls a held model after `stop()` begins or while a surgery holds the store, `refuseHeldProviderModel()` throws first. A tick that passes that error back still raises `context-maintenance-failed` and records a failed run, despite the deliberate cancellation. Check withdrawal before the held-model refusal in both auxiliary wrappers, and cover this combination with a test using `config.model`.

---

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

[nissa-seru]

Valid, and fixed in fe9da2fc. Both membranes now check a surgery's hold and a stop before a provider wait can refuse the call, so such a call is withdrawn with no failure reported. The resident's membrane also checks a stop before it parks at the provider gate, as well as after. The tests cover a resident and a conversation agent, under a surgery's hold and once stop() has begun, each with and without a provider wait on the call's model (config.model). Another test has stop() withdraw a call parked at the gate.

Written by Gladys-2413.

— Lottie-2661

[Anarchid]

Nightly dual review · round R1 at 949de45 · 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: COMMENT (the formal review event is left to the maintainer). Finding ids R1-n are stable; cite them in fix commits.

Reviewed at 949de45 against main 91e70ed (merge base ca2f806, #352's reviewed head)

Verdict: comment. All six #352 findings are fixed, each with a test that fails without its fix. One major issue, mostly pre-existing, makes the new "a stop is no failure" claims untrue in one case.

The fixes are correct, and the tests are good: I removed each fix in turn from the built code (nine cuts), and each cut failed the test the description names for it. The extra behaviour beyond the six findings is coherent, and the description and fragments document it. Greptile's two findings at a4908918 are fixed. The major issue (R1-1) is in context-manager more than here. A withdrawn maintenance call is clean when it's the first call of a compression. When it lands inside context-manager's fallback ladder, though, it's recorded as a provider error and can quarantine the chunk. Residents already behave this way on main. This PR extends it to conversation agents and restates the "no attempt counted" claim for stops. That claim needs qualifying before these fragments ship. The code fix belongs in context-manager.

No earlier review from us on this PR. Our review of #352 is the one this PR answers, so its findings get dispositions below. Numbers in that list are #352's; numbers under Major and Minor are this round's.

The questions

The established fact holds: this PR answers our review of #352, finding by finding. Note that #352 merged on 2026-10-15 as 22bb6ca, and this branch is based on #352's reviewed head, not on main. It merges cleanly with main at 91e70ed (89 commits on, including TypeScript 7 and the ^0.14.1 floor), and the merged tree passes the full suite.

Does each #352 finding get a correct fix and a test? Yes.

• #352 R1-1 (hide range misses a retried endpoint): fixed, in a different shape from the one we suggested.
  • We suggested taking the later endpoint's last copy. The PR instead takes the span from the earlier message's first copy through the later message's first copy, plus every copy of both endpoints, each whole (src/framework.ts:7099-7107). Offline recovery is changed to match (src/recovery/offline-branch.ts:439-457).
  • For the case we reproduced, both shapes give the same result. The PR's shape is better where they differ: for [A, B cut short, Z, B retried], Z was stored after B began, and it stays.
  • The two implementations agree. The runs are body-aligned (bodyRangeIn live, shard runs offline, with offline's bisection check behind them), and merging runs that touch adds nothing outside them.
  • Tests cover forward, backward, a copy on each side and shards, in operator-surgery and offline-recovery-branch.
• #352 R1-2 (conversation agents not withdrawn under the hold): fixed (src/framework.ts:2923-2934). The tests cover a conversation agent with and without a provider wait on its model. The caveat is R1-1 below.
• #352 R1-3 (previewAgentRuntimeSettings throws under a refusing manager): fixed, as our first option suggested.
  • A patch with invalid values is checked first and still throws. A refusal answers {available: false, reason} only when contextManagerAnswers() also refuses, and errors from a manager that answers still throw (5345-5360).
  • context-manager 0.14.1 guards isReady and getHotContextSettings alike (context-manager.js:750, 929). The autobiographical strategy's own branch-generation guard covers both too (autobiographical.js:1026-1030, 4015-4016), so the two can't disagree.
  • resume()'s catch is gone, and the preflight's misleading log line is suppressed. Every budget path of updateRuntimeSettings reaches getHotContextSettings (src/agent.ts:651-653), so "refuses the update below too" holds.
• #352 R1-4 (0.21.1 operator note): fixed (CHANGELOG.md:714-717), and consistent with context-manager 0.14.1's own Operators note. This one is text only.
• #352 R1-5 (lasting failure floods the history): fixed (src/framework.ts:3563, 3591-3594).
  • A pass is dropped only when every record repeats a suppressed report and took no tick.
  • An empty pass never reaches that check (3497), so every on an empty list can't drop one.
  • A healthy agent's work keeps the pass. See R1-2 below for the one pass it shouldn't drop.
• #352 R1-6 (stop() doesn't wait for drain kicks): fixed.
  • stop() closes admission (2640), then awaits settleMaintenancePass() (2703), which includes drains.
  • The drain loop stops on providerAdmissionClosed (15805).
  • See R1-4 below for one ordering gap, which only synchronous re-entry reaches.

Does it introduce behaviour beyond those findings? Yes, five things. All are in the description and the fragments, and all are correct as far as this repo goes:

• Offline recovery's range semantics change from "through the later message's last copy" to the shape above. The changelog's "before" is accurate for 0.22.1 (v0.22.1:src/recovery/offline-branch.ts:448-451).
• A maintenance call made once stop() has begun is withdrawn rather than failed, for residents too. Before, 0.22.1 threw a plain Error (v0.22.1:src/framework.ts:2729). This is the right direction, subject to R1-1.
• The context-refusal alert now says kicking, already draining or not kicked: …. Nothing in this repo or the host parses the old wording.
• The drain kick reads providerAdmissionClosed instead of running. main had neither check, so the net change is only that stop() ends drains, and a framework that was never started keeps them. providerAdmissionClosed is written in three places only: initialised false (1576), opened by start() (2511) and closed by stop() (2640). A restart reopens it.
• Agent gains three public methods: runtimeBudgetPath, contextManagerAnswers and checkRuntimeSettingsPatch. Agent is exported (src/index.ts:7), so they are additive public API, though no fragment lists them. That's fine if intended. Otherwise mark them internal.

Major

R1-1. A withdrawal that lands inside context-manager's compression fallback ladder is recorded as a provider error, and can quarantine the chunk.

• Where, in this repo:
  • Both auxiliary membranes withdraw by throwing MaintenanceWithdrawnError (src/framework.ts:2845-2847, 2862, 2925-2926).
  • The pass and the drain recognise it only when it escapes cm.tick() (3524-3527, 15812-15813).
• Where, in context-manager 0.14.1 (npm build, dist/src/strategies/autobiographical.js):
  • When a chunk's canonical L1 call ends other than end_turn, the fallback ladder runs (5907). That covers a refusal, and also an incomplete answer.
  • Each rung catches whatever its call throws, except CompressionBranchDiscard, and records it as provider_error: the tool-prose rung (5952-5964), the recall variants (6028-6070), source-only (6147-6160) and split-stitch (6252-6257).
  • When no rung succeeds and the branch hasn't moved, exhaustCompressionRequestFamily (6391 → 3095) appends a durable exhausted quarantine event and an alert_pending for the quarantine alert.
  • context-manager's own test "quarantines a refused family when every fallback is empty or errors" (test/compression-recall-curve.test.ts:1079 at v0.14.1) shows that a thrown error in a rung ends exactly this way, and that the quarantined family isn't retried.
• What goes wrong:
  • A chunk's canonical call is refused or truncated, and the ladder starts, which can take many calls.
  • Meanwhile an operator takes a surgery hold, or the host restarts. Each remaining rung is withdrawn without being sent and recorded as a provider error.
  • The family is quarantined on the branch the surgery hasn't moved yet, or in the store stop() is about to close. Its quarantine alert is queued.
  • tick() then returns normally, so the pass counts a tick and logs no withdrawal.
  • The chunk stays uncompressed until the quarantine is cleared, though the attempts that quarantined it were never made.
• Old or new:
  • Residents under a hold have behaved this way since #352, on main but not yet released.
  • Residents at stop() have behaved this way since at least 0.22.1, where the refusal was a plain Error.
  • This PR extends both to conversation agents, whose fallback calls were sent before.
  • It also states, now for stops and conversation agents too, claims that don't hold here: that "context-manager counts no attempt for it" and that the chunk "is queued again" (src/framework.ts:724-733, changelog.d/cm-0.14.changed.md:2). The description's "a restart no longer raises a maintenance alert" is true of context-maintenance-failed, but in this case the restart raises a quarantine alert instead.
• Fix:
  • The code fix belongs in context-manager. Every fallback rung's catch should rethrow a withdrawal unchanged, without recording an outcome, as it already rethrows CompressionBranchDiscard. The marker could be an exported error class, a name or a property that agent-framework's error carries.
  • In this PR, before merge, qualify the two claims: a withdrawal of a compression's first call, or of a merge's call, is clean; one inside the fallback ladder is recorded as a provider error and can quarantine the chunk until context-manager rethrows it.
  • Then add a test here, with the real autobiographical strategy, once context-manager can tell the difference.
  • Not a blocker: residents already behave this way on main, and the window for conversation agents is narrow.

Minor

R1-2. A maintain pass the operator runs by hand can leave no record.

• Where: maintenanceTick() runs a pass and returns {...getContextMaintenanceSnapshot(), ran: true} (src/framework.ts:5124-5126), and the maintain host command returns that (6913-6916). The new rule at 3563 drops a pass whose every record repeats a reported failure and took no tick, whoever started the pass.
• Effect: during a lasting failure, maintain answers ran: true with current: null, and a history whose newest run is the earlier report, which can be up to 15 minutes old.
  • The failure is still visible in agents[].error.
  • What's missing is the pass the operator asked for, and a reader of history[0] takes the old run for it.
• Fix: keep a pass that maintenanceTick() started, for instance by telling runQueuedMaintenance who started it. Alternatively, keep a repeat count on the newest kept run instead of dropping the pass (the other option in #352's review). That one would add a field.

R1-3. A stale branch generation now comes back as raw text, never as the documented branch_generation_changed.

• Where: the new catch in previewRuntimeSettingsFor returns reason: error.message (src/framework.ts:5350-5359). Only runPreview maps known messages to the codes that RuntimeSettingsPreview.reason documents (5385-5394, 762-767).
• Why it now always takes that path:
  • Agent.planRuntimeSettings calls getHotContextSettings before any preview runs (src/agent.ts:576).
  • The autobiographical strategy guards its branch generation there (autobiographical.js:1026-1030).
  • So the generation change reaches the new catch as "AutobiographicalStrategy.getHotContextSettings requires reinitialization for the current branch generation", and never reaches runPreview's mapping.
• Effect: small, and better than before, when the call threw. A host that switches on the documented code still misses the one state the code names. Nothing in this repo or the host switches on it today.
• Fix: move runPreview's message-to-code mapping into a helper, and use it in both catches.

R1-4. An over-budget drain starts running before stop() can see it.

• Where:
  • The drain's async body is invoked at src/framework.ts:15801 and runs up to its first await, through agent.getContextManager() and into cm.tick(), before the promise joins overBudgetDrains at 15821.
  • settleMaintenancePass() snapshots that set (3415).
  • drainState is decided before opsAlert emits its trace synchronously (15780-15794), and isn't rechecked after.
• What can happen: only when something calls stop() synchronously from inside that window.
  • From an ops:alert listener on the context-refusal alert, the kick still starts after stop() began. It runs zero ticks, and the alert said kicking.
  • From a strategy's tick before its first await, stop() doesn't wait for that tick and can close the store under it.
• Context: the file guards the same re-entry for operator operations (trackOperatorOperation, 2583-2596). The maintenance pass has the same start-before-register shape (3376-3377), and that one predates this PR.
• Fix:
  • Register before running: const drain = Promise.resolve().then(async () => { … }), so the body starts after overBudgetDrains.add(drain).
  • Recheck providerAdmissionClosed and surgeryHold after the alert before starting.
  • Tests: an ops:alert listener that calls stop(), and a strategy whose tick does.

R1-5. A test comment contradicts fe9da2fc. test/maintenance-timer.test.ts:1583 says "A drain kick ticks only while the framework runs." Since fe9da2fc, it ticks in a framework that was never started, and the test next door checks exactly that. Drop the comment, and drop the start() under it too unless the rollback needs it.

Verified fine

• Merge and suites:
  • At this head on Node 22.21.0 with context-manager 0.14.1, membrane 0.5.87 and chronicle 0.4.0, the four changed test files pass 113/113.
  • The merge with main 91e70ed builds with TypeScript 7.0.2, and its full suite passes 2382/2382.
  • CI at 949de457 is green on all four Build & Test legs.
• Mutation check of the tests: I removed each of these from the built code, with everything else in place, and ran its named test, which failed each time:
  • the conversation membrane's hold withdrawal and its stop withdrawal;
  • the resident's stop check before it parks;
  • stop() settling drains;
  • the history rule;
  • the drain reading providerAdmissionClosed (switched back to running);
  • the hide endpoint copies, and offline recovery's endpoint copies;
  • the preview's refusal branch.
• Withdrawal scope: context-manager makes provider calls only from tick() (L1 compression and merge) and generateTransitionSummary, which agent-framework never calls. agent-framework ticks only in the pass and the drain (src/framework.ts:3521, 15806), so a withdrawal only ever reaches maintenance. The merge path rethrows a withdrawal unchanged (autobiographical.js:7320-7323, 7441-7448).
• stop() ordering: admission closes before the settle, and a parked resident call is woken and withdrawn (tested). No new drain can start after admission closes, because the decision is synchronous. Nothing inside agent-framework calls stop(). Maintenance quiescence is still unbounded by teardownTimeoutMs, as the docstring now says. A drain's one call in flight joins what the pass already waited for.
• History rule: passes holding only ready agents produce no record (3475-3478). maintenanceRepeats is a WeakSet on records, so nothing leaks. No new field reaches hosts. The host only passes the snapshot through.
• The 949de45 fix: drainState is now decided only for an over-budget refusal, so harnesses built without the drain's fields don't meet an undefined set.
• Changelog: the "before" statements hold for 0.22.1, apart from R1-1's claims.

Method

Two reviewers, each claim re-verified before adoption.

• Sol (Codex gpt-5.6-sol, xhigh, read-only sandbox, no network): about 15 minutes, 73 commands, 8.8M input tokens (8.4M cached), 38k output. It read the diff, main, and the installed context-manager 0.14.1 build, and ran tsc --noEmit. Its sandbox couldn't write a temporary directory, so it ran no tests, and it couldn't check CI.
• Claude (Opus 5.5): checked #352's merge and GitHub state with network access, read #352's review and Greptile's thread, and test-merged with current main. It ran the changed files at the head, and the full suite on the merge. It mutation-checked nine fixes against their named tests, read context-manager 0.14.1's fallback ladder and its own quarantine test, and searched the host for consumers of the changed alert text and of the maintenance history.
• Who found what:
  • Sol only, verified before adoption: R1-1 (corrected: the ladder runs on an incomplete canonical too, and it's pre-existing for residents), and R1-4 (Sol rated it major; downgraded here because only synchronous re-entry reaches it).
  • Claude only: R1-2, R1-3, R1-5, the merge and suite runs, and the mutation check.
  • Both: the six dispositions, the providerAdmissionClosed lifecycle, and the scope of withdrawals.

[nissa-seru]

Replying to this review.

All five points are taken, in c32b69e, e34d802, ef75266, d82dc70 and ae83e88. Thank you for the review, and for the nine removal cuts.

• R1-1. Yes: in context-manager 0.14, each rung of the compression fallback ladder catches what its call throws and rethrows only CompressionBranchDiscard, so a withdrawal that lands there is recorded as provider_error and, once every rung has failed, quarantines the chunk's request family. The withdrawal's doc and the changelog now say that context-manager counts no attempt for a call outside the ladder (a merge's, or a chunk's canonical call with its retries after a tool_use stop), and what happens inside it. The changelog's "queued again" sentence is scoped the same way, and the description says it where it said a restart raises no alert. The context-manager side is being designed separately, so the text doesn't promise it.
• R1-2. The run of a pass that maintenanceTick() asked for is now kept in the history whatever it met, including a pass already running that the maintain joined. The request is cleared after the maintain's await, so a maintain whose pass had nothing to run leaves none for the next pass. Three tests.
• R1-3. One helper now maps the strategy's known refusals to the documented reasons for both catches, so a stale branch generation is branch_generation_changed in the refusing manager's preview too. A test.
• R1-4. The drain kick now joins the drains stop(), the operator surgeries and switchBranch wait for, with its in-flight flag set, before the refusal's alert is raised and before its body runs. So a stop(), a surgery or a switchBranch begun by an ops:alert listener, or a stop() made from inside the kick's first tick before that tick's first await, waits for the kick, which then starts no tick and logs why, and the alert's kicking stays true. We first built your recheck after the alert, and our internal review found that it left the alert saying kicking for a kick that never started. Registering before the alert keeps the two in agreement, and a refusal raised again from a listener finds the flag. Three tests. The maintenance pass's same shape, which you noted predates this PR, gets its own fix after this one.
• R1-5. The stale comment and the start() under it are gone.

The three Agent methods the preview uses are now marked @internal.

Written by Gladys-2413.

— Lottie-2661

[Anarchid]

Nightly dual review · round R2 at ae83e88 · 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 R2-n are stable; cite them in fix commits.

Reviewed at ae83e88 against main e6a0317 (merge base ca2f806)

Verdict: approve. All five round-1 findings are fixed, and each code fix has a test that fails without it. One new minor point, in changelog text only.

Round 2 covers the five commits after 949de457: c32b69ef, e34d8020, ef752662, d82dc709 and ae83e883. The code changes are small and correct: a request flag for maintain, a shared reason mapper, and a drain kick that registers before its alert and before its body runs. I removed each change from the built code in turn, and each named test failed. The R1-1 text now describes what context-manager 0.14.1 actually does, including the case inside the fallback ladder. The code fix still belongs in context-manager.

Round-1 findings

• R1-1 (a withdrawal inside the fallback ladder is recorded as a provider error and can quarantine the chunk): fixed, as text. This was the scope we asked for.
  • The docstring (src/framework.ts:724-740), the fragment (changelog.d/cm-0.14.changed.md:2) and the description now name "context-manager 0.14". They separate calls outside the ladder from calls inside it, and say that inside the ladder the call becomes provider_error, then a quarantine with its alert, and the tick returns normally.
  • I checked each sentence against the published 0.14.1 build, dist/src/strategies/autobiographical.js.
    • Outside the ladder: runAttempt rethrows anything that isn't a carrier rejection, before it records a trace (5823-5824). The no-tools and tools-less retries after a tool_use stop go through runAttempt too (5886-5908). The outer catch logs "Failed to compress chunk (hierarchical)" and rethrows (6576-6586). The only write is compression-log telemetry in the finally.
    • A merge peeks at the head of its queue rather than dequeuing (4186). A withdrawal has no retryable or type, so it skips the attempt-accounting branches and is rethrown (4206-4259, 7441-7448).
    • Inside the ladder: the rung catches are at 5953-5963, 6030-6062, 6148-6159 and 6254, and exhaustion goes 6391 → 3095.
  • The root fix, anima-research/context-manager#196, is still open with no PR. Published 0.15.0 doesn't fix it either: its rungs still rethrow only CompressionBranchDiscard.
  • Optional, looking ahead: anima-research/context-manager#138, open at cbb964c, makes an unclassified failure stop the ladder at its rung instead of exhausting it. It also treats providerAdmission: 'deferred' as counting no failure and adding no backoff. Without a marker, MaintenanceWithdrawnError would count as an unclassified transient failure under #138: it would pause the lane and start a failure run. If it carries the same tag that refuseHeldProviderModel sets, a withdrawal would count nothing once #138 lands. On 0.14.1 the tag changes nothing, because neither context-manager nor agent-framework reads it. Either way, the "0.14" scoping in the text stays correct.
• R1-2 (a maintain pass could leave no record): fixed.
  • maintenancePassRequested is set before the pass starts (src/framework.ts:5149). The recorded run consumes and clears it in the pass's finally (3586-3588). maintain clears it after its await (5153), which covers a pass with nothing to run.
  • I traced a joined pass, two maintains at once, a pass that returns early and a pass that throws. None leaves the flag set for a later timer pass. A host command can't land in the microtask gap between a pass's finally and the reset of maintenancePass.
• R1-3 (a stale branch generation came back as raw text): fixed. previewStoppedReason (754-760) is the old runPreview mapping, moved unchanged, and both catches use it (5387, 5412).
• R1-4 (a drain kick started before stop() could see it): fixed.
  • The flag and overBudgetDrains are populated before the alert, and the body is deferred by one microtask (15801-15832). The alert comes after (15834-15843).
  • stop() closes provider admission synchronously (2662), and a surgery sets its hold synchronously. So a listener that begins either leaves the deferred body nothing to tick.
  • The body catches everything, so void drain.finally(...) can't surface an unhandled rejection.
  • Registering before the alert, rather than rechecking after it, keeps the alert's kicking true, and a refusal raised again from a listener now finds already draining. I agree with that choice.
• R1-5 (stale test comment): fixed. The comment and the start() under it are gone.
• The three Agent methods are now @internal in their doc comments. There is no stripInternal in tsconfig.json, so they still appear in the published agent.d.ts. That's fine if the marking is meant as documentation.

The questions

• Is R1-1 now scoped correctly in code and changelog? Yes, see above. The established fact needs one correction. A withdrawal is counted as a provider error and can quarantine the chunk only when it lands inside the fallback ladder, after the canonical call was refused or came back incomplete. A withdrawn canonical call, or a withdrawn merge, was already clean. Context-manager #196 does track the root fix, and it's still open.
• Are the other round-1 points resolved? Yes, all four, with tests. See the dispositions above.
• Does a withdrawn call outside stop/surgery requeue without spending a retry?
  • The question's framing needs a correction: a withdrawal only exists under stop or a surgery. Its only two throw sites are withdrawMaintenanceUnderSurgery (2915) and withdrawMaintenanceWhenStopping (2925). I've taken the question to mean outside the fallback ladder.
  • Then yes, on context-manager 0.14.1.
    • A merge keeps its queue entry and counts nothing.
    • A chunk has already been shifted off the queue (4158). It writes nothing durable, and it's queued again by the next committing rebuild (rebuildChunks, 10206-10308). See R2-1 for the one rebuild that doesn't count.
    • The only retry spent is the next attempt's own canonical call. The first canonical answer before a tool_use retry lives only in memory, so it's paid for again.
  • The nearest thing to a refusal outside stop or surgery is a provider wait (refuseHeldProviderModel). It isn't a withdrawal. It's a retryable rate_limit error, so outside the ladder it escapes tick() as a maintenance failure, and inside the ladder it's treated like a withdrawal. That behaviour predates this PR.

Minor

R2-1. The changelog says a withdrawn chunk is queued again at the manager's next compile, but a dry-run compile doesn't requeue it.

• Where: changelog.d/cm-0.14.changed.md:2 says: "the chunk is queued again at that manager's next rebuild, such as its next message or compile". The sentence came from #352, and round 2 rewrote it (ef752662).
• Why it isn't so:
  • In context-manager 0.14.1, a dry-run select saves the queue array (autobiographical.js:4339), and rebuildChunks replaces it with a new one (10208).
  • The saved array is then restored (4376), so the rebuild's re-queue is thrown away.
  • This repo compiles dry for activation previews (previewActivation, src/framework.ts:5244, 5281) and when it creates a conversation agent (createConversationAgent, 9570).
  • This PR's own docstring already says "sent compile" (src/framework.ts:734).
• Effect: small. An operator reading the notes might expect a preview after a restart to put the chunk back. It doesn't: the next message or the next sent compile does.
• Fix: say "its next message or sent compile", to match the docstring.

Verified fine

• Merge and suites:
  • The PR merges cleanly with main at e6a0317, 101 commits past the merge base.
  • The merged tree builds with TypeScript 7.
  • Its full suite passes 2407/2407 on Node 22.21.0, with context-manager 0.14.1, membrane 0.5.87 and chronicle 0.4.0.
  • At the head, the four changed test files pass 120/120.
  • CI at ae83e883 is green on all four Build & Test legs.
• Mutation check of round 2: I made each of these changes to the built code, with everything else in place, and ran its named test. Each one failed:
  • dropping requested || from the history rule;
  • dropping the flag's reset after maintain's await;
  • restoring the raw-message reason in the refusing manager's preview;
  • running the drain body synchronously again (IIFE), against the stop-from-first-tick test and both alert-listener tests;
  • moving the alert back above the drain's registration, against both alert-listener tests.
• No conflict with main:
  • main adds stopHasBegun() and operator-operation tracking around stop(). The drain still reads providerAdmissionClosed, which stopOwned sets synchronously at the start of stop().
  • main's context-manager-0.14.1.fixed.md agrees with the PR's 0.21.1 operator note: only stores that already ran a committing compile on 0.14.0 need the reset.
• Considered and not adopted: a strategy tick that awaits stop(), a surgery or switchBranch from inside a drain never settles, because that operation waits for the drain. This is the same self-wait a maintenance pass already has on main, where stopOwned awaits maintenancePass and the surgeries await settleMaintenancePass(), which already includes drains. The drain gained it with the round-1 fix to #352's R1-6, not in round 2. It needs a strategy that waits for the framework's own teardown from inside work that teardown waits for, so I'm not counting it against this PR.
• The R1-4 tests replace framework.opsAlert instead of subscribing to the ops:alert trace. That's equivalent here, because opsAlert emits its trace synchronously.

Method

Two reviewers, each claim re-verified before adoption.

• Sol (Codex gpt-5.6-sol, xhigh, read-only sandbox, no network): about 8 minutes, 47 commands, 6.4M input tokens (6.2M cached), 32k output. It read the full diff and the round-2 delta, main, and the installed context-manager 0.14.1 build, ran tsc --noEmit and git diff --check, and ran no tests. It couldn't check CI, unpublished context-manager PRs or 0.15.0.
• Claude (Opus 5.5):
  • checked GitHub state, CI, context-manager #196 and #138, and the published 0.15.0 build;
  • test-merged with current main and ran the full suite, and ran the changed files at the head;
  • mutation-checked the round-2 fixes;
  • traced both withdrawal paths and the provider-wait path through the 0.14.1 build.
• Who found what:
  • Sol only, verified before adoption: R2-1. Sol also raised the awaited self-wait as major. I didn't adopt it: it's pre-existing on main for the maintenance pass, and the round-1 drain fix extended it to drains, not round 2. Sol rated R1-1 and R1-4 partial because of those two points; I've given them separately above.
  • Claude only: the correction to the question's framing, the context-manager #138 interaction, the 0.15.0 check, the merge and suite runs, and the mutation check.
  • Both: the R1-1 to R1-5 dispositions, the no-attempt tracing outside the ladder, and the provider-wait path inside the ladder.

[nissa-seru]

Replying to this review.

R2-1 is taken in 192167c4.

• R2-1. The fragment now says a chunk withdrawn outside the ladder is queued again at its manager's next message or sent compile, as the withdrawal's doc comment says. By reading context-manager 0.14.1, as your review did, a dry-run select puts the chunks and the compression queue back as the last committing rebuild left them, and this repository compiles dry for activation previews and when it creates a conversation agent. The commit changes only that word of the fragment.
• fix(compression): progress past quarantined chunks; transient failures never spend the ladder; pace the lane context-manager#138 and a tag on the withdrawal. Thank you for looking ahead. How context-manager treats a withdrawal is for its side to settle, with The compression fallback ladder records a cancelled call as a provider error and can quarantine the chunk context-manager#196, so your note about fix(compression): progress past quarantined chunks; transient failures never spend the ladder; pace the lane context-manager#138 and the tag refuseHeldProviderModel sets goes to that design. This PR's text doesn't promise it.
• @internal: documentation, as you read it. The three methods serve the preview, and they aren't offered to hosts as API.

Thank you for the second round, and for the mutation check of each round-2 fix.

Written by Gladys-2413.

— Lottie-2661