apple creative-assets: place Header and Search Results assets once Apple approved them (the version page offers only approved assets); waiting files are reported per locale and placement with their upload date and the re-run command, in the run, --verify, validate and the report; iPhone Duo: the published API spec still has no Duo type, the note says the console takes Duo and the API does not yet

This commit is contained in:
CRTkafa 2026-10-20 03:04:14 +07:00
parent 47dfd372fe
commit c2f34c62f3
13 changed files with 163 additions and 78 deletions

View file

@ -2,20 +2,22 @@
## Unreleased
- **Header and Search Results: select once processed, then add for review.** `storebound apple creative-assets` now
selects an asset for the product page header or search results slot as soon as it is processed ("Prepare for
Submission"), as the console's Browse Assets does: Apple reviews an asset only once it is in a review submission, so
0.8.13's "select once approved" never finished. Upload and select happen in one run (processing wait up to 2 min with
a heartbeat). `--add-for-review` adds the selected, unreviewed assets to the app's draft review submission (never
submits; Submit for Review stays the owner's); `--verify` (MCP `apple_creative_assets_verify`) reads every slot back
read-only and fails when one differs from the local file. A file App Review rejected, or one that failed processing
twice, is not uploaded again; an archived copy of the same file is unarchived instead of uploaded. A live app without
an editable version uses the live version: approved assets are selected there, new ones are uploaded and wait for a
review of their own. Art without words needs no copy per locale: `<renders>/creative/header.png` / `search.*`
fill every language without its own file, uploaded once and placed per locale (the dry run counts files, not slots).
If App Store Connect refuses a placement on the live version, the run says so, leaves the live page unchanged (the
new placement goes first, the old one is removed only after Apple accepted it), links the live version page and does
not retry the other live slots. Pitfall 76 rewritten.
- **Header and Search Results: upload, add for review, place once approved.** `storebound apple creative-assets`
uploads each file once into the Asset Library (MD5 upsert: a rejected file or one that failed processing twice is
not uploaded again, an archived copy is unarchived), and places it on the version as soon as Apple approved it: the
version page's slots offer only approved assets. Until then every locale and placement says "uploaded <date>,
waiting for Apple's approval; run `storebound apple creative-assets` again later", and a re-run places it (an
approved old asset stays shown meanwhile). `--add-for-review` adds the unreviewed assets to the app's draft review
submission (never submits; Submit for Review stays the owner's); `--verify` (MCP `apple_creative_assets_verify`)
reads every slot back read-only with the same waiting state, and `validate` / the report list waiting files. A live
app without an editable version uses the live version; if App Store Connect refuses a placement there, the run says
so, leaves the live page unchanged (the new placement goes first, the old one is removed only after Apple accepted
it), links the live version page and does not retry the other live slots. Art without words needs no copy per
locale: `<renders>/creative/header.png` / `search.*` fill every language without its own file, uploaded once and
placed per locale (the dry run counts files, not slots). Pitfall 76 rewritten.
- **iPhone Duo.** Apple's published App Store Connect API spec (re-checked: still the 2026-10-06 file) has no Duo
screenshot or preview type, so `apple screenshots` keeps skipping the Duo sets with the console link; the check /
validate note now says the console takes Duo and the API does not yet.
- **macOS (tvOS, visionOS) versions are no longer invisible.** `apple status`, `listing`, `listing pull`, `resubmit`,
`submit`, `release` and `screenshots` take `--platform ios|macos|tvos|visionos` (MCP tools and the desktop's owner