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/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