Updates are agent steps: --yes ships an update of a live app (Play production, App Store submit / release) without an owner gate; the first release stays the owner's (exit 3 OWNER_STEP, --first-release); apple release is a ship step

skills/play-first-release/SKILL.md

@@ -87,7 +87,9 @@ products) and answers the compliance facts no file proves, all in one batch at t
     new app shows "Not selected": set `play.category` (Play's name, e.g. "Strategy"; `storebound check` warns
     without it), then `storebound console plan play-store-settings`: /store-settings > the FIRST Edit > App or game >
     the Category dropdown's `[role=option]` with exactly that name > Save. Contact details come from `play listing`.
-12. **API + UI · Production.** `storebound play release --version-code N --production draft`, then in the Console
+12. **API + UI · Production.** The first-ever production release is the owner's (`storebound play release ... --production
+    completed --yes` on a never-published app is exit 3 `OWNER_STEP`, `--first-release` after the owner's yes; once the app is published every later version is an
+    update the agent ships itself, `release-management`). `storebound play release --version-code N --production draft`, then in the Console
     (you, with your browser tool):
     a) `storebound console plan play-production-countries`: tracks/production > Countries / regions tab > Edit
        countries / regions > the mat-checkbox "Select all rows" (or `play.countries`) > Save; a "Go to Publishing

skills/release-management/SKILL.md

@@ -14,8 +14,8 @@ presses release; you prepare, dry-run and report. `storebound mcp` deliberately
   `--versions` lists every version the stores know. The same stages as the desktop's Releases tab.
 - `storebound release plan 1.3.0` (MCP `release_plan`, read-only): what is left for that version on each store, in
   fix order: config problems (`check`), the version on the store, store blockers (`validate`), the next move, warnings.
-  Owner steps (submit, release, raise / complete a rollout) are named with where the owner does them; you never run
-  them. "could not be read" means unknown, not "not there": fix the credentials first.
+  Owner steps (the first-ever submit / release of an app) are named with where the owner does them; updates of an app
+  on sale (submit, release, raise / complete a rollout) are yours, `--yes`. "could not be read" means unknown, not "not there": fix the credentials first.
 - Many apps (a `storebound.workspace.json` above the app folders): the same commands cover every app, or `--app a,b`.
   `storebound ws status` is the portfolio table across apps and stores.
 
@@ -31,20 +31,26 @@ presses release; you prepare, dry-run and report. `storebound mcp` deliberately
    teammate may have uploaded another one meanwhile.
 2. `storebound apple release --phased on --dry`, then without `--dry` (works while the version is being prepared).
    With versions on more than one App Store platform add `--platform ios|macos|tvos|visionos` (pitfall 79).
-3. Submit (owner, UI). Wait: `storebound apple status --wait-review` (polls with backoff, exit 0 approved, 1 rejected,
+3. Submit: an update of an app on sale is yours, `storebound apple submit --build <n> --yes` (exit 7 when it was sent
+   already); the first-ever submission is the owner's (exit 3 `OWNER_STEP`, re-run with `--first-release` after the
+   owner's yes). Wait: `storebound apple status --wait-review` (polls with backoff, exit 0 approved, 1 rejected,
    7 timeout; `--timeout 72h`). Rejected: `review-rejections` skill.
-4. Approved = PENDING_DEVELOPER_RELEASE. Owner releases: `storebound apple release --manual-release` (asks to confirm)
-   or the "Release This Version" button. With phased release on, automatic updates reach 1 %, 2 %, 5 %, 10 %, 20 %,
+4. Approved = PENDING_DEVELOPER_RELEASE. Release an update yourself: `storebound apple release --manual-release --yes`
+   (the first-ever release of an app is the owner's: `OWNER_STEP`) or the "Release This Version" button. With phased release on, automatic updates reach 1 %, 2 %, 5 %, 10 %, 20 %,
    50 %, 100 % over 7 days; anyone can still update manually from the store.
 5. During the rollout watch crashes / reviews. Problem: `storebound apple release --phased pause` (up to 30 days in
    total). Pausing stops automatic updates only; it is **not a rollback**: users who updated keep the build, and new
    users still get the new version. The fix is a new build (expedited review is possible for critical bugs).
-6. All good early: `storebound apple release --phased resume` / `--phased complete` (owner; asks to confirm).
+6. All good early: `storebound apple release --phased resume --yes` / `--phased complete --yes` (an update's rollout is
+   yours).
 
 ## Google Play
 1. `storebound play next-version-code` before building; the versionCode must be higher than every uploaded one.
-2. Upload and start the rollout (owner confirms): `storebound play release app.aab --production inProgress --fraction 0.05`.
-   Draft apps cannot do this until the first release is reviewed (`play-first-release`).
+2. Upload and start the rollout of an UPDATE (no owner step; the app is published): `storebound play release app.aab
+   --production inProgress --fraction 0.05 --yes` (`--production completed --yes` for everyone; or `storebound play
+   upload app.aab --track production --yes`). Re-running it is exit 7. The first-ever production release is the owner's
+   (exit 3 `OWNER_STEP`; after the owner's yes `--first-release`), and draft apps cannot do this until the first
+   release is reviewed (`play-first-release`).
    Changes made in the Console (listing, App content) are sent from Publishing overview > "Submit N changes for
    review". While a review is running that button opens "Do you want to restart your review?" with **Restart
    review**: the running review starts over with the new changes. The owner's button, never the agent's; to keep the

skills/store-pitfalls/SKILL.md

@@ -1515,3 +1515,21 @@ that fails without the fix (see CONTRIBUTING.md).
 - **Guard:** `cli/lib/broker.ts` (config, key file mode, token cache and single flight, grants, preflight, redaction),
   `cli/lib/google-auth.ts` `playToken` (broker first, local key fallback), `cli/lib/google-access.ts` (403 ->
   GoogleAccessError, no retry), `tests/credential-broker.test.ts` (a local fake broker).
+
+
+## 123. Updates are agent steps: a pipeline could not ship a production update without the owner
+
+- **Symptom:** a CI pipeline shipping a new version of an app that was long on the store was told that production is
+  "the owner's" (an AAB to production refused with "play upload is for testing tracks ... the owner sends it"), though
+  the owner's rule is that updates of a live app ship end to end without a confirmation per update.
+- **Do:** an update is read from the store (Play: the production track holds a completed / inProgress / halted release;
+  App Store: a version of the platform is or was READY_FOR_SALE) and runs with `--yes`, in a terminal or a pipeline:
+  `storebound play release <aab> --production completed --yes` (or `--production inProgress --fraction 0.05`, or
+  `play upload --track production --yes`), `storebound apple submit --build <n> --yes`, `storebound apple release
+  --manual-release --yes`; `--json` / `--result-file` give the ship-step result (`releaseKind: "update"`), a re-run is
+  exit 7. Only the first-ever release of an app is the owner's: exit 3 `OWNER_STEP` "first release of this app", approved
+  once (`--first-release` after the owner's yes, or bypass mode). Removal from sale and live prices keep their own gates.
+- **Never:** tell the owner to press a button for an update, pass `--first-release` without the owner's yes, or decide
+  update-or-first from the config instead of the store.
+- **Guard:** `cli/lib/release-kind.ts` (the kind from the store, the policy), `tests/update-gate.test.ts` (fake stores:
+  update goes through, first release is exit 3, already there is exit 7), docs/bypass.md "Updates are agent steps".