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

skills/store-pitfalls/SKILL.md

@@ -913,31 +913,33 @@ that fails without the fix (see CONTRIBUTING.md).
   `screenshots-duo` note in check / validate. `tests/ppo.test.ts`.
 
 ## 76. Header and Search Results assets are not uploaded like screenshots
-- **Symptom:** a header or search results image was "uploaded" but the version page shows no header, a run kept saying
-  "waiting for Apple's approval" for days, or a re-run uploaded the same file again.
+- **Symptom:** a header or search results image was "uploaded" but the version page shows no header, a run waited on
+  an asset nobody had sent to review, or a re-run uploaded the same file again.
 - **Cause:** these slots take assets from the app's Asset Library (`GET /v1/apps/{id}/assetLibrary`), not a set of
   their own: a slot is an `appAssetLibraryPlacements` row (`PRODUCT_PAGE_HEADER_ASSET` or
   `APP_STORE_SEARCH_RESULTS_ASSET`, the version localization). An asset is reviewed only once it is in a review
   submission (its own item, `reviewSubmissionItems` with `appAssetLibraryImage` / `appAssetLibraryVideo`; the console's
-  "Add for Review"). Apple's "App Store asset statuses": a processed asset is "Prepare for Submission" and can already
-  be selected for a version. So an earlier storebound that selected only APPROVED assets waited forever: nothing ever
-  sent the asset to review. Library assets carry no `sourceFileChecksum`, a rejected asset stays rejected (uploading
-  the same bytes again only adds a copy), and the search slot is the API's `APP_STORE_SEARCH_RESULTS_ASSET`
-  (`SEARCH_RESULTS_ADS_ASSET` is the Apple Ads one). Seen live (19 Oct 2026): placements of a live version read back
-  with state `ACTIVE`, which the 4.5.1 spec's `AppAssetLibraryPlacementState` does not list; never validate placement
-  states against the spec enum.
+  "Add for Review"); after processing it is "Prepare for Submission". The version page's slots offer only approved
+  assets ("Browse approved assets", seen in a real release, 20 Oct 2026), so placing waits for Apple's approval.
+  Library assets carry no `sourceFileChecksum`, a rejected asset stays rejected (uploading the same bytes again only
+  adds a copy), and the search slot is the API's `APP_STORE_SEARCH_RESULTS_ASSET` (`SEARCH_RESULTS_ADS_ASSET` is the
+  Apple Ads one). Seen live (19 Oct 2026): placements of a live version read back with state `ACTIVE`, which the 4.5.1
+  spec's `AppAssetLibraryPlacementState` does not list; never validate placement states against the spec enum.
 - **Do:** `storebound apple creative-assets`: MD5 in `referenceName` ("storebound <md5>"), reuse (or unarchive) a library
-  asset with the same MD5, select it once processed, never re-upload a rejected file or one that failed processing
-  twice. Then `--add-for-review` puts the unreviewed assets into the draft submission (with the first version, or alone
-  once the app has an approved version) and `--verify` reads every slot back. With no editable version the live version
-  is used and only APPROVED assets go onto it; the rest wait for their own review. Whether the API accepts a new
-  placement on a live version is not documented: storebound places the new asset first and removes the old one only
-  after Apple accepted it, and on a 4xx it says so, leaves the live page unchanged, gives the live version page's deep
-  link (select it there, or create a version and re-run) and does not try the remaining live slots. Uploading, selecting and adding to the
-  draft are normal steps, not owner buttons; Submit for Review stays the owner's.
-- **Guard:** `cli/apple/creative-assets.ts` (`classify`, `pickAsset`, `processingTiming`), `tests/creative-assets.test.ts`
-  (fake App Store Connect: upload and select in one run, still processing, rejected / archived files, add-for-review
-  without submitting, verify read-only, a refused live placement); the fake commits library assets to PREPARE_FOR_SUBMISSION, as Apple does.
+  asset with the same MD5, never re-upload a rejected file or one that failed processing twice. `--add-for-review`
+  puts the unreviewed assets into the draft submission (with the first version, or alone once the app has an approved
+  version; Submit for Review stays the owner's). An asset that is not APPROVED is reported per locale and placement as
+  "uploaded <date>, waiting for Apple's approval; run `storebound apple creative-assets` again later"; the run is an
+  upsert, so a later run places it as soon as it is approved (an approved old asset stays shown meanwhile). `--verify`
+  and `validate` / the report show the same waiting state. With no editable version the live version is used.
+  Whether the API accepts a new placement on a live version is not documented: storebound places the new asset first
+  and removes the old one only after Apple accepted it, and on a 4xx it says so, leaves the live page unchanged, gives
+  the live version page's deep link (select it there, or create a version and re-run) and does not try the remaining
+  live slots.
+- **Guard:** `cli/apple/creative-assets.ts` (`classify`, `pickAsset`, `waitingText`, `creativeWaiting`,
+  `processingTiming`), `tests/creative-assets.test.ts` (fake App Store Connect: upload, wait for approval, place on a
+  re-run, still processing, rejected / archived files, add-for-review without submitting, verify read-only with the
+  waiting state, a refused live placement, the validate finding).
 
 ## 77. A macOS (tvOS, visionOS) version was invisible next to the iOS one
 - **Symptom:** `apple resubmit` said "nothing to resubmit" while a macOS version was REJECTED with an