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

apple signing ensure with automatic signing only adds capabilities (no profiles or certificates; the dry run says so) and lists unused storebound profiles with the exact delete command, never run; every capability write is read back (lag retries, timeout) and fails with the API answers when one did not stick; apple status, signing status and validate compare the App ID, apple.signing.capabilities and the iOS project's entitlements (CODE_SIGN_ENTITLEMENTS too) and name what is missing where; api writes outside a terminal say TTY by design and name the dedicated command; pitfalls 64-66; tests

Browse source
This commit is contained in:
CRTkafa 2026-10-14 19:10:01 +08:00
parent 357319a775
commit daae3715bf
12 changed files with 463 additions and 23 deletions
Download patch file Download diff file Expand all files Collapse all files

27
skills/store-pitfalls/SKILL.md
View file

@ -740,3 +740,30 @@ that fails without the fix (see CONTRIBUTING.md).
"price changes on existing products (held)" section. `apple iap` never changes an existing schedule.
- **Guard:** `allowPriceChanges` / `heldSection` (cli/lib/price-gate.ts), `tests/price-gate.test.ts` (TTY and non-TTY:
a "y" creates the new product and holds the live price; the flag's question names each change).
## 64. `signing ensure` made a manual App Store profile for an automatic-signing app
- **Do:** with `apple.signing.style: automatic` (the default), `apple signing ensure` only keeps the App ID and its
capabilities in step. It never creates certificates or profiles: Xcode owns them (`xcodebuild
-allowProvisioningUpdates` with the API key) and renews its managed profile when the capabilities change. The dry
run says so. Profiles storebound made that nothing uses ("storebound <bundle id> App Store <date>") are listed by
name with the exact `storebound api apple profiles_deleteInstance --param id=<id> --yes` command; deleting them is
the owner's call, never run by storebound.
- **Guard:** `ensureScope`, `unusedStoreboundProfiles` (cli/lib/signing.ts), `tests/signing-capabilities.test.ts`.
## 65. A capability add "succeeded" but the App ID kept only IN_APP_PURCHASE
- **Do:** never report a capability as added from the POST answer. `signing ensure` reads the App ID back after any
capability write (a few tries with growing waits, about 45 s at most) and fails with the API's answers when one is
missing. The capability names were right (CapabilityType: PUSH_NOTIFICATIONS, GAME_CENTER); what an App ID shows
and what a build may use are different things: a provisioning profile keeps the entitlements of the moment it was
made, and an app whose project has no `.entitlements` (or one not set in CODE_SIGN_ENTITLEMENTS) ships without
the capability whatever the App ID says. `apple status`, `apple signing status` and `validate` compare the App ID,
`apple.signing.capabilities` and the project's entitlements and name what is missing where.
- **Guard:** `verifyCapabilities`, `compareCapabilities`, `ENTITLEMENT_CAPABILITIES` (cli/lib/signing.ts),
`checkCapabilitiesStuck` (cli/apple/signing.ts), `tests/signing-capabilities.test.ts` (live-shape
bundleIdCapabilities answers, lag, a write that never sticks).
## 66. `storebound api apple ... --body f.json --yes` only dry-ran from an agent
- **Do:** expected: writes through `storebound api` are sent only from an interactive terminal, by design. Use the
dedicated command the message names (bundle id capabilities: `apple signing ensure`; IAPs: `apple iap`; listing:
`apple listing`, ...), which runs anywhere with its own dry run and read-back.
- **Guard:** `dedicatedCommand` (cli/api/gate.ts), `tests/signing-capabilities.test.ts`.