v0.2.5-pre.006

docs/formats/KSPWALLET_V1.md

@@ -1,5 +1,5 @@
 <!-- file: docs/formats/KSPWALLET_V1.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # `.kspwallet` V1 — spécification du format natif Wallet KSP
 
@@ -764,7 +764,7 @@ Une création KSP V1 en mémoire suit conceptuellement :
 10. vérifier immédiatement la signature produite avant de retourner le handle OWNER.
 ```
 
-Les opérations Argon2id sont exécutées hors du thread executor async par une frontière blocking dédiée. La création `pre.005` est **in-memory** : la persistence arrive en `pre.006`.
+Les opérations Argon2id sont exécutées hors du thread executor async par une frontière blocking dédiée. La construction cryptographique reste entièrement en mémoire ; `pre.006` ajoute ensuite la publication filesystem no-clobber décrite en section 23.
 
 ### 21.2 Ouverture VIEW
 
@@ -830,3 +830,22 @@ wallet JSON complet
 
 Le vecteur a été généré et revérifié indépendamment du code Rust avec Argon2id, XChaCha20-Poly1305 construit via HChaCha20 + ChaCha20-Poly1305 IETF et Ed25519. Une implémentation externe conforme doit pouvoir reproduire les mêmes dérivations, déchiffrements et vérifications à partir des deux fichiers sans dépendre d'un type Rust KSP.
 
+## 23. Persistence native matérialisée par `pre.006`
+
+La persistence ne modifie aucun octet du wire V1. Elle définit uniquement comment un document V1 complet est publié et relu :
+
+```text
+caller path explicite
+  -> temp file unique dans le même répertoire
+  -> écriture complète des bytes JSON verrouillés
+  -> sync_all(temp)
+  -> persist_noclobber(destination)
+  -> sync_all(fichier publié)
+  -> sync parent directory best-effort sur Unix
+```
+
+`create_wallet_file_v1` n'écrase jamais une destination existante. Une collision ou une course concurrente retourne `wallet.destination_exists`; il n'existe aucun mode overwrite pour create/import. Les ouvertures fichier sont bornées à `KSPWALLET_MAX_FILE_BYTES` avant parser/KDF et délèguent ensuite exactement aux procédures VIEW/OWNER des sections 21.2/21.3.
+
+La couche filesystem est async-first, mais les appels OS bloquants sont regroupés derrière `tokio::task::spawn_blocking`. KSP ne lit ni Config ni environnement pour choisir le chemin et ne journalise pas les chemins par défaut.
+
+La durabilité est décrite sans surpromesse : `persist_noclobber` ne garantit pas une atomicité universelle sur tous les filesystems et un crash brutal peut laisser un artefact ou hard-link temporaire complet. KSP garantit le no-clobber et l'absence de publication partielle dans le flux normal et dans les fault tests avant publication ; il ne garantit pas la suppression des temporaires après kill/power-loss ni une durabilité identique de l'entrée de répertoire sur tous les OS. Ces limites concernent la persistence et ne changent pas les garanties cryptographiques du format.