fix(rebuild): make manual /rebuild perform an on-the-spot rebuild with writer-freshness + waiting UI

[wqymi]

Summary

• Bug: Manual /rebuild only inserted a DB boundary marker and returned — the actual context rebuild was deferred to the NEXT user message, with zero frontend feedback (no spinner, no text).
• Root cause: The handler called rebuildFromCheckpoint() (which inserts a boundary) then prompt({noReply:true}) which short-circuited before the runLoop ever set busy status.
• Fix:
  1. Set session.status busy BEFORE rebuild work so the TUI spinner lights up immediately, with a descriptive message: "Rebuilding context…" (all cases) and "Writing checkpoint…" (case 2 writer-wait phase).
  2. Remove noReply:true on the rebuild-success path so the runLoop actually runs — the model sees the rebuilt context and produces a response; the Runner's onIdle clears busy status automatically.
  3. Keep noReply:true only for the no-checkpoint case with explicit idle clear.
  4. Case 2 (no checkpoint): Actively spawns a checkpoint-writer via tryStartCheckpointWriter(), waits for it via waitForWriter() (5-min safety bound), then rebuilds from the freshly-written checkpoint.

3-Case Checkpoint-Freshness Semantics (via renderRebuildContext)

Case	Condition	Behavior	Timeout
1	Checkpoint exists, no writer	Immediate rebuild	N/A
2	No checkpoint, no writer	Spawn writer + wait + rebuild	FIRST_CHECKPOINT_WAIT_MS (5 min)
3	Checkpoint exists, writer in-flight	Wait for fresher checkpoint	REBUILD_WAIT_MS (30 sec), fallback on timeout

Files Changed

• packages/opencode/src/session/prompt.ts:3964-4080 — /rebuild handler rewired with 3-case logic + busy messages
• packages/opencode/test/session/rebuild-on-the-spot.test.ts — 3 new tests

Verification

• bun typecheck from packages/opencode: EXIT 0
• 3 new tests pass (case 1 immediate rebuild, case 2 source-level guard, busy message assertions)
• 7 existing rebuild tests continue to pass (no regressions)

---

Follow-up fix — manual /rebuild must NOT auto-reply (b8a879d)

Correction to item 2 above. Live TUI testing confirmed a regression: dropping noReply:true on the manual /rebuild success path made the model emit a spurious reply (e.g. "Ready for your next request") after every manual rebuild. A manual /rebuild is a user action whose only intent is to free/rebuild context — the user asked no question, so a model reply is a "reply to nothing". The earlier review already flagged "Dropping noReply so the model responds after rebuild is a deliberate behavior change" — that change was the bug.

Trigger-source distinction (the correct behavior):

• Manual /rebuild (user-initiated, no pending question) → rebuild, then STOP. No auto-reply.
• Auto-triggered rebuild (compaction mid-turn, pending user message) → rebuild, then continue answering the pending message (correct, unchanged).

The distinction is structural: the auto path lives inside the runLoop and uses continue/return "continue" (prompt.ts ~3188/3761) to keep answering the pending user turn — it never re-enters prompt(). Only the manual handler calls prompt() with the synthetic note.

Fix (prompt.ts manual /rebuild success path):

• Restore noReply:true so the boundary is inserted and the waiting UI still shows, but the runLoop is never entered — no spurious reply.
• Clear busy status explicitly (the runLoop's onIdle no longer fires since loop() doesn't run) — mirrors the existing no-checkpoint paths.
• Unchanged: busy-UI wiring ("Rebuilding context…" / "Writing checkpoint…"), on-the-spot rebuild, writer-freshness, and the case-2 spawn→wait→rebuild behavior.

Tests (rebuild-on-the-spot.test.ts): case 1 and case 2 now assert NO model reply after a manual /rebuild (llm.calls === 0, returned message role ≠ assistant) while still asserting the boundary insertion and busy-status messages.

Verification: bun typecheck EXIT 0; rebuild-on-the-spot.test.ts 4/4 pass; related rebuild/checkpoint tests (prompt-rebuild-loop, prompt-rebuild-reset, checkpoint-rebuild-unify, checkpoint-rebuild-nonblocking, rebuild-microcompact, command/rebuild) all pass. Rebased clean onto latest origin/main.

---

Real fix — remove the fabricated second user turn (e43b1ba)

This supersedes the noReply follow-up above. The noReply approach was a band-aid on the wrong layer. Root-causing against the DB revealed the actual defect.

Root cause (verified via the message table): The manual /rebuild handler did TWO things:

• Step A (correct, kept): rebuildFromCheckpoint() → insertRebuildBoundary() inserts the legitimate rebuild boundary as a role:"user" message carrying a checkpoint part. This is the SHARED mechanism the auto pre-turn overflow (prompt.ts ~3205), auto mid-turn (~3778), and manual /rebuild paths all use.
• Step B (the bug, removed): a trailing prompt({ parts:[{text:"Context rebuilt from the latest checkpoint…", synthetic:true}], noReply:true }) that fabricated a SECOND, standalone role:"user" turn. The auto/compaction paths NEVER create this — they just continue/return "continue" the runLoop to answer the pending user message. noReply:true only suppresses the model REPLY; createUserMessage still PERSISTS the fabricated user message. So after a manual /rebuild the DB showed extra role=user rows ("Context rebuilt from the latest checkpoint…") with ZERO assistant replies — the reply was hidden but the fabricated user turn remained.

The correct fix: Make manual /rebuild behave exactly like the auto/compaction path — insert the boundary and settle transparently, WITHOUT fabricating a second user turn:

1. Kept Step A (boundary insertion via the shared helper).
2. Removed Step B — no more prompt({…"Context rebuilt…", noReply:true}). The noReply band-aid on the /rebuild path is gone (still preserved for other callers such as /goal clear).
3. Outcome surfaced via the status channel, not a persisted synthetic user message: "Context rebuilt from the latest checkpoint…" (success) / "No checkpoint is available to rebuild from yet…" (no checkpoint) are emitted on the SessionStatus / Bus busy-status channel — the same channel that drives "Rebuilding context…"/"Writing checkpoint…" — then the session goes idle.
4. Returns to idle correctly: manual /rebuild is a user-initiated maintenance action with NO pending question, so after inserting the boundary it finishes to idle (no model turn, no auto-reply). The auto path continues only because it HAS a pending user message mid-runLoop; the manual handler has none, so it cleanly returns the boundary message and clears busy status. No broken/busy state, no auto-reply.

Handler edit (before → after, success path):

// BEFORE (band-aid): fabricates a second user turn, hidden by noReply
const result = yield* prompt({
  sessionID, messageID, agent: agentName,
  parts: [{ type: "text", text: "Context rebuilt from the latest checkpoint…", synthetic: true }],
  noReply: true,
})
yield* status.set(sessionID, { type: "idle" })
return result

// AFTER (real fix): surface outcome on status channel, return the boundary itself
yield* settle(rebuiltMsg) // status.set(busy, "Context rebuilt…") then status.set(idle)
const after = yield* sessions.messages({ sessionID, agentID: "main" })
const boundaryMessage = after.findLast((m) => m.parts.some((p) => p.type === "checkpoint"))
return boundaryMessage ?? lastUser ?? after[after.length - 1]!

(The no-checkpoint and degraded paths likewise drop prompt({noReply:true}), surface the outcome via settle(noCheckpointMsg), and return the existing last user message — persisting nothing new.)

Tests (rebuild-on-the-spot.test.ts): now assert that after a manual /rebuild the message table gains EXACTLY ONE new message — the boundary (role:"user" + checkpoint part) — with no fabricated "Context rebuilt…" user turn and no assistant reply (llm.calls === 0, returned role ≠ assistant). The no-checkpoint fallback asserts the count is unchanged (nothing persisted). All assert the outcome is surfaced on the busy-status channel, not as a persisted user message. The busy-message test ("Rebuilding context…"/"Writing checkpoint…") is unchanged and still passes.

Verification: bun typecheck EXIT 0 (full-repo turbo typecheck 12/12 on push); rebuild-on-the-spot.test.ts 4/4 pass; 29 related rebuild/checkpoint tests pass (command/rebuild, rebuild-microcompact, checkpoint-rebuild-unify, prompt-rebuild-reset, prompt-rebuild-loop, checkpoint-rebuild-nonblocking, checkpoint-rebuild-v3, checkpoint-rebuild-fallback-decision). Rebased clean onto latest origin/main. #1752's core value (on-the-spot rebuild + writer-freshness + busy "Rebuilding context…"/"Writing checkpoint…" UI) fully intact.

---

UX completion — make the boundary VISIBLE in the transcript (054775d, folded in from #1940 which is now closed)

The real fix above leaves the manual /rebuild boundary as the only new message. But that message rendered zero rows in the TUI, so a user who ran /rebuild saw the spinner, then nothing — no way to tell it happened or where the boundary sits.

Why nothing rendered: the boundary is a role:"user" message whose parts are a checkpoint part plus synthetic: true text parts. PART_MAPPING (tui/routes/session/index.tsx) covers only text/tool/reasoning — there is no checkpoint entry — and UserMessage renders its text block only when a non-synthetic text part exists. Both conditions fail, so the whole message drew nothing.

Why this is render-only: what each mechanism actually sends to the model

The obvious alternative was "reuse compaction's mechanism" — compaction is visible because it writes a real summary: true assistant message whose text renders through TextPart. Tracing toModelMessagesEffect/filterCompacted shows why copying that shape would be a downgrade, not an upgrade:

	compaction	rebuild
boundary message	role:user + compaction part	role:user + checkpoint part
what the boundary contributes to model context	bare label "Summary of previous conversation:" (message-v2.ts:709-713) — no content	label "Summary of previous conversation from checkpoint files:" (message-v2.ts:703-708) plus the rendered checkpoint index + rebuild context + actor registry, carried as synthetic: true text parts (checkpoint.ts:1465-1497)
where the summary text lives	a separate summary: true assistant message written by processCompaction (compaction.ts:337-364), needing a second LLM call	inline on the boundary user turn, deterministic, no extra LLM call
does the summary reach the model?	yes — the assistant branch has no summary filter (message-v2.ts:786-792); filterCompacted stops at the boundary so the newer summary message survives (message-v2.ts:1025-1033)	yes — the user-part filter is !part.ignored, not !part.synthetic (message-v2.ts:681-685), so all of the rebuild text is sent

Both boundaries therefore deliver a real, model-readable summary; rebuild's is arguably richer (structured index + rebuild context + actors) and cheaper (no summarizer call). The asymmetry was purely in the render layer: synthetic: true hides text from the transcript, never from the model.

So bolting a compaction-style assistant summary onto rebuild would duplicate that text in the context window and change model-facing semantics for zero comprehension gain. Only the render layer moves.

Change: render the checkpoint part as a one-line badge row in UserMessage, reusing the badge pattern already used for cron fires and actor notifications:

 ⟲ context rebuilt   earlier messages summarized

• i18n keys tui.session.rebuild_boundary.{label,detail} added for en / zh / zht.
• test/cli/cmd/tui/rebuild-boundary-marker.test.ts pins the copy and asserts zh/zht are genuinely translated (not silently falling back to English through the base merge in context/language.tsx).
• test/session/rebuild-boundary-model-context.test.ts (new) pins the semantics table above so a future refactor cannot silently change what the model receives: the synthetic rebuild content survives into the model messages, the compaction summary: true assistant turn survives into the model messages, and filterCompacted keeps the summary message after the boundary.

No rebuild or compaction logic changed.

Verification: bun typecheck EXIT 0 (12/12 turbo tasks). test/cli/cmd/tui/ + checkpoint-rebuild-unify + the new model-context test: 74 pass / 0 fail. All rebuild/checkpoint/message-v2 suites: 55 pass / 0 fail. Rebased clean onto latest origin/main (eaac8b7ac).

---

Follow-up (eb4183825): a finished status message latched into the next turn, and squeezed the counter

Live verification of this PR surfaced a second, render-layer defect. After /rebuild, the whole following turn showed the rebuild outcome sentence on the spinner line instead of the current activity, and because that sentence wraps to three lines it squeezed the footer until the context counter rendered clipped as 52.4K/96 instead of 52.4K/960K — the exact number this PR is about.

Diagnosed mechanism (not a coalescing race, and not the server holding state):

• settle() (session/prompt.ts:4173-4174) emits busy{message} then idle. Server-side that is clean: SessionStatus.set publishes and then deletes the map entry on idle (session/status.ts:77-80). No debounce, no dedupe, no "keep last message".
• The TUI stored it with setStore("session_status", sessionID, status) (cli/cmd/tui/context/sync.tsx:454). Solid's store setter merges a plain object into the existing node — updatePath → mergeStoreNode only writes Object.keys(next) (solid-js@1.9.10/store/dist/store.js:201-202, :139-145). Keys absent from the incoming status are retained.
• So idle merged down to { type:"idle", message:"Context rebuilt…" }. Invisible, because the spinner row is gated on status().type !== "idle" (component/prompt/index.tsx:1884) — which is why it "only cleared when the session went fully idle".
• The next turn's runner emits a bare { type: "busy" } with no message (session/run-state.ts:74). Merged over the latched object it became { type:"busy", message:"Context rebuilt…" }, and busyMessage() (component/prompt/index.tsx:1898-1901) rendered the stale sentence for the entire turn.

Fix — TUI store layer, sync.tsx. A session.status event is authoritative for the whole status object, so it is wrapped in reconcile() (nextSessionStatus), which drops the fields the new status omits. Chosen over the alternatives because the bug is general (any status that omits a field inherited it — retry's attempt/next leaked the same way), not rebuild-specific; and because settle()'s emission is left intact for the non-TUI consumers (SDK session.status, plugin API, run completion) and its existing tests. The user-visible confirmation is unaffected: it is the ⟲ context rebuilt transcript boundary row added earlier in this PR, which is persisted and verified.

Footer hardening (independent of clearing): the status message is clamped to a fixed cell budget with newlines flattened (component/prompt/footer.ts, clampStatusMessage, 48 cells) and rendered wrapMode="none" flexShrink={1}; the context counter gets flexShrink={0} so it is never the element that gives way.

Tests (each proven by reverting only the src change):

• test/cli/tui/session-status-store.test.ts — status lifecycle against a real Solid store: a following turn's bare busy does not inherit the rebuild message; idle clears; busy replaces; retry fields do not survive. Revert probe (reconcile → raw status): 3 fail, e.g. Expected {"type":"idle"} / Received {"type":"idle","message":"Context rebuilt from the latest checkpoint. …"}.
• test/cli/cmd/tui/prompt-footer-status.test.ts — over-long status clamped to the budget, newlines flattened, empty → nothing, and the budget arithmetic leaves room for spinner + esc interrupt + 52.4K/960K (5%) on 80 columns. Revert probe (clamp removed): 2 fail, Expected: 48 / Received: 109.
• test/session/rebuild-on-the-spot.test.ts — now also asserts the terminal status is idle, so /rebuild cannot leave a busy status behind. Revert probe (drop settle's idle): Expected: "idle" / Received: "busy".

Verification: bun typecheck EXIT 0. test/cli/tui + test/cli/cmd/tui + rebuild-on-the-spot + run-completion: 214 pass / 0 fail (pristine baseline of the same command: 204 pass / 0 fail — the +10 are the new files). Live in a real TUI on mimo/mimo-v2.5, the turn immediately after /rebuild:

   ∙·🛸             esc interrupt                      51.1K/960K (5%)  tab 切换模式  ctrl+p 设置
     ·˙∙·˙🛸        esc interrupt                      51.1K/960K (5%)  tab 切换模式  ctrl+p 设置
           ·˙∙·˙🛸  esc interrupt                      51.1K/960K (5%)  tab 切换模式  ctrl+p 设置

No stale sentence, counter intact. And with a status genuinely in flight during the rebuild itself:

   ·˙∙🛸           Writing checkpoint…  esc interrupt            49.0K/960K (5%)

---

Auto overflow now writes a checkpoint before it degrades (closes an asymmetry with manual /rebuild)

The asymmetry. Both paths share rebuildFromCheckpoint (prompt.ts:398), which only checks hasCheckpoint and returns false — it never starts a writer. The two callers then disagreed about what false means:

• Manual /rebuild treated it as "make one": it called tryStartCheckpointWriter, waited on waitForWriter, and only then rebuilt.
• Auto overflow treated it as "give up": if (inserted) {…} then straight to compaction.create.

So in the same state — no checkpoint — a human who asked got one created, while an automatic mid-turn overflow silently degraded.

Fix. One shared helper, rebuildEnsuringCheckpoint, used by all three main-agent sites (token-threshold overflow, provider-signalled overflow, manual /rebuild). It returns a discriminated outcome so there is exactly one compaction fallback condition instead of three lookalikes that can drift:

outcome	meaning	may compact?
"rebuilt"	boundary inserted, context freed	—
"no-checkpoint"	no usable checkpoint and the writer failed / never ran / the bound expired	yes — the only one
"insert-failed"	a usable checkpoint exists but the boundary insert refused	no — compacting would amputate history we hold a checkpoint for

Per the narrowed rule, manual /rebuild now also compacts on "no-checkpoint". That reverses this branch's earlier deliberate choice not to (the reasoning being that /rebuild means "rebuild from a checkpoint", so substituting a summary would misreport what happened). If the writer genuinely failed, a truncating compaction beats doing nothing. The substitution is named on the status channel rather than swapped in silently, and neither an assistant reply nor a synthetic user turn is fabricated (the noReply decision in 3244ca732 still stands). The defensive writer-succeeded-but-insert-failed exit stopped reusing the no-checkpoint text, which gave false advice there — it said "continue the conversation and a checkpoint will be written automatically" when the checkpoint had already been written and continuing fixes nothing — and now reports its own degraded state.

"Usable" deliberately means what rebuildFromCheckpoint needs — a checkpoint file and a watermark — not just hasCheckpoint. tryStartCheckpointWriter scaffolds an empty template file before spawning (checkpoint.ts:650) and prune.fireCheckpoints runs immediately before the overflow check (prune.ts:289), so a content-free template with no watermark is the normal state on arrival. Keying off hasCheckpoint alone would have skipped the wait in the exact case the change exists for.

Measured cost — and a correction to the premise

The obvious objection is that waiting 60–180 s mid-turn freezes the conversation, and the counter-argument offered was that compaction is also an LLM call, so it's slow-vs-slow. That counter-argument is wrong, and the measurement says so.

compaction.create (compaction.ts:499) performs three local operations — one synthetic message row, one compaction part row, one bus event — and no model call. Measured over 20 sequential calls on a 40-message session:

compaction.create  n=20  total=18.10ms  mean=0.905ms  min=0.185ms  p50=0.240ms  max=12.551ms

(max is first-call warmup.) Against the writer wait, which the writer documents for itself at checkpoint.ts:981 as "frequently take 60-180s":

	cost	result
compaction.create	p50 0.240 ms	all pre-boundary history dropped, unsummarized
writer wait	60 000–180 000 ms (documented)	structured digest + live tail preserved verbatim

Compaction is ~250 000–750 000× cheaper. The cost-parity justification does not hold and is withdrawn.

The change still stands, but on quality, not cost. The LLM summarizer is processCompaction, reached only from /compact — never from create. Nothing generates the summary later either (the sole Event.Compacted subscriber, cron-bridge.ts:196, just resets a cache). Since MessageV2.filterCompacted (message-v2.ts:1037) breaks at the marker, falling back truncates the conversation with no summary at all. So the real trade is a bounded, explained, one-time stall versus silently amputating the entire history — worth waiting for. The in-code comment claiming this fallback was an "LLM-driven lossy summary" that "preserves semantic content via summary" was factually wrong and is corrected. (In-tree corroboration predates this PR: checkpoint-rebuild-unify.test.ts:194 already says create "runs purely synthetically (no LLM)".)

The bound: 3 min auto, 5 min manual

waitForWriter takes no timeout argument — its 5-minute bound is hardcoded at checkpoint.ts:986 — so the bound is applied by wrapping the call site rather than by passing an argument.

• Manual: 300 s, matching waitForWriter's internal bound, i.e. unchanged. A human just typed /rebuild and is watching a spinner.
• Auto: 180 s. It fires mid-turn without being asked, so the stall is unsolicited and should not be as generous. 180 s is exactly the top of the 60–180 s band the writer documents for itself, so it admits every writer behaving as designed while refusing to hold an unrequested turn for the extra two minutes a watching human would tolerate. Abandoning the wait does not cancel the writer — it keeps running detached — so a bound that is too tight costs one degraded turn, not the checkpoint itself.

Reentrancy. The isWriterRunning probe plus tryStartCheckpointWriter's own "queued" result (rather than forking a second writer) mean two writers can never start for one session, even across successive runLoop iterations. On "rebuilt" and "no-checkpoint" the auto sites keep their existing skipOverflowCheck = true; continue shape; on "insert-failed" they fall through to the model call instead of continuing, since nothing freed context and the provider-signalled handler is the backstop. Auto overflow also sets "Writing checkpoint…" on the status channel so a multi-minute mid-turn wait is explained rather than looking frozen. The three subagent compaction.create sites are untouched — subagents have no checkpoints, so checkpoint-first does not apply.

Tests

• test/session/auto-overflow-writer-first.test.ts (new) drives the real overflow branch in the runLoop and asserts on what the session contains:
  • no checkpoint + writer succeeds → checkpoint boundary, zero compactions. Revert probe against eb4183825: expect(checkpoints.length).toBe(1) → Expected: 1 / Received: 0.
  • no checkpoint + writer genuinely fails → still compacts, zero checkpoints. Passes before and after by design — it guards behaviour the change preserves, so it must not flip.
• test/session/rebuild-on-the-spot.test.ts — rewritten, not tweaked. Its "case 2 fallback" test asserted after.length === countBefore: that a manual /rebuild whose writer could not run must not compact. That is now the wrong behaviour, so the assertion was replaced rather than edited quietly. It now asserts one compaction part plus the status text naming the substitution, and still asserts everything the old test protected (no runLoop entry, no assistant reply, no fabricated user turn). Revert probe: expect(after.length).toBe(countBefore + 1) → Expected: 2 / Received: 1.
• prompt-rebuild-reset.test.ts and command/rebuild.test.ts are source-grep guards keyed to the old code text. Their invariants are unchanged and still asserted; only the shape moved — except the deleted "No checkpoint is available to rebuild from yet" string, which was not reshaped but removed as false advice.

Verification. bun typecheck EXIT 0. Scoped run (rebuild.test.ts, auto-overflow-writer-first, prompt-rebuild-reset, cron-bridge.integration, rebuild-on-the-spot, checkpoint-rebuild-unify, checkpoint-rebuild-v3, overflow): 81 pass / 0 fail at loadavg 5.41. Pristine baseline of the identical command at eb4183825 (7 pre-existing files; the new file does not exist there): 79 pass / 0 fail at loadavg 4.66 — the +2 are exactly the new tests, and nothing pre-existing regressed.

---

Scaffolded arrival state: why the guard above was still a no-op (95a3d6ea9)

The commit before this one re-keyed the compaction discriminator off bare
hasCheckpoint and onto lastBoundary. That was the right value to read, and it
still did nothing.

The trap. hasCheckpoint is literally Bun.file(checkpointPath(sid)).exists()
(checkpoint.ts:1021), and tryStartCheckpointWriter scaffolds an empty
template (checkpoint.ts:650) before it spawns the writer. Since
prune.fireCheckpoints (prune.ts:289) runs immediately before the overflow
check, "checkpoint file on disk, watermark not yet written" is how a normal
rebuild arrives — not a degraded state, the ordinary one.

Why re-keying didn't fix it. The new guard was written as
boundary !== undefined, and that predicate never excluded anything.
lastBoundary reads a nullable column behind an unchecked
as MessageID | undefined cast (checkpoint.ts:1422), so an unset watermark
arrives as JS null — the declared MessageID | undefined was simply untrue
at runtime. null !== undefined is true, so the guard fired for every
session with a file on disk and behaved exactly like the bare hasCheckpoint
check it replaced. Nobody had noticed the nullability because every pre-existing
caller happens to test truthiness (!boundary at prompt.ts:413,
watermarkBefore ? at checkpoint.ts:1131, boundaryID ? in
nudgedSinceBoundary); this was the first strict-equality caller.

Why it was invisible. The misclassification lands on insert-failed, which is
the one outcome that neither rebuilds nor compacts — prompt.ts:3515-3521
deliberately falls through to the model call. So the overflow was left unresolved
with zero checkpoints and zero compactions and no error anywhere. A
scaffolded-state seed reproduces exactly that signature:

[DIAG] checkpoints=0 compactions=0
[DIAG2] OVERFLOW BRANCH entered agentID=main
[DIAG2] step2 hasCP=true boundary=null      <- null, not undefined
[DIAG2] attempt=insert-failed

The overflow branch was entered and tryStartCheckpointWriter was never
reached; after the fix the same seed logs boundary=undefined -> tryStart=started
-> writerOutcome=success -> attempt=rebuilt.

What closes it. Two one-liners, either of which is sufficient (verified
independently); both kept because the first makes the declared type honest for
future callers and the second makes the two readers of this value agree:

• checkpoint.ts:1431 — return ?? undefined, so the value matches the signature
  declared at :489 instead of relying on every caller to test truthiness.
• prompt.ts:528 — if (hasCP && boundary), the same truthiness test
  rebuildFromCheckpoint applies to the same value at :413.

Regression test. auto-overflow-writer-first.test.ts — "a scaffolded-but-empty
checkpoint file still starts and awaits the writer". It pre-writes the empty
template exactly as tryStartCheckpointWriter leaves it, then asserts one
checkpoint boundary, zero compactions, and a non-null watermark. Revert probe
against the previous commit's source, verbatim:

451 |                   const checkpoints = after.filter((m) => m.parts.some((p) => p.type === "checkpoint"))
452 |                   const compactions = after.filter((m) => m.parts.some((p) => p.type === "compaction"))
453 |                   expect(checkpoints.length).toBe(1)
      ^
error: expect(received).toBe(expected)

Expected: 1
Received: 0

The sibling writer-first test cannot catch this: it seeds no checkpoint file, so
it never reaches the misclassified branch and passes with the bug in place.

Verification. bun typecheck EXIT 0 (confirmed to cover test/ — a deliberate
type error in the test file is reported). Scoped run of
auto-overflow-writer-first, rebuild-on-the-spot, prompt-rebuild-reset,
command/rebuild: 11 pass / 0 fail. Pristine baseline of the identical command
at 5189f1974: 10 pass / 0 fail — the +1 is exactly the new test, and nothing
pre-existing regressed.