allow / ask me before

Syntax

allow edits automatically, but ask me before migrations or pushes

What it does

The action policy — it splits what the loop may do into an auto class it performs without asking and a confirm class that pauses for you first. The canonical classes are edit, migrate, push, deploy, delete. allow … automatically grants a class outright; ask me before … makes the loop stop and wait for a yes/no before it takes that action, then remembers your answer for the rest of the run.

This is how you get an unattended loop that is still safe on the irreversible parts. The whole point of a self-correcting loop is that it iterates on its own — but iterating freely over a schema migration, a force-push, or a production deploy is how a green run leaves real damage behind. The policy line lets you say "edit source all you like, but stop at the blast radius": routine work stays fast, risky work stays gated. Reach for it whenever a loop can touch anything you'd want a human to sign off on. It pairs with a human approves before …, which is a harder, per-stage gate for the truly one-way doors; ask me before … is the lighter, run-scoped control for everyday risk. When no policy is given, the loop follows the git strategy's defaults — edits allowed, no push.

Example

allow edits automatically, but ask me before migrations or pushes

loop "tidy the invoices module":
  goal: invoices code is clean and the suite is green
  done when "pnpm test invoices" passes
  look at: src/invoices/, and the last failure
  allow edits automatically, but ask me before deletes or migrations

Common mistakes

• Gating nothing on an unattended run. allow edits automatically with no ask me before … lets the loop migrate, delete, and push on its own. On anything irreversible, always name a confirm class.
• Using ask me before for a hard stop. It pauses once and remembers your answer for the run — fine for everyday risk, but for a true one-way door (charging a card, a prod deploy) use a human approves before …, a per-stage gate that blocks every time.
• Expecting it to override git safety. The policy can't authorize a push to main/master — that's blocked unconditionally regardless of what you allow. Set the branch strategy in a git: block, not here.
• Inventing action classes. Stick to the canonical classes — edit, migrate, push, deploy, delete. A made-up class may not map to anything the runner recognizes.

Related