Rate and Blast-Radius Limits for Destructive Tools

PROJECT CONTEXT:
Even with permissions, an approved-but-wrong plan can shred a workspace fast: fifty edits, a hundred deletions, all technically allowed. Mature agent UX pairs approvals with blast-radius mechanics - budgets per window, checkpoints, and one-step undo.

GOAL:
Implement blast-radius controls: per-window change budgets, escalating friction as usage climbs, automatic checkpoints, and reliable rollback.

REQUIREMENTS:
- Change budgets per time window and per task: files modified, files deleted, lines changed, commands run
- Escalating response as budgets deplete: warn, then require confirmation, then pause
- Automatic checkpoints before risky operations and at intervals
- One-command rollback to any checkpoint
- Deletion-specific caps stricter than modification caps

CONSTRAINTS:
- Budgets are harness-enforced counters, invisible to model negotiation
- Rollback must be tested regularly, not assumed from the checkpoint's existence

DEFINITION OF DONE:
- An agent burst-modifying files hits the budget and pauses for review
- Deleting more than the deletion cap requires explicit batch approval with the list shown
- A checkpoint exists before every approved destructive operation
- Rollback restores a checkpoint correctly, verified by test

COMMON FAILURES TO AVOID:
- Per-call approvals with no aggregate view - a hundred small yeses summing to disaster
- Checkpoints created but never restore-tested until the emergency
- Budgets so tight normal work trips them, training users to override reflexively
- No deletion asymmetry, treating rm like edit