WALLET / Code, builds & verification
What to publish on GitHub
Source, instructions, licenses and evidence should identify the same release.
The open package
The package needs source for distributed components as required by their licenses, pinned dependencies, build instructions, licenses and notices, a security policy, changelog and a source → build → binary link. Commit history alone does not make a build reproducible.
What to exclude
Exclude keys, seeds, wallet databases, credentials, private provider configuration, user data, internal server addresses and incidental logs. A purchased UI kit cannot automatically be published wholesale: verify redistribution rights for derived files first.
The local preparation kit
The local kit includes a README, documentation structure, release checklist, reproducibility and SBOM policies, security policy, bug report template and verification-record schema. This prepares publication; no public GitHub repository was created in this iteration.
Where the app components belong
The target stack is Flutter presentation and Rust authority for keys, data and operations. apps/flutter contains the interface; core owns wallet authority; bridge provides the typed asynchronous boundary; platform contains OS adapters. docs holds guides, verification holds approved public results, and releases records versions.