Step 1 of 4
Set the budgets from real usage
Caps must fit normal work and catch abnormal work.
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.
Expected after this step
Data-derived budgets with an escalation ladder in config.
Should not happen
- ✕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
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !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
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
No usage data to derive from. Run a week with counters in log-only mode first - budgets guessed without data either strangle work or catch nothing.