Play console steps without an API as agent plans: play-store-settings (App category; play listing cannot set it), play-app-content (every card in order, one owner batch) and its cards (privacy policy, ads, sign in details, advertising ID, government, financial, health), play-production-countries and play-production-release; IARC plan with the Terms of Use agreement, follow-ups (console.contentRating.details, products[].randomRewards, social) and the Summary's final Save; config play.category / countries / managedPublishing, console.appContent; check, validate, play status and play release reminders; inPageLoop helper and material checkbox clicks; App Privacy published signal; first IAPs via apple iap-submit --with-version. Pitfalls 27, 28
This commit is contained in:
parent
dbd9f2973c
commit
b7bfe89151
37 changed files with 1624 additions and 121 deletions
|
|
@ -64,12 +64,17 @@ answers the compliance facts no file proves, all in one batch at the start.
|
|||
`reviewContact`, or `--contact-from <Apple ID of another app of the team>`; notes from the config). Apps behind a
|
||||
sign-in: the demo account from `.storebound/` (`review-access` skill). Apps with accounts: in-app deletion
|
||||
(`account-deletion` skill).
|
||||
11. **API + UI · In-app purchases and subscriptions.** `store-iap-setup` and `store-subscriptions` skills. First
|
||||
IAPs and subscriptions go to review **with** this version.
|
||||
11. **API · In-app purchases and subscriptions.** `store-iap-setup` and `store-subscriptions` skills. First
|
||||
IAPs and subscriptions go to review **with** this version: `storebound apple iap-submit --with-version --dry`,
|
||||
then (after the owner's yes, since it submits) `storebound apple iap-submit --with-version --yes`. On a real first
|
||||
release (2026-10-12) it added the IAPs to the draft submission that already held version 1.0.0 and submitted
|
||||
them, first try. Not the console: its IAP "Add for Review" menu did not react to scripted clicks, and the version
|
||||
page no longer has an "In-App Purchases and Subscriptions" section.
|
||||
12. **UI · App Privacy.** `store-declarations` skill (nutrition labels; you fill and save them), then the owner
|
||||
presses **Publish**.
|
||||
13. **Preflight.** `storebound validate --apple` until it shows no blocker (`store-preflight`).
|
||||
14. **UI · Submit.** Version page > Add for Review (with the IAPs in the same draft submission) > Submit for Review
|
||||
14. **Submit.** The owner's yes for `storebound apple iap-submit --with-version --yes` (version and IAPs in one
|
||||
review submission; step 11), or Version page > Add for Review > Submit for Review when there are no IAPs
|
||||
(owner). Release type MANUAL means the owner presses "Release" after approval.
|
||||
15. **Verify + wait.** `storebound apple status`: version WAITING_FOR_REVIEW, IAPs WAITING_FOR_REVIEW, one review
|
||||
submission. `storebound apple status --wait-review` polls until approved (exit 0) or rejected (exit 1,
|
||||
|
|
@ -78,11 +83,13 @@ answers the compliance facts no file proves, all in one batch at the start.
|
|||
## Gotchas
|
||||
|
||||
- The app record cannot be created via API; the bundle id can.
|
||||
- First consumable / non-consumable IAPs must be submitted together with an app version, only from the IAP page
|
||||
("Add for Review" puts them into the draft submission). The API (`inAppPurchaseSubmissions`) answers
|
||||
`FIRST_*_MUST_BE_SUBMITTED_ON_VERSION`. If the version was already submitted without them: cancel the review
|
||||
submission (`storebound apple status --cancel-submission <id>`, PATCH canceled: true), wait a minute, add the IAPs
|
||||
from their page, then resubmit.
|
||||
- First consumable / non-consumable IAPs must be submitted together with an app version. The deprecated
|
||||
`inAppPurchaseSubmissions` answers `FIRST_*_MUST_BE_SUBMITTED_ON_VERSION`; `storebound apple iap-submit
|
||||
--with-version` puts both into one review submission through `reviewSubmissionItems` (worked on a real first
|
||||
release, 2026-10-12). The console route is broken for agents: the IAP "Add for Review" menu ignored scripted clicks
|
||||
and the version page has no "In-App Purchases and Subscriptions" section any more. If the version was already
|
||||
submitted without them: cancel the review submission (`storebound apple status --cancel-submission <id>`, the
|
||||
owner's yes), wait a minute, then `apple iap-submit --with-version` (pitfall 28).
|
||||
- App Privacy (data types, purposes, linked, tracking) is UI-only and must be **published**, not just saved.
|
||||
- Export compliance unanswered = "Missing Compliance": `storebound apple encryption` (`export-compliance`).
|
||||
- ITMS-91053 / 91061 privacy manifest emails after upload: `privacy-manifest` skill.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
name: console-autofill
|
||||
description: Fill App Store Connect and Google Play Console forms that have no API (New App, App Privacy, Play Create app, the IARC content rating, Target audience and content plus Ads; the App Store age rating is guidance because the API sets it). Agent-first by default - `storebound console plan <form> --json` (MCP console_plan) gives the start URL, steps, answer sheet with the console's exact labels, never-press list and verified UI facts; you drive the page with your own browser tool (Claude in Chrome, a built-in browser, Playwright), stop before the final button and tell the owner what to press, then `storebound console verify <form>` (MCP console_verify). `storebound console fill` is the optional scripted fast path. Answers come only from storebound.config.ts. Never sign in, submit, publish, accept agreements or grant permissions. Use when the user wants help filling one of these console forms, asks what to answer in them, or wants the answers as a checklist.
|
||||
description: Fill App Store Connect and Google Play Console forms that have no API (New App, App Privacy, Play Create app, IARC content rating, every Play App content card, Play Store settings category, first production release countries and send-for-review). Agent-first by default - `storebound console plan <form> --json` (MCP console_plan) gives the start URL, steps, answer sheet with the console's exact labels, never-press list and verified UI facts; you drive the page with your own browser tool, stop before the final button and tell the owner what to press, then `storebound console verify <form>` (MCP console_verify). `storebound console fill` is the optional scripted fast path. Answers come only from storebound.config.ts. Never sign in, submit, publish, accept agreements or grant permissions. Use when the user wants help filling one of these console forms, asks what to answer in them, or wants the answers as a checklist.
|
||||
---
|
||||
|
||||
# Console forms without an API
|
||||
|
|
@ -30,7 +30,16 @@ the UI shows. This is the primary mode.
|
|||
`label` (curly quotes as shown, `curlyQuotes: true`), `action` (tick / untick / pick / type / choose) and `where`;
|
||||
- `buttons.neverPress` (Publish, Submit, Create, Create app, Send, Release, "Definitions and Examples", "?", the
|
||||
final Save of a form ...), `buttons.final` and `buttons.allowed` (navigation and draft saves);
|
||||
- `uiFacts` (verified facts per form, see below), `driving` and `verify` (the command and what to capture).
|
||||
- `uiFacts` (verified facts per form, see below), `driving`, `inPageLoop` (a ready-made in-page helper, see 5) and
|
||||
`verify` (the command and what to capture).
|
||||
|
||||
Forms: `apple-app-record`, `apple-age-rating`, `apple-app-privacy`, `play-app-record`, `play-content-rating`,
|
||||
`play-target-audience` (these also have the scripted `console fill`), and agent-only Play pages:
|
||||
`play-store-settings` (the App category: the Play API has no category field, so `play listing` leaves it "Not
|
||||
selected"), `play-app-content` (every App content card in order, its page, its plan and ONE batch of owner
|
||||
questions), its cards `play-privacy-policy`, `play-ads`, `play-sign-in-details`, `play-advertising-id`,
|
||||
`play-government-apps`, `play-financial-features`, `play-health-apps`, and the first production release:
|
||||
`play-production-countries` and `play-production-release`. `storebound console plan` lists them.
|
||||
2. Collect the `ask-owner` answers of every form you will fill in ONE question to the owner before you start (AGENTS.md
|
||||
rule 5) and write them into the config, so the plan has them. Never guess them; leave them empty if the owner
|
||||
wants to answer in the page.
|
||||
|
|
@ -38,16 +47,21 @@ the UI shows. This is the primary mode.
|
|||
4. Follow `steps`. Read the page (text or accessibility tree) before each action, click by visible text, set each
|
||||
answer as the sheet says, wait for the next step to render. If the page differs from the plan, adapt (the console
|
||||
changes), but never press anything in `buttons.neverPress` and never tick an agreement.
|
||||
5. Long flows (App Privacy with many data types): one evaluate call times out around 45 s, so start an in-page async
|
||||
loop and poll it:
|
||||
5. Long flows (App Privacy with many data types, the IARC questionnaire, App content): one Runtime.evaluate call
|
||||
times out at about 45 s on big console pages, so never loop over many controls in one call. Paste the plan's
|
||||
`inPageLoop` once per page (one short call; it defines `window.__sb`), start the job and poll in short calls:
|
||||
```js
|
||||
window.__log = []; window.__run = (async () => { /* for each step: wait for it, act, */ window.__log.push('Device ID: purposes set'); /* ... */ window.__log.push('done'); })().catch(e => window.__log.push('stopped: ' + e.message));
|
||||
window.__sb.run([{ role: 'radio', label: 'No', within: '<question text>' }, { role: 'checkbox', label: '<box label>', want: true }])
|
||||
// then, every 2-5 s: window.__log.slice(-20), window.__done
|
||||
```
|
||||
then read `window.__log` every few seconds until it says `done` or `stopped`. Never click past a step you have not
|
||||
read; on an unknown step, stop the loop and look.
|
||||
The helper finds each control by its label (aria-label, else the nearest parent with non-empty innerText), clicks
|
||||
the inner `[role=radio]` / `[role=checkbox]` of a material control and reads it back; it never clicks buttons and
|
||||
refuses agreements. Press Next / Save yourself afterwards. Never click past a step you have not read.
|
||||
6. Stop before `buttons.final` and tell the owner exactly what to press (App Privacy: review the summary, press
|
||||
Publish; Play Create app: tick the two declarations, press Create app; content rating: Submit; target audience:
|
||||
Save; New App: Create).
|
||||
Publish, then Publish in the "Publish Your App Privacy Responses?" dialog; Play Create app: tick the two
|
||||
declarations, press Create app; content rating: the Summary's Save (not Submit); target audience and the other
|
||||
App content cards: Save; Play production: "Submit N changes for review", then "Send changes for review"; New App:
|
||||
Create).
|
||||
7. `storebound console verify <form> --from-text -` (MCP: `console_verify` with `text`) with what `verify.capture`
|
||||
says: App Privacy the page's `innerText`, Play Create app the JSON of the capture snippet. Exit 1 / mismatches:
|
||||
fix them in the page (or the config), verify again. `apple-app-record` and `apple-age-rating` verify from the API
|
||||
|
|
@ -72,6 +86,32 @@ the UI shows. This is the primary mode.
|
|||
click the inner `[role=radio]` with a JS click, then check `aria-checked="true"` and that no "Select …" hint is
|
||||
left. Text inputs set by `form_input` are fine. After Create app the app lives at
|
||||
`/console/u/0/developers/<developerId>/app/<appId>/app-dashboard`: put the id in `play.appId`.
|
||||
- **Play material radios and checkboxes** (Create app, App content, IARC, 2026-10-12): `<material-radio>` /
|
||||
`<material-checkbox>`; click the inner `[role=radio]` / `[role=checkbox]` (or the `<input>`) with a JS click and read
|
||||
`aria-checked` back. Their labels sit in sibling nodes: read the nearest parent with non-empty `innerText`.
|
||||
- **Play Store settings** (2026-10-12): `/app/<appId>/store-settings` > the FIRST Edit (App category) > App or game >
|
||||
the Category dropdown's `[role=option]` with exactly the category name (`play.category`) > Save.
|
||||
- **Play App content** (2026-10-12): `/app-content/overview`; each card has a button aria-label="Start <Name>
|
||||
declaration". Pages: privacy-policy, ads-declaration, testing-credentials (Sign in details), ad-id-declaration,
|
||||
government-apps, finance (2 steps; the last has "My app doesn't provide any financial features"; Next, Save),
|
||||
health (2 steps; the last step's "Other" box was the no-features answer on that run; Next, Save),
|
||||
target-audience-content (age checkboxes; with 13+ only it went straight to the Summary, no appeal question; Save),
|
||||
content-rating-overview > "Start questionnaire" > content-rating-iarc-questionnaire.
|
||||
- **IARC questionnaire** (2026-10-12): page 1 has the email, the category radio and an IARC Terms of Use checkbox (an
|
||||
agreement: the owner ticks it, never you). Then ONE long page of sections; each Yes reveals follow-ups (Violence:
|
||||
humans / non-humans, setting, childlike style, reactions, presentation, blood level, historical war, innocent
|
||||
characters, fierce sounds; Digital Purchases: digital goods, then loot boxes, then player trading; Miscellaneous:
|
||||
user interaction then block / report / moderation / friends-only, location sharing, Nazi symbols, Korea history,
|
||||
terrorism, crimes). The answers come from `console.contentRating.answers` and `.details`, `products[].randomRewards`
|
||||
and `social`. Save, then Next to the Summary with per-authority ratings; its final button is **Save**, not Submit
|
||||
(the owner's). Example: PEGI 7, ESRB E10+, USK 12, ClassInd 18 (paid random items), Google Play 7+.
|
||||
- **App Privacy Publish** (2026-10-12): a `<dialog>` "Publish Your App Privacy Responses?" with Cancel / Publish (the
|
||||
owner's); afterwards the page shows "Published a few seconds ago by …", which `console verify` reads.
|
||||
- **Play first production release** (2026-10-12): countries are console-only (`edits.countryAvailability` is
|
||||
read-only): tracks/production > Countries / regions > Edit countries / regions > "Select all rows" > Save. Then
|
||||
Releases > Edit release > Next > Save; Publishing overview > "Submit N changes for review" > "Send changes for
|
||||
review" (the owner's; a JS `.click()` did nothing, it needs a real click). Managed publishing is off by default:
|
||||
approved means live.
|
||||
- **After Play Create app, an owner step:** a service account's app-level permissions do NOT cover apps created
|
||||
later. Granting them is the owner's (a permission grant; auto mode blocks it too): give the exact path together
|
||||
with the Create app button, Users and permissions > the service account > Add app > the new app > Admin (or the
|
||||
|
|
@ -247,7 +287,7 @@ content", "Create and set up your app"):
|
|||
| New App (App Store) | + and New App (Cancel only to leave a team without the bundle id) | **Create**: creates the app record for good |
|
||||
| Age rating (guide only) | nothing (`storebound apple appinfo` sets it by API) | Set Up / Next / Done, if the owner wants to look |
|
||||
| Create app (Play) | Create app on the app list (opens the form); Check availability next to the package name (read-only) | the two **declarations** (agreements, never ticked) and **Create app** in the form: creates the app |
|
||||
| Content rating (Play) | Start; **Save draft** then Next on each page (a draft: IARC gets nothing before Submit; the owner agreed) | **Submit** on the Summary: sends the questionnaire to IARC |
|
||||
| Content rating (Play) | Start; **Save draft** then Next on each page (a draft: IARC gets nothing before the Summary's Save; the owner agreed) | the **IARC Terms of Use** box (an agreement) and **Save** on the Summary (not "Submit", verified 2026-10-12): sends the questionnaire to IARC |
|
||||
| Target audience (Play) | Start / Manage, Next between the pages | **Save** on the last page: stores the declaration, which Google then reviews |
|
||||
|
||||
Mid-way storebound stops only for an uncertain answer (see 6). A navigation button is never the owner's: when the
|
||||
|
|
@ -257,8 +297,9 @@ console page changed so that storebound cannot find it, it says so and you click
|
|||
|
||||
Every `[check]` answer, linked-to-identity and tracking for each App Privacy data type (unless `appPrivacy.types`
|
||||
answers them), Developer's Advertising or Marketing, the IARC answers, the target
|
||||
ages, Play's Free or paid and its declarations, and pressing the final button (App Privacy Publish, IARC Submit,
|
||||
Target audience Save, New App Create, Play Create app).
|
||||
ages, Play's Free or paid and its declarations, the IARC Terms of Use box, the Sign in details username and password,
|
||||
and pressing the final button (App Privacy Publish, the IARC Summary's Save, each App content card's Save, New App
|
||||
Create, Play Create app, Play's Send changes for review).
|
||||
|
||||
## Out of scope
|
||||
|
||||
|
|
|
|||
|
|
@ -66,15 +66,34 @@ products) and answers the compliance facts no file proves, all in one batch at t
|
|||
permission on any track first.
|
||||
9. **API · Data safety.** Answers in `dataSafety` of the config, `storebound play data-safety`, then check the summary
|
||||
in Policy and programs > App content > Data safety.
|
||||
10. **UI · App content.** `store-declarations` skill: privacy policy, ads, app access, content rating (IARC), target
|
||||
audience, advertising ID, government / financial / health / news, data safety review. Behind a sign-in: App access
|
||||
with the demo account (`review-access`); with accounts: the delete-account URL (`account-deletion`); subscriptions:
|
||||
`storebound play subscriptions` (`store-subscriptions`).
|
||||
11. **UI · Store settings.** Category + tags, contact details.
|
||||
10. **UI · App content.** `storebound console plan play-app-content --json` lists every card of
|
||||
`/app-content/overview` in order (Privacy policy, Ads, Sign in details, Content ratings, Target audience and
|
||||
content, Data safety, Advertising ID, Government apps, Financial features, Health apps), each card's page and
|
||||
start button (aria-label "Start <Name> declaration"), its own plan (`console plan play-privacy-policy`,
|
||||
`play-ads`, `play-sign-in-details`, `play-content-rating`, `play-target-audience`, `play-advertising-id`,
|
||||
`play-government-apps`, `play-financial-features`, `play-health-apps`) and ONE batch of owner questions
|
||||
(`askOwner`): ask them at the start, write the answers into the config (`console.contentRating.details`,
|
||||
`console.appContent`, `social`, `products[].randomRewards`), rerun the plan. Data safety goes through the API
|
||||
(step 9). The IARC Terms of Use box and each card's final Save are the owner's (`store-declarations` skill).
|
||||
Behind a sign-in: the owner types the demo account in Sign in details (`review-access`); with accounts: the
|
||||
delete-account URL (`account-deletion`); subscriptions: `storebound play subscriptions` (`store-subscriptions`).
|
||||
11. **UI · Store settings (App category).** `play listing` cannot set it (the Play API has no category field), so a
|
||||
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
|
||||
(you, with your browser tool):
|
||||
Production > Countries/regions > Add countries > select all > Save; Production > the draft release > Edit >
|
||||
Next > Save; Publishing overview > **Send changes for review** (owner).
|
||||
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
|
||||
overview?" dialog follows. `edits.countryAvailability` is read-only in the API; `storebound validate --play`
|
||||
reports "production has 0 countries".
|
||||
b) `storebound console plan play-production-release`: Releases tab > Edit release > Next (a missing
|
||||
deobfuscation file is only a warning) > Save.
|
||||
c) Publishing overview > "Submit N changes for review" > dialog "Send N changes for review?" > **Send changes for
|
||||
review**: the owner's final button, and it needs a real click (a JS `.click()` did nothing on it).
|
||||
Managed publishing is off by default: the app goes live automatically once Google approves it. If the owner wants
|
||||
to pick the moment, they turn on Publishing overview > Managed publishing first; record it in
|
||||
`play.managedPublishing` (`play release` and the plan warn while it is off).
|
||||
13. **Verify.** `storebound validate --play` (no blockers), `storebound play status` (tracks, listings, products), Console dashboard has no open tasks,
|
||||
Publishing overview shows "In review".
|
||||
|
||||
|
|
|
|||
|
|
@ -26,10 +26,19 @@ CLI: `storebound` (or `bunx storebound` in a project that has it, or `bun <toolc
|
|||
Play cannot read the form back: storebound keeps the hash of the last upload in `.storebound/data-safety.sha256`
|
||||
and skips an unchanged CSV. After a hand edit in Play Console, `--force` sends the config's answers again.
|
||||
Then check the summary in Play Console > Policy and programs > App content > Data safety.
|
||||
3. **Play App content (UI, you drive it).** Policy and programs > App content, each card with `store/declarations.md`
|
||||
(`storebound console plan play-content-rating` / `play-target-audience` for the forms it knows):
|
||||
privacy policy, app access, ads, content rating (IARC questionnaire), target audience and content, news, COVID-19,
|
||||
data safety, government apps, financial features, health, advertising ID.
|
||||
3. **Play App content (UI, you drive it).** `storebound console plan play-app-content --json` lists every card of
|
||||
`/app-content/overview` in order (Privacy policy, Ads, Sign in details, Content ratings, Target audience and
|
||||
content, Data safety, Advertising ID, Government apps, Financial features, Health apps) with its page, start
|
||||
button (aria-label "Start <Name> declaration") and its own plan, plus ONE batch (`askOwner`) of what the config
|
||||
does not prove. Ask that batch at the start and write the answers into the config:
|
||||
- `console.contentRating.answers` and `.details` (the IARC follow-ups each Yes reveals: violence details,
|
||||
`other` for fear / sexuality / gambling / language / controlled substances / crude humor, player trading, the
|
||||
user interaction follow-ups, the Miscellaneous questions: Nazi symbols, Korea history, terrorism, crimes);
|
||||
- `products[].randomRewards` (loot boxes: proven per product; ClassInd rated such a game 18), `social` (chat,
|
||||
block, report, moderation, friends only, location sharing);
|
||||
- `console.appContent` (government, financialFeatures, healthFeatures, advertisingId), `reviewAccess`.
|
||||
The IARC Terms of Use box is an agreement (the owner ticks it). Each card's final Save, and the IARC Summary's Save
|
||||
(not "Submit"), are the owner's, or yours after the owner's clear yes in chat.
|
||||
4. **Apple age rating (API).** `storebound apple appinfo` (all NONE except your overrides, e.g. `advertising: true`).
|
||||
5. **Apple App Privacy (UI only, you drive it: `storebound console plan apple-app-privacy`).** App Store Connect >
|
||||
the app > App Privacy > Get Started / Edit, from `store/app-privacy.md`; per data type: purposes > linked to
|
||||
|
|
|
|||
|
|
@ -101,11 +101,12 @@ App Store only, a future YYYY-MM-DD).
|
|||
- Apple: first IAPs must ship with an app version ("FIRST_*_MUST_BE_SUBMITTED_ON_VERSION" from the old
|
||||
inAppPurchaseSubmissions). If the version is already in review without them: cancel the review submission
|
||||
(`storebound apple status --cancel-submission <id>`, ask the owner), then `storebound apple iap-submit --with-version`
|
||||
(or "Add for Review" in the UI) and resubmit.
|
||||
- Not verified against a live account yet: adding the **first** IAP of a type next to the app version through
|
||||
`reviewSubmissionItems` follows the API 4.4.1 release notes and the 4.5.1 spec (the item takes `appStoreVersion` and
|
||||
`inAppPurchaseVersion` in one submission). If App Store Connect refuses it, `--no-submit` leaves the draft and the
|
||||
UI "Add for Review" finishes the job. The deprecated `inAppPurchaseSubmissions` / `subscriptionSubmissions` are not used.
|
||||
and resubmit.
|
||||
- Verified on a real first release (2026-10-12): `storebound apple iap-submit --with-version --yes` (after the owner's
|
||||
yes: it submits) added the first IAPs to the existing draft submission that already held version 1.0.0 and
|
||||
submitted them, first try, through `reviewSubmissionItems`. Do not use the console for this: the IAP page's "Add for
|
||||
Review" menu did not react to scripted clicks, and the version page no longer has an "In-App Purchases and
|
||||
Subscriptions" section (pitfall 28). The deprecated `inAppPurchaseSubmissions` / `subscriptionSubmissions` are not used.
|
||||
- Apple needs an exact existing price point for each manual price; the error lists the nearest ones.
|
||||
- Apple IAP display name 2-30 characters, description max **45** (App Store Connect Help > Reference > "In-app
|
||||
purchase information"; an older App Store marketing page says 55, but App Store Connect enforces 45).
|
||||
|
|
|
|||
|
|
@ -348,3 +348,31 @@ that fails without the fix (see CONTRIBUTING.md).
|
|||
GEMINI.md, Copilot and Cursor rules), of README and of this skill; `tests/do-it-dont-ask.test.ts` checks that and
|
||||
fails when a skill or the rules hand navigation, draft saves, exports, uploads or form filling to the owner
|
||||
(navigation "by hand", uploads or exports left to the owner, asking the owner to click through a form).
|
||||
|
||||
## 27. Play steps without an API: category, countries, App content, IARC
|
||||
- **Symptom:** after a first Play release through the API the App category showed "Not selected", production had 0
|
||||
countries, and an agent hunted for each App content card; the IARC questionnaire kept revealing new questions, an
|
||||
evaluate call timed out at 45 s, material checkboxes ignored `form_input`, and "Send changes for review" ignored a
|
||||
JS click.
|
||||
- **Cause:** `play listing` cannot set the category (edits.details has no category field) and
|
||||
edits.countryAvailability is read-only; the IARC questionnaire is one long page where each Yes reveals follow-ups;
|
||||
Play's `<material-checkbox>` / `<material-radio>` keep their own model.
|
||||
- **Do:** set `play.category`, `play.countries` (or all), `console.contentRating.details`, `console.appContent`,
|
||||
`social` and `products[].randomRewards` from ONE batch of owner answers (`storebound console plan play-app-content`
|
||||
lists them), then drive `console plan play-store-settings`, `play-app-content` and its cards,
|
||||
`play-production-countries` and `play-production-release`. Click the inner `[role=radio]` / `[role=checkbox]`;
|
||||
run long flows with the plan's `inPageLoop` and poll `window.__log`. Never tick the IARC Terms of Use box; the
|
||||
Summary's final button is "Save" (the owner's). "Send changes for review" is the owner's real click; managed
|
||||
publishing is off by default, so approved means live (`play.managedPublishing`).
|
||||
- **Guard:** the plans above, `check` (category warning, open App content answers), `validate` (category reminder,
|
||||
"production has 0 countries"), `play status` / `play release` notes; `tests/console-play-plans.test.ts`.
|
||||
|
||||
## 28. First App Store IAPs: `apple iap-submit --with-version`, not the console
|
||||
- **Symptom:** the IAP page's "Add for Review" menu ignored scripted clicks, and the version page no longer has an
|
||||
"In-App Purchases and Subscriptions" section.
|
||||
- **Do:** `storebound apple iap-submit --with-version --dry`, then after the owner's yes (it submits)
|
||||
`--with-version --yes`: on a real first release it added the IAPs to the draft submission that already held
|
||||
version 1.0.0 and submitted them, first try. App Privacy: the owner's Publish opens "Publish Your App Privacy
|
||||
Responses?" (Cancel / Publish); afterwards "Published … ago by …" shows, which `console verify apple-app-privacy`
|
||||
reads as the published signal.
|
||||
- **Guard:** appstore-first-release and store-iap-setup skills; `tests/console-play-plans.test.ts`.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue