[dewabisma]

Summary

First step toward the desktop app. This adds a wallet_core package for platform-neutral code shared by mobile and desktop, and moves the leaf pieces (models, small utils, translations) into it. No behaviour change.

Phase 1 plan:

1. This PR: create wallet_core; move models, leaf utils and l10n.
2. Move services and providers; put mobile-only integrations (Firebase push, post-logout/creation navigation) behind interfaces.
3. Import cleanup and AGENTS.md rules for wallet_core.

Changes

• New wallet_core package
  • Includes test/architecture_test.dart, which fails if lib/ imports, or pubspec.yaml declares, a mobile-only package or resonance_network_wallet. Mobile-only here means Firebase, local_auth, mobile_scanner, image_picker, app_links, flutter_local_notifications, swap_live_activity_channel and play_install_referrer.
  • Its pubspec.lock is seeded from mobile's, so all 150 packages are at the versions mobile already uses.
• Moved from mobile-app with git mv, so history follows:
  • lib/models/ (12 files) → wallet_core/lib/models/
  • shared/utils/{account_utils,miner_stats_csv,provider_reader}.dart → wallet_core/lib/utils/
  • lib/l10n/ and l10n.yaml → wallet_core/. Regenerating with flutter gen-l10n there gives no diff.
  • The 3 test files that cover the moved code.
• quantusPrint: quantus_sdk now exports its existing copy. The identical copy in mobile-app/lib/shared/utils/print.dart is deleted and its 75 importers updated.
• mobile-app/pubspec.yaml: depends on wallet_core. It drops flutter_localizations and generate: true, which mobile no longer uses directly.
• melos / CI: wallet_core is added to melos.yaml (package list, path override, test script) and gets a "Test Wallet Core" step in ci.yaml.
• AGENTS.md: lists wallet_core and adds a Translations section saying where the ARB files live and how to regenerate them.

Verification

• mobile-app: flutter test gives 719 passed. With the 11 tests moved to wallet_core, that's the 730 from the baseline before this change.
• wallet_core: flutter test gives 13 passed. The architecture test was checked against a temporary Firebase import and a temporary local_auth dependency, and failed on both.
• quantus_sdk: flutter test --exclude-tags=native gives 678 passed, 1 skipped.
• melos run analyze: no issues in any of the 5 packages.
• dart format: no changes.
• melos bootstrap: succeeds and leaves the lockfiles and pubspec_overrides.yaml files unchanged. Lockfile changes in this PR: mobile-app/pubspec.lock gains wallet_core and flutter_localizations becomes transitive. No version changes.

🤖 Generated with Claude Code

[n13]

Verdict: Approve
Reviewer: GPT-6.1 Sol

Reviewed head 03741b7b08bdb31b68661bcb10e0c97ec91ea939 against base a8f1661dde9df650714e59c54b5c5fd578e6d4d1. No blocking findings.

The extraction preserves the moved model, utility, localization, and test bodies. Existing Dart changes are import/export updates, and the deleted quantusPrint implementation is identical to the SDK implementation now exported. Callers consistently use the new package paths, localization delegates remain connected, and all 150 resolutions in the new lockfile match the mobile baseline.

Validation:

• Inspected the full diff and checked internal import targets and references to removed paths; no broken references found.
• git diff --check passed. The non-writing workspace formatter check reported no changes, with unresolved lint-include warnings because package bootstrap was incomplete.
• GitHub CI at the reviewed head passed bootstrap, formatting, analysis across all five packages, and tests: wallet_core 13, mobile 719, SDK 678 (1 skipped), cold wallet 459. Dependency cooldown also passed.

Local runtime tests and analysis were blocked by the installed Flutter 3.44.4 versus the repository's pinned 3.47.7: locked offline bootstrap rejected SDK-dependent resolutions. Lockfiles and PR code were left unchanged.

[n13]

LGTM

Would just want to know what is the difference between sdk and wallet_core now?

What's their respective functions?

Meaning why not put wallet core into sdk?

Also another question about the architecture is whether these mobile and desktop functions have enough overlap to use the same codebase - I think they do...

In short, would like this answered:

• what goes in sdk?
• what goes in mobile_core
• what's in mobile
• what's in desktop

We're also sunsetting the GUI miner but it's good to keep these things in separate PRs - I like that this PR just moves files around without changes, makes it easier to track what happened later

[dewabisma]

Claude said this,

Short version: quantus_sdk is what talking to Quantus requires. wallet_core is how our hot wallet behaves. The two apps are views on top of wallet_core.

Why not put wallet_core in the SDK?

1. Different consumers. cold-wallet-app and miner-app also use the SDK. They don't need hot-wallet state, polling or multisig workflows, and they shouldn't have to carry them.
2. Different layer. The SDK is a library: stateless services you call. wallet_core is app state wired with Riverpod. Merging them would pull Riverpod and app concerns into every SDK consumer, and would mix "how the chain works" with "how our wallet UX behaves."
3. Different rate of change. wallet_core changes with every product feature. The SDK should stay stable and change slowly.

Is there enough overlap to share code? Yes, and that's why wallet_core exists. Everything except the UI and the platform integrations is the same: accounts, sending, history, multisig, swap, polling and translations. Roughly 10k lines of Dart logic plus the whole Rust core are shared. Only the screens differ, because a phone-style stacked UI feels wrong on desktop and the macOS guidelines expect a sidebar, a menu bar and shortcuts. Where the two apps need the same capability done differently, like push notifications, wallet_core defines an interface and each app provides its own implementation (Firebase on mobile, nothing on desktop for now).

[n13]

Yes sounds good. LGTM!