@@ -131,7 +131,7 @@ N/A
 
 ### QA Notes
 
-N/A
+Sanity planning: deferred until the intended release candidates are available (step 8a). No sanity tests have run.
 ```
 
 Store the PR URL for the summary.
@@ -279,7 +279,8 @@ Version bump PRs (release branches, merged into master after the store release):
 - Android: [{Android PR URL label}]({Android PR URL from step 4})
 - iOS: [{iOS PR URL label}]({iOS PR URL})
 
-These builds will be used for testing following the [testing framework](https://docs.google.com/spreadsheets/d/10_DufEPwKUCExkXF-jTY7njE0mh5ZspwhRw42NBBd-o).
+Sanity plan: {canonical release PR QA Notes link and planning status, or explicit deferred/blocked reason from step 8a}.
+Execution results will be recorded in the [testing framework](https://docs.google.com/spreadsheets/d/10_DufEPwKUCExkXF-jTY7njE0mh5ZspwhRw42NBBd-o).
 
 ## Mentions
 
@@ -314,19 +315,35 @@ gh release upload v{newVersionName} \
 
 For the Play Store release, upload the AAB as usual, then upload `native-debug-symbols-{newVersionCode}.zip` for the exact version/build in Play Console: App bundle explorer → Downloads → Assets. Verify Play lists the native debug symbols after upload. Keep the release-built archive in GitHub releases or internal release storage; Play Console may only show delete/replace controls after upload, which is enough for release verification.
 
+### 8a. Generate Release Sanity Plan (after candidates are available)
+
+Run this handoff before finalizing the Slack reply, including when Slack is skipped or already posted. The earlier local Slack draft is only a scaffold; do not generate a sanity suite while preparing the release branch/tag.
+
+**Readiness:** use the intended release scope (both platforms by default; only one for an explicitly selected single-platform release). Android needs a completed signed mainnet APK with its version/build, source SHA and artifact location verified. iOS needs the matching build **available to testers in TestFlight**; an archive, upload or processing build is not sufficient. Use build/distribution evidence or explicit confirmation of availability, not the existence of a tag or version PR.
+
+- If an intended candidate is missing, record `deferred — awaiting <platform/build>` in the version PR's QA Notes, local Slack draft and final summary, then continue the remaining release steps. Resume this handoff when availability is confirmed; do not repeat version bumps, tagging or builds merely to resume planning. This also applies to a manual Xcode upload.
+- Once all intended candidates are available, **execute** `/release-sanity {newVersionName}` using the shared [release-sanity skill](https://github.com/synonymdev/bitkit-e2e-tests/blob/main/.agents/skills/release-sanity/SKILL.md) and [release QA method](https://github.com/synonymdev/bitkit-e2e-tests/blob/main/docs/release-qa.md). This means applying the agent instructions, not running a shell command or only printing a reminder. Load both files from `bitkit-e2e-tests` at one resolved default-branch commit (from a matching local checkout or GitHub) and record that revision. If unavailable, record `blocked — shared release-sanity method unavailable` and the follow-up needed; do not substitute an old checklist or claim completion.
+- Supply the previous release tags/SHAs, intended platform scope, actual candidate SHAs/builds/artifact locations, version PRs and current automation/device evidence. Test jobs still running do not defer planning once candidates exist: mark the plan provisional, retain pending/failed/skipped evidence, and refresh affected coverage when results settle or candidate revisions change. Use the shared method for case selection rather than copying it here. Generating the plan does not run payments/device tests, launch reruns or approve the release.
+
+**One plan per version:** first inspect both version PRs for an existing plan. Reuse its canonical location; otherwise put the plan in Android's version PR for a dual-platform or Android-only release, or iOS's version PR for an iOS-only release. Keep the proposed cases, pinned evidence and gaps in a managed `<!-- release-sanity:start -->` / `<!-- release-sanity:end -->` section under QA Notes. Link the other version PR's QA Notes to that canonical section instead of independently generating a second suite. Only include the intended platform(s); selecting a single-platform scope later must re-enter this handoff before Slack finalization.
+
+Read the latest PR body before each edit, preserve other authored content and existing case IDs/results, and verify the edited body. New cases start `Not run`; when the candidate changes, preserve earlier results at their tested revisions and reassess affected cases. Mirror the plan locally in `.ai/release-sanity-{newVersionName}.md`, with the canonical PR URL. Re-entering from the other platform refreshes the same record, not a duplicate. Put the plan URL and planning status (`generated`, `generated — evidence pending`, `deferred` or `blocked`) in the local Slack draft and final summary. Planning status is separate from test execution status and release sign-off.
+
 ### 8b. Post Slack (both RCs, or rare single-platform hotfix)
 
 **Both ready** (default) means all of the following (no `TODO` left in the Reply body):
 - Android: APK is on the `v{newVersionName}` GH draft release (just uploaded), version-bump PR URL known, store-notes Google Doc URL known.
-- iOS: `v{newVersionName}` tag/draft exists, TestFlight build number known, version-bump PR URL known, store-notes Google Doc URL known when the iOS doc was created.
+- iOS: `v{newVersionName}` tag/draft exists, matching build available to testers in TestFlight (not merely uploading/processing), version-bump PR URL known, store-notes Google Doc URL known when the iOS doc was created.
 
-Refresh `.ai/slack-release-{newVersionName}.md` with finalized values.
+Refresh `.ai/slack-release-{newVersionName}.md` with finalized values and the plan link/status from step 8a. Skipping Slack or finding an existing announcement does not skip that handoff.
 
 **If the sibling is not ready yet:** ask the user:
 1. `Wait for sibling` (default) — print `⏸ Slack not posted — waiting until iOS {newVersionName} is on TestFlight (and its doc/PR are known). Local draft: .ai/slack-release-{newVersionName}.md`. Do not call Slack. Continue the release.
 2. `Single-platform hotfix` (rare) — rewrite the Reply to **Android-only**: drop iOS RC / doc / PR lines (do not leave `TODO`); open with a clear Android-only/hotfix cue in the first line of the reply (e.g. `Android-only hotfix:`). Then post per the steps below.
 3. `Skip Slack` — print a manual reminder and continue.
 
+Before drafting a reply, recheck step 8a if candidate availability or the intended platform scope changed in this Slack step (including selecting a single-platform hotfix). Generate/update the plan when eligible; otherwise retain the explicit deferred/blocked reason. Do not describe planning as completed without its record.
+
 **If ready to post** (both platforms filled, or user chose single-platform hotfix): post as Slack drafts (one attached draft per channel at a time). **Never call `slack_send_message`** — it always appends `Sent using Cursor`. Use `slack_send_message_draft` only; the user must send each draft **from the Slack app** (Cursor widget also adds the footer).
 
 1. Locate the parent with `slack_read_channel` on `C07BJ7DNPCG` (`slack_read_channel` returns **top-level messages only** — not reply bodies). If `Release \`{newVersionName}\` :thread:` is already posted and does **not** include `Sent using`, reuse its `ts` and skip to step 4. Otherwise create the **parent** draft in `#bitkit-native` (`channel_id`: `C07BJ7DNPCG`) with body exactly: `Release \`{newVersionName}\` :thread:`
@@ -350,7 +367,7 @@ git checkout master
 
 ### 10. Required Release Handoffs
 
-These follow-ups happen after the relevant release milestone; do not run them early just because the release branch and tag exist.
+The sanity-planning handoff in step 8a runs once the intended candidates are available, before Slack finalization, even if Slack is skipped. If deferred, resume that handoff when the missing candidate becomes available. The follow-ups below happen after their own milestones; do not run them early just because the release branch and tag exist.
 
 1. After the Android and iOS `release-{newVersionName}` branches are staging or migration green, switch to `bitkit-e2e-tests` and run:
 
@@ -377,7 +394,12 @@ Store release notes: .ai/release-notes-{newVersionName}.md
 Release notes doc: {Google Doc URL or "(not created)"} ({sharing status from 6b})
 Slack draft: .ai/slack-release-{newVersionName}.md ({posted parent+reply | deferred — waiting for sibling RC | single-platform hotfix posted | already posted | skipped})
 
+Sanity plan: {canonical PR QA Notes URL or pending reason} ({generated | generated — evidence pending | deferred | blocked})
+Local plan: .ai/release-sanity-{newVersionName}.md (only when generated)
+
 Next steps:
+- If sanity planning is deferred/blocked: resume step 8a once candidates/method are available; apply `/release-sanity {newVersionName}` without re-cutting the release
+- Refresh provisional sanity coverage when pending test results settle or candidate revisions change
 - If Slack was deferred: post once the sibling RC is ready, or choose single-platform hotfix if this cut ships alone (no TODOs in the reply)
 - Send any #bitkit-native Slack drafts from the Slack app (if not already)
 - Share the release notes doc with Jacobo for review (if domain share is still pending, apply it first)