Block resuming checkpoints with an uncertain in-flight write #7

Problem

write creates or overwrites files, but it is missing from the core isMutating() classification. A checkpoint written immediately before a write call therefore records inFlightTool.mutating: false. Both resume checks trust that recorded flag, so a checkpoint whose file-write outcome is uncertain can be accepted for continuation.

This is a maintainer-priority reliability issue: the consequences and compatibility with existing journals need review before expanding contributor work on session recovery. It is intentionally not labeled good first issue.

Verified reproduction

At the linked commit, isMutating("write") returns false. Passing an otherwise compatible synthetic checkpoint with the following in-flight tool to resumeBlock(checkpoint, null) returns null (no blocker):

inFlightTool: {
  id: "root-c1",
  name: "write",
  argumentsHash: "synthetic-fixture",
  mutating: false,
}

The CLI-facing checkResumable() also checks only the stored mutating flag. The existing in-flight apply_patch tests demonstrate the intended refusal behavior for mutations, but do not cover this misclassified write case.

The confirmed problem is acceptance of an uncertain file-write state. This reproduction does not demonstrate that the same write was automatically executed twice. No process-kill end-to-end experiment or live model call was performed.

Expected behavior

An interrupted in-flight write whose effect cannot be established must be treated as an uncertain mutation and must not pass the normal resume checks. Old journals that recorded write with mutating: false need the same protection; updating only the classification for newly written checkpoints is insufficient.

Acceptance criteria

• write is classified as mutating for newly recorded checkpoints.
• Existing checkpoints with an in-flight write and a false stored mutation flag are evaluated using the current tool classification and blocked when execution is uncertain.
• Core resumeBlock() and the CLI-facing checkResumable() agree on these cases.
• Regression coverage distinguishes a checkpoint before a write starts, an in-flight write without a durable completion checkpoint, and a write whose observation and completion checkpoint were durably recorded.
• Normal read-only resumptions remain supported, and existing compatibility/corruption checks remain intact.
• The refusal explains that the working tree must be inspected before starting a new run; it does not guess whether the file changed.

Starting points

• packages/core/src/checkpoint.ts: tool classification and resumeBlock()
• packages/core/src/loop.ts: durable intent before execution
• packages/journal/src/index.ts: CLI resume check
• packages/core/test/resume.test.ts
• packages/journal/test/journal.test.ts

Suggested validation

pnpm exec vitest run packages/core/test/resume.test.ts packages/journal/test/journal.test.ts
pnpm typecheck

Use deterministic checkpoints, journal fixtures, and a fake executor for regression coverage. An integration test should exercise the resume decision used by the CLI without contacting a model endpoint. This issue does not require changing the journal format or implementing automatic replay of uncertain mutations.

Maintainer coordination

Please discuss the handling of legacy checkpoints with @TaewoooPark before starting implementation. This issue can be reproduced and tested without an API key or GPU.

Verified against 4d3e20a on 2026-09-21 using synthetic state.