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

price changes of existing products need --allow-price-changes (play products, play/apple subscriptions, prices import): --yes and flow run --apply --yes confirm creates, first prices and other updates only; without the flag the run writes the rest, names each held change and exits 3 (declined), dry runs mark them owner, flows refuse the flag; lib/price-gate.ts, tests/price-gate.test.ts. CLI wording: console fill leaves what it cannot open or fill to the calling agent's browser tool (console plan / verify) instead of 'yourself'; other 'by hand' output points at the config; do-it-dont-ask test scans cli/ output

Browse source
This commit is contained in:
CRTkafa 2026-10-12 09:38:56 +08:00
parent b5b8f2da9d
commit e01a27d7b7
33 changed files with 414 additions and 117 deletions
Download patch file Download diff file Expand all files Collapse all files

18
skills/store-iap-setup/SKILL.md
View file

@ -30,10 +30,13 @@ Auto-renewable subscriptions are a separate list (`subscriptions`, `store-subscr
2. `storebound play products`. Per product: `pricing:convertRegionPrices` (USD -> every region at local price points,
and the `regionsVersion`), your overrides on top, `PATCH .../onetimeproducts/{id}?allowMissing=true&regionsVersion.version=...`
(create or update), then `oneTimeProducts/{id}/purchaseOptions:batchUpdateStates` to activate (new options are DRAFT).
New products and listing text go straight through. Price, region or activation changes of an EXISTING product
are the owner's decision: the run shows the diff and asks in a terminal; without a terminal (MCP, CI, the desktop
app's normal write) they are skipped with a warning, the listing text still updates. The owner confirms in a
terminal, or applies prices with the desktop Prices "Apply" (owner action, `prices import`).
New products (with their first prices) and listing text go straight through; `--yes` confirms activating the
purchase option of an existing product. Price or region changes of an EXISTING product are the owner's decision
and `--yes` never confirms them (also not the `--yes` that `flow run --apply --yes` adds): the dry run marks those
rows `owner`, and a real run writes everything else, prints `price change on <id> (<from> -> <to>) needs the
owner: re-run with --allow-price-changes` and exits 3 (declined; a flow stops there). After the owner's yes in
chat for exactly that diff, run `storebound play products --allow-price-changes`; the owner can also answer the
question in a terminal (no `--yes`) or use the desktop Prices "Apply" (owner action).
3. Verify: `storebound play status` lists every product with `buy:ACTIVE`.
4. Test: Play Console > Settings > License testing: add tester Gmail accounts; install from the internal testing
link; purchases are free test orders.
@ -41,7 +44,8 @@ Auto-renewable subscriptions are a separate list (`subscriptions`, `store-subscr
## App Store (API + UI)
1. `storebound apple iap --dry`, then `storebound apple iap`: creates missing products, localizations, a price schedule
(USA base + overrides; Apple equalizes the rest) and availability. Existing schedules and availability are never
changed by it; price changes go through `storebound prices import` (diff first, then the owner confirms).
changed by it; price changes go through `storebound prices import` (diff first, then the owner's yes and
`--allow-price-changes`).
2. Review screenshot per product (a real device size, e.g. 1290 x 2796, showing the item in the shop):
`storebound apple iap-review`. States move to READY_TO_SUBMIT when complete.
3. **Send them to App Review** (the owner's step): `storebound apple iap-submit --dry` shows the plan: which version
@ -74,7 +78,9 @@ App Store only, a future YYYY-MM-DD).
neighbours); Play takes any price in the region's currency.
3. `storebound prices import --dry` (MCP: `prices_diff`) prints the diff table: product, store, region, from, current,
new, change %. Show it to the owner.
4. The owner runs `storebound prices import` (asks first; not an MCP tool). Apple: one new price schedule per changed
4. After the owner's yes for that diff: `storebound prices import --yes --allow-price-changes` (not an MCP tool;
`--yes` alone only sets first prices of products that have none and exits 3 naming every held price change).
Apple: one new price schedule per changed
product (base territory, default the current one or `prices.baseTerritory`, plus every manual price; territories
without one follow Apple's equalization). Play: the purchase option's regional prices are replaced; regions the
product has no price for get `convertRegionPrices` from the USD base, `--reconvert` resets every region the CSV