# Prompt de démarrage `0.2.5` — Wallet foundation ## 1. Contexte de reprise La base attendue est la release stable : ```text v0.2.4 ``` `0.2.1` à `0.2.4` ont stabilisé la foundation HTTP Solana puis complété toute la surface HTTP courante auditée : ```text 52/52 méthodes HTTP courantes avec wrapper typed 14/14 méthodes historiques Deprecated / runtime Removed conservées KSP-TRANSPORT-007 appliqué à la surface complète ``` La prochaine release est : ```text 0.2.5 — Wallet foundation ``` Sa mission n'est pas d'ajouter une UI ni de commencer l'exécution métier. Elle introduit le **cœur Wallet autonome** dont les applications et l'exécution future pourront dépendre. La première tranche est : ```text 0.2.5-pre.001 ``` et commence obligatoirement par **audit actuel + reprise de l'héritage utile + brainstorming + threat model + sizing** avant toute implémentation cryptographique ou format lourd. ## 2. Mission de `0.2.5` Créer : ```text crates/ksp-wallet-lib ``` et stabiliser le format natif : ```text .kspwallet ``` Le Wallet doit fournir au minimum les capacités conceptuelles suivantes : ```text création ouverture / déverrouillage identité publique après autorisation protection du secret signature capacité VIEW indépendante capacité OWNER indépendante changement/rotation des mots de passe sans changement de keypair alias interne indépendant du filename notes internes protégées persistence atomique / no-clobber projection sûre selon capacité import/export extensible interopérabilité externe documentée du format natif ``` La release doit aboutir à une bibliothèque utilisable **sans Config, sans Transport, sans Tauri et sans execution policy**. Le format `.kspwallet` ne doit pas dépendre de l'existence future de KSP pour rester récupérable. Une implémentation externe conforme doit pouvoir le lire/déchiffrer avec les bons secrets d'accès à partir d'une spécification publique et de vecteurs de test. ## 3. Frontières architecturales déjà décidées La direction attendue reste : ```text ksp-wallet-lib -> ksp-core-lib -> ksp-logging-lib -> primitives crypto/key/signature low-level explicitement retenues ``` Interdictions : ```text ksp-wallet-lib -X-> ksp-config-lib ksp-wallet-lib -X-> ksp-onchain-transport-lib ksp-wallet-lib -X-> ksp-execution-policy-api ksp-wallet-lib -X-> Store ksp-wallet-lib -X-> Tauri ``` Le Wallet **stocke, ouvre et signe**. Il ne décide pas si une transaction ou une dépense est autorisée. Les règles de dépense, programme, réseau, simulation, plafonds ou approbation appartiennent à la future frontière : ```text ksp-execution-policy-api ``` et non à `ksp-wallet-lib`. ## 4. Décisions Wallet déjà acquises Les décisions suivantes ne doivent pas être rouvertes sans raison nouvelle et documentée : 1. le format natif KSP se nomme `.kspwallet` ; 2. KSP ne crée pas de `ksp-wallet-api` séparée dans l'architecture actuelle ; 3. `WalletPolicy` est explicitement exclu du Wallet ; 4. le wallet JSON temporaire historique bot2/bot3 n'est pas migré ; 5. l'ancien nom `.kswallet` n'est pas le nom final KSP ; 6. les secrets wallet ne doivent jamais être déplacés dans Config par commodité ; 7. Wallet n'a pas besoin de Transport pour son cœur ; 8. l'import/export doit rester extensible, mais seules les conversions réellement nécessaires doivent être implémentées ; 9. les futurs scénarios doivent pouvoir utiliser de vrais `.kspwallet`, y compris des wallets dédiés Devnet/tests ; 10. Wallet Desk arrive séparément en `0.2.6` ; 11. le format `.kspwallet` doit être **documenté et implémentable en dehors de KSP** ; la sécurité ne doit jamais dépendre de la confidentialité du format ; 12. aucun secret global KSP, `pepper` propriétaire ou donnée cachée dans le logiciel ne doit être nécessaire pour récupérer un `.kspwallet` autonome ; 13. la Pubkey, l'alias et les notes ne sont **pas lisibles wallet verrouillé** par défaut ; 14. l'alias est une identité humaine interne au wallet et reste indépendant du nom du fichier ; 15. les notes sont des metadata internes protégées et peuvent être ajoutées/modifiées/supprimées par la capacité OWNER ; 16. le `format_version` décrit **la version du format**, pas un compteur d'éditions, de changements de mot de passe ou de metadata ; 17. les paramètres cryptographiques nécessaires au déchiffrement doivent être sérialisés dans le fichier afin que les anciens wallets restent lisibles après durcissement futur des paramètres par défaut ; 18. le modèle cible possède deux capacités indépendantes : - `VIEW` : lecture Pubkey/alias/notes ; - `OWNER` : toutes les capacités VIEW + signature + administration du wallet ; 19. `OWNER` ne doit jamais dépendre de `VIEW` : la perte du password VIEW ne doit pas empêcher l'ouverture, la signature ou l'administration avec OWNER ; 20. un compromis du password VIEW ne doit pas permettre d'obtenir le secret Solana ni une clé permettant de dériver/déverrouiller la capacité OWNER ; 21. la rotation d'un password VIEW ou OWNER ne doit pas modifier la keypair Solana ; 22. OWNER doit pouvoir remplacer/supprimer/recréer la capacité VIEW sans connaître l'ancien password VIEW. Références KSP à relire avant le plan : ```text docs/rules/RULES_KSP.md docs/rules/RULES_DEPENDENCIES.md docs/architecture/002-LAYERS_AND_DEPENDENCIES.md docs/architecture/003-COMPONENT_CONTRACTS.md docs/architecture/004-COMPONENT_INVENTORY.md docs/architecture/005-DEPENDENCY_GRAPH.md docs/architecture/007-EXECUTION_AND_POLICY.md docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md docs/plans/007-V0_2_0_SERIES_PLANNING.md docs/validation/002-V0_2_0_SERIES_PLANNING.md docs/IDEAS.md ``` ## 5. `pre.001` — audit officiel actuel + brainstorming + threat model + sizing `pre.001` ne doit pas démarrer directement par le chiffrement du fichier. Il doit d'abord produire un plan Wallet dédié et répondre explicitement aux questions suivantes. ### 5.1 Héritage bot3/bot2 Réaduiter les implémentations historiques réellement disponibles de Wallet afin de classer chaque idée en : ```text réutiliser conceptuellement refondre abandonner reporter ``` Examiner notamment, lorsqu'ils existent dans les sources historiques : - création de keypair ; - lecture/écriture du format wallet ; - modèle de mot de passe ; - secret/public separation ; - changement de mot de passe ; - signature ; - import/export ; - aliases/metadata ; - atomicité/no-clobber ; - redaction ; - temporary wallet JSON ; - ancien `.kswallet` ; - `WalletPolicy`. Ne pas copier automatiquement une dépendance, un format ou une primitive cryptographique uniquement parce qu'elle existait dans bot3. ### 5.2 Threat model du `.kspwallet` Le plan doit documenter explicitement au minimum les scénarios suivants : ```text attaquant obtient une copie du fichier .kspwallet attaquant peut lancer des essais de password hors ligne sans limite serveur attaquant connaît intégralement la spécification du format attaquant connaît les algorithmes et paramètres KDF/AEAD stockés dans le fichier attaquant connaît seulement le password VIEW attaquant connaît seulement le password OWNER attaquant peut modifier partiellement le fichier attaquant peut remplacer totalement le fichier sur le filesystem ``` Conclusions à préserver : - le format ouvert/documenté n'est pas une faiblesse de sécurité ; - un wallet protégé uniquement par password reste attaquable **offline** par dictionnaire/bruteforce ; - le KDF rend chaque tentative coûteuse mais ne transforme pas un mauvais password en secret à forte entropie ; - le salt doit empêcher la réutilisation efficace de précalculs entre wallets, pas être traité comme un secret ; - aucun rate-limit applicatif KSP ne protège un fichier déjà volé ; - la résistance au remplacement total d'un fichier ne peut pas être promise uniquement par une information de confiance stockée dans ce même fichier ; - les garanties de `VIEW read-only` doivent distinguer clairement la sécurité de l'API KSP de la résistance cryptographique à un détenteur VIEW malveillant. Le plan doit déterminer quelles garanties sont assurées : ```text par la cryptographie du fichier par les types/capabilities de ksp-wallet-lib par les permissions/persistence filesystem par une éventuelle ancre de confiance externe future ``` ### 5.3 Primitives Solana actuelles Réaduiter les crates low-level Solana réellement nécessaires pour : ```text Pubkey keypair / secret material Signer Signature ``` Objectifs : - garder les dépendances au niveau le plus bas possible ; - ne pas tirer un client RPC Solana ; - ne pas recréer localement une primitive cryptographique standard bien maintenue ; - conserver toutes les dépendances tierces communes dans `[workspace.dependencies]`. L'audit doit vérifier les versions réellement actuelles au moment de la session, pas recopier les versions historiques bot3. ### 5.4 Protection cryptographique du fichier Comparer les primitives cryptographiques maintenues et adaptées au besoin réel du `.kspwallet`. Le plan doit décider explicitement, avec justification : ```text KDF password AEAD / chiffrement authentifié CSPRNG key wrapping / envelope encryption gestion salt / nonce paramètres KDF sérialisés format_version payload_version si distinct et justifié stratégie de migration zeroization / secret memory handling authentification OWNER des metadata si VIEW doit être cryptographiquement read-only ``` Ne pas inventer de cryptographie KSP. La shortlist à réauditer inclut au minimum : ```text KDF: Argon2id favori actuel à confirmer scrypt alternative memory-hard PBKDF2 compatibilité/legacy, pas favori sans raison AEAD: XChaCha20-Poly1305 AES-256-GCM-SIV autres alternatives seulement si elles apportent un avantage documenté Secret memory: zeroize secrecy ou types KSP simples basés sur zeroize ``` Cette shortlist n'est pas un verrouillage. `pre.001` doit vérifier l'état réel des crates, audits, maintenance, risques de nonce, portabilité, interopérabilité et dépendances avant décision. Le KDF ne doit pas recevoir des paramètres copiés arbitrairement d'un RFC ou d'un ancien projet. Les paramètres de création par défaut doivent être benchmarkés sur les machines cibles et conçus pour pouvoir être durcis plus tard sans rendre les wallets existants illisibles. ### 5.5 Architecture de clés et capacités `VIEW` / `OWNER` Le design ne doit pas chiffrer naïvement « tout le wallet avec deux passwords successifs ». Le plan doit étudier une architecture de **content keys + key slots**, conceptuellement de la forme : ```text password VIEW -> KDF VIEW -> VIEW key slot -> accès metadata seulement password OWNER -> KDF OWNER -> OWNER key slot -> root/owner capability -> accès metadata -> accès secret Solana -> signature -> administration / rotations ``` Invariants obligatoires : ```text VIEW et OWNER ont des KDF/salts indépendants OWNER ne dépend jamais de VIEW VIEW compromis != secret Solana compromis VIEW compromis != OWNER compromis OWNER peut recréer/supprimer VIEW sans ancien password VIEW rotation VIEW != rechiffrement ou changement de keypair obligatoire rotation OWNER != changement de keypair ``` Le plan doit décider si les key slots sont sérialisés sous une structure générique telle que : ```text key_slots: - role: view - role: owner ``` afin de conserver une extensibilité future sans implémenter dès V1 des rôles tels que recovery/hardware/automation. #### `VIEW` réellement read-only Dans l'API publique KSP, `VIEW` est obligatoirement read-only : ```text VIEW: lire Pubkey lire alias lire notes VIEW -X-> signer VIEW -X-> modifier alias/notes VIEW -X-> changer passwords VIEW -X-> exporter le secret ``` Cependant une clé symétrique permettant de déchiffrer un compartiment peut généralement aussi servir à produire un nouveau ciphertext valide pour ce même compartiment. `pre.001` doit donc trancher explicitement le niveau recherché : ```text A. read-only garanti seulement par les capabilities/types KSP B. read-only également renforcé cryptographiquement contre un détenteur VIEW malveillant ``` La préférence de conception est **B si elle peut être réalisée proprement et interopérablement sans complexité disproportionnée**. Si B est retenu, étudier une authentification des metadata contrôlée par OWNER, idéalement avec une autorité de contrôle distincte de la keypair Solana sauf justification contraire. Ne pas réutiliser automatiquement la clé de signature blockchain comme clé d'administration du format. La documentation doit rester honnête : même une metadata correctement authentifiée ne peut pas, à elle seule, empêcher quelqu'un ayant accès en écriture au filesystem de remplacer entièrement le fichier par un autre fichier valide. ### 5.6 Modèle de fichier `.kspwallet` Le plan doit définir les invariants du format avant l'API de persistence. Le format doit séparer conceptuellement : ```text enveloppe publique minimale key slots / paramètres nécessaires au déverrouillage compartiment metadata protégé compartiment secret protégé ``` L'enveloppe publique verrouillée ne doit exposer par défaut que ce qui est strictement nécessaire à l'interprétation/déverrouillage, par exemple : ```text magic format_version suite/identifiants crypto paramètres KDF salts nonces ou équivalents wrapped keys / key slots ciphertexts ``` Ne doivent pas être lisibles sans VIEW ou OWNER : ```text Pubkey alias notes secret Solana ``` Le compartiment metadata déverrouillé par VIEW ou OWNER doit pouvoir contenir au minimum : ```text Pubkey alias optionnel notes optionnelles ``` L'alias : ```text est indépendant du filename peut être modifié par OWNER peut être absent ``` Les notes : ```text peuvent être ajoutées/modifiées/supprimées par OWNER sont lisibles par VIEW et OWNER ne doivent jamais être exposées wallet verrouillé doivent avoir des limites de taille explicites ``` Le compartiment secret n'est accessible qu'à OWNER et contient le matériau nécessaire aux opérations de signature. Questions à trancher : - JSON, binaire ou enveloppe hybride ; - magic/version ; - représentation de la Pubkey ; - encodages exacts des salts/nonces/ciphertexts ; - schéma des key slots ; - champs obligatoires/optionnels ; - limites de taille globales et par champ ; - politique unknown-version ; - politique unknown-field ; - migrations futures ; - checksum séparé utile ou redondant avec AEAD/authentification ; - compatibilité endianness/encodage si format binaire ; - canonicalisation nécessaire si des signatures/authentifications couvrent des structures sérialisées. ### 5.7 Versionnement et migration Le plan doit distinguer clairement : ```text format_version ``` de tout historique de modification. `format_version` signifie : ```text comment parser/interpréter ce fichier ``` et **ne doit pas être incrémenté** pour : ```text changement de password changement d'alias ajout/modification/suppression de note réécriture atomique sans changement de schéma/crypto ``` Étudier séparément un éventuel : ```text payload_version ``` uniquement si l'évolution du contenu protégé justifie une frontière distincte de l'enveloppe. La stratégie doit permettre par exemple : ```text wallet ancien: paramètres KDF plus faibles mais sérialisés nouveau défaut KSP: paramètres KDF plus forts => les deux restent lisibles ``` Toute migration automatique future doit être explicite, testable et atomique. ### 5.8 Interopérabilité externe obligatoire Le `.kspwallet` ne doit pas être un format « lisible seulement par ksp-wallet-lib ». La release doit prévoir une spécification indépendante du code, par exemple : ```text docs/formats/KSPWALLET_V1.md ``` avec au minimum : - grammaire/structure exacte ; - suites crypto et paramètres ; - encodages ; - dérivation/wrapping ; - données authentifiées ; - ordre/canonicalisation lorsque pertinent ; - règles de parsing/rejet ; - limites ; - comportement unknown-version ; - procédure VIEW ; - procédure OWNER ; - procédure de rotation ; - vecteurs de test. Des **test vectors publics déterministes** doivent permettre à une implémentation externe en Rust, Python, Go, C ou autre de vérifier qu'elle dérive/déchiffre exactement les mêmes données. Le test vector peut naturellement contenir un password connu et un secret explicitement test-only ; il ne doit jamais être présenté comme wallet sûr de production. ### 5.9 Secret en mémoire Définir explicitement l'ownership du secret déverrouillé. Au minimum : - pas de `Debug`/`Display` révélant le secret ; - pas de valeur secrète dans les erreurs/logs/contextes KSP ; - éviter `Copy` et les clones implicites de secret ; - zeroization des buffers possédés lorsque raisonnablement possible ; - durée de vie du secret déverrouillé explicitement contrôlée ; - distinction nette metadata / encrypted payload / unlocked secret ; - aucune conservation du password en clair au-delà du besoin cryptographique ; - VIEW ne doit jamais matérialiser le secret Solana ; - le déverrouillage OWNER doit éviter l'exposition du secret brut aux consommateurs qui n'ont besoin que de `sign()`. Le plan doit être honnête sur les limites réelles de zeroization dans Rust et des allocations/transcodages choisis ; ne pas promettre une garantie que la stack ne peut pas fournir. ### 5.10 Persistence et opérations d'administration Définir la stratégie : ```text create open VIEW open OWNER atomic replace no-clobber create rotate VIEW password remove VIEW capability create/recreate VIEW capability rotate OWNER password modify alias add/update/delete notes permissions filesystem recovery after interrupted write ``` La rotation de password doit : - conserver la même identité/keypair ; - produire un nouveau matériau de protection approprié ; - ne pas dégrader l'atomicité ; - ne jamais laisser un fichier partiellement remplacé comme nouveau wallet valide ; - permettre à OWNER de gérer VIEW sans connaître l'ancien VIEW password. Le plan doit distinguer comportement portable et durcissement spécifique Unix si nécessaire. ### 5.11 Import/export extensible Établir une architecture ouverte qui permette d'ajouter des formats sans enum central fermé imposant de modifier le cœur à chaque intégration. Auditer les formats réellement utiles maintenant parmi les pistes historiques, par exemple : ```text Solana CLI keypair JSON Backpack Phantom Solflare Trust Wallet autres formats réellement disponibles dans les sources/audits ``` Cette liste est une **liste d'audit**, pas un engagement d'implémentation complet. `pre.001` sélectionne le minimum de formats nécessaire pour prouver l'extensibilité et le round-trip utile de la release. Ne pas ajouter des dépendances « au cas où ». ### 5.12 Sizing Évaluer séparément : ```text crate/API foundation threat model format wire interop/test vectors KDF/AEAD/key wrapping VIEW/OWNER key slots authentification cryptographique metadata si retenue persistence signing password/key-slot rotation metadata alias/notes import/export security tests docs/USAGE + format specification ``` Si le scope ne paraît plus clôturable proprement dans la session, découper **avant** l'implémentation lourde plutôt que réduire silencieusement les garanties de sécurité. ## 6. API publique à concevoir Les noms exacts sont décidés pendant le plan, mais les responsabilités doivent rester distinctes. Il doit exister des contrats clairs pour : ```text wallet locked/encrypted representation wallet VIEW capability wallet OWNER capability wallet metadata/info après autorisation create/open/save rotate/remove/create key slots import/export/inspect ``` La séparation conceptuelle minimale attendue est : ```text WalletView -> pubkey() -> alias() -> notes() WalletOwner -> tout WalletView -> sign(...) -> update_alias(...) -> add/update/delete_note(...) -> rotate_view_password(...) -> disable/recreate_view(...) -> rotate_owner_password(...) ``` Les noms ne sont pas imposés, les capacités oui. Ne pas exposer directement un champ `secret: Vec` comme API publique de commodité. Une API explicitement dangereuse d'export du secret ne doit exister que si un format d'export retenu l'exige réellement et avec une sémantique qui évite l'exposition accidentelle. La capacité de signature doit permettre aux couches supérieures d'obtenir une signature sans devoir extraire le secret brut. ## 7. Erreurs Utiliser le type d'erreur commun KSP. Prévoir des catégories suffisamment précises pour distinguer au minimum : ```text format invalide version non supportée paramètres crypto invalides authentification/déchiffrement échoué VIEW password invalide/non déverrouillable OWNER password invalide/non déverrouillable capability insuffisante I/O no-clobber / destination existante persistence atomique import/export non supporté key material invalide signature ``` Les messages et contextes ne doivent pas contenir : ```text password secret bytes seed phrase private key payload chiffré complet KDF input ``` Éviter également de créer un oracle inutile en distinguant trop finement les causes d'échec d'authentification lorsque cela affaiblirait la sécurité. ## 8. Logging `ksp-wallet-lib` utilise exclusivement la façade `ksp-logging-lib`. Les événements utiles peuvent inclure : ```text opération create/open-view/open-owner/import/export/rotate/sign format/version non secrète type de capability sans password succès/échec catégorisé durée destination/path seulement selon politique sûre retenue ``` Ne jamais logger : ```text password VIEW password OWNER secret seed private key signature payload arbitraire contenu complet du wallet ciphertext complet nonce/salt si le log n'en a aucun besoin opérationnel alias/notes par défaut ``` Même `trace` ne constitue pas une exception. ## 9. Tests de sécurité et de contrat Les tests déterministes doivent couvrir au minimum les domaines suivants. ### Format - round-trip du format natif ; - magic/format_version corrects ; - unknown version rejetée ; - fichier tronqué/reformaté rejeté ; - champs/tailles invalides rejetés ; - corruption/tampering détectée ; - absence du secret, de la Pubkey, de l'alias et des notes en clair dans le fichier verrouillé ; - paramètres KDF/crypto nécessaires au déverrouillage présents et cohérents ; - vecteurs de test externes reproductibles. ### VIEW / OWNER - VIEW correct lit Pubkey/alias/notes ; - VIEW ne peut pas signer via l'API ; - VIEW ne peut pas modifier alias/notes via l'API ; - VIEW ne peut pas administrer les key slots ; - VIEW ne peut pas obtenir le secret Solana ; - OWNER lit tout ce que VIEW lit ; - OWNER signe ; - OWNER modifie alias/notes ; - OWNER peut changer VIEW sans ancien VIEW password ; - OWNER peut supprimer puis recréer VIEW ; - OWNER fonctionne même si VIEW est perdu/inconnu ; - compromise/knowledge de VIEW ne permet pas d'ouvrir OWNER ; - VIEW et OWNER utilisent salts/KDF material indépendants. Si le read-only cryptographique est retenu : - un détenteur VIEW ne peut pas produire une modification de metadata acceptée comme authentique par la vérification prévue ; - les limites face au remplacement total du fichier sont documentées et testées seulement dans la mesure réellement possible. ### Password / crypto - bon VIEW password ouvre VIEW seulement ; - bon OWNER password ouvre OWNER ; - mauvais password échoue sans fuite ; - rotation VIEW conserve Pubkey/keypair ; - rotation OWNER conserve Pubkey/keypair ; - anciens passwords ne déverrouillent plus les key slots remplacés ; - nouveaux passwords fonctionnent ; - salt/nonce/paramètres ne sont pas accidentellement réutilisés lorsque le design impose leur renouvellement ; - les paramètres KDF enregistrés permettent de rouvrir un wallet après changement des defaults KSP. ### Metadata - alias indépendant du filename ; - alias absent/présent/modifié ; - notes absentes/présentes ; - ajout/modification/suppression de notes ; - limites de taille ; - metadata non visible sans VIEW/OWNER ; - metadata conservée lors d'une rotation OWNER/VIEW sauf modification explicite. ### Secret / diagnostics - `Debug`/snapshots/projections VIEW/OWNER ne contiennent pas le secret ; - erreurs n'échoent pas passwords/secret ; - logs de test ne contiennent pas de secret ni metadata non autorisée ; - types secrets n'acquièrent pas `Copy` par accident ; - zeroization testable lorsqu'elle est réellement observable sans faux sentiment de sécurité. ### Persistence - create ; - destination existante/no-clobber ; - write atomique ; - remplacement lors des rotations/admin changes ; - échec intermédiaire ne détruisant pas le wallet précédent, dans la mesure testable par la couche ; - permissions/durcissement filesystem retenus. ### Signature - Pubkey dérivée correcte ; - signature produite et vérifiable ; - rotations VIEW/OWNER ne changent pas la signature déterministe d'un même message si la primitive de signature est déterministe ; - VIEW ne peut pas signer ; - le consumer OWNER peut signer sans extraction publique du secret brut. ### Import/export - format(s) retenu(s) ; - validation stricte ; - round-trip lorsque le format le permet ; - inspect sans import si cette capability est retenue ; - architecture extensible démontrée sans dépendance au format natif dans les adapters externes. ### Public API / architecture - canary publique depuis crate root ; - aucune dépendance Wallet -> Config/Transport/ExecutionPolicy ; - aucune dépendance crypto dupliquée injustifiée ; - aucun accès environnement direct ; - aucun `unsafe` ajouté. ## 10. Tests et fixtures contenant des secrets Les secrets de tests doivent être **explicitement des fixtures non réelles**. Ne jamais utiliser : - un wallet personnel ; - une seed Mainnet ; - une clé provenant d'un `.env` opérateur ; - un fichier `.kspwallet` réel. Si une fixture déterministe est nécessaire, son caractère test-only doit être évident et elle ne doit jamais être utilisable comme secret de production recommandé. Les test vectors d'interopérabilité peuvent publier volontairement : ```text password VIEW connu password OWNER connu secret test-only connu Pubkey/alias/notes attendus bytes/JSON .kspwallet attendus ``` uniquement lorsqu'ils sont explicitement réservés aux tests et documentés comme tels. ## 11. Dépendances Toutes les dépendances tierces communes sont déclarées au `Cargo.toml` racine sous `[workspace.dependencies]`. Les membres consomment : ```toml .workspace = true ``` Éviter : - crypto maison ; - deux crates concurrentes pour la même primitive sans justification ; - stack async ou sérialisation supplémentaire sans besoin ; - client Solana RPC ; - dépendance Tauri ; - Config ; - Store. Toute nouvelle dépendance liée au secret doit être auditée au minimum sur : ```text maintenance actuelle version Rust/MSRV pertinente features par défaut unsafe/transitifs importants zeroize support format/compatibilité audit de sécurité disponible interopérabilité externe duplications cargo tree ``` ## 12. Async / sync Les opérations I/O doivent respecter la règle async-first du projet. Le plan doit néanmoins distinguer : - calcul CPU KDF potentiellement coûteux ; - opérations filesystem ; - signature CPU locale. Ne pas bloquer naïvement un runtime async avec une dérivation de clé coûteuse. Décider explicitement si l'API de bas niveau est sync avec wrapper async, utilise `spawn_blocking`, ou adopte une autre frontière cohérente. Ce choix doit rester compatible avec l'usage futur Tauri sans introduire Tauri dans Wallet. ## 13. Projection après autorisation Wallet doit pouvoir fournir une représentation sûre destinée aux consommateurs autorisés qui n'ont besoin que des metadata. Wallet verrouillé : ```text ne révèle pas Pubkey ne révèle pas alias ne révèle pas notes ``` Avec VIEW ou OWNER : ```text Pubkey alias notes format/version si pertinent état/capability sans secret ``` Avec OWNER seulement : ```text capacité de signature administration metadata/key slots ``` La terminologie « identité publique » signifie que la Pubkey elle-même n'est pas un secret blockchain, mais le fichier `.kspwallet` ne doit pas la révéler à un lecteur non authentifié par défaut. ## 14. Hors périmètre `0.2.5` Sont exclus sauf décision de rescoping explicite pendant le gate `pre.001` : ```text ksp-app-wallet-desk lecture réseau du solde HTTP/WebSocket/gRPC WalletPolicy execution policy construction/simulation/envoi de transaction Store seed phrase UI hardware wallet / Ledger remote signer browser extension mobile app cloud key management custody service trading recovery slot réellement implémenté hardware/automation key slot réellement implémenté ``` Les futurs rôles/key slots peuvent être anticipés structurellement sans être implémentés en V1. Les pistes d'import/export peuvent être étudiées sans rendre leurs applications/providers propriétaires du cœur Wallet. ## 15. Relation avec `0.2.6 — Wallet Desk` `0.2.6` doit pouvoir composer : ```text Config + ksp-wallet-lib + ksp-onchain-transport-lib + ksp-logging-lib -> ksp-app-wallet-desk ``` Le premier flux réseau attendu peut devenir : ```text sélectionner un .kspwallet -> déverrouiller VIEW ou OWNER -> obtenir la Pubkey -> getBalance via Transport HTTP -> afficher identité + alias/notes + solde selon capability ``` Aucune logique réseau nécessaire à ce flux ne doit remonter dans `ksp-wallet-lib`. ## 16. Prévision souple des prereleases Prévision initiale à réévaluer par `pre.001` : ```text pre.001 audit bot3 + crypto/deps actuelles + threat model + VIEW/OWNER + format/API + sizing pre.002 crate foundation + capabilities VIEW/OWNER + erreurs + canaries architecture pre.003 enveloppe/key slots .kspwallet + format/version + KDF/AEAD/wrapping + test vectors pre.004 compartiments metadata/secret + create/open VIEW/OWNER + persistence atomique/no-clobber pre.005 signature + administration alias/notes + rotations VIEW/OWNER + read-only cryptographique si retenu pre.006 architecture import/export + premier(s) format(s) réellement retenu(s) pre.007 security/interoperability/compliance audit + format spec + README/USAGE + graphes pre.008 clôture candidate + documentation finale + prompt 0.2.6 — Wallet Desk rel.001 publication strictement publicationnelle ``` Cette prévision est **souple**. Si l'architecture VIEW/OWNER, l'authentification metadata ou la persistence exige une tranche supplémentaire, ajouter une prerelease/fix plutôt que compresser les validations. Si `pre.001` conclut qu'un format/import particulier doit être reporté, le report doit être explicite et ne doit pas affaiblir les garanties du format natif. ## 17. Validation continue Après chaque changement Rust : ```bash cargo fmt --all cargo check --workspace cargo clippy --workspace --all-targets ``` Pendant le développement : ```bash cargo test -p ksp-wallet-lib ``` Les checkpoints de clôture doivent également réauditer : ```text cargo tree / duplications crypto frontières de dépendances absence d'accès environnement direct absence de secrets dans logs/errors/debug interop test vectors ```