fix: keep every store working in minified release builds

.claude/commands/audit-code.md

@@ -221,11 +221,12 @@ Update the documentation site for users:
 - Do not add RC or npm `next` publications from the `next` branch. Preserve the
   change evidence and add one grouped entry when the train reaches stable `main`.
 - Verify every package version from its real metadata before writing the release list:
-  `openiap-versions.json` only for `spec`, `google`, and `apple`;
+  `openiap-versions.json` only for `clientProtocol`, `google`, and `apple`;
   framework versions come from each library's package metadata
-- Derive planned versions from the explicit release plan and stable metadata;
+- Derive expected versions from the explicit release plan and stable metadata;
   release workflows own package-version commits
-- Add GitHub Release links only after `gh release view <tag>` confirms the tag exists
+- Link each package to its expected GitHub Release tag, per "Docs Ship With The
+  Change" in `knowledge/internal/05-docs-patterns.md`
 - Document ALL changes: new features, bug fixes, breaking changes
 - Add entry at the TOP of `allNotes` array (newest first)
 

.claude/commands/release.md

@@ -168,11 +168,15 @@ Train rules (mistake guards):
   Maven Central POMs publicly fetchable) and its package metadata is
   synchronized on `main`. Workflow success is not deployment; poll the
   registry.
-- **Release notes last.** After every package in the train is
-  registry-verified, add the consolidated entry to
-  `packages/docs/src/pages/docs/updates/releases.tsx` (see `generate-doc`),
+- **Release notes ship in the PR.** The consolidated card in
+  `packages/docs/src/pages/docs/updates/releases.tsx` merged with the change,
+  written ahead of the release (see `generate-doc`). After every package in the
+  train is registry-verified, check the card's versions and links against the
+  published releases and correct any that differ; if that needs an edit,
   commit it directly to `main` together with any release-process doc updates,
-  and do not open a PR for that post-release docs-only commit; then run the docs
+  and do not open a PR for that post-release docs-only commit. The deploy
+  refuses a page that links an unpublished release, so a train that stops
+  partway resumes or trims its card to what published first. Then run the docs
   deployment. There is no Docs release workflow and no docs tag; if a Docs
   GitHub Release is requested, explain that the docs site is not a versioned
   artifact.
@@ -236,9 +240,9 @@ independent version edits:
    tag. A branch-ref checkout of an existing tag does not align npm's OIDC event
    SHA. If the tag predates this publisher lane, do not retrofit provenance;
    release a new reviewed version.
-9. After every affected artifact is publicly available, use `generate-doc` to
-   add one consolidated release entry with the actual published versions and
-   GitHub Release links, then deploy docs last. A docs deployment creates no
+9. After every affected artifact is publicly available, check the release card
+   that merged with the PR against the published versions and GitHub Release
+   links (see `generate-doc`), correct what differs, then deploy docs last. A docs deployment creates no
    tag and no GitHub Release.
 
 Every `current` retry that finds an existing tag must run

.claude/skills/generate-doc/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: generate-doc
-description: Use for OpenIAP documentation generation work, especially pre-deployment release-note entries in packages/docs/src/pages/docs/updates/releases.tsx that must name the expected native and framework versions, link their future GitHub Releases, and update an existing unreleased train instead of creating a duplicate.
+description: Use for OpenIAP documentation generation work, especially the release-note card each PR carries in packages/docs/src/pages/docs/updates/releases.tsx, written as already published with the expected native and framework versions and their future GitHub Release links, updating an existing unreleased train instead of creating a duplicate.
 ---
 
 # Generate OpenIAP Docs (Claude Code)

.claude/skills/loop-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: loop-review
-description: "Run OpenIAP's complete latest-main-to-production loop: review-self, PR review and merge, exact-main cleanup, sequential stable releases, consolidated release docs, and production docs deployment."
+description: "Run OpenIAP's complete latest-main-to-production loop: review-self, PR review and merge, exact-main cleanup, sequential stable releases, release-note verification, and production docs deployment."
 ---
 
 # Loop Review (Claude Code)
@@ -18,8 +18,9 @@ Use Claude Code's matching skills or commands for each delegated phase:
 - `/e2e-tests` for the device-regression gate — hand back to the user to run it
   rather than merging, since it needs real devices and store accounts.
 - `/ship-release` for affected-only sequential stable publication, registry
-  verification, consolidated release docs, and production docs deployment.
-- `/generate-doc` for the release-note entry and exact package links.
+  verification, release-note verification, and production docs deployment.
+- `/generate-doc` for the release card the PR carries and its expected package
+  links.
 - `ScheduleWakeup` for every five-minute re-entry; never use a shell sleep loop.
 
 Do not merge until the canonical exact-head clean gate is satisfied, and stop

.claude/skills/ship-release/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ship-release
-description: Merge a verified OpenIAP PR, release affected stable packages sequentially with public verification, publish release docs, run review-self to stability, and deploy production docs when the user explicitly requests the full shipping workflow.
+description: Merge a verified OpenIAP PR, release affected stable packages sequentially with public verification, verify the release note the PR carried, stabilize any correction with review-self, and deploy production docs when the user explicitly requests the full shipping workflow.
 ---
 
 # Ship an OpenIAP Release (Claude Code)

.codex/skills/generate-doc/SKILL.md

@@ -1,13 +1,12 @@
 ---
 name: generate-doc
-description: Use for OpenIAP documentation generation work, especially pre-deployment release-note entries in packages/docs/src/pages/docs/updates/releases.tsx that must name the expected native and framework versions, link their future GitHub Releases, and update an existing unreleased train instead of creating a duplicate.
+description: Use for OpenIAP documentation generation work, especially the release-note card each PR carries in packages/docs/src/pages/docs/updates/releases.tsx, written as already published with the expected native and framework versions and their future GitHub Release links, updating an existing unreleased train instead of creating a duplicate.
 ---
 
 # Generate OpenIAP Docs
 
-Use this skill when the user asks to generate or update OpenIAP docs, especially
-release notes that should be written as if package releases are already
-published.
+Use this skill when the user asks to generate or update OpenIAP docs, and for
+the release card every PR into `main` that changes a published package carries.
 
 ## Required Reading
 
@@ -24,15 +23,16 @@ read the package or library convention file before editing that code.
 
 ## Release Note Mode
 
-Current scope: pre-deployment notes written in assumed-published form.
+A PR into `main` writes its release card before the release, as already
+published; "Docs Ship With The Change" in
+`knowledge/internal/05-docs-patterns.md` is the canonical rule.
 
 RC and npm `next` releases live on the on-demand `next` branch and do not get a
 release-history entry. Gather their changes as source material, but add the
 consolidated docs entry only when the train is promoted to a stable release on
 `main`. Production `npm run deploy` is stable-only.
 
-Use shipped wording only when the user explicitly says to assume deployment or
-write the docs as already released. In that mode:
+Write every card this way:
 
 - Use `Package Releases`, not `Planned Package Releases`.
 - Link expected release/package URLs exactly as the release will publish them.
@@ -41,9 +41,8 @@ write the docs as already released. In that mode:
 - State in your response that the links are expected release links until actual
   deployment is complete.
 
-For non-assumed releases, follow the release-note verification rules in
-`knowledge/internal/05-docs-patterns.md` and
-`knowledge/internal/06-git-deployment.md`; do not invent shipped links.
+After the train publishes, compare each version and link with the published
+releases and correct only what differs.
 
 ## Existing Unreleased Train
 
@@ -128,7 +127,7 @@ remain available.
 
 Write every resolved target into the release card with its expected tag link.
 Do not leave versionless package bullets, `(planned)` labels, or a
-`Planned Package Releases` list in assumed-published mode. Ask for confirmation
+`Planned Package Releases` list. Ask for confirmation
 only when repository evidence names conflicting target versions or it is unclear
 whether work belongs to the existing train.
 
@@ -144,8 +143,7 @@ Follow the existing card pattern:
 - Use a stable kebab-case `id` with the date.
 - Use `new Date('YYYY-MM-DD')`.
 - Use `AnchorLink` for the heading.
-- Keep package links in a `Package Releases` list when using assumed-published
-  mode.
+- Keep package links in a `Package Releases` list.
 - Name the expected version in each package-specific bullet, as well as in the
   linked `Package Releases` list.
 - Link issues and PRs when they exist.

.codex/skills/loop-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: loop-review
-description: "Run OpenIAP's complete change-to-production loop from the latest origin/main: implement and verify, stabilize with review-self, open and review a PR until its exact head is clean, merge, return to an exact clean main, release affected stable packages sequentially, publish the consolidated release note, and deploy production docs."
+description: "Run OpenIAP's complete change-to-production loop from the latest origin/main: implement and verify with the docs and release note in the PR, stabilize with review-self, open and review a PR until its exact head is clean, merge, return to an exact clean main, release affected stable packages sequentially, verify the release note, and deploy production docs."
 ---
 
 # Loop Review
@@ -67,8 +67,10 @@ work.
 
 Implement the requested scope and run the checks required by each touched path.
 Keep generated files, documentation, previews, and knowledge context in sync
-through their canonical workflows. Do not proceed while the working diff has a
-known failing required check.
+through their canonical workflows. A change to a published package also updates
+the guides it affects and the release card for the next version, written as
+already published with `$generate-doc`. Do not proceed while the working diff
+has a known failing required check.
 
 Once it works, clean it up before review: apply "Clean Up Once It Works" in
 `knowledge/internal/03-coding-style.md` to the diff and to smells met along the
@@ -199,11 +201,11 @@ Follow `.codex/skills/ship-release/SKILL.md` as the release SSOT:
    Before each release, require an exact clean `main`; after each release-bot
    commit, fast-forward `main` again. Do not start the next release until the
    GitHub Release and public registry or downloadable artifact are verified.
-3. Use `$generate-doc` to add one consolidated release note with the exact
-   published versions and GitHub Release links. Update the existing unreleased
-   train instead of creating a duplicate when one exists.
-4. Run `$review-self` over the complete docs and workflow diff until two
-   consecutive five-minute snapshots are clean. Any edit resets the count.
+3. Check the release card that merged with the PR against the exact published
+   versions and GitHub Release links. If nothing differs, go to step 6.
+4. Correct what differs with `$generate-doc`, then run `$review-self` over that
+   docs diff until two consecutive five-minute snapshots are clean. Any edit
+   resets the count.
 5. Commit and push the reviewed release note and process-documentation changes
    directly to `main`. If review finds a product-code fix, return it to the PR
    loop instead of committing that fix directly to `main`. Do not open a PR for
@@ -229,4 +231,6 @@ describe a pending or partially reviewed PR as clean.
 After merge, stop the shipping phase when an affected release fails, its public
 artifact cannot be verified, production docs cannot be verified, or continuing
 would require a code change outside the reviewed PR. Preserve every successful
-release and report the exact resume point.
+release and report the exact resume point. Do not deploy docs while the card
+links an unpublished release; if the train will not resume, trim the card to
+what published through steps 4 and 5 first.

.codex/skills/review-self/SKILL.md

@@ -52,7 +52,8 @@ result is stable.
    - public contracts, naming, compatibility, generated-file rules, and
      cross-package or SDK parity;
    - missing or weak tests, documentation, examples, migrations, and operational
-     safeguards required by the change;
+     safeguards required by the change, including, for a published package,
+     the guides it affects and its release card for the next version;
    - the canonical KISS/SSOT release rules in
      `knowledge/internal/03-coding-style.md`;
    - code smells in the diff, the code it touches, and any code read during

.codex/skills/ship-release/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ship-release
-description: Merge a verified OpenIAP PR, release every affected stable package one at a time, verify each public registry, publish the consolidated release note, stabilize it with review-self, and deploy production docs. Use when the user explicitly asks for this full post-review shipping workflow.
+description: Merge a verified OpenIAP PR, release every affected stable package one at a time, verify each public registry, verify the release note the PR carried, stabilize any correction with review-self, and deploy production docs. Use when the user explicitly asks for this full post-review shipping workflow.
 ---
 
 # Ship an OpenIAP Release
@@ -67,30 +67,35 @@ For each package:
    the new version before starting the next package.
 
 Do not run package releases concurrently. Stop on the first failed gate and
-report the exact workflow job and package state.
+report the exact workflow job and package state. Leave production docs
+undeployed while the card links a release that has not published; if the train
+will not resume, trim the card to the packages that published, through §4,
+before deploying.
 
 Godot releases also require the authenticated Godot Asset Library listing to be
 updated. Prepare the edit when possible, request action-time confirmation before
 the public form submission, and report it as an explicit remaining manual step
 when authentication is unavailable. Never reuse credentials supplied for a
 different service.
 
-## 3. Write the shipped release note
+## 3. Verify the release note
 
-After every package version and public URL is known, use `generate-doc` to add
-or update the consolidated release card in
-`packages/docs/src/pages/docs/updates/releases.tsx`.
+The merged PR carried the consolidated release card in
+`packages/docs/src/pages/docs/updates/releases.tsx` (see `generate-doc`). After
+every package version and public URL is known:
 
-- Read versions from current package metadata, not from the release plan.
-- Link the real package tags. The docs/spec tag may be the expected tag until
-  the docs release is created.
+- Compare each version and link on the card with current package metadata and
+  the published tags, and correct any that differ.
+- If the PR carried no card, add it with `generate-doc` and report the gap.
 - Lead with user-visible behavior, include required migration or platform
   caveats once, and omit version-bump mechanics.
 - Add no versioned IAPKit entry; it is a service.
 
-## 4. Stabilize and commit
+If nothing differs, go to §5.
 
-Run `review-self` against the complete docs and workflow diff until two
+## 4. Stabilize and commit a correction
+
+When §3 changed the card, run `review-self` against the docs diff until two
 consecutive full snapshots are clean at least five minutes apart. A material
 change resets the clean count. Run all path-specific validation, including the
 docs build, docs and release-state audits, skill validation, and

.github/workflows/ci-kmp-iap.yml

@@ -35,7 +35,7 @@ jobs:
   compile-check:
     name: Compile Check
     runs-on: ubuntu-latest
-    timeout-minutes: 15
+    timeout-minutes: 25
     steps:
       - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
         with:
@@ -66,6 +66,17 @@ jobs:
             :example:composeApp:assembleHorizonDebug \
             :example:composeApp:assembleAmazonDebug
 
+      # R8 runs only in an app's release build, over kmp-iap and openiap-google.
+      - name: Build minified release apps per store
+        run: |
+          "$GITHUB_WORKSPACE/scripts/ci/retry-gradle.sh" ./gradlew \
+            --no-parallel \
+            -Dorg.gradle.jvmargs=-Xmx8192M \
+            -Dkotlin.daemon.jvm.options=-Xmx4096M \
+            :example:composeApp:assemblePlayRelease \
+            :example:composeApp:assembleHorizonRelease \
+            :example:composeApp:assembleAmazonRelease
+
   ios-compile-check:
     name: iOS Compile Check
     runs-on: macos-26

.github/workflows/ci.yml

@@ -599,6 +599,11 @@ jobs:
         working-directory: packages/google
         run: bash scripts/verify-store-plugin.sh
 
+      # Nothing above runs R8; an app's release build does.
+      - name: Verify minified release builds per store
+        working-directory: packages/google
+        run: bash scripts/verify-release-consumer.sh
+
       # Run every store flavor so flavor-specific API-23 regressions cannot
       # bypass lint coverage.
       - name: Lint Android API compatibility

AGENTS.md

@@ -124,6 +124,14 @@ canonical standard in
 [`knowledge/internal/05-docs-patterns.md`](knowledge/internal/05-docs-patterns.md#reader-first-writing-standard),
 including its stricter release-note limits.
 
+### Docs Ship With The Change
+
+A PR into `main` that changes a published package also updates the guides it
+affects and the release card for the next version, written as already
+published; after the release, only verify the versions and deploy. Canonical
+rule in
+[`knowledge/internal/05-docs-patterns.md`](knowledge/internal/05-docs-patterns.md#docs-ship-with-the-change).
+
 ### GitHub Writing Style
 
 Write pull request bodies, review replies, issue comments, and release text the