storebound/docs/bypass.md

Bypass mode

Default off. The owner turns it on once per machine when they want their AI agent to press the owner-only buttons too, instead of stopping and asking:

storebound settings bypass on      # or answer "y" to the question in storebound init
storebound settings bypass status
storebound settings bypass off     # back to the owner pressing every final button, at once

It is stored in ~/.storebound/settings.json (this machine only), never in a project's config or repo.

Updates are agent steps (no bypass needed)

The owner's standing rule: a new version of an app that is already on the store ships end to end by the agent or the pipeline, with no owner gate per update: submit for review, promote to production, roll out, release an approved version. This holds with bypass mode off, in a terminal and in CI:

Store	Update commands (all take --yes; --json / --result-file for the ship-step contract)
Google Play	storebound play release <app.aab> --production completed --yes (or --production inProgress --fraction 0.05), or storebound play upload <app.aab> --track production --yes
App Store	storebound apple submit --build <n> --yes, then (manual release) storebound apple release --manual-release --yes

What makes it an update is read from the store, never from the config: Play's production track holds a completed / inProgress / halted release; the App Store platform has a version that is or was READY_FOR_SALE (READY_FOR_DISTRIBUTION, REPLACED_WITH_NEW_VERSION). The result line carries releaseKind: "update".

Still the owner's, bypass mode or not (the commands refuse with exit 3, error.code OWNER_STEP, "first release of this app"): the first-ever release of an app (the first production release on Play, the first submission or release on the App Store), removal from sale, live price changes and anything that costs money. The owner approves a first release once: after the owner's yes in chat re-run with --first-release (or turn on bypass mode). A person at a terminal answering the normal confirmation prompt (no --yes) is the owner's approval too, and so is the desktop's owner dialog. Re-running an update that is on the store already is exit 7, nothing sent.

MCP is unchanged: it still does not offer --yes or --production; an update goes through the CLI in a terminal or pipeline (or owner_step in bypass mode).

What it unlocks

• MCP: the owner_step tool appears. It runs one of (a first release also passes the gate in bypass mode): apple submit, apple resubmit, apple iap-submit, apple release, apple preorder, play release, play rollout, reviews (replies), apple testflight (testers), play products, play subscriptions, apple iap, apple subscriptions, prices (live prices). Dry run first (dry_run defaults to true), then dry_run: false runs it with --yes.
• storebound api: owner-only operations (submit, release, delete, ...) are sent for an agent with --yes --confirm <operationId>.
• Console plans: the agent may press buttons.final (Publish, Create app, Send for review) itself.

What stays

• Every owner action an agent runs is appended to <project>/.storebound/owner-actions.log (time, dry or ran, exit code, the command, the last line of its output).
• Dry runs still come first and must pass.
• An AI client may still ask the owner for legal agreements, passwords and 2FA codes: those are its own rules, and a storebound setting cannot change them.