Rate and Blast-Radius Limits for Destructive Tools

The route

4 steps to Done

1. 01

   Set the budgets from real usage

   Caps must fit normal work and catch abnormal work.

   Preview prompt + verify gate ▾ Hide ▴

   Define the budget scheme with data. Measure from recent normal sessions: files modified per task (distribution), deletions per task, lines changed, commands per hour. Set budgets at generous multiples of normal (e.g. p95 x 3) so legitimate work never trips them: per-task and per-15-minute-window caps for files-modified, files-deleted (much stricter - deletions are rarer and riskier), total lines changed, and shell commands. Define the escalation ladder per budget: at 60% - log; at 85% - inline warning shown to user; at 100% - pause requiring review-and-continue. Write the scheme into harness config with the measurement basis documented.

   • ✓ Budgets derived from measured distributions
   • ✓ Deletion caps stricter than edit caps
   • ✓ Ladder thresholds defined per budget
2. 02

   Implement the counters and ladder

   Counting in the dispatch path, escalation in the loop.

   Preview prompt + verify gate ▾ Hide ▴

   Implement enforcement. Counters live in the dispatch path: every file write, deletion, and command increments the relevant windows (task-scoped and rolling time window); state survives within the session. The ladder acts in the loop: warnings render to the user (and a compact note to the model: 'change budget 85% consumed'); at 100%, the loop pauses before the next mutating call with a review screen - what changed so far (file list with churn counts), remaining plan, and continue/adjust/rollback options; continuing grants a budget extension logged with the user's ack. Deletions additionally batch: multiple pending deletes present as one list-approval regardless of budget state. Test by scripting a burst task past each threshold.

   • ✓ All mutations counted at dispatch
   • ✓ Pause shows churn summary and options
   • ✓ Deletions batch into list approvals
3. 03

   Add checkpoints and rollback

   The undo story turns caution into confidence.

   Preview prompt + verify gate ▾ Hide ▴

   Implement checkpointing. Triggers: session start, before any approved destructive/dangerous-tier operation, at every budget pause, and every N minutes of active mutation. Mechanism: git-based where the workspace is a repo (a checkpoint ref/stash including untracked files), snapshot-copy otherwise; checkpoints record {id, timestamp, trigger, files-at-risk}. Rollback: a restore command taking a checkpoint ID, restoring workspace state, and reporting what was reverted; partial restore (named files only) for surgical undo. Wire references into the pause screen ('rollback to checkpoint from 12:04'). Verify storage overhead is acceptable and stale checkpoints prune by policy.

   • ✓ All four triggers create checkpoints
   • ✓ Untracked files included
   • ✓ Partial restore works for named files
4. 04

   Fire-drill the whole system

   Simulate the bad day; grade the safety net.

   Preview prompt + verify gate ▾ Hide ▴

   Run the fire drill. Scenario: instruct the agent (in a disposable copy of a real workspace) to perform a plausible-but-wrong sweeping change - a misguided rename refactor touching many files, including deletions. Verify the sequence: budget warnings fired, deletion batch-approval showed the list, the pause engaged at 100% with an accurate churn summary, a checkpoint existed before the destructive phase, and rollback restored the pre-drill state byte-for-byte (diff the workspace against a control copy). Time the recovery. Then schedule the ritual: a quarterly restore test in CI or checklist form, because rollback that is not rehearsed decays. Fix and re-drill anything that failed.

   • ✓ Full ladder engaged in order
   • ✓ Rollback verified by workspace diff
   • ✓ Recovery timed and a re-test scheduled

Research-backed

Sources behind this flow