Planning snapshot recorded 2026-11-03 (Europe/Warsaw). This illustrates the shared release QA method, including why checks were selected or omitted. It is not a live status page, release sign-off or a default checklist for future versions. All cases below were Not run when the plan was recorded.
| Input | Pinned value |
|---|---|
| Android previous release | v3.0.1 — dba2a2177d6f671d96f377206e5dc50db1cc59c6 |
| Android candidate | Signed mainnet 3.1.0 (196), d13769269cf17737100e092d66b2bc9236bc8eb8; release PR #1755 |
| iOS previous release | v3.0.1 — 2eceedb1cef2497533412912b582db7bbefb5dd1 |
| iOS candidate | TestFlight 3.1.0 (203), 6bcce8f77d4077430d7183c40e8062b0a0326d67; release PR #1193 |
| E2E suite | 611509ee2d6dc44094276b567ac51949d63760f9 |
Mainnet cases use real devices and existing funded test wallets/channels. RS-CAP-A/I use matching regtest builds from the candidate revisions; record their artifact identity when executing. Mainnet distribution, local CI and regtest builds exercise different environments, even at the same app revision.
The release diffs and latest review/device records were assessed together. The links below identify the recorded evidence; reuse remains limited to its reviewed revision, fixture and assertions. Older unchecked PR boxes were not treated as proof that later documented device runs were missing.
| Behavior | Applicable evidence and decision |
|---|---|
| core behavior | Onboarding/settings/widgets/PIN logic, address matrix, coin selection and Boost have applicable automation. Native/RN upgrade/restore results are in release PRs. synonymdev/bitkit-android#1755 · synonymdev/bitkit-ios#1193 |
| allowance basics | Set/accept, under-limit, cap/End behavior and allowance-history restore have recorded journey/device evidence. Keep the hardening limits below separate. synonymdev/bitkit-ios#1141 · synonymdev/bitkit-android#1707 |
| public/private sharing | Latest device reviews cover remote endpoint combinations, address separation/rotation, upgrade/restore and marketplace payment. Do not repeat the full privacy matrix. synonymdev/bitkit-ios#1095 (review) · synonymdev/bitkit-android#1668 (review) |
| recovery and app lock | Controlled USDT backup/retry/restart/restore evidence and paid-request lock/unlock evidence remain scoped to their recorded inputs. synonymdev/bitkit-ios#1118 · synonymdev/bitkit-android#1681 · synonymdev/bitkit-ios#1039 (review) |
| cross-platform restore | Recorded native iOS→Android and Android→iOS restore runs already exist; do not repeat a full restore solely for sanity. synonymdev/bitkit-android#1736 · synonymdev/bitkit-ios#1173 |
| Initial USDT subscription with PIN | Android #1568 review exercised automatic success with PIN disabled and PIN success during manual retry. Add the exact automatic-with-PIN gap as MN-USDT-A's outgoing payment. iOS #1006 review already exercised automatic success with PIN, so no duplicate iOS subscription case. |
| Live fixed-request source selection | Android #1713 and iOS #1149 review leave live Lightning variants to check. Fold those assertions into the recurring Lightning payment. |
| Production USDT services / bridge | Controlled recovery and bridge fixture coverage does not establish deployed paymaster/provider compatibility. Keep production USDT smoke on both platforms and one enabled bridge route; do not repeat the recovery fault matrix. See iOS #1032. |
| Physical biometrics | iOS #788 has policy coverage; physical-device lifecycle evidence was not found. Add one iPhone check and combine payment authentication with an existing payment. |
| Receive above 10% of channel capacity | Android #1662 and iOS #1086 lack app-journey evidence for the changed boundary. Ordinary E2E uses exactly 10% (10,000 / 100,000 sats); upstream integration tests do not execute the app path. Add one new-channel regtest check per platform. |
Release-head results are recorded in the release PRs above. Relevant completed runs include:
| Gate | Android | iOS |
|---|---|---|
| Local E2E | Passed with retries | Passed with retries |
| Staging | Passed with retries and skips | Passed with retries and skips |
| Migration | Passed | Passed, up to three attempts |
- Both staging runs skipped transfer/multi-address cases; these were not passes. iOS staging recorded two transfer skips, one multi-address skip and
settings_08skipped in the nightly UI shard. Its Pubky shard passed six cases on attempt 2 after a session-startup timeout; the nightly UI shard passed 28 cases on attempt 1. - iOS local E2E passed 13 cases across attempts, with the retired Blocktank
hardware_wallet_3case intentionally skipped. Attempt 2's twelve already-passed omissions were not twelve additional untested cases. - Android native UI run remained FAILED: three stale assertions and two funding/sync readiness failures. The release PR records the accepted 3.1.0 gate exception. It does not waive other tests/manual QA; subsequent master test fixes cannot turn this release run into a pass.
- 3.1.0 limits: allowances: Stale-ledger Resume with retained spending/ended allowances, controlled End during handoff and Android Resume TalkBack isolation retain documented device gaps. Android approval explicitly accepted these limits; unit coverage is not a complete device pass. synonymdev/bitkit-android#1738 (review) | synonymdev/bitkit-ios#1175 (comment)
- Other partial device evidence: Fixed-request quote/deadline/late-completion and hardware-recovery variants retain the limits stated in their reviews. The selected Lightning smoke is intended to exercise its named live-route gap only; it is not a claim that every fixture branch passed. synonymdev/bitkit-android#1713 | synonymdev/bitkit-ios#1149 (review)
These are historical limits and decisions for this cut. A later release must reassess them; a reduced sanity plan does not silently close untested behavior.
Each case has status Not run; tester/date, device/OS, actual build and execution evidence are not yet recorded. Populate those fields independently per platform when running the plan. Payment/proof references belong in the execution record with appropriate privacy controls.
- Scope: Recurring · Android.
- Steps and pass condition: Send and receive a small amount, including an external wallet. Confirm recipient output, amount and fee independently. After confirmation/reopening, balances and activity reconcile with no duplicates.
- Why selected: Production binary/services check; do not repeat address-type, coin-selection or Boost matrices.
- Status: Not run.
- Scope: Recurring · iOS.
- Steps and pass condition: Send and receive a small amount, including an external wallet. Confirm recipient output, amount and fee independently. After confirmation/reopening, balances and activity reconcile with no duplicates.
- Why selected: Production binary/services check; existing E2E covers functional variations.
- Status: Not run.
- Scope: Recurring + 3.1.0 · Android.
- Steps and pass condition: Send/receive via BOLT11 and make one external Lightning-address payment. Use a fixed Paykit request offering Savings and Spending for one outgoing payment: switch source, retain requested value, show the appropriate fee, authorize once and verify recipient settlement and requester proof.
- Why selected: Recurring production route smoke; source-selection variant closes a 3.1.0 live Lightning gap. synonymdev/bitkit-android#1713
- Status: Not run.
- Scope: Recurring + 3.1.0 · iOS.
- Steps and pass condition: Send/receive via BOLT11 and make one external Lightning-address payment. Use a fixed Paykit request offering Savings and Spending for one outgoing payment: switch source, retain requested value, show the appropriate fee, authorize once and verify recipient settlement and requester proof.
- Why selected: Remaining live Lightning variants: synonymdev/bitkit-ios#1149 (review)
- Status: Not run.
- Scope: Recurring · Android.
- Steps and pass condition: Complete a small production USDT send/receive. Use RS-SUB-A below for the outgoing payment, not an additional send. Verify recipient token balance, quoted/charged fee, final activity and balance after reopening.
- Why selected: Local-fork recovery already tested; production paymaster/provider settlement remains distinct. synonymdev/bitkit-android#1681
- Status: Not run.
- Scope: Recurring · iOS.
- Steps and pass condition: Complete a small production USDT send/receive. Check recipient token balance independently, quoted/charged fee, final activity and balance after reopening. Combine physical payment authentication with RS-BIO-I.
- Why selected: Local controlled recovery acceptance is reusable. synonymdev/bitkit-ios#1118
- Status: Not run.
- Scope: 3.1.0 · Android.
- Steps and pass condition: Use as MN-USDT-A's outgoing transfer. With payment PIN enabled: one Subscribe swipe → warning → correct PIN → one payment and Subscribed. Verify one recipient receipt/proof; no second payment swipe.
- Why selected: Existing automatic success had PIN disabled; PIN success covered manual retry. synonymdev/bitkit-android#1568 (review)
- Status: Not run.
- Scope: 3.1.0 · choose one platform.
- Steps and pass condition: Use one currently enabled route as part of USDT funding/receive. Verify source settlement, destination credit, final bridge status and working transaction references. Record platform/network/provider. One route, not a provider/network matrix.
- Why selected: Changed bridge validation has fixture coverage; verify compatibility with the deployed provider. synonymdev/bitkit-ios#1032
- Status: Not run.
- Scope: 3.1.0 · real iPhone.
- Steps and pass condition: Reopen locked app: one automatic prompt. Cancel/fail: usable PIN fallback, no prompt loop. Background/reopen: authentication works again. During a planned payment, cancel biometrics (no send), then explicitly authorize successfully.
- Why selected: Policy tests exist; physical-device evidence was not found. synonymdev/bitkit-ios#788
- Status: Not run.
- Scope: 3.1.0 · Android · REGTEST.
- Steps and pass condition: On a channel newly opened by this build, receive one Lightning payment above 10% of channel capacity with sufficient inbound liquidity. Independently verify settlement. Use regtest; do not open a mainnet channel for this check.
- Why selected: App journey unverified. Ordinary E2E receives 10,000 sats over a 100,000-sat channel (exactly 10%). synonymdev/bitkit-android#1662 (review)
- Status: Not run.
- Scope: 3.1.0 · iOS · REGTEST.
- Steps and pass condition: On a channel newly opened by this build, receive one Lightning payment above 10% of channel capacity with sufficient inbound liquidity. Independently verify settlement. Use regtest; existing channels retain their old negotiated limit.
- Why selected: Upstream integration coverage does not execute the app journey. synonymdev/bitkit-ios#1086 (review)
- Status: Not run.
- Reuse the latest applicable evidence rather than copying an old regression checklist.
- Combine the Android subscription check with its USDT send, and iPhone biometric payment approval with an existing payment; assess the linked assertions independently.
- Use a controlled regtest channel for a release-specific boundary instead of creating an unnecessary mainnet channel.
- Keep accepted failures and incomplete device coverage visible without describing them as passed.
- Re-derive the next release's plan from its own diff, builds and evidence.