Automation boundaries

Development and automation (CI, scripts, agents, extensions) can do a lot on their own. Some actions always need a person.

Allowed without confirmation

Writing code, tests, documentation and decision records in the project repositories.
Running local builds, tests, simulations and synthesis.
Creating reversible commits on development branches.
Installing pinned, license-reviewed development dependencies from the package registry.

Spending money; buying domains, certificates, accounts or cloud capacity.
Making any repository public, publishing packages, tagging public releases, publishing installers.
Production deployments, DNS or edge (Cloudflare) changes, entering production secrets.
Accepting proprietary licenses or EULAs; redistributing third-party binaries before license review.
Flashing, erasing, unlocking or configuring fuses on real hardware; driving bench instruments; anything with physical effect.
Deleting repositories, branches or user data; destructive database migrations; history rewrites.
Approving design changes proposed by extensions or MCP clients.

MCP and extensions can only propose edits. Approval lives in the app or the interactive CLI.
Hardware operations need an approval bound to the device identity and the firmware’s SHA-256. The approval is single-use.
Cloud jobs need explicit user choice, with cost shown before running.