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

apple testflight distribute: a build's groups read per group (GET /v1/betaGroups/{id}/relationships/builds) instead of GET /v1/betaGroups?filter[builds]=, which App Store Connect refuses with 400 although the spec declares it; internal all-builds groups reported as already available and never sent the build; a re-run adds nothing; configured groups missing on App Store Connect point at groups sync, unknown ones list what exists; APPLE_LIVE_REJECTED (refused by storebound api too), tests/asc-query-guard.test.ts checks every App Store Connect GET with a query in cli/ against the spec's declared parameters, and the fake App Store Connect answers 400 to undeclared or live-refused parameters (pitfall 42)

Browse source
This commit is contained in:
CRTkafa 2026-10-13 06:03:16 +08:00
parent f741c15829
commit bba46b5c7f
13 changed files with 354 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

4
docs/api-coverage.md
View file

@ -567,10 +567,10 @@ Specs: Apple [App Store Connect API 4.5.1](https://developer.apple.com/sample-co
| `betaGroups_builds_createToManyRelationship` | POST | `/v1/betaGroups/{id}/relationships/builds` | write (dry by default) | lib/testflight |
| `betaGroups_builds_deleteToManyRelationship` | DELETE | `/v1/betaGroups/{id}/relationships/builds` | owner only (typed confirm) | |
| `betaGroups_builds_getToManyRelated` | GET | `/v1/betaGroups/{id}/builds` | read | apple/testflight |
| `betaGroups_builds_getToManyRelationship` | GET | `/v1/betaGroups/{id}/relationships/builds` | read | |
| `betaGroups_builds_getToManyRelationship` | GET | `/v1/betaGroups/{id}/relationships/builds` | read | apple/testflight |
| `betaGroups_createInstance` | POST | `/v1/betaGroups` | write (dry by default) | lib/testflight |
| `betaGroups_deleteInstance` | DELETE | `/v1/betaGroups/{id}` | owner only (typed confirm) | |
| `betaGroups_getCollection` | GET | `/v1/betaGroups` | read | apple/testflight |
| `betaGroups_getCollection` | GET | `/v1/betaGroups` | read | |
| `betaGroups_getInstance` | GET | `/v1/betaGroups/{id}` | read | apple/testflight |
| `betaGroups_publicLinkUsages_getMetrics` | GET | `/v1/betaGroups/{id}/metrics/publicLinkUsages` | read | |
| `betaGroups_updateInstance` | PATCH | `/v1/betaGroups/{id}` | write (dry by default) | |

1
docs/pitfalls.md
View file

@ -9,6 +9,7 @@ fails without the fix.
| # | date | lesson | guard |
|---|---|---|---|
| 42 | 2026-10 | `apple testflight distribute --build 1 --group Team --yes` failed with 400 on `GET /v1/betaGroups?filter[builds]=`: Apple's spec declares the filter, App Store Connect refuses it, and the spec has no GET of a build's groups. Before the groups existed it said `unknown group "Team" ()`. | Distribute reads each target group's builds (`GET /v1/betaGroups/{id}/relationships/builds`), reports internal all-builds groups as "already available" and never sends them the build; `unknownGroupMessage` points at `groups sync` for configured groups. `APPLE_LIVE_REJECTED` (`cli/api/client.ts`, also refused by `storebound api`); `tests/asc-query-guard.test.ts` checks every App Store Connect GET with a query in `cli/` against the spec's declared parameters and that list; the fake App Store Connect answers 400 to them (`tests/idempotency.test.ts`). |
| 41 | 2026-10 | Every Play App content card ended in an owner-only Save, so the owner came back once per card (privacy policy, ads, app access, advertising ID, government, financial, health, target audience, content rating, data safety). Saving an App content declaration is not public: it goes to Google only with the next "Send changes for review" in Publishing overview (verified 2026-10-13). | Card Saves are the agent's (`declaration-save`): `declarationSaveAllowed` (exactly Save / Kaydet, a button on an /app-content/<card> page) and `flowAllowed` for content rating and target audience, while `publishingControl` refuses "Send changes for review", "Submit N changes for review", Submit, Publish, "Restart review" everywhere; the plans' `buttons.final` is "Send changes for review"; `console fill` presses the declaration's Save; `console plan play-app-content --all` walks every card and ends with one owner list (`cli/lib/console-forms.ts`, `cli/lib/console-plan.ts`, `cli/lib/console-play-plans.ts`, `cli/console/fill.ts`; `tests/console-play-plans.test.ts`, `tests/console-flow.test.ts`). |
| 40 | 2026-10 | Finding a new app's Play Console app id (`play.appId`) took several steps: the app list shows 10 apps per page and the new app was not on page 1. The id was in the URL Create app redirects to (/developers/<devId>/app/<appId>/app-dashboard) all along. | `console verify play-app-record --url <url>` reads the id from the redirect (or the capture JSON's url), shows the `play.appId` change as a dry diff and `--write` upserts it (`upsertNestedString`); `storebound play app-id` finds it by package name across captured app list pages (search box or pages) as an agent step (`cli/lib/play-app-id.ts`, `cli/play/app-id.ts`; `tests/play-app-id.test.ts`, a modeled 3-page list). |
| 39 | 2026-10 | Play IARC questionnaire: page 1's Next did nothing until the IARC Terms of Use box was ticked, an owner-only agreement, so the agent stopped mid-run and waited for the owner. | The box is in the plan's ONE owner batch before the run with its exact place (`ownerBatch`, printed first; `play-app-content` and `play-content-rating`); the step says not to press Next again and again; `console fill` waits for the tick ("agreement needed on …", `blocksNext`) instead of pressing a Next that does nothing (`tests/console-play-plans.test.ts`, `tests/console-flow.test.ts`). |