# 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:

```sh
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](ship-step.md)) |
|---|---|
| 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.