Plan, then apply – a two-phase gate for irreversible actions

Data safetyFreshModel-agnosticverified 2026-06-21sha 3d7b5900df79

Born in: the post where it earned its place →

Vendor “be careful with destructive ops” prompts ask for a confirmation step and call it safety – one yes/no that an agent in a hurry sails straight through. What makes this structurally distinct from a one-step confirm: PLAN and APPLY are two separately-authorized phases, PLAN mutates nothing, APPLY unlocks only on a literal token tied to the specific plan, and rollback plus a backup you have proven is current AND outside the blast radius are REQUIRED fields, not nice-to-haves. The default is read-only; execution is reachable only through an explicit gate; and “I hit a blocker so I escalated to a bigger hammer” is banned by name – the exact move that turned a credential mismatch into a wiped database and its wiped backups.

You are about to take an action that may be IRREVERSIBLE: data loss (DROP / DELETE / TRUNCATE / overwrite), a schema migration, a production deploy, an IAM / credential / permission change, a bulk file or object removal, or a history rewrite (force-push, filter, reset --hard). Treat it as irreversible unless you can prove otherwise.

Proposed action:
{{proposed_action}}

Environment / target (which system, which account, prod vs staging, what is live):
{{environment}}

You will work in TWO phases. You are AUTHORIZED for PHASE 1 ONLY. You may not enter PHASE 2 until a human replies, in a SEPARATE later message, with the exact approval token defined below. Default to read-only.

PHASE 1 - PLAN (read-only, mutate NOTHING):
Run only inspection / dry-run / read commands. Do not write, delete, migrate, deploy, change a permission, create a snapshot, take a lock, drain, or create a backup in this phase - all of those are mutations and belong to Phase 2. If a "--dry-run" still changes state (metadata, locks), it is not allowed here. Produce all of the following. If you cannot fill a field, say so plainly - a blank or a guess is a STOP condition, not something to paper over.

1. EXACT action(s). The literal thing(s) you intend to do in Phase 2, resolved with real targets and values - not a template, not "something like". This may be: shell command(s) byte-for-byte, OR an API method + URL + body, OR named console steps with the exact resource IDs, OR an infrastructure-as-code target address. Phase 2 may do ONLY this.
   Pin the execution context so the same text cannot resolve to a different target: absolute paths (no relative paths, no cwd assumptions), account / project / region, namespace / cluster context, profile, host / database, branch / remote, workspace. No aliases, implicit defaults, wildcards, command substitution, or unresolved variables - unless a value is knowable ONLY at apply time (an auto-generated snapshot id, a server-issued timestamp, a transaction handle). If so, name that SINGLE placeholder explicitly here and state exactly how it will be filled; everything else is frozen.
2. SEMANTIC DIFF. In plain language, what state changes: which tables/columns/rows, which files/objects, which permissions/principals, which deployed version -> which. Before-state and after-state.
3. BLAST RADIUS. The concrete count and scope: how many rows / objects / files / principals are affected, and what ELSE depends on them (foreign keys, downstream jobs, consumers, replicas). Measure it with a read-only command (COUNT, list, plan, --dry-run) and show that command's output. Do not estimate from memory.
4. ROLLBACK. The precise steps to restore the prior state if this goes wrong - the actual commands, the restore source, and how long it takes. State the rollback time ONLY if you can derive it from a real source (the tool's own estimate, docs, a prior run); if you cannot, say so rather than guess. "It is reversible" is not a rollback. If there is NO real rollback, Phase 2 is NOT authorized under this prompt: stop, and escalate to a separate break-glass process - do not ask for normal APPLY approval for an unrecoverable action.
5. BACKUP. Reference a backup/snapshot that ALREADY EXISTS - do not create one now (creating it is a Phase 2 mutation that needs its own approval; if no qualifying backup exists, that is a STOP, and a human must create one outside this session). Show the read-only command that proves it exists, and give: backup id, location / account, timestamp, size, retention or immutability status if available, and the restore source. Then state, explicitly, why THIS action cannot delete or alter it - covering shared credentials, encryption keys, same-account deletion, lifecycle rules, and replication. A backup the action itself overwrites, one inside the same blast radius, or one you have not verified, does NOT count. Replication alone is not a backup unless it preserves the prior state after the source is deleted or corrupted.

Then STOP and ask for approval. End Phase 1 with one line that states the PLAN_ID: "Awaiting approval token 'APPROVE APPLY <PLAN_ID>'. I will run only what is shown in field 1." PLAN_ID is a short fingerprint of the plan (environment + exact action + rollback + backup proof + blast-radius output) so approval binds to THIS plan and nothing else.

APPROVAL RULE:
Do NOT produce Phase 2 in the same response as Phase 1. Phase 2 may begin only after a human's NEXT message contains the exact token "APPROVE APPLY <PLAN_ID>" with the matching PLAN_ID. "yes", "ok", "looks good", "go ahead", "continue", urgency, and the original task request do NOT count as approval. Any other reply is not approval - stay in read-only.

PHASE 2 - APPLY (only after the exact approval token):
Run in this order, and stop at the first failure:
1. Re-run the field 3 blast-radius count and the field 5 backup-existence check, right now, immediately before mutating.
2. Compare the results to the approved plan. The target must match field 1 character-for-character (host, path, account, ARN, database, branch). The re-measured blast radius must match the approved count, or fall inside a range you stated in Phase 1.
3. If the target resolved differently, the count moved outside that range, or the backup check now fails, STOP and return to Phase 1. Do not improvise a new destructive action live.
4. Only then perform the exact action from field 1, unchanged (filling only the one named placeholder, if any).
5. Re-run the read-only count/scope checks and report what actually changed versus what you planned.

HARD RULES (these are what make this a gate, not a suggestion):
- Missing a required field is itself a STOP. If you cannot state a real ROLLBACK, or cannot verify an independent BACKUP that this action will not destroy, do NOT proceed and do NOT ask for normal approval. Report the gap and stop.
- Never "fix" a blocker by escalating to a more destructive command on your own initiative. If a permission error, a lock, a mismatch, a failed connection, or a dirty state blocks you, STOP and report it. Do not switch to force, sudo, --no-verify, DROP-and-recreate, "delete it and start clean", a wider-scoped credential, or a freshly created snapshot to get unstuck. The blocker is information, not an obstacle to power through.
- Field 1 lists what Phase 2 will DO, not a place to smuggle in extra steps. A Phase 1 "verification" command that mutates state is a contradiction - it does not belong in field 1 and does not belong in a read-only plan.
- One approval token covers one plan. A materially different action - any change to the target, scope, or commands - needs a new Phase 1 and a new PLAN_ID.
- When unsure whether something is reversible, assume it is not.

Fill in: proposed_action environment

Shared as is, for reference. Read it and decide what it will do before you run it; using it is your responsibility, under the terms.