What should happen?
Use the product specification for the promised behavior and explicit exclusions.
Documentation
The product, security model, architecture, evidence, and release records are documented separately so every important claim can be checked.
Source of truth
Identity, colors, typography, wordmark construction, components, imagery, and usage rules.
docs/brand-system.mdThe serious-but-cool personality, writing rules, humor boundary, calls to action, and claims checklist.
docs/voice-and-copy.mdCanonical wallet behavior, supported flows, invariants, and explicit exclusions.
docs/product-spec.mdAssets, trust boundaries, required controls, and residual risk.
docs/security-model.mdThe Svelte, Tauri, Rust, BDK, persistence, network, and hardware boundaries.
docs/architecture.mdCapability-by-capability separation of fixture, native implementation, evidence, and release state.
docs/implementation-status.mdThe evidence and review expected for each public release.
docs/mainnet-release-checklist.mdWork ordered by security dependency rather than marketing priority.
docs/roadmap.mdFree, Family, and Business boundaries, non-lock-in rules, revenue model, and licensing proposal.
docs/commercial-product-strategy.mdThreat model and phased plan for end-to-end encrypted, self-hostable proposal exchange.
docs/remote-signer-coordination-roadmap.mdFamily, inheritance, business-continuity, cosigner, and insurance direction.
docs/recovery-assurance-roadmap.mdReading order
Use the product specification for the promised behavior and explicit exclusions.
Use the security model and architecture for secret, persistence, hardware, and network boundaries.
Use implementation status and the release checklist before treating a capability as ready.