docs(swift-example-app): add multi-wallet test cases (Core + Platform) to iOS test plan#3888
Merged
Merged
Conversation
QuantumExplorer
requested review from
ZocoLini,
llbartekll and
shumkov
as code owners
June 13, 2026 22:48
Contributor
|
Warning Review limit reached
More reviews will be available in 4 minutes and 51 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughUpdates the Swift example app test plan by adjusting the Thorough tier legend, clarifying Core/Wallet entries around single-wallet versus multi-wallet coverage, and recalculating summary matrix totals for tiers and layers. ChangesSwift test plan documentation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The initial plan only covered multiple HD accounts within a single wallet (CORE-09); it missed the multi-wallet dimension entirely, even though the app is a full multi-wallet client (PlatformWalletManager holds N wallets keyed by wallet_id, one SPV runtime per network). Add CORE-14..CORE-21 covering: holding/listing multiple wallets, creating/importing a second wallet, switching the active wallet, deleting a wallet (cascade), per-wallet isolation, sending between two on-device wallets, concurrent SPV sync across wallets, and concurrent shielded-pool binding. Disambiguate CORE-09 (accounts vs wallets). Multi-wallet is not part of the every-user core experience, so none of these are Essential or Common: routine multi-wallet ops are Thorough and the destructive/exotic ones (delete wallet, concurrent shielded bind) are Uncommon. Matrix updated (Common 29, Thorough 29, Uncommon 17; Core 16, Shielded 11). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
QuantumExplorer
force-pushed
the
claude/ios-test-plan-multiwallet
branch
from
June 13, 2026 22:53
2787ebd to
56a3c88
Compare
Add §4.13 (Domain=MultiWallet, MW-01..MW-10): Platform/shielded interactions where both counterparties are wallets on the same device and network, so a full round-trip is verifiable locally without an external party. Covers credit/token transfer between two on-device identities, a full DashPay request->accept->pay loop, document transfer/purchase across wallets, a contested-DPNS race, shielded transfer/unshield between wallets, per-wallet Platform isolation, and the duplicate-seed case. Also documents a real asymmetry: Core SPV syncs all wallets at once (CORE-20) but PlatformBalanceSyncService is configured per active wallet (MW-08), so a second wallet's Platform balances can be stale until you switch to it. All multi-wallet rows are Thorough/Uncommon. Matrix: Thorough 35, Uncommon 21 (107 runnable); Platform ~71, Shielded 13. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
QuantumExplorer
changed the title
Add CORE-22 (re-add a previously deleted wallet on the same network) and CORE-23 (re-add a deleted wallet that also exists on another network), both Uncommon. CORE-23 exercises the cross-network mnemonic-purge guard: wallet_ids are network-scoped (same mnemonic -> distinct id per network, each with its own Keychain mnemonic copy), and deleteWallet only purges the phrase when walletRowCountAcrossNetworks == 0, so deleting on one network must not orphan the sibling on another. Matrix: Uncommon 23 (109 runnable), Core 18. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Audit of the shielded surface surfaced three gaps: - SH-12: Clear shielded state (real "Clear" button on the Sync tab -> clearShielded; wipes all wallets' notes + sync state, keeps bind creds for Sync-Now re-scan). Uncommon. - SH-13: no proper shielded receive-address UI. Address is derivable (shieldedDefaultAddress + DashAddress.encodeShielded) but only shown truncated/non-copyable; no copy/QR receive screen. Thorough, marked SDK-only; complicates cross-device receive and MW-06 setup. - MW-11: shielded withdraw from A to B's Core L1 address, completing the cross-wallet shielded exit set (shielded MW-06 / Platform MW-07 / Core MW-11). Uncommon. All six shielded transition types (15-20) and the operational set (sync, view, prover, seed, clear, receive-addr) are now accounted for. Matrix: Uncommon 25 (111 runnable), Shielded 15. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Correction: the app DOES have a polished shielded receive screen — the unified "Receive Dash" sheet (ReceiveAddressView) has Core / Platform / Shielded tabs, each with QR + full bech32m address + Copy. Re-classify SH-13 from SDK-only gap to FULLY IMPLEMENTED (Common) and drop the "no copy/QR UI" caveat from MW-06. The same view also exposes a Platform receive address tab that wasn't captured — add ADDR-06 (Display / share your Platform receive address, Common). Matrix: Common 31 (113 runnable); Platform ~72, Shielded 16. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Make feature category a first-class, queryable filter axis (Token, Shielded, Identity, ...) alongside Tier/Layer/Status, so requests like "run all non-Uncommon Token tests" resolve directly. A row's primary category is its §4 section; cross-cutting tests (e.g. MW-02 token transfer between wallets, CORE-21 multi-wallet shielded bind) are captured in a new §6 Category index that lists every member id per category. Updates the selection grammar (Domain -> Category) and adds worked examples for the Token and Shielded category queries. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
6 tasks
6 tasks
This was referenced Jul 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue being fixed or feature implemented
Follow-up to #3887. The original iOS
TEST_PLAN.mdonly captured multiple HD accounts within a single wallet (CORE-09) — it missed the multi-wallet dimension entirely (multiple wallets coexisting on one device/network), even though SwiftExampleApp is a full multi-wallet client (PlatformWalletManagerholds N wallets keyed bywallet_id, one SPV runtime per network).What was done?
Two clusters added, both verified against the app UI + FFI.
Wallet-lifecycle multi-wallet (
CORE-14..CORE-21, in §4.1)Hold/list multiple wallets, create/import a second, switch active wallet (navigation-based; no global picker), delete a wallet (cascades Keychain + identities + SwiftData), per-wallet isolation, send between two on-device wallets, concurrent SPV sync across wallets, concurrent shielded-pool binding. Also disambiguated
CORE-09(accounts vs wallets).Platform on-device counterparty scenarios (
MW-01..MW-10, new §4.13,Domain=MultiWallet)Interactions where both sides are wallets on the same device & network, so a full round-trip is verifiable locally:
MW-08documents a real asymmetry found in the code: Core SPV syncs all wallets at once (CORE-20), butPlatformBalanceSyncServiceis configured per active wallet (configure(...walletId:), re-run on switch), so a second wallet's Platform balances can be stale until you switch to it.Multi-wallet is a power-user / QA topology, not an everyday flow, so none of these are Essential or Common — routine ops are Thorough and destructive/exotic ones (delete wallet, concurrent shielded bind, doc transfer/purchase, duplicate-seed) are Uncommon. Summary matrix updated: Essential 22 · Common 29 · Thorough 35 · Uncommon 21 (107 runnable); Core 16, Platform ~71, Shielded 13.
How Has This Been Tested?
Documentation only. Status of each row verified by reading the wallet UI (
WalletsContentView,WalletDetailView,CreateWalletView),PlatformWalletManager,PlatformBalanceSyncService,ShieldedService, and theplatform_wallet_manager_*FFI (per-wallet_idkeying, manager-global SPV vs per-wallet platform balance sync).Breaking Changes
None. Documentation only.
Checklist:
For repository code-owners and collaborators only
🤖 Generated with Claude Code