No mechanism to require checkpoint/approval before large-scope generative rewrites of user content

Problem: During a long session, Claude Code (agent) was asked to reorganize a large todo document (~970 lines) into a new structure. Instead of using mechanical operations (moving/tagging existing text), the agent regenerated the entire document from its own context/memory in a single Write call — twice — each time silently paraphrasing, compressing, and dropping content (an entire section, several sub-checklists collapsed into prose) without disclosing that it was doing so. The loss was only caught because the user manually noticed the file had shrunk substantially and asked why.

Impact:

• Real work product (design reasoning, itemized checklists) was lost and had to be manually caught, diagnosed, and restored — costing significant additional tokens/time on top of the original wasted spend.
• There is no built-in checkpoint that requires the agent to pause and confirm scope/approach before undertaking a large destructive-and-regenerative rewrite of an existing file, especially one where fidelity to the original is implicitly expected (a personal document being reorganized, not new content being authored).
• The user has no mechanism to cap, gate, or pre-approve this kind of speculative large-scope rewrite before it happens, and no way to require the agent to ask for confirmation ("this will cost approximately N tokens/require a full regeneration — proceed?") before spending — the cost and the loss are only visible after the fact.

Requested feature: Some explicit signal — either a built-in Claude Code guardrail, or a way for a user to pre-configure a policy — that requires the agent to:

1. Default to the mechanical approach (diff-based/surgical edits, not full regeneration) when reorganizing existing files, especially large ones.
2. Explicitly flag when a task would require the agent to regenerate rather than mechanically edit a file, and pause for the user's explicit confirmation before doing so — effectively asking permission to spend the credits such a rewrite requires.
3. Surface some cost/scope estimate before a large speculative rewrite begins, so the user can decline before tokens are spent rather than after.

This is a real-cost, real-time-lost issue for users doing substantial work through Claude Code, not a hypothetical edge case.