Checkpoint directly after code change

[ebeaufay]

Problem (one or two sentences)

I ask roo to do some changes and notice a bug. Did the last change cause a regression?

The checkpoint before the change allows me to revert but then I cannot re-apply the change easily.

Context (who is affected and when)

While coding, a real "nice to have" feature

Desired behavior (conceptual, not technical)

A checkpoint after the change would allow quickly re-applying the last change

Constraints / preferences (optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

No response

Proposed approach (optional)

No response

Trade-offs / risks (optional)

No response

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Problem

Currently, checkpoints are saved before code changes (via checkpointSaveAndMark() in presentAssistantMessage.ts), but not after. This means:

• You can revert to the state before a change
• But if you revert, there is no way to quickly re-apply that change

Proposed approach

Add a post-change checkpoint that fires after all tools in an assistant response have finished executing. This gives each change a "before" and "after" snapshot, enabling both undo and redo workflows.

Implementation details

1. In src/core/task/Task.ts (~line 3588-3615): After await pWaitFor(() => this.userMessageContentReady) completes and tools were used successfully, save a new checkpoint. This is the point where all tool results have been collected and file changes are complete.

   The logic would check this.currentStreamingDidCheckpoint (which indicates a pre-change checkpoint was saved, meaning file-modifying tools ran) and then call this.checkpointSave() to capture the post-change state. This checkpoint would NOT be suppressed -- it would show in the UI timeline so users can interact with it.

2. No changes needed to the checkpoint service itself (ShadowCheckpointService, RepoPerTaskCheckpointService) -- the existing saveCheckpoint() method already handles creating new commits from the current workspace state.

3. No changes to the UI/webview -- existing checkpoint UI (restore, diff) already works with any checkpoint in the timeline.

Key considerations

• The post-change checkpoint only fires when currentStreamingDidCheckpoint is true (i.e., file-modifying tools were used), so read-only operations won't create unnecessary checkpoints.
• The checkpoint is non-blocking (void fire-and-forget pattern, similar to the existing user-message checkpoint at line 1513).
• This maintains backward compatibility -- the pre-change checkpoint behavior is unchanged.

Trade-offs

• Disk usage: Each assistant response with file changes will create one additional git commit in the shadow repo. This is minimal overhead since shadow repos are already per-task.
• Performance: The checkpoint save is async and non-blocking, so it won't slow down the response cycle.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.