Batch Editing and the Dialog Box

Overview

The Dialog Box is Mouse's staging workflow for multi-edit operations. When an assistant calls batch_quick_edit (or quick_edit with autoSave: false), changes are staged in memory rather than written to disk. The assistant then operates within the Dialog Box state: a set of options and contextual reminders that guide it through review, refinement, and commitment of the staged changes.

The Dialog Box Lifecycle

1. Staging

The assistant calls batch_quick_edit with one or more edit operations. All operations reference the original file state: line numbers, character positions, and find patterns all resolve against the file as it exists on disk, regardless of what other operations in the same batch do.

If all operations succeed, the changes are staged in memory. The original file on disk remains untouched.

2. Contextual Reminders

While the Dialog Box state is active, every Mouse tool response includes reminders about the pending staged changes and available next steps. These reminders keep the assistant aware of uncommitted work, even across multiple turns of conversation.

3. Review

The assistant can inspect the staged changes using any of Mouse's read tools (read_lines, read_first_n_lines, read_last_n_lines, jump_to_line_n, find_in_file) with the staged: true parameter. This shows the file as it would appear after saving, without actually modifying the file on disk.

The assistant can also read the original file (without staged: true) to compare the before and after states.

4. Decision

The assistant chooses one of four paths:

Example: Comparing Original and Staged Content

After staging a batch of edits, the assistant can view the original file and the proposed changes side by side using read_lines:

View the proposed changes (staged):

{
  "filePath": "/path/to/file.js",
  "region": [10, 30],
  "staged": true
}

View the original file (on disk):

{
  "filePath": "/path/to/file.js",
  "region": [10, 30],
  "staged": false
}

By comparing the two results, the assistant verifies that the staged edits produce the expected outcome before saving. If something looks wrong, it can refine or cancel. The original file has not been touched.

Atomic Batch Operations

All-or-Nothing Staging

When batch_quick_edit is called, all operations are evaluated against the original file state. This means:

• No position drift. The 5th operation in a batch references the same line numbers as the 1st. If the 1st operation inserts 10 lines at line 20, the 5th operation can still target line 50. Mouse resolves all positions against the original file, not the intermediate state.
• Conflict detection. If two operations target overlapping regions, Mouse detects the conflict and reports it. The non-conflicting operations are staged successfully; only the conflicting one is blocked.
• Clear error reporting. For each failed operation, Mouse provides the specific reason for failure and guidance on how to fix it.

Multi-File Batches

Each operation in a batch can specify its own filePath. Changes across multiple files are staged atomically: all operations succeed or fail together. However, save_changes must be called separately for each file. If you save one file and cancel another, the saved file's changes persist while the cancelled file reverts.

Self-Correction Workflows

Partial Success

When a batch contains 25 operations and 24 succeed, the response identifies exactly which operation failed, why it failed, and what the assistant can do next. The assistant has three options for the failed operation:

• ADJUST: The content was correct but the placement was wrong. The assistant uses an adjust operation to relocate the staged content to the correct position.
• REFINEMENT: The position was correct but the content needs changes. The assistant stages a new edit that modifies the content at the same location.
• UNSTAGE + re-stage: The operation was fundamentally wrong. The assistant unstages it and stages a corrected replacement.

In all cases, the 24 successful operations remain staged. The assistant iterates only on the problem, then saves everything together.

Catching Erroneous Output

Even when all operations stage successfully, Mouse's response encourages the assistant to review the staged changes before saving. This matters most for the hardest scenario to detect: output that is technically valid but semantically wrong.

The assistant reads the staged file, notices a subtle error, unstages the problematic operation, re-stages a corrected version, reviews again, and saves. The user never sees the mistake.

Safety Guardrails

Mouse includes automatic safety thresholds for edit operations:

• Operations exceeding certain size thresholds (e.g., large line counts or high replacement counts) automatically trigger the Dialog Box review state, even if the assistant requested immediate save.
• cancel_changes is always available to discard all staged changes and return the file to its original state with zero risk.

Relationship to Best Practices

This page covers the technical mechanics of batch editing and the Dialog Box. For best practices on when and why to use staging, and how to prompt your assistant for staged review workflows, see Staged Changes, Review, and Self-Correction.

For the full reference of edit operations that can be used within a batch, see the Edit Operations Reference.