apple iap-submit: DEVELOPER_REJECTED IAP / subscription / group versions (left by a canceled submission) are submitted as they are, plan says 'add (developer rejected, re-submitted as is)', --new-version only for APPROVED / REJECTED, empty draft reused; fake ASC models cancel and re-add. play build / check: warn before Gradle when defaultConfig does not read -PversionCode / -PversionName, with the exact Groovy / Kotlin line (built with AGP 8.13); android.injected.version.code does not override bundleRelease; post-build versionCode mismatch is a hard stop. play-production-release plan: 'Do you want to restart your review?' dialog, Restart review is never-press. Pitfalls 31-33

skills/build-and-sign/SKILL.md

@@ -81,8 +81,16 @@ when the owner said so for this run). The MCP server offers only `apple_signing_
    Flutter, the root for native, a Unity export with `launcher/` + `unityLibrary/`; or `play.build.dir` / `module` /
    `flavor`), the task (`:app:bundleRelease`; Flutter: `flutter build appbundle`), the next free versionCode from Play
    (or `--version-code N`) and where the key comes from. Then without `--dry`. The AAB lands in
-   `build/android/<package>-<versionCode>.aab`; storebound reads the versionCode back from the bundle and warns when
-   the build file ignored the one it passed (read `-PversionCode` there, or `android.injected.version.code`).
+   `build/android/<package>-<versionCode>.aab`. The app module's `defaultConfig` must read the project properties
+   storebound passes; `play build` (and `check`) warn before Gradle runs when `versionCode` / `versionName` is a
+   literal or comes from an env var, with the line to use:
+   Groovy `versionCode((project.findProperty('versionCode') ?: 1) as Integer)` and
+   `versionName project.findProperty('versionName') ?: '1.0'`; Kotlin
+   `versionCode = (project.findProperty("versionCode") as String?)?.toInt() ?: 1` and
+   `versionName = project.findProperty("versionName") as String? ?: "1.0"` (keep your current values as the
+   defaults). `android.injected.version.code` is passed too but does NOT override `defaultConfig` for
+   `bundleRelease` (checked with AGP 8.13); don't count on it. After the build storebound reads the versionCode back
+   from the bundle; another number than planned is a hard stop (the AAB is not copied).
    The Android SDK is found the way Android Studio finds it: `ANDROID_HOME`, `ANDROID_SDK_ROOT`, `sdk.dir` in the
    Gradle project's `local.properties`, then `~/Library/Android/sdk` (macOS) / `~/Android/Sdk` (Linux) /
    `%LOCALAPPDATA%\Android\Sdk` (Windows), and handed to Gradle through `ANDROID_HOME` / `ANDROID_SDK_ROOT`;

skills/play-first-release/SKILL.md

@@ -91,6 +91,9 @@ products) and answers the compliance facts no file proves, all in one batch at t
        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).
+       While a review is already running, "Submit N changes for review" opens **"Do you want to restart your
+       review?"** with **Restart review** instead: that restarts the running review with the new changes. It is the
+       owner's button too (never the agent's); Cancel leaves the running review alone.
     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).

skills/release-management/SKILL.md

@@ -44,6 +44,10 @@ presses release; you prepare, dry-run and report. `storebound mcp` deliberately
 1. `storebound play next-version-code` before building; the versionCode must be higher than every uploaded one.
 2. Upload and start the rollout (owner confirms): `storebound play release app.aab --production inProgress --fraction 0.05`.
    Draft apps cannot do this until the first release is reviewed (`play-first-release`).
+   Changes made in the Console (listing, App content) are sent from Publishing overview > "Submit N changes for
+   review". While a review is running that button opens "Do you want to restart your review?" with **Restart
+   review**: the running review starts over with the new changes. The owner's button, never the agent's; to keep the
+   running review, Cancel and send the changes after it is done.
 3. Increase: `storebound play rollout --fraction 0.2` (then 0.5, ...). Play never lowers a fraction.
 4. Problem: `storebound play rollout --halt` (no confirmation needed; stops new installs of the update). Like Apple's
    pause it is **not a rollback**: updated users keep it. Ship a fixed build with a higher versionCode; resume with

skills/store-iap-setup/SKILL.md

@@ -62,7 +62,9 @@ Auto-renewable subscriptions are a separate list (`subscriptions`, `store-subscr
      **submits the app too**.
    - The real run asks before adding the items and again before submitting; `--no-submit` stops at the filled draft so
      the owner presses "Submit for Review" in App Store Connect. `--new-version` makes a new draft version of an
-     approved or rejected product first (changed name, description or screenshot). Never an MCP tool; MCP has the
+     approved or rejected product first (changed name, description or screenshot). After the owner canceled a
+     submission the versions are DEVELOPER_REJECTED: they go into the next submission as they are (the plan says
+     "add (developer rejected, re-submitted as is)"); no new version is needed. Never an MCP tool; MCP has the
      read-only plan `apple_iap_review_plan`. `--json` prints the plan for scripts.
 4. Offer codes (free or discounted) for one-time purchases: see the app-store-promotion skill (`storebound apple offer-codes`).
 5. Test: Sandbox testers (Users and Access > Sandbox) on device; or a StoreKit configuration file in Xcode for local

skills/store-pitfalls/SKILL.md

@@ -421,3 +421,41 @@ that fails without the fix (see CONTRIBUTING.md).
   it) when one out of scope is left, backing off only when none is; `apple status` labels an empty draft "empty draft
   (harmless; App Store Connect keeps it, not cancellable)" and treats the cancel 409 as harmless; the fake ASC blocks
   the submit while an item is REJECTED and refuses to cancel an empty draft; `tests/resubmit.test.ts`.
+
+## 31. After a canceled submission: DEVELOPER_REJECTED versions go in as they are
+- **Symptom:** the owner canceled a WAITING_FOR_REVIEW submission; `apple iap-submit --with-version --dry` then
+  skipped every IAP ("latest version is DEVELOPER_REJECTED: change it in App Store Connect (or --new-version)") and
+  said "nothing to submit".
+- **Cause:** canceling leaves the app version DEVELOPER_REJECTED (then PREPARE_FOR_SUBMISSION) and every IAP version
+  DEVELOPER_REJECTED. Apple accepts the same IAP version again: `POST /v1/reviewSubmissionItems` → 201
+  READY_FOR_REVIEW, then the submit → 200 WAITING_FOR_REVIEW. storebound treated it like an approved product.
+- **Do:** `storebound apple iap-submit --with-version --dry`: the plan lists them as "add (developer rejected,
+  re-submitted as is)" into the open draft (an empty one is reused); then after the owner's yes `--yes`. Use
+  `--new-version` only for APPROVED or REJECTED products whose metadata changed.
+- **Guard:** `planIapSubmission` (cli/lib/review-submit.ts) takes DEVELOPER_REJECTED IAP, subscription and group
+  versions; the fake ASC models the cancel and the re-add; `tests/resubmit.test.ts`.
+
+## 32. `play build`: the AAB keeps the build file's versionCode
+- **Symptom:** `play build` passed versionCode 3, the AAB had versionCode 1 (the post-build check stopped it). The
+  Capacitor `app/build.gradle` read versionCode from an env var.
+- **Cause:** storebound passes `-PversionCode` / `-PversionName` (and `android.injected.version.*`); a build file
+  that does not read the project property ignores them. `android.injected.version.code` does NOT override
+  `defaultConfig` for `bundleRelease` (checked with AGP 8.13).
+- **Do:** in `defaultConfig`, Groovy: `versionCode((project.findProperty('versionCode') ?: 1) as Integer)` and
+  `versionName project.findProperty('versionName') ?: '1.0'`; Kotlin:
+  `versionCode = (project.findProperty("versionCode") as String?)?.toInt() ?: 1` and
+  `versionName = project.findProperty("versionName") as String? ?: "1.0"` (your current values as defaults). Not
+  `versionCode (project.findProperty('versionCode') ?: 1) as Integer`: Groovy reads it as `versionCode(...) as
+  Integer` and Gradle fails with "Value is null".
+- **Guard:** `play build` (also `--dry`) and `check` warn before Gradle with the file, the line and the line to use;
+  the post-build versionCode check is a hard stop; `tests/build-sign.test.ts`, `tests/web-assets.test.ts`.
+
+## 33. Play "Do you want to restart your review?"
+- **Symptom:** in Publishing overview, "Submit N changes for review" while a review is running opens "Do you want
+  to restart your review?" with "Restart review".
+- **Cause:** Play reviews one set of changes at a time; restarting sends the new changes and starts the running
+  review over.
+- **Do:** never press "Restart review" as an agent: tell the owner a review is running and what restarting means;
+  the owner decides (Cancel keeps the running review).
+- **Guard:** the `play-production-release` console plan lists the dialog, "Restart review" is in neverPress;
+  `tests/console-play-plans.test.ts`.