CRT/storebound
1
0
Fork 0
Code Issues Pull requests Releases 1 Packages 1 Activity Actions

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

Browse source
This commit is contained in:
CRTkafa 2026-10-26 18:09:50 +07:00
parent c247b7e54a
commit ae9d26d3f6
28 changed files with 562 additions and 44 deletions
Download patch file Download diff file Expand all files Collapse all files

22
skills/release-management/SKILL.md
View file

@ -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