Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.2.5-pre.010.fix.001

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-20 11:17:12 +02:00
parent 5bf9651038
commit c0b131bf6f
97 changed files with 2277 additions and 655 deletions
Download Patch File Download Diff File Expand all files Collapse all files

242
prompts/011-V0_2_6_START_PROMPT.md
View File

@@ -1,5 +1,5 @@
<!-- file: prompts/011-V0_2_6_START_PROMPT.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Prompt de démarrage `0.2.6` — Wallet Desk
@@ -91,7 +91,112 @@ strong disable/recreate VIEW
Ces capacités appartiennent déjà à Wallet ; l'application ne doit jamais les réimplémenter. `pre.001` décide leur découpage exact après sizing, mais ne réduit pas le MVP en dessous de l'ouverture VIEW/OWNER + identité autorisée + balance réseau.
## 3. Frontières architecturales
## 3. Contrat de session et sources de vérité obligatoires
Cette nouvelle session doit être autonome : **ne pas reconstruire les règles de mémoire, ne pas improviser les conventions et ne pas commencer par coder**.
La source de vérité est, dans cet ordre :
1. l'archive/repository opérateur réellement fourni pour la base stable `v0.2.5` ;
2. les règles KSP versionnées ;
3. les documents d'architecture/plans/validation actuels ;
4. les contrats publics réellement présents dans les crates ;
5. les sources externes officielles actuelles lorsque le comportement d'une dépendance ou de Tauri/Solana doit être vérifié ;
6. les anciennes générations bot3 uniquement comme référence historique, jamais comme autorité supérieure aux règles KSP actuelles.
Avant toute modification, relire au minimum, **dans cet ordre** :
```text
RULES.md
docs/000-README.md
docs/rules/RULES_GENERAL.md
docs/rules/RULES_KSP.md
docs/rules/RULES_RUST.md
docs/rules/RULES_DEPENDENCIES.md
docs/rules/PROMPT_STRUCTURE.md
docs/rules/VERSION_WORKFLOW.md
docs/rules/FILE_CONTRACTS.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/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
docs/plans/007-V0_2_0_SERIES_PLANNING.md
docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md
docs/formats/KSPWALLET_V1.md
docs/validation/008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md
crates/ksp-wallet-lib/README.md
crates/ksp-wallet-lib/USAGE.md
```
Réauditer ensuite les surfaces réellement consommées dans :
```text
crates/ksp-core-lib
crates/ksp-logging-lib
crates/ksp-config-lib
crates/ksp-onchain-transport-lib
crates/ksp-wallet-lib
crates/ksp-app-config-desk
```
Ne jamais supposer une API ou une convention parce qu'elle existait dans une session précédente. Si le repository réel contredit ce prompt, **le repository + les règles versionnées priment**, et l'écart est signalé avant de bâtir dessus.
## 4. Première mission `pre.001` — méthode d'ouverture obligatoire
`0.2.6-pre.001` est d'abord une tranche d'**audit, conception, inventaire et sizing**. L'implémentation UI lourde ne commence pas avant son gate.
Ordre de travail obligatoire :
```text
1. relire les sources internes obligatoires
2. vérifier la base stable et les versions réellement présentes
3. exécuter l'audit Rust structurel existant avant modification
4. auditer Config Desk comme référence Tauri sans le copier aveuglément
5. auditer les APIs publiques finales Config / Wallet / Transport / Logging
6. vérifier sur les sources officielles actuelles les dépendances Tauri/frontend réellement nécessaires
7. produire screen map + command/DTO map + threat model + matrice Config/composition
8. dimensionner les prereleases
9. seulement ensuite commencer l'implémentation de `pre.002` ou la petite fondation explicitement validée par le gate
```
Le premier audit Rust de la session doit inclure :
```bash
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
```
Une commande non exécutée n'est jamais déclarée réussie. Un warning, une exception globale ou une violation de règles n'est pas accepté comme « assez bon » pour avancer.
## 5. Prévision souple initiale des prereleases
Point de départ à réviser par `pre.001` :
```text
pre.001 audit/sizing/UX/Config/bridge/security
pre.002 crate Tauri + frontend shell + logging + splash/main
pre.003 std.wallet + composite Wallet Desk + adapters Config
pre.004 inventory/selection + locked inspection + DTOs
pre.005 create/import + unlock VIEW/OWNER + lifecycle
pre.006 wallet details + balance HTTP + refresh/diagnostics
pre.007 metadata administration + rotations VIEW/OWNER
pre.008 strong VIEW disable/recreate + export OWNER + security UX
pre.009 integration tests + Devnet smoke + compliance/security review
pre.010 README/USAGE/build final + prompt 0.2.7 si nécessaire
rel.001 publication stable
```
Cette séquence est un **forecast souple**, pas un engagement de clôture au numéro `pre.010`. `pre.001` doit la recalibrer avec un sizing concret. Si une tranche révèle un manque, insérer une prerelease ou un `fix` est préférable à forcer la clôture. Le numéro de tranche n'a jamais priorité sur la complétude du contrat.
## 6. Frontières architecturales
Direction autorisée :
@@ -121,7 +226,7 @@ frontend -X-> localStorage/sessionStorage pour passwords
L'application compose les couches ; elle ne déplace aucune logique métier ou cryptographique dans les commands Tauri ou TypeScript.
## 4. Config et composition
## 7. Config et composition
`0.2.6-pre.001` doit réauditer la surface Config existante avant de créer un document.
@@ -157,7 +262,7 @@ transport
Le nom exact des `component_id`, filenames et profils doit être fixé par `pre.001`/la tranche Config correspondante, pas inventé dans le frontend.
## 5. Wallet lifecycle dans l'application
## 8. Wallet lifecycle dans l'application
Le runtime Rust doit posséder les handles `WalletView` / `WalletOwner`. Le frontend ne reçoit que des DTO sûrs.
@@ -193,7 +298,7 @@ Les handles OWNER/VIEW ne doivent pas être sérialisés ou copiés dans le fron
Le lock explicite doit supprimer le handle Rust possédé par l'application et purger les projections frontend protégées.
## 6. Passwords et secrets
## 9. Passwords et secrets
Les passwords OWNER/VIEW sont des entrées éphémères :
@@ -215,7 +320,7 @@ Interdictions :
Les exports OWNER sont des opérations explicitement privilégiées et doivent utiliser une UX de confirmation intégrée.
## 7. Balance réseau
## 10. Balance réseau
Le cas réseau minimal est :
@@ -237,7 +342,7 @@ Le balance refresh doit :
- ne pas inventer de cache réseau dans Wallet ;
- préserver les règles de redaction URL/credentials de Transport.
## 8. UI/UX à auditer en `pre.001`
## 11. UI/UX à auditer en `pre.001`
Évaluer au minimum les vues/flows suivants :
@@ -261,7 +366,7 @@ Le sizing décide si tous ces flows tiennent dans `0.2.6` sans dégrader la qual
Les interactions destructives ou privilégiées utilisent des modals Bootstrap intégrés, pas `window.alert`, `window.confirm` ou `window.prompt`.
## 9. Référence Tauri existante
## 12. Référence Tauri existante
`ksp-app-config-desk` est le template principal à réauditer avant création :
@@ -284,7 +389,7 @@ Le port de développement doit être réservé distinctement de Config Desk apr
Le build frontend standalone `npm run check` reste un type-check/lint/test, pas un production build. Le build production final est déclenché par Tauri via `beforeBuildCommand`.
## 10. Logging
## 13. Logging
L'application doit rester dans l'écosystème `tracing` KSP :
@@ -300,7 +405,7 @@ Le bridge frontend -> Rust doit reprendre/refondre le pattern validé de Config
Les fichiers logs restent uniques par lancement selon la politique KSP existante.
## 11. DTOs Tauri
## 14. DTOs Tauri
Les commands Tauri doivent exposer des DTOs applicatifs sûrs, pas les types internes Wallet complexes lorsque cela élargit la surface inutilement.
@@ -323,7 +428,7 @@ Les noms sont indicatifs ; `pre.001` doit les rationaliser. Les DTOs ne contienn
TS-RS reste une frontière applicative Tauri. Ne pas ajouter des dérivations TS-RS dans `ksp-wallet-lib` uniquement pour cette app.
## 12. Inventory et chemins Wallet
## 15. Inventory et chemins Wallet
Wallet core reçoit toujours un chemin explicite. Si Wallet Desk affiche un inventaire de fichiers sous un répertoire configuré, cette énumération est une responsabilité de composition/application, pas une raison d'ajouter Config ou directory discovery dans `ksp-wallet-lib`.
@@ -339,7 +444,7 @@ L'audit doit fixer :
Aucun alias ne doit être dérivé du filename ; l'alias reste metadata protégée interne au wallet.
## 13. Administration OWNER
## 16. Administration OWNER
Les opérations OWNER existent déjà et doivent être appelées directement :
@@ -360,7 +465,7 @@ Le frontend doit refléter les permissions : les controls OWNER ne sont pas affi
Un `wallet.state_conflict` doit déclencher un message de conflit/refresh explicite, pas une réécriture forcée ou un retry aveugle.
## 14. Import/export
## 17. Import/export
Formats acquis :
@@ -386,7 +491,7 @@ OWNER uniquement
Le frontend ne doit pas recevoir le secret si un export fichier peut être effectué entièrement côté Rust. Un éventuel export texte/copie clipboard doit être traité comme une nouvelle surface de fuite et n'est pas supposé requis par défaut.
## 15. Tests
## 18. Tests
### 15.1 Rust déterministe
@@ -428,7 +533,7 @@ Config composite Devnet
Le smoke ne doit pas utiliser un secret de production ni exiger un wallet financé.
## 16. Sécurité desktop
## 19. Sécurité desktop
Préserver les règles acquises de Config Desk :
@@ -441,12 +546,77 @@ Préserver les règles acquises de Config Desk :
Les file pickers natifs éventuellement nécessaires doivent être évalués comme surface Tauri explicite, pas ajoutés implicitement.
## 17. Validation finale Tauri
## 20. Discipline Rust et normalisation workspace
Toute modification Rust de `0.2.6` respecte **simultanément** `rustfmt`, Clippy et les règles structurelles KSP. Le script d'audit n'est pas optionnel.
Rappels qui doivent être appliqués dès le premier patch, y compris dans les tests :
- `use` uniquement pour des traits réellement nécessaires à la résolution de méthode/contrainte du langage, annotés `rust-rules: trait-import` ;
- aucun import non-trait, alias de `use`, glob ou groupe `{...}` ;
- les `use` restent au début du module, jamais dans une fonction/méthode/test ;
- un item KSP `pub` ou `pub(crate)` partagé est réexporté au crate-root et consommé via le chemin le plus court (`crate::Item` dans sa crate, `ksp_*::Item` depuis une autre crate) ;
- `super::Item` dans un test n'est utilisé que pour un item strictement privé du module parent ;
- aucun `crate::module::Item` pour contourner une façade crate-root ;
- aucun alias de réexport pour résoudre une collision : renommer l'item dans son module propriétaire avec un nom canonique ;
- rustdoc utile pour tout `pub`/`pub(crate)` et leurs champs/méthodes visibles ;
- blocs homogènes ordonnés alphabétiquement lorsque l'ordre n'est pas sémantique ; façade `pub use` puis `pub(crate) use` ; constantes `pub`, puis `pub(crate)`, puis privées ;
- aucune ligne vide dans le corps d'une fonction/méthode ni à l'intérieur d'un `struct`/`enum` ; les lignes vides séparent les items ;
- les versions de fichiers modifiés sont incrémentées conformément aux règles KSP.
Le contrôle mécanique obligatoire est :
```bash
python3 scripts/audit_rust_workspace_rules.py
```
`cargo fmt` et Clippy **ne remplacent pas** ce contrôle.
## 21. Workflow version, delta et validation opérateur
Chaque tranche technique conserve les conventions KSP :
```text
Cargo workspace.package.version : 0.2.6-pre.N ou 0.2.6-pre.N.fix.M
Delta : deltas/0.2.6/pre.NNN.md ou pre.NNN-fix.MMM.md
Commit : v0.2.6-pre.NNN ou v0.2.6-pre.NNN-fix.MMM
Tag Git : uniquement pour la release stable finale v0.2.6
```
Une modification code/build/runtime/config/migration incrémente le signal technique Cargo. Une tranche réellement documentaire ne le fait pas. Le delta de livraison contient uniquement les fichiers ajoutés/modifiés nécessaires à la tranche, jamais une archive complète du repository.
Après toute modification Rust, ordre minimal :
```bash
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
```
Puis tests ciblés pendant le développement. Aux checkpoints globaux et à la clôture :
```bash
cargo test --workspace
```
Pour toute dépendance ajoutée/mise à niveau :
- vérifier la version stable réellement actuelle depuis la source primaire ;
- documenter les features réellement nécessaires ;
- exécuter les `cargo tree`/inverse trees pertinents ;
- ne pas conserver une génération ancienne uniquement par inertie ;
- ne pas forcer une unification impossible si deux dépendances externes imposent légitimement des générations différentes.
Les résultats opérateur collés dans la session deviennent la preuve de validation. Ne jamais inventer une validation locale non exécutée.
## 22. Validation finale Tauri
Après les validations ciblées et workspace :
```bash
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-app-wallet-desk
@@ -462,7 +632,7 @@ cargo tauri build -c crates/ksp-app-wallet-desk/tauri.conf.json
Le smoke Devnet opt-in, s'il est livré, est exécuté séparément avec une commande documentée.
## 18. Gate `pre.001`
## 23. Gate `pre.001`
Avant toute implémentation lourde, `0.2.6-pre.001` doit produire :
@@ -479,27 +649,9 @@ Avant toute implémentation lourde, `0.2.6-pre.001` doit produire :
Si le scope UI complet ne tient pas dans une release clôturable, scinder les fonctionnalités non essentielles avant implémentation lourde, mais préserver le MVP identité + balance.
## 19. Forecast initial non contraignant
Le gate n'est considéré franchi que si ces livrables sont écrits/consignés dans le delta/plan, que les dépendances nécessaires sont auditées et que la prévision de prereleases est explicitement recalibrée. Une simple discussion en chat sans matérialisation durable ne clôt pas `pre.001`.
Point de départ à réviser par `pre.001` :
```text
pre.001 audit/sizing/UX/Config/bridge/security
pre.002 crate Tauri + frontend shell + logging + splash/main
pre.003 std.wallet + composite Wallet Desk + adapters Config
pre.004 inventory/selection + locked inspection + DTOs
pre.005 create/import + unlock VIEW/OWNER + lifecycle
pre.006 wallet details + balance HTTP + refresh/diagnostics
pre.007 metadata administration + rotations VIEW/OWNER
pre.008 strong VIEW disable/recreate + export OWNER + security UX
pre.009 integration tests + Devnet smoke + compliance/security review
pre.010 README/USAGE/build final + prompt 0.2.7 si nécessaire
rel.001 publication stable
```
Cette séquence est un forecast, pas un engagement. `pre.001` peut la réduire, l'étendre ou la resegmenter selon l'audit réel.
## 20. Hors périmètre
## 24. Hors périmètre
```text
modification du wire .kspwallet V1 sans défaut démontré
@@ -516,7 +668,7 @@ trading
Le Wallet Desk valide et administre Wallet ; il ne devient pas l'application globale KSP.
## 21. Résultat attendu de `0.2.6`
## 25. Résultat attendu de `0.2.6`
À la clôture stable :
@@ -533,3 +685,17 @@ les validations Rust/frontend/Tauri sont vertes
un smoke Devnet de composition est disponible si retenu par le gate
README/USAGE et prompt de suite sont synchronisés
```
## 26. Instruction d'ouverture
Commencer la nouvelle session par **la relecture effective des sources internes obligatoires et l'audit de la base stable `v0.2.5`**. Ne pas répondre uniquement à partir de ce prompt ou de souvenirs de sessions précédentes.
Ensuite :
1. vérifier l'état réel de `ksp-app-config-desk`, Config, Wallet, Transport et Logging ;
2. exécuter la validation Rust structurelle de base ;
3. consulter les documentations officielles actuelles nécessaires pour Tauri/plugins/frontend ;
4. produire l'audit/sizing `0.2.6-pre.001`, avec screen map, DTO/commands, Config/composite, sécurité et forecast recalibré ;
5. **ne pas commencer l'implémentation UI lourde avant ce gate**.
Les règles de la session ne doivent pas être renégociées au fil des corrections : elles sont dans les documents KSP versionnés et doivent être appliquées dès chaque premier patch. Si un conflit ou une règle manquante est découvert, corriger la règle et son contrôle durable avant de propager une nouvelle convention.