diff --git a/Cargo.toml b/Cargo.toml index 09f3a77..c21ac71 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -1,12 +1,12 @@ # file: Cargo.toml -# version: 441 +# version: 442 [workspace] resolver = "3" members = ["crates/ksp-app-backfill-desk", "crates/ksp-app-config-desk", "crates/ksp-app-solprices-desk", "crates/ksp-app-wallet-desk", "crates/ksp-config-lib", "crates/ksp-core-lib", "crates/ksp-interface-lib", "crates/ksp-job-api", "crates/ksp-job-backfill-lib", "crates/ksp-logging-lib", "crates/ksp-offchain-transport-lib", "crates/ksp-onchain-transport-lib", "crates/ksp-program-api", "crates/ksp-store-api", "crates/ksp-store-lib", "crates/ksp-store-postgres-lib", "crates/ksp-wallet-lib"] [workspace.package] -version = "0.3.7-pre.15" +version = "0.3.7-pre.16" edition = "2024" license = "MIT" repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project" diff --git a/README.md b/README.md index 31c85f6..54f535d 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ - + # Khadhroony Solana Project @@ -51,6 +51,8 @@ Les besoins du trading constituent une priorité produit à court terme mais ne La couche RAW dispose d'une façade Store backend-neutral et d'un premier job historique concret. `ksp-job-api` porte les contrats passifs communs des jobs bornés ; `ksp-job-backfill-lib` compose Transport observé et Store pour découvrir, hydrater et persister des transactions historiques RAW avec concurrence bornée, checkpoint contigu caller-owned, annulation coopérative et snapshots latest-value. +`ksp-app-backfill-desk` fournit la surface desktop spécialisée de composition de ce runtime : sélection d'un scope historique et d'un rôle HTTP logique, validation backend des bornes, Start single-run, monitoring latest-value, Cancel ciblé et Resume in-session sur checkpoint Rust-only. L'application ouvre Transport et Store via leurs façades KSP, ne dépend d'aucun backend Store concret et n'expose ni URL/credential, ni payload RAW, ni checkpoint opaque au frontend. + Ces contrats restent distincts des futurs workers continus : un job borné n'est ni un service worker ni un pipeline générique imposé aux autres couches. ## Points d'entrée diff --git a/crates/ksp-app-backfill-desk/README.md b/crates/ksp-app-backfill-desk/README.md new file mode 100644 index 0000000..4fa0565 --- /dev/null +++ b/crates/ksp-app-backfill-desk/README.md @@ -0,0 +1,105 @@ + + + +# `ksp-app-backfill-desk` + +`ksp-app-backfill-desk` est l'application desktop spécialisée de contrôle d'un backfill historique `RawTransaction` KSP. + +Elle reste une couche de composition Tauri : Config sélectionne les profils, Transport possède les endpoints/rôles/retry/rate-limit, Store possède la persistence et le backend, et `ksp-job-backfill-lib` possède découverte, hydratation, frontier/checkpoint et lifecycle du job. + +## Package + +```text +package : ksp-app-backfill-desk +lib : ksp_app_backfill_desk_lib +bin : ksp-app-backfill-desk +``` + +Le binaire est un launcher mince. La bibliothèque applicative possède le bootstrap, l'état Rust single-run, les DTOs Tauri, les commands et le bridge latest-value vers le frontend. + +## Composition + +```text +ksp-config-lib -> composite, profils, secrets et runtime packagé +ksp-core-lib -> erreurs, Pubkey et registre Program IDs +ksp-onchain-transport-lib -> HTTP pool, rôles, admission, retry/rate-limit +ksp-store-lib -> façade Store backend-neutral +ksp-job-api -> lifecycle Job commun +ksp-job-backfill-lib -> request/runtime/checkpoint/snapshots Backfill +ksp-logging-lib -> logging/tracing applicatif +ksp-app-backfill-desk -> orchestration Tauri + projections sûres +``` + +L'application ne dépend pas directement de `ksp-store-api`, `ksp-store-postgres-lib`, `tokio-postgres`, `reqwest`, `tonic` ou `yellowstone-grpc-proto`. + +## Capacités + +La surface utilisateur comprend : + +- quatre scopes : latest address, before address, after address et explicit signatures ; +- engagements `finalized` et `confirmed` ; +- sélection d'un rôle HTTP logique compatible avec `getSignaturesForAddress` et `getTransaction` ; +- bornes page/candidats/concurrence validées côté Rust par le contrat Backfill ; +- validation de la requête avant Start ; +- un seul run actif ; +- monitoring latest-value par événement `ksp-backfill-status` avec resynchronisation explicite ; +- Cancel ciblé par JobId backend et idempotent ; +- Resume in-session lorsqu'un checkpoint terminal est disponible ; +- autocomplete libre des Program IDs provenant du registre canonique `ksp-core-lib`. + +L'autocomplete n'est jamais une allow-list : une adresse Solana valide non enregistrée reste saisissable. + +## Checkpoint et Resume + +Le checkpoint concret ne traverse jamais IPC. Le backend conserve uniquement en mémoire Rust le dernier terminal compatible et la requête nécessaire à une reprise dans la même session. + +Un Resume crée un nouveau JobId backend. `ksp-job-backfill-lib` valide le checkpoint contre la requête d'origine puis le réémet pour ce nouveau Job sans modifier le scope fingerprint ni la frontier. Il n'existe pas de checkpoint durable de Backfill Desk après redémarrage de l'application. + +## Config et réseaux + +Le composite dédié est : + +```text +cfg.composite.ksp-app-backfill-desk +``` + +Les profils committed couvrent `mainnet`, `devnet` et `testnet`. Mainnet est le profil par défaut. Transport et Store doivent sélectionner exactement le même réseau avant que la composition soit déclarée ready. + +Les profils Store committed utilisent actuellement TLS PostgreSQL `disabled`; cette politique de profil n'enlève pas le support `verify_full` du Store/schema. + +Le frontend ne reçoit jamais URI Store, URL RPC, credential provider, secret Config ou backend physique. + +## Monitoring et sécurité + +Le monitoring expose des compteurs et codes sûrs : lifecycle, phase, boundary, candidats, entités/observations, missing/conflicts/holes, concurrence maximale, frontier contiguë, présence de checkpoint et éventuel domain/code d'échec. + +Il n'expose pas : + +- payload RAW ; +- adresse ou signatures de campagne ; +- checkpoint/cursor concret ; +- endpoint URL ou credential ; +- contexte d'erreur arbitraire. + +Le frontend ne possède ni accès direct filesystem/réseau, ni persistence navigateur de données Backfill. Les capabilities Tauri guest restent `core:default` et `tracing:default`. + +## Ports et développement + +```text +Vite HTTP : 1436 +Vite WS : 1437 +``` + +Lancement : + +```bash +(cd crates/ksp-app-backfill-desk && cargo tauri dev) +``` + +Build production : + +```bash +(cd crates/ksp-app-backfill-desk && cargo tauri build) +``` + +Voir également [`USAGE.md`](USAGE.md), [`../ksp-job-backfill-lib/README.md`](../ksp-job-backfill-lib/README.md), [`../../docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md`](../../docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md) et [`../../docs/validation/024-V0_3_7_BACKFILL_DESK.md`](../../docs/validation/024-V0_3_7_BACKFILL_DESK.md). diff --git a/crates/ksp-app-backfill-desk/USAGE.md b/crates/ksp-app-backfill-desk/USAGE.md new file mode 100644 index 0000000..38f9478 --- /dev/null +++ b/crates/ksp-app-backfill-desk/USAGE.md @@ -0,0 +1,145 @@ + + + +# Utilisation de `ksp-app-backfill-desk` + +## 1. Lancement + +Depuis la racine du workspace : + +```bash +(cd crates/ksp-app-backfill-desk && cargo tauri dev) +``` + +Le runtime charge le composite Backfill Desk via `ksp-config-lib`, construit le pool HTTP, ouvre Store puis vérifie que les deux surfaces utilisent le même réseau avant d'autoriser une campagne. + +## 2. Choix du profil et readiness + +Le composite `cfg.composite.ksp-app-backfill-desk` utilise Mainnet par défaut. Devnet et Testnet restent disponibles via la sélection Config du profil composite. + +Avant Start, l'écran indique séparément : + +```text +Transport ready +Store ready +Network coherent +Composition ready +``` + +Une composition non ready doit être corrigée côté Config/runtime ; le frontend ne peut pas fournir une URL RPC, une URI Store ou un secret pour contourner ces contrôles. + +## 3. Adresse et autocomplete Program IDs + +Le champ adresse accepte toute Pubkey Solana valide. Le `datalist` propose en complément les Program IDs du registre canonique `ksp-core-lib` avec leurs metadata publiques. + +Choisir une proposition remplit simplement le champ ; une adresse absente du dataset reste autorisée. Le dataset n'est pas une allow-list. + +## 4. Scopes + +Les scopes disponibles sont : + +```text +latest_address +before_address +after_address +explicit_signatures +``` + +`latest_address` recherche l'historique récent d'une adresse. `before_address` et `after_address` ajoutent une signature d'ancrage selon la sémantique Backfill. `explicit_signatures` traite une liste explicite de signatures et n'accepte pas `min_context_slot`. + +Les signatures et adresses sont revalidées côté Rust ; leur présence dans le formulaire ne les rend pas persistantes dans le frontend. + +## 5. Engagement, route HTTP et bornes + +Les engagements disponibles sont `finalized` et `confirmed`. + +Le sélecteur HTTP expose uniquement des rôles logiques que le backend a vérifiés compatibles avec les deux méthodes nécessaires au Backfill. Le rôle pool permet au Transport de choisir/rerouter entre endpoints selon ses propres règles ; les rôles ciblés permettent de sélectionner une route logique spécifique sans exposer l'URL physique. + +Les bornes de campagne comprennent notamment : + +```text +page size +max pages +max candidates +hydration concurrency +min context slot +``` + +Les limites maximales proviennent de `ksp-job-backfill-lib` et sont revalidées lors de la conversion vers `BackfillRequest`. + +## 6. Valider puis démarrer + +**Valider la requête** projette un résumé sûr de la campagne sans démarrer le job. + +**Démarrer** crée ensuite un JobId backend et installe le handle de contrôle avant le spawn asynchrone. Un second Start est refusé tant qu'un run est actif, y compris pendant `cancelling`. + +## 7. Monitoring latest-value + +La carte de monitoring est alimentée par les snapshots latest-value du runtime. Le backend émet `ksp-backfill-status`; **Resynchroniser** appelle également `backfill_status` afin de récupérer explicitement le dernier état complet. + +Les informations utiles incluent : + +- lifecycle et phase ; +- scope et discovery boundary ; +- candidats selected/admitted/finished ; +- entités et observations inserted/existing ; +- purged/missing/conflicts/holes/cancelled candidates ; +- maximum in flight ; +- contiguous completed ; +- présence d'un checkpoint ; +- domain/code stable d'échec éventuel. + +Le monitoring ne doit pas être interprété depuis les logs texte. + +## 8. Annuler + +**Annuler** envoie le JobId actuellement affiché. Cette cible protège un nouveau run contre une requête Cancel retardée destinée au run précédent. + +Le premier Cancel pré-terminal demande une annulation coopérative. Une répétition est idempotente. Le lifecycle peut passer par `cancelling`; les opérations déjà admises vers la persistence ne sont pas présentées comme brutalement interrompues. + +## 9. Reprendre + +**Reprendre** est disponible uniquement lorsqu'un snapshot terminal retenu contient un checkpoint. La commande n'accepte aucun checkpoint ou payload de campagne depuis le frontend. + +Le backend : + +1. exige qu'aucun run ne soit actif ; +2. récupère la requête terminale Rust-only ; +3. revalide le réseau Store et le rôle HTTP courant ; +4. génère un nouveau JobId ; +5. demande à `ksp-job-backfill-lib` de réémettre le checkpoint pour ce JobId ; +6. relance le même runtime/monitoring. + +La reprise est limitée à la session courante. Fermer l'application supprime ce checkpoint applicatif en mémoire. + +## 10. Fermeture de l'application + +La fermeture de la fenêtre principale bloque d'abord tout nouveau Start, tente une annulation coopérative du run actif puis ferme Store avant l'exit. + +Le shutdown applicatif n'est pas un mécanisme de checkpoint durable ou de reprise après crash. + +## 11. Données qui ne traversent pas le frontend + +Backfill Desk ne projette jamais : + +```text +URI Store +URL RPC +credentials/secrets +payload RAW +checkpoint/cursor concret +handles Store/Transport/Job +contexte d'erreur arbitraire +``` + +Les actions utilisateur et transitions sont instrumentées via Logging KSP sans journaliser adresse, signature ou payload métier. + +## 12. Runtime packagé + +Le build Tauri embarque les documents Config/schemas enregistrés. `ksp-config-lib` prépare ensuite la racine KSP user-writable et conserve les Config utilisateur existantes ; `.env` n'est jamais embarqué. + +Le build production est : + +```bash +(cd crates/ksp-app-backfill-desk && cargo tauri build) +``` diff --git a/deltas/0.3.7/pre.016.md b/deltas/0.3.7/pre.016.md new file mode 100644 index 0000000..f0f177f --- /dev/null +++ b/deltas/0.3.7/pre.016.md @@ -0,0 +1,63 @@ + + + +# Delta `0.3.7-pre.016` — réconciliation documentaire finale Backfill Desk + +## 1. Base requise + +```text +0.3.7-pre.015 +``` + +Le gate technique final est entièrement vert : format check, audits, check, Clippy `-D warnings`, workspace all-targets/all-features, graphes Cargo, duplicates et build Tauri Linux. + +## 2. Objectif + +Réconcilier exclusivement la documentation durable avec la surface réellement livrée de Backfill Desk. Aucun runtime, test, frontend, Config ou manifest de crate n'est rouvert. + +## 3. Version + +```text +workspace.package.version = 0.3.7-pre.16 +``` + +## 4. Réconciliation + +- README/USAGE durables de `ksp-app-backfill-desk` ; +- README racine et index docs/validation ; +- plan réaligné sur les six commandes Backfill réelles et `ksp-backfill-status` ; +- validation finale avec preuve du gate `pre.015` ; +- architecture Layers/Contracts/Inventory/Dependency Graph/Apps & Services mise à jour ; +- inventaire Backfill Desk fixé sur `ksp-app-backfill-desk`, statut Implémenté. + +`USAGE.md` reste strictement version-neutral : aucun journal de gate/prerelease n'y est ajouté. + +## 5. Gate technique enregistré + +La preuve opérateur `pre.015` établit : + +```text +1 494 tests passés +0 échec +15 tests ignorés opt-in/operator-only +Clippy -D warnings propre +3 bundles Tauri Linux : deb, rpm, AppImage +``` + +## 6. Hors scope + +```text +CHANGELOG.md +ROADMAP.md +prompt suivant +code/test/frontend/config +``` + +Ces surfaces restent réservées à `pre.017`. + +## 7. Suite + +```text +0.3.7-pre.017 — préparation publication minimale + prompt suivant +0.3.7-rel.001 — publication stable +``` diff --git a/docs/000-README.md b/docs/000-README.md index 039db00..45c4ed4 100644 --- a/docs/000-README.md +++ b/docs/000-README.md @@ -1,5 +1,5 @@ - + # Documentation KSP @@ -63,7 +63,8 @@ docs/ │ ├── 024-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION_PLAN.md │ ├── 025-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT_PLAN.md │ ├── 026-V0_3_5_INTERFACE_ACQUISITION_EVENTS_PLAN.md -│ └── 027-V0_3_6_JOB_API_BACKFILL_PLAN.md +│ ├── 027-V0_3_6_JOB_API_BACKFILL_PLAN.md +│ └── 028-V0_3_7_BACKFILL_DESK_PLAN.md ├── validation/ │ ├── 000-README.md │ ├── 001-V0_1_4_CONFIG_DESKTOP.md @@ -88,7 +89,8 @@ docs/ │ ├── 020-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION.md │ ├── 021-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT.md │ ├── 022-V0_3_5_INTERFACE_ACQUISITION_EVENTS.md -│ └── 023-V0_3_6_JOB_API_BACKFILL.md +│ ├── 023-V0_3_6_JOB_API_BACKFILL.md +│ └── 024-V0_3_7_BACKFILL_DESK.md └── rules/ ├── FILE_CONTRACTS.md ├── PROMPT_STRUCTURE.md @@ -105,7 +107,7 @@ D'autres sous-répertoires seront ajoutés uniquement lorsque leur rôle aura é ## Documents de planification -Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la release stable `0.1.1` est conservé comme historique clôturé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.2` est conservé comme historique clôturé dans [`plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.3 — Configuration foundation` est conservé comme historique clôturé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.4 — ksp-app-config-desk` est conservé comme historique clôturé dans [`plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md), avec sa matrice finale [`validation/001-V0_1_4_CONFIG_DESKTOP.md`](validation/001-V0_1_4_CONFIG_DESKTOP.md). Son prompt d'ouverture historique reste [`../prompts/004-V0_1_4_START_PROMPT.md`](../prompts/004-V0_1_4_START_PROMPT.md). La release stable `0.2.0` clôt l'audit de bot3 et le découpage de la série. Son plan directeur est conservé comme historique clôturé dans [`plans/007-V0_2_0_SERIES_PLANNING.md`](plans/007-V0_2_0_SERIES_PLANNING.md), avec sa matrice finale [`validation/002-V0_2_0_SERIES_PLANNING.md`](validation/002-V0_2_0_SERIES_PLANNING.md). La release stable `0.2.1 — HTTP Solana foundation` a été ouverte par [`../prompts/006-V0_2_1_START_PROMPT.md`](../prompts/006-V0_2_1_START_PROMPT.md). Son gate de sizing et sa matrice exhaustive sont conservés dans [`plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md`](plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md), avec la validation finale [`validation/003-V0_2_1_ONCHAIN_HTTP.md`](validation/003-V0_2_1_ONCHAIN_HTTP.md), README/USAGE Transport et le smoke Devnet opt-in de composition Config -> Transport. Le prompt [`../prompts/007-V0_2_2_START_PROMPT.md`](../prompts/007-V0_2_2_START_PROMPT.md) a ouvert la release stable `0.2.2 — HTTP Accounts + Tokens + Cluster`. Son plan clôturé [`plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md`](plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md) conserve l'audit et l'implémentation des 22 wrappers typés, tandis que [`validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md`](validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md) enregistre les validations déterministes, les graphes Cargo et les deux smokes Devnet passés avant publication. Le prompt [`../prompts/008-V0_2_3_START_PROMPT.md`](../prompts/008-V0_2_3_START_PROMPT.md) a ouvert la release stable `0.2.3 — HTTP Transactions`. Son plan clôturé [`plans/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md`](plans/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md) conserve l'audit et l'implémentation des 11 wrappers ; le réaudit [`validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md`](validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md) confirme la complétude des 37 wrappers HTTP typés et [`validation/006-V0_2_3_HTTP_TRANSACTIONS.md`](validation/006-V0_2_3_HTTP_TRANSACTIONS.md) enregistre les validations finales, graphes Cargo et deux smokes Devnet passés avant publication. Le prompt [`../prompts/009-V0_2_4_START_PROMPT.md`](../prompts/009-V0_2_4_START_PROMPT.md) a ouvert la release stable `0.2.4 — HTTP Blocks + Economics + compliance HTTP finale`. Son plan clôturé [`plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md`](plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md) conserve l’implémentation des 15 wrappers et la compliance `52/52 + 14/14`; la matrice finale [`validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md`](validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md) enregistre le réaudit SIMD/inventaire, les canaries globales et les preuves opérateur avant publication. Le prompt [`../prompts/010-V0_2_5_START_PROMPT.md`](../prompts/010-V0_2_5_START_PROMPT.md), finalisé par `0.2.4-pre.009-fix.001`, ouvre `0.2.5 — Wallet foundation` sur la base stable `v0.2.4`. Son plan historique clôturé [`plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md`](plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md) part du gate `pre.001` (héritage, threat model offline, VIEW/OWNER indépendants et niveau B read-only), puis matérialise la crate en `pre.002`, le wire/transcript en `pre.003`, les primitives Argon2id/XChaCha20-Poly1305 en `pre.004`, les payloads/create/open en `pre.005`, la persistence en `pre.006`, l'administration/signature en `pre.007` et les adapters transfer en `pre.008`. `pre.009` ferme l'audit adversarial/interoperability/compliance dans [`validation/008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md`](validation/008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md) avant la documentation finale `pre.010` ; `pre.010` finalise [`../crates/ksp-wallet-lib/README.md`](../crates/ksp-wallet-lib/README.md), [`../crates/ksp-wallet-lib/USAGE.md`](../crates/ksp-wallet-lib/USAGE.md), la spec, les graphes et la matrice ; `pre.010-fix.001`–`fix.003` ferment ensuite la mise à niveau Dalek et la normalisation Rust/audit structurel. `0.2.5-rel.001` publie la release stable et [`../prompts/011-V0_2_6_START_PROMPT.md`](../prompts/011-V0_2_6_START_PROMPT.md) ouvre `0.2.6 — Wallet Desk`. Le gate `0.2.6-pre.001` est conservé dans [`plans/013-V0_2_6_WALLET_DESK_PLAN.md`](plans/013-V0_2_6_WALLET_DESK_PLAN.md) : il réaudite Config Desk et les APIs finales, retient le gabarit desktop, fixe `std.wallet`, la composition Config/Wallet/HTTP/Logging, les secrets `KSP_SECRET_WALLET_PASS_*`, les frontières VIEW/OWNER et la trajectoire de validation. `pre.002`–`pre.014` matérialisent ensuite le shell Tauri, Config Wallet/composite, inventory, create/open, balance HTTP, import/export, metadata, rotations, révocation VIEW forte, compliance et polish desktop. `pre.015` fige le wire binaire `.kspwallet` V2, `pre.016` matérialise les APIs génériques/versionnées et le runtime V2, puis `pre.017` ajoute la migration explicite OWNER-authentifiée V1 -> V2. `pre.018` ferme le runtime Tauri packagé Config/resources et la documentation candidate ; `pre.018-fix.001` corrige le canari d'ownership Config, après quoi le gate workspace et le build final Linux sont verts. `pre.018-fix.002` renforce uniquement le contrat de reprise `0.2.7`. `0.2.6-rel.001` publie cette surface stable et [`../prompts/012-V0_2_7_START_PROMPT.md`](../prompts/012-V0_2_7_START_PROMPT.md) devient le prochain point d'entrée. Le gate `0.2.7-pre.001` ouvre la release WebSocket standard dans [`plans/014-V0_2_7_ONCHAIN_WEBSOCKET_PLAN.md`](plans/014-V0_2_7_ONCHAIN_WEBSOCKET_PLAN.md) ; la matrice normative puis finale est conservée dans [`validation/010-V0_2_7_ONCHAIN_WEBSOCKET.md`](validation/010-V0_2_7_ONCHAIN_WEBSOCKET.md). `0.2.7-pre.014` ferme la candidate technique/documentaire après validation 18/18, smoke WebSocket Devnet et audit du graphe Cargo ; `pre.014-fix.001` renforce uniquement le prompt suivant. `0.2.7-rel.001` publie `0.2.7 — WebSocket Solana standard` stable et [`../prompts/013-V0_2_8_START_PROMPT.md`](../prompts/013-V0_2_8_START_PROMPT.md) ouvre `0.2.8 — Helius LaserStream WebSocket`. Le plan historique clôturé [`plans/015-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET_PLAN.md`](plans/015-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET_PLAN.md) et la matrice finale [`validation/011-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET.md`](validation/011-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET.md) conservent la release stable `0.2.8 — Helius LaserStream WebSocket` publiée par `rel.001` : protocol `helius_laserstream`, sept familles standard Helius (`account/logs/program/root/signature/slot/slotsUpdates`), extension `transactionSubscribe`/`transactionUnsubscribe`, `block/vote` absents, heartbeat Ping 60 s, Config/secrets redacted, lifecycle adversarial et graphes Cargo finaux validés. [`../prompts/014-V0_2_9_START_PROMPT.md`](../prompts/014-V0_2_9_START_PROMPT.md) devient le contrat actif pour ouvrir Yellowstone gRPC standard/provider-neutral depuis le tag stable `v0.2.8`. La release stable `0.2.9` est conservée dans [`plans/016-V0_2_9_YELLOWSTONE_GRPC_PLAN.md`](plans/016-V0_2_9_YELLOWSTONE_GRPC_PLAN.md) et [`validation/012-V0_2_9_YELLOWSTONE_GRPC.md`](validation/012-V0_2_9_YELLOWSTONE_GRPC.md) : stratégie proto Apache + client KSP/Tonic, moteur N1, standard N2, Config V3, profils PublicNode Mainnet/Testnet authentifiés par `x-token` secret et smoke live `Subscribe` validé sur les deux réseaux. La candidate `0.2.10 — OrbitFlare Yellowstone gRPC` est réconciliée dans [`plans/017-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC_PLAN.md`](plans/017-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC_PLAN.md) et [`validation/013-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC.md`](validation/013-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC.md) : Devnet `http://devnet.rpc.orbitflare.com:10000`, License Key `ORBIT-*` injectée comme metadata secrète `x-token`, Config Transport V3 inchangée, live `Subscribe -> Slot + Ping` passé, aucun overlay provider et aucun heartbeat supplémentaire. La candidate `0.2.11 — Off-chain price transport` est réconciliée dans [`plans/018-V0_2_11_OFFCHAIN_PRICE_TRANSPORT_PLAN.md`](plans/018-V0_2_11_OFFCHAIN_PRICE_TRANSPORT_PLAN.md) et [`validation/014-V0_2_11_OFFCHAIN_PRICE_TRANSPORT.md`](validation/014-V0_2_11_OFFCHAIN_PRICE_TRANSPORT.md) : SOL/USD V1, huit adapters REST sans SDK provider, décimal exact, registry/availability/rate limits possédés par Off-chain Transport, Config `std.offchain_transport`, refresh individuel/multiple provider-neutral et smoke live keyless final `7/7` après correction CoinMarketCap V2. [`../crates/ksp-offchain-transport-lib/README.md`](../crates/ksp-offchain-transport-lib/README.md) et [`../crates/ksp-offchain-transport-lib/USAGE.md`](../crates/ksp-offchain-transport-lib/USAGE.md) deviennent les références durables ; la future `ksp-app-solprices-desk` reste une HID sans logique provider. La release stable `0.2.12 — SOL Prices Desk + intégration prix Wallet Desk` est conservée dans [`plans/019-V0_2_12_SOL_PRICES_DESK_PLAN.md`](plans/019-V0_2_12_SOL_PRICES_DESK_PLAN.md) et [`validation/015-V0_2_12_SOL_PRICES_DESK.md`](validation/015-V0_2_12_SOL_PRICES_DESK.md) : `ksp-app-solprices-desk` fournit le refresh manuel row/selected/all provider-neutral, états/timestamps exacts et diagnostics sûrs sur ports 1434/1435 ; Wallet Desk réutilise `MarketPriceService::refresh_all` pendant le refresh balance pour afficher une moyenne SOL/USD consumer-owned et l'équivalent USD exact, sans provider concret ni fallback Off-chain. Les gates finaux workspace/live et les trois builds Tauri Linux sont verts avant publication. `0.2.13 — Interface / wire foundation` est réconciliée comme candidate dans [`plans/020-V0_2_13_INTERFACE_PLAN.md`](plans/020-V0_2_13_INTERFACE_PLAN.md) avec la matrice finale candidate [`validation/016-V0_2_13_INTERFACE.md`](validation/016-V0_2_13_INTERFACE.md) : `ksp-interface-lib` expose le `Pubkey` Core, `ProgramAccountMeta` et `ProgramInstruction`, bornés à `255` account metas et `10_240` bytes de data, avec façade crate-root exacte, diagnostics bornés, consumer externe et firewall `Interface -> Core` validés. Le gate technique final `pre.006` est intégralement vert ; [`../crates/ksp-interface-lib/README.md`](../crates/ksp-interface-lib/README.md) et [`../crates/ksp-interface-lib/USAGE.md`](../crates/ksp-interface-lib/USAGE.md) deviennent les références durables avant préparation de publication. Le prompt d’ouverture historique reste [`../prompts/018-V0_2_13_START_PROMPT.md`](../prompts/018-V0_2_13_START_PROMPT.md). `0.2.14 — Program API foundation` est réconciliée comme candidate dans [`plans/021-V0_2_14_PROGRAM_API_PLAN.md`](plans/021-V0_2_14_PROGRAM_API_PLAN.md) avec la matrice finale candidate [`validation/017-V0_2_14_PROGRAM_API.md`](validation/017-V0_2_14_PROGRAM_API.md) : `ksp-program-api` fournit une façade instruction-only ouverte, `ProgramInstructionRecognition`, `ProgramInstructionDecodeOutcome` et `ProgramInstructionDecoder`, avec output associé possédé par l’implémentation, Program Pubkeys opaques/non enregistrés acceptés, canari externe et firewall `Program API -> Core + Interface`. Le gate technique final `pre.006` est intégralement vert ; [`../crates/ksp-program-api/README.md`](../crates/ksp-program-api/README.md) et [`../crates/ksp-program-api/USAGE.md`](../crates/ksp-program-api/USAGE.md) deviennent les références durables avant préparation de publication. Le prompt d’ouverture historique reste [`../prompts/019-V0_2_14_START_PROMPT.md`](../prompts/019-V0_2_14_START_PROMPT.md). `0.3.1 — Store API RAW foundation` est réconciliée comme candidate dans [`plans/022-V0_3_1_STORE_RAW_PLAN.md`](plans/022-V0_3_1_STORE_RAW_PLAN.md) avec la matrice [`validation/018-V0_3_1_STORE_RAW.md`](validation/018-V0_3_1_STORE_RAW.md) : `ksp-store-api` reste Core-only et backend-agnostic, expose les modèles RAW transaction/account et observations, queries cursorisées, outcomes, capabilities fines et lifecycle de rétention/tombstone, sans backend runtime, PostgreSQL, processing ledger ni N2/N3/N4. Le gate `pre.008` a été reconstruit après `cargo clean` et validé sur le workspace complet et les trois builds Tauri ; `pre.009` réconcilie la documentation durable avant la préparation de publication `pre.010`. `0.3.2 — Store/PostgreSQL runtime foundation` est réconciliée comme candidate dans [`plans/023-V0_3_2_STORE_POSTGRES_FOUNDATION_PLAN.md`](plans/023-V0_3_2_STORE_POSTGRES_FOUNDATION_PLAN.md) avec la matrice finale [`validation/019-V0_3_2_STORE_POSTGRES_FOUNDATION.md`](validation/019-V0_3_2_STORE_POSTGRES_FOUNDATION.md) : `ksp-store-lib` fournit la façade runtime backend-neutral, `ksp-store-postgres-lib` possède le backend physique tokio-postgres/Deadpool/Rustls et les migrations metadata-only, tandis que `std.store` sélectionne des targets PostgreSQL séparés par réseau. Le gate technique `pre.010` valide workspace, graphes, trois builds Tauri et la fondation PostgreSQL réelle sur un serveur major 17 ; [`../crates/ksp-store-lib/README.md`](../crates/ksp-store-lib/README.md), [`../crates/ksp-store-lib/USAGE.md`](../crates/ksp-store-lib/USAGE.md), [`../crates/ksp-store-postgres-lib/README.md`](../crates/ksp-store-postgres-lib/README.md) et [`../crates/ksp-store-postgres-lib/USAGE.md`](../crates/ksp-store-postgres-lib/USAGE.md) deviennent les références durables avant la lane de publication. `0.3.3 — Store/PostgreSQL RawTransaction vertical slice` est réconciliée comme candidate dans [`plans/024-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION_PLAN.md`](plans/024-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION_PLAN.md) avec la matrice finale [`validation/020-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION.md`](validation/020-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION.md) : les six capabilities `RawTransaction*` sont implémentées côté backend et façade, V001 matérialise canonical/observations/archive avec binding réseau, navigation keyset et rétention atomique, et le gate final rejoue le workspace complet ainsi que le live PostgreSQL 17. `RawAccountState` physique reste réservé à `0.3.4`. `0.3.4 — Store/PostgreSQL RawAccountState` est conservée dans [`plans/025-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT_PLAN.md`](plans/025-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT_PLAN.md) et [`validation/021-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT.md`](validation/021-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT.md) ; elle complète la surface RAW backend/façade à dix capabilities. `0.3.5 — Interface acquisition events` est conservée dans [`plans/026-V0_3_5_INTERFACE_ACQUISITION_EVENTS_PLAN.md`](plans/026-V0_3_5_INTERFACE_ACQUISITION_EVENTS_PLAN.md) et [`validation/022-V0_3_5_INTERFACE_ACQUISITION_EVENTS.md`](validation/022-V0_3_5_INTERFACE_ACQUISITION_EVENTS.md) ; elle ajoute les faits passifs provider-neutral de slot et d'exécution de transaction sans déplacer l'ownership Transport/Store. La candidate `0.3.6 — Job API + RAW transaction backfill` est réconciliée dans [`plans/027-V0_3_6_JOB_API_BACKFILL_PLAN.md`](plans/027-V0_3_6_JOB_API_BACKFILL_PLAN.md) avec [`validation/023-V0_3_6_JOB_API_BACKFILL.md`](validation/023-V0_3_6_JOB_API_BACKFILL.md) : `ksp-job-api` reste Core-only et runtime-neutral, tandis que `ksp-job-backfill-lib` fournit le premier runtime historique borné vers RAW via Transport observé + façade Store, avec provenance, idempotence, concurrence bornée, frontier/checkpoint contigus, annulation et snapshots latest-value. [`../crates/ksp-job-api/README.md`](../crates/ksp-job-api/README.md), [`../crates/ksp-job-api/USAGE.md`](../crates/ksp-job-api/USAGE.md), [`../crates/ksp-job-backfill-lib/README.md`](../crates/ksp-job-backfill-lib/README.md) et [`../crates/ksp-job-backfill-lib/USAGE.md`](../crates/ksp-job-backfill-lib/USAGE.md) deviennent les références de crate durables. +Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la release stable `0.1.1` est conservé comme historique clôturé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.2` est conservé comme historique clôturé dans [`plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.3 — Configuration foundation` est conservé comme historique clôturé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.4 — ksp-app-config-desk` est conservé comme historique clôturé dans [`plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md), avec sa matrice finale [`validation/001-V0_1_4_CONFIG_DESKTOP.md`](validation/001-V0_1_4_CONFIG_DESKTOP.md). Son prompt d'ouverture historique reste [`../prompts/004-V0_1_4_START_PROMPT.md`](../prompts/004-V0_1_4_START_PROMPT.md). La release stable `0.2.0` clôt l'audit de bot3 et le découpage de la série. Son plan directeur est conservé comme historique clôturé dans [`plans/007-V0_2_0_SERIES_PLANNING.md`](plans/007-V0_2_0_SERIES_PLANNING.md), avec sa matrice finale [`validation/002-V0_2_0_SERIES_PLANNING.md`](validation/002-V0_2_0_SERIES_PLANNING.md). La release stable `0.2.1 — HTTP Solana foundation` a été ouverte par [`../prompts/006-V0_2_1_START_PROMPT.md`](../prompts/006-V0_2_1_START_PROMPT.md). Son gate de sizing et sa matrice exhaustive sont conservés dans [`plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md`](plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md), avec la validation finale [`validation/003-V0_2_1_ONCHAIN_HTTP.md`](validation/003-V0_2_1_ONCHAIN_HTTP.md), README/USAGE Transport et le smoke Devnet opt-in de composition Config -> Transport. Le prompt [`../prompts/007-V0_2_2_START_PROMPT.md`](../prompts/007-V0_2_2_START_PROMPT.md) a ouvert la release stable `0.2.2 — HTTP Accounts + Tokens + Cluster`. Son plan clôturé [`plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md`](plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md) conserve l'audit et l'implémentation des 22 wrappers typés, tandis que [`validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md`](validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md) enregistre les validations déterministes, les graphes Cargo et les deux smokes Devnet passés avant publication. Le prompt [`../prompts/008-V0_2_3_START_PROMPT.md`](../prompts/008-V0_2_3_START_PROMPT.md) a ouvert la release stable `0.2.3 — HTTP Transactions`. Son plan clôturé [`plans/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md`](plans/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md) conserve l'audit et l'implémentation des 11 wrappers ; le réaudit [`validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md`](validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md) confirme la complétude des 37 wrappers HTTP typés et [`validation/006-V0_2_3_HTTP_TRANSACTIONS.md`](validation/006-V0_2_3_HTTP_TRANSACTIONS.md) enregistre les validations finales, graphes Cargo et deux smokes Devnet passés avant publication. Le prompt [`../prompts/009-V0_2_4_START_PROMPT.md`](../prompts/009-V0_2_4_START_PROMPT.md) a ouvert la release stable `0.2.4 — HTTP Blocks + Economics + compliance HTTP finale`. Son plan clôturé [`plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md`](plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md) conserve l’implémentation des 15 wrappers et la compliance `52/52 + 14/14`; la matrice finale [`validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md`](validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md) enregistre le réaudit SIMD/inventaire, les canaries globales et les preuves opérateur avant publication. Le prompt [`../prompts/010-V0_2_5_START_PROMPT.md`](../prompts/010-V0_2_5_START_PROMPT.md), finalisé par `0.2.4-pre.009-fix.001`, ouvre `0.2.5 — Wallet foundation` sur la base stable `v0.2.4`. Son plan historique clôturé [`plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md`](plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md) part du gate `pre.001` (héritage, threat model offline, VIEW/OWNER indépendants et niveau B read-only), puis matérialise la crate en `pre.002`, le wire/transcript en `pre.003`, les primitives Argon2id/XChaCha20-Poly1305 en `pre.004`, les payloads/create/open en `pre.005`, la persistence en `pre.006`, l'administration/signature en `pre.007` et les adapters transfer en `pre.008`. `pre.009` ferme l'audit adversarial/interoperability/compliance dans [`validation/008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md`](validation/008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md) avant la documentation finale `pre.010` ; `pre.010` finalise [`../crates/ksp-wallet-lib/README.md`](../crates/ksp-wallet-lib/README.md), [`../crates/ksp-wallet-lib/USAGE.md`](../crates/ksp-wallet-lib/USAGE.md), la spec, les graphes et la matrice ; `pre.010-fix.001`–`fix.003` ferment ensuite la mise à niveau Dalek et la normalisation Rust/audit structurel. `0.2.5-rel.001` publie la release stable et [`../prompts/011-V0_2_6_START_PROMPT.md`](../prompts/011-V0_2_6_START_PROMPT.md) ouvre `0.2.6 — Wallet Desk`. Le gate `0.2.6-pre.001` est conservé dans [`plans/013-V0_2_6_WALLET_DESK_PLAN.md`](plans/013-V0_2_6_WALLET_DESK_PLAN.md) : il réaudite Config Desk et les APIs finales, retient le gabarit desktop, fixe `std.wallet`, la composition Config/Wallet/HTTP/Logging, les secrets `KSP_SECRET_WALLET_PASS_*`, les frontières VIEW/OWNER et la trajectoire de validation. `pre.002`–`pre.014` matérialisent ensuite le shell Tauri, Config Wallet/composite, inventory, create/open, balance HTTP, import/export, metadata, rotations, révocation VIEW forte, compliance et polish desktop. `pre.015` fige le wire binaire `.kspwallet` V2, `pre.016` matérialise les APIs génériques/versionnées et le runtime V2, puis `pre.017` ajoute la migration explicite OWNER-authentifiée V1 -> V2. `pre.018` ferme le runtime Tauri packagé Config/resources et la documentation candidate ; `pre.018-fix.001` corrige le canari d'ownership Config, après quoi le gate workspace et le build final Linux sont verts. `pre.018-fix.002` renforce uniquement le contrat de reprise `0.2.7`. `0.2.6-rel.001` publie cette surface stable et [`../prompts/012-V0_2_7_START_PROMPT.md`](../prompts/012-V0_2_7_START_PROMPT.md) devient le prochain point d'entrée. Le gate `0.2.7-pre.001` ouvre la release WebSocket standard dans [`plans/014-V0_2_7_ONCHAIN_WEBSOCKET_PLAN.md`](plans/014-V0_2_7_ONCHAIN_WEBSOCKET_PLAN.md) ; la matrice normative puis finale est conservée dans [`validation/010-V0_2_7_ONCHAIN_WEBSOCKET.md`](validation/010-V0_2_7_ONCHAIN_WEBSOCKET.md). `0.2.7-pre.014` ferme la candidate technique/documentaire après validation 18/18, smoke WebSocket Devnet et audit du graphe Cargo ; `pre.014-fix.001` renforce uniquement le prompt suivant. `0.2.7-rel.001` publie `0.2.7 — WebSocket Solana standard` stable et [`../prompts/013-V0_2_8_START_PROMPT.md`](../prompts/013-V0_2_8_START_PROMPT.md) ouvre `0.2.8 — Helius LaserStream WebSocket`. Le plan historique clôturé [`plans/015-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET_PLAN.md`](plans/015-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET_PLAN.md) et la matrice finale [`validation/011-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET.md`](validation/011-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET.md) conservent la release stable `0.2.8 — Helius LaserStream WebSocket` publiée par `rel.001` : protocol `helius_laserstream`, sept familles standard Helius (`account/logs/program/root/signature/slot/slotsUpdates`), extension `transactionSubscribe`/`transactionUnsubscribe`, `block/vote` absents, heartbeat Ping 60 s, Config/secrets redacted, lifecycle adversarial et graphes Cargo finaux validés. [`../prompts/014-V0_2_9_START_PROMPT.md`](../prompts/014-V0_2_9_START_PROMPT.md) devient le contrat actif pour ouvrir Yellowstone gRPC standard/provider-neutral depuis le tag stable `v0.2.8`. La release stable `0.2.9` est conservée dans [`plans/016-V0_2_9_YELLOWSTONE_GRPC_PLAN.md`](plans/016-V0_2_9_YELLOWSTONE_GRPC_PLAN.md) et [`validation/012-V0_2_9_YELLOWSTONE_GRPC.md`](validation/012-V0_2_9_YELLOWSTONE_GRPC.md) : stratégie proto Apache + client KSP/Tonic, moteur N1, standard N2, Config V3, profils PublicNode Mainnet/Testnet authentifiés par `x-token` secret et smoke live `Subscribe` validé sur les deux réseaux. La candidate `0.2.10 — OrbitFlare Yellowstone gRPC` est réconciliée dans [`plans/017-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC_PLAN.md`](plans/017-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC_PLAN.md) et [`validation/013-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC.md`](validation/013-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC.md) : Devnet `http://devnet.rpc.orbitflare.com:10000`, License Key `ORBIT-*` injectée comme metadata secrète `x-token`, Config Transport V3 inchangée, live `Subscribe -> Slot + Ping` passé, aucun overlay provider et aucun heartbeat supplémentaire. La candidate `0.2.11 — Off-chain price transport` est réconciliée dans [`plans/018-V0_2_11_OFFCHAIN_PRICE_TRANSPORT_PLAN.md`](plans/018-V0_2_11_OFFCHAIN_PRICE_TRANSPORT_PLAN.md) et [`validation/014-V0_2_11_OFFCHAIN_PRICE_TRANSPORT.md`](validation/014-V0_2_11_OFFCHAIN_PRICE_TRANSPORT.md) : SOL/USD V1, huit adapters REST sans SDK provider, décimal exact, registry/availability/rate limits possédés par Off-chain Transport, Config `std.offchain_transport`, refresh individuel/multiple provider-neutral et smoke live keyless final `7/7` après correction CoinMarketCap V2. [`../crates/ksp-offchain-transport-lib/README.md`](../crates/ksp-offchain-transport-lib/README.md) et [`../crates/ksp-offchain-transport-lib/USAGE.md`](../crates/ksp-offchain-transport-lib/USAGE.md) deviennent les références durables ; la future `ksp-app-solprices-desk` reste une HID sans logique provider. La release stable `0.2.12 — SOL Prices Desk + intégration prix Wallet Desk` est conservée dans [`plans/019-V0_2_12_SOL_PRICES_DESK_PLAN.md`](plans/019-V0_2_12_SOL_PRICES_DESK_PLAN.md) et [`validation/015-V0_2_12_SOL_PRICES_DESK.md`](validation/015-V0_2_12_SOL_PRICES_DESK.md) : `ksp-app-solprices-desk` fournit le refresh manuel row/selected/all provider-neutral, états/timestamps exacts et diagnostics sûrs sur ports 1434/1435 ; Wallet Desk réutilise `MarketPriceService::refresh_all` pendant le refresh balance pour afficher une moyenne SOL/USD consumer-owned et l'équivalent USD exact, sans provider concret ni fallback Off-chain. Les gates finaux workspace/live et les trois builds Tauri Linux sont verts avant publication. `0.2.13 — Interface / wire foundation` est réconciliée comme candidate dans [`plans/020-V0_2_13_INTERFACE_PLAN.md`](plans/020-V0_2_13_INTERFACE_PLAN.md) avec la matrice finale candidate [`validation/016-V0_2_13_INTERFACE.md`](validation/016-V0_2_13_INTERFACE.md) : `ksp-interface-lib` expose le `Pubkey` Core, `ProgramAccountMeta` et `ProgramInstruction`, bornés à `255` account metas et `10_240` bytes de data, avec façade crate-root exacte, diagnostics bornés, consumer externe et firewall `Interface -> Core` validés. Le gate technique final `pre.006` est intégralement vert ; [`../crates/ksp-interface-lib/README.md`](../crates/ksp-interface-lib/README.md) et [`../crates/ksp-interface-lib/USAGE.md`](../crates/ksp-interface-lib/USAGE.md) deviennent les références durables avant préparation de publication. Le prompt d’ouverture historique reste [`../prompts/018-V0_2_13_START_PROMPT.md`](../prompts/018-V0_2_13_START_PROMPT.md). `0.2.14 — Program API foundation` est réconciliée comme candidate dans [`plans/021-V0_2_14_PROGRAM_API_PLAN.md`](plans/021-V0_2_14_PROGRAM_API_PLAN.md) avec la matrice finale candidate [`validation/017-V0_2_14_PROGRAM_API.md`](validation/017-V0_2_14_PROGRAM_API.md) : `ksp-program-api` fournit une façade instruction-only ouverte, `ProgramInstructionRecognition`, `ProgramInstructionDecodeOutcome` et `ProgramInstructionDecoder`, avec output associé possédé par l’implémentation, Program Pubkeys opaques/non enregistrés acceptés, canari externe et firewall `Program API -> Core + Interface`. Le gate technique final `pre.006` est intégralement vert ; [`../crates/ksp-program-api/README.md`](../crates/ksp-program-api/README.md) et [`../crates/ksp-program-api/USAGE.md`](../crates/ksp-program-api/USAGE.md) deviennent les références durables avant préparation de publication. Le prompt d’ouverture historique reste [`../prompts/019-V0_2_14_START_PROMPT.md`](../prompts/019-V0_2_14_START_PROMPT.md). `0.3.1 — Store API RAW foundation` est réconciliée comme candidate dans [`plans/022-V0_3_1_STORE_RAW_PLAN.md`](plans/022-V0_3_1_STORE_RAW_PLAN.md) avec la matrice [`validation/018-V0_3_1_STORE_RAW.md`](validation/018-V0_3_1_STORE_RAW.md) : `ksp-store-api` reste Core-only et backend-agnostic, expose les modèles RAW transaction/account et observations, queries cursorisées, outcomes, capabilities fines et lifecycle de rétention/tombstone, sans backend runtime, PostgreSQL, processing ledger ni N2/N3/N4. Le gate `pre.008` a été reconstruit après `cargo clean` et validé sur le workspace complet et les trois builds Tauri ; `pre.009` réconcilie la documentation durable avant la préparation de publication `pre.010`. `0.3.2 — Store/PostgreSQL runtime foundation` est réconciliée comme candidate dans [`plans/023-V0_3_2_STORE_POSTGRES_FOUNDATION_PLAN.md`](plans/023-V0_3_2_STORE_POSTGRES_FOUNDATION_PLAN.md) avec la matrice finale [`validation/019-V0_3_2_STORE_POSTGRES_FOUNDATION.md`](validation/019-V0_3_2_STORE_POSTGRES_FOUNDATION.md) : `ksp-store-lib` fournit la façade runtime backend-neutral, `ksp-store-postgres-lib` possède le backend physique tokio-postgres/Deadpool/Rustls et les migrations metadata-only, tandis que `std.store` sélectionne des targets PostgreSQL séparés par réseau. Le gate technique `pre.010` valide workspace, graphes, trois builds Tauri et la fondation PostgreSQL réelle sur un serveur major 17 ; [`../crates/ksp-store-lib/README.md`](../crates/ksp-store-lib/README.md), [`../crates/ksp-store-lib/USAGE.md`](../crates/ksp-store-lib/USAGE.md), [`../crates/ksp-store-postgres-lib/README.md`](../crates/ksp-store-postgres-lib/README.md) et [`../crates/ksp-store-postgres-lib/USAGE.md`](../crates/ksp-store-postgres-lib/USAGE.md) deviennent les références durables avant la lane de publication. `0.3.3 — Store/PostgreSQL RawTransaction vertical slice` est réconciliée comme candidate dans [`plans/024-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION_PLAN.md`](plans/024-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION_PLAN.md) avec la matrice finale [`validation/020-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION.md`](validation/020-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION.md) : les six capabilities `RawTransaction*` sont implémentées côté backend et façade, V001 matérialise canonical/observations/archive avec binding réseau, navigation keyset et rétention atomique, et le gate final rejoue le workspace complet ainsi que le live PostgreSQL 17. `RawAccountState` physique reste réservé à `0.3.4`. `0.3.4 — Store/PostgreSQL RawAccountState` est conservée dans [`plans/025-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT_PLAN.md`](plans/025-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT_PLAN.md) et [`validation/021-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT.md`](validation/021-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT.md) ; elle complète la surface RAW backend/façade à dix capabilities. `0.3.5 — Interface acquisition events` est conservée dans [`plans/026-V0_3_5_INTERFACE_ACQUISITION_EVENTS_PLAN.md`](plans/026-V0_3_5_INTERFACE_ACQUISITION_EVENTS_PLAN.md) et [`validation/022-V0_3_5_INTERFACE_ACQUISITION_EVENTS.md`](validation/022-V0_3_5_INTERFACE_ACQUISITION_EVENTS.md) ; elle ajoute les faits passifs provider-neutral de slot et d'exécution de transaction sans déplacer l'ownership Transport/Store. La candidate `0.3.6 — Job API + RAW transaction backfill` est réconciliée dans [`plans/027-V0_3_6_JOB_API_BACKFILL_PLAN.md`](plans/027-V0_3_6_JOB_API_BACKFILL_PLAN.md) avec [`validation/023-V0_3_6_JOB_API_BACKFILL.md`](validation/023-V0_3_6_JOB_API_BACKFILL.md) : `ksp-job-api` reste Core-only et runtime-neutral, tandis que `ksp-job-backfill-lib` fournit le premier runtime historique borné vers RAW via Transport observé + façade Store, avec provenance, idempotence, concurrence bornée, frontier/checkpoint contigus, annulation et snapshots latest-value. [`../crates/ksp-job-api/README.md`](../crates/ksp-job-api/README.md), [`../crates/ksp-job-api/USAGE.md`](../crates/ksp-job-api/USAGE.md), [`../crates/ksp-job-backfill-lib/README.md`](../crates/ksp-job-backfill-lib/README.md) et [`../crates/ksp-job-backfill-lib/USAGE.md`](../crates/ksp-job-backfill-lib/USAGE.md) deviennent les références de crate durables. La candidate `0.3.7 — Backfill Desk` est réconciliée dans [`plans/028-V0_3_7_BACKFILL_DESK_PLAN.md`](plans/028-V0_3_7_BACKFILL_DESK_PLAN.md) avec [`validation/024-V0_3_7_BACKFILL_DESK.md`](validation/024-V0_3_7_BACKFILL_DESK.md) : `ksp-app-backfill-desk` compose Config, HTTP Transport, Store et le runtime Backfill pour Start/monitoring/Cancel/Resume in-session, conserve checkpoint et ressources physiques côté Rust, et fournit un autocomplete libre alimenté par le registre Program IDs de Core. [`../crates/ksp-app-backfill-desk/README.md`](../crates/ksp-app-backfill-desk/README.md) et [`../crates/ksp-app-backfill-desk/USAGE.md`](../crates/ksp-app-backfill-desk/USAGE.md) deviennent les références applicatives durables. ## Spécifications de formats diff --git a/docs/architecture/002-LAYERS_AND_DEPENDENCIES.md b/docs/architecture/002-LAYERS_AND_DEPENDENCIES.md index b770f39..13c8ccc 100644 --- a/docs/architecture/002-LAYERS_AND_DEPENDENCIES.md +++ b/docs/architecture/002-LAYERS_AND_DEPENDENCIES.md @@ -1,5 +1,5 @@ - + # Couches et dépendances KSP @@ -134,7 +134,7 @@ Les applications Tauri restent minces : - instrumentation frontend ; - aucun déplacement de logique de transport, Wallet, Config, Program, Store ou Materializer dans Tauri. -Des applications spécialisées sont ajoutées au fur et à mesure pour valider les couches : Config Desk, Wallet Desk, `ksp-app-solprices-desk`, backfill/RAW tooling, CORE tooling puis Market Desk. `ksp-app-solprices-desk` reste une HID mince : elle consomme l’inventaire, les observations, les états et les opérations génériques de `ksp-offchain-transport-lib` sans connaître les providers, leurs endpoints, leurs credentials ni leurs limites. +Des applications spécialisées sont ajoutées au fur et à mesure pour valider les couches : Config Desk, Wallet Desk, `ksp-app-solprices-desk`, `ksp-app-backfill-desk`, Store/RAW tooling, CORE tooling puis Market Desk. `ksp-app-solprices-desk` reste une HID mince : elle consomme l’inventaire, les observations, les états et les opérations génériques de `ksp-offchain-transport-lib` sans connaître les providers, leurs endpoints, leurs credentials ni leurs limites. `ksp-app-backfill-desk` compose Config, Transport HTTP, Store et `ksp-job-backfill-lib` sans absorber découverte, retry/rate-limit, persistance ou checkpoint ; son frontend ne reçoit que des DTOs sûrs et le checkpoint de reprise reste Rust-only. ## Workers et jobs diff --git a/docs/architecture/003-COMPONENT_CONTRACTS.md b/docs/architecture/003-COMPONENT_CONTRACTS.md index 4cdb28a..eff661c 100644 --- a/docs/architecture/003-COMPONENT_CONTRACTS.md +++ b/docs/architecture/003-COMPONENT_CONTRACTS.md @@ -1,5 +1,5 @@ - + # Contrats initiaux des composants KSP @@ -203,14 +203,17 @@ KSP privilégie des applications spécialisées servant à valider/exploiter une ```text ksp-app-config-desk ksp-app-wallet-desk -price desk -backfill/raw tooling +ksp-app-solprices-desk +ksp-app-backfill-desk +ksp-app-store-desk CORE tooling ksp-app-market-desk ``` Une application globale reste future. +`ksp-app-backfill-desk` est l'interface spécialisée du premier job historique. Elle dépend des façades KSP nécessaires à la composition (`ksp-config-lib`, `ksp-job-api`, `ksp-job-backfill-lib`, `ksp-onchain-transport-lib`, `ksp-store-lib`, Core et Logging), garde Store/Transport/checkpoint côté Rust et expose uniquement les options, demandes opérateur bornées, états latest-value et acquittements de contrôle sûrs. + ## Progression verticale Program À partir de DECODE : diff --git a/docs/architecture/004-COMPONENT_INVENTORY.md b/docs/architecture/004-COMPONENT_INVENTORY.md index e987ff9..fe9a99d 100644 --- a/docs/architecture/004-COMPONENT_INVENTORY.md +++ b/docs/architecture/004-COMPONENT_INVENTORY.md @@ -1,5 +1,5 @@ - + # Inventaire initial des composants KSP @@ -42,7 +42,7 @@ Ce document maintient l'inventaire synthétique des composants retenus ou presse | Store PostgreSQL | `ksp-store-postgres-lib` | lib | Stable | `0.3.2`–`0.3.4` | backend référence : fondation, RawTransaction et RawAccountState | | Job lifecycle | `ksp-job-api` | API | Implémenté | `0.3.6` | identité/lifecycle/annulation/notifications latest-value runtime-neutral | | Backfill | `ksp-job-backfill-lib` | lib | Implémenté | `0.3.6` | backfill `RawTransaction` borné via Transport observé + Store, checkpoint et runtime | -| Backfill Desk | nom à fixer | app | Retenu | `0.3.7` | contrôle/inspection du backfill RAW | +| Backfill Desk | `ksp-app-backfill-desk` | app | Implémenté | `0.3.7` | Start/monitoring/Cancel/Resume in-session du backfill RAW via façades KSP | | Worker lifecycle | `ksp-worker-api` | API | Retenu | fin couche RAW | lifecycle des services continus | | RAW worker | `ksp-worker-raw-retriever` ou nom révisé | worker | Retenu | fin couche RAW | acquisition live vers RAW | | CORE processor | nom à fixer | processor/lib | Retenu | couche CORE | normalisation Solana générique RAW -> CORE | diff --git a/docs/architecture/005-DEPENDENCY_GRAPH.md b/docs/architecture/005-DEPENDENCY_GRAPH.md index 9a94c99..3057c28 100644 --- a/docs/architecture/005-DEPENDENCY_GRAPH.md +++ b/docs/architecture/005-DEPENDENCY_GRAPH.md @@ -1,5 +1,5 @@ - + # Graphe de dépendances KSP @@ -425,16 +425,21 @@ ksp-app-solprices-desk L'application est une HID pure. Elle ne dépend d'aucun SDK provider, ne construit aucune requête HTTP provider et ne connaît ni endpoint, ni credential, ni limite provider. Les rows et actions de refresh sont alimentées par les descriptors/états/opérations génériques de `ksp-offchain-transport-lib`. -### Backfill app +### Backfill Desk ```text -backfill app - -> ksp-job-api - -> concrete backfill job +ksp-app-backfill-desk + -> ksp-core-lib -> ksp-config-lib + -> ksp-job-api + -> ksp-job-backfill-lib -> ksp-logging-lib + -> ksp-onchain-transport-lib + -> ksp-store-lib ``` +La Desk compose les ressources et contrôles du job sans traverser la façade Store : aucune dépendance directe à `ksp-store-api`, `ksp-store-postgres-lib`, `tokio-postgres`, `reqwest`, `tonic` ou `yellowstone-grpc-proto`. Le frontend ne connaît que des rôles HTTP logiques et des DTOs sûrs ; endpoints, credentials, backend Store, RAW et checkpoint concret restent sous les composants Rust propriétaires. + ### Market Desk ```text diff --git a/docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md b/docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md index 94aae45..9db3474 100644 --- a/docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md +++ b/docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md @@ -1,5 +1,5 @@ - + # Acquisition, workers, jobs et pipelines spécialisés @@ -90,6 +90,8 @@ Le job : - publie des snapshots latest-value sûrs sans payload RAW ni secrets/URLs Transport ; - n'effectue aucun décodage Program et n'écrit aucun fait CORE/DECODE/SPECIALIZED. +Le caller desktop spécialisé actuel est `ksp-app-backfill-desk`. Il compose Config, le pool HTTP et Store, puis remet ces ressources au runtime Backfill. Il peut retenir le checkpoint terminal uniquement en mémoire Rust pour un Resume in-session ; cette rétention applicative ne transforme pas le checkpoint en garantie de reprise durable après redémarrage. + ### Worker RAW live Le worker live futur : diff --git a/docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md b/docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md index d214b93..485e234 100644 --- a/docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md +++ b/docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md @@ -1,5 +1,5 @@ - + # Applications, services, scenarios et control plane @@ -77,6 +77,7 @@ Exemples de familles spécialisées : ksp-app-config-desk ksp-app-wallet-desk ksp-app-solprices-desk +ksp-app-backfill-desk ksp-app-store-desk ksp-app-worker--desk ksp-app-scenario---desk-demo @@ -106,12 +107,23 @@ ksp-app-solprices-desk -> ksp-config-lib -> ksp-offchain-transport-lib +ksp-app-backfill-desk + -> ksp-core-lib + -> ksp-config-lib + -> ksp-job-api + -> ksp-job-backfill-lib + -> ksp-logging-lib + -> ksp-onchain-transport-lib + -> ksp-store-lib + ksp-app-store-desk -> ksp-store-lib ``` `ksp-store-lib` réexporte la surface Store commune nécessaire aux applications ; une app ne dépend pas directement de `ksp-store-api` uniquement pour atteindre les modèles/capabilities, et ne dépend jamais d'une crate backend concrète. +Backfill Desk suit exactement cette règle : elle ouvre Store via `ksp-store-lib`, construit le pool HTTP via `ksp-onchain-transport-lib`, puis remet ces ressources à `ksp-job-backfill-lib`. Start/Cancel/Resume restent des opérations applicatives de composition ; le checkpoint de reprise et les ressources physiques ne deviennent jamais des DTOs Tauri. + Les couches N1–N4 expriment des responsabilités et une direction de dépendances ; elles n'imposent pas de traverser toutes les couches intermédiaires. ## Tauri diff --git a/docs/plans/028-V0_3_7_BACKFILL_DESK_PLAN.md b/docs/plans/028-V0_3_7_BACKFILL_DESK_PLAN.md index 3bf7505..4a551ce 100644 --- a/docs/plans/028-V0_3_7_BACKFILL_DESK_PLAN.md +++ b/docs/plans/028-V0_3_7_BACKFILL_DESK_PLAN.md @@ -1,5 +1,5 @@ - + # Plan v0.3.7 — Backfill Desk @@ -108,27 +108,31 @@ main Les DTOs sont possédés par l'application et dérivés TS-RS uniquement à cette frontière. -| Élément | Direction | Contenu | Validation / source de vérité | Sensibilité | -|-----------------------------|------------|-----------------------------------------------------------------------------------------------|------------------------------------------|--------------| -| `BackfillDeskOptionsDto` | Rust -> UI | réseau, rôles compatibles, commitments, scopes, bornes, readiness | Config + Transport + constantes Backfill | sûre | -| `BackfillStartRequestDto` | UI -> Rust | scope inputs, commitment, rôle, bornes, optional min context slot | conversion stricte vers types KSP | métier borné | -| `BackfillRunStatusDto` | Rust -> UI | job state, phase, compteurs, boundary, checkpoint_present, contiguous_completed, failure code | `JobNotification` | sûre | -| `BackfillCancelResponseDto` | Rust -> UI | accepted + état courant | `BackfillJobHandle` | sûre | -| `BackfillResumeResponseDto` | Rust -> UI | accepted/new job status | checkpoint Rust détenu par AppState | sûre | -| `SafeAppErrorDto` | Rust -> UI | domain/code + message app maîtrisé | mapping applicatif | sûre | +| Élément | Direction | Contenu | Validation / source de vérité | Sensibilité | +|----------------------------------|------------|-----------------------------------------------------------------------------------------------|-----------------------------------------------|--------------| +| `BackfillDeskOptionsDto` | Rust -> UI | réseau, rôles, commitments, scopes, bornes, readiness, Program IDs autocomplete | Config + Transport + Core + Backfill | sûre | +| `BackfillRequestLimitsDto` | Rust -> UI | defaults + maxima de campagne | constantes publiques Backfill | sûre | +| `BackfillStartRequestDto` | UI -> Rust | scope inputs, commitment, rôle, bornes, optional min context slot | conversion stricte vers types KSP | métier borné | +| `BackfillRequestPreviewDto` | Rust -> UI | request validée sans valeur d'adresse/signature | mapping applicatif + `BackfillRequest` | sûre | +| `BackfillStartResponseDto` | Rust -> UI | JobId backend + état initial | slot single-run | sûre | +| `BackfillRunStatusDto` | Rust -> UI | job state, phase, compteurs, boundary, checkpoint_present, contiguous_completed, failure code | `BackfillSnapshotSource` | sûre | +| `BackfillCancelResponseDto` | Rust -> UI | accepted + JobId ciblé + état | `BackfillJobHandle` | sûre | +| `BackfillResumeResponseDto` | Rust -> UI | accepted + nouveau JobId + état | checkpoint Rust détenu par `BackfillRunState` | sûre | +| `ProgramIdAutocompleteOptionDto` | Rust -> UI | program_id + metadata publiques de taxonomie | `ksp_core_lib::entries()` | publique | +| `CommandErrorDto` | Rust -> UI | domain/code + message app maîtrisé | mapping applicatif | sûre | -Commandes prévues : +Commandes finales : ```text backfill_options() -> BackfillDeskOptionsDto -backfill_status() -> BackfillRunStatusDto -backfill_start(request) -> BackfillRunStatusDto +backfill_status() -> Option +backfill_validate_request(request) -> BackfillRequestPreviewDto +backfill_start(request) -> BackfillStartResponseDto backfill_cancel(job_id) -> BackfillCancelResponseDto backfill_resume() -> BackfillResumeResponseDto -backfill_reset() -> BackfillRunStatusDto ``` -Le monitoring continu ne dépend pas du parsing de logs. Le backend possède un bridge latest-value qui attend `JobSnapshotSource::wait_for_change`, projette le snapshot et émet un événement Tauri borné, par exemple `backfill-status-changed`. `backfill_status` reste le chemin de resynchronisation initiale/explicite. +Le monitoring continu ne dépend pas du parsing de logs. Le backend possède un bridge latest-value depuis `BackfillSnapshotSource`, projette le snapshot et émet l'événement Tauri stable `ksp-backfill-status`. `backfill_status` reste le chemin de resynchronisation initiale/explicite. Aucun `BackfillCheckpoint`, `Store`, `HttpTransportPool`, sender/receiver Tokio ni payload RAW n'est sérialisé vers le frontend. @@ -314,7 +318,9 @@ La tranche `pre.015` n'ajoute aucune capacité ni aucun test. Elle matérialise ### pre.016 — réconciliation documentaire -README/USAGE/plan/validation et architecture seulement si la surface finale l'exige. Aucun nouveau runtime. +Le gate technique final `pre.015` est intégralement vert : `cargo fmt --check`, audits, `cargo check --workspace`, Clippy workspace/all-targets/all-features avec `-D warnings`, `cargo test --workspace --all-targets --all-features`, arbres Cargo ciblés, `cargo tree --duplicates` et build Tauri Linux passent. Le run workspace agrège 1 494 tests passés, 0 échec et 15 tests ignorés explicitement opt-in/operator-only ; le build produit les bundles `.deb`, `.rpm` et `.AppImage`. + +La tranche réconcilie exclusivement les documents durables : README/USAGE de Backfill Desk, index documentaires, plan/validation et architecture courante. Aucun runtime, test, frontend ou Config n'est rouvert. ### pre.017 — préparation publication diff --git a/docs/validation/000-README.md b/docs/validation/000-README.md index 711efdc..ffaca10 100644 --- a/docs/validation/000-README.md +++ b/docs/validation/000-README.md @@ -1,5 +1,5 @@ - + # Validations KSP @@ -32,3 +32,4 @@ Documents : - [`021-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT.md`](021-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT.md) — matrice finale de `0.3.4 — RawAccountState + complétude RAW` : quatre capabilities account supplémentaires, V002, pagination/idempotence et conformance Store 10/10. - [`022-V0_3_5_INTERFACE_ACQUISITION_EVENTS.md`](022-V0_3_5_INTERFACE_ACQUISITION_EVENTS.md) — matrice finale de `0.3.5 — Interface acquisition events` : événements passifs slot/transaction, façade crate-root, bornes/debug et firewall Interface. - [`023-V0_3_6_JOB_API_BACKFILL.md`](023-V0_3_6_JOB_API_BACKFILL.md) — matrice candidate de `0.3.6 — Job API + RAW transaction backfill` : lifecycle/notifications runtime-neutral, scopes, provenance, RAW v1, Store/idempotence, concurrence/checkpoint, annulation/snapshots, hardening externe et gate workspace final. +- [`024-V0_3_7_BACKFILL_DESK.md`](024-V0_3_7_BACKFILL_DESK.md) — matrice candidate de `0.3.7 — Backfill Desk` : composition Config/Transport/Store/Job, scopes et rôles HTTP, single-run, monitoring latest-value, Cancel, Resume in-session Rust-only, autocomplete Program IDs, hardening et gate workspace/Tauri final. diff --git a/docs/validation/024-V0_3_7_BACKFILL_DESK.md b/docs/validation/024-V0_3_7_BACKFILL_DESK.md index 1ddf6a4..c936886 100644 --- a/docs/validation/024-V0_3_7_BACKFILL_DESK.md +++ b/docs/validation/024-V0_3_7_BACKFILL_DESK.md @@ -1,5 +1,5 @@ - + # Validation v0.3.7 — Backfill Desk @@ -99,15 +99,15 @@ Le journal opérateur fourni rapporte `cargo clean`, `cargo fmt`, audits Rust/Ma - [X] Transport readiness et role inventory sûrs. - [X] Store readiness et cohérence réseau. - [X] Quatre scopes + commitments + bornes mappés. -- [ ] Single active run + Start. -- [ ] Snapshot latest-value bridge. -- [ ] Cancel + races terminales. -- [ ] Checkpoint/frontier projection + Resume in-session. -- [ ] Frontend/security/composition tests verts. -- [ ] `cargo test --workspace` final vert. -- [ ] `(cd crates/ksp-app-backfill-desk && cargo tauri build)` final vert. -- [ ] Smoke live opt-in exécuté si environnement sûr disponible, sinon explicitement non requis. -- [ ] Réconciliation README/USAGE/plan/validation dans sa tranche dédiée. +- [X] Single active run + Start. +- [X] Snapshot latest-value bridge. +- [X] Cancel + races terminales. +- [X] Checkpoint/frontier projection + Resume in-session. +- [X] Frontend/security/composition tests verts. +- [X] `cargo test --workspace --all-targets --all-features` final vert. +- [X] `(cd crates/ksp-app-backfill-desk && cargo tauri build)` final vert. +- [X] Smokes Mainnet opérateur antérieurs suffisants ; aucun nouveau smoke final requis. +- [X] Réconciliation README/USAGE/plan/validation/architecture dans `pre.016`. - [ ] Prompt 0.3.8 + CHANGELOG + ROADMAP uniquement dans la lane de publication. ## 9. pre.002 — scaffold desktop @@ -651,4 +651,34 @@ Un `cargo clean` préalable est optionnel : il peut être utilisé pour une reco - [X] gate final borné au workspace, arbres Cargo et build Tauri ; - [ ] gate opérateur final à exécuter ; - [ ] `pre.016` interdit tant que ce gate n'est pas intégralement vert. +## 32. `pre.015` — gate technique final + +Le gate opérateur final est intégralement vert sur `0.3.7-pre.15` : + +- [X] `cargo fmt --all -- --check` ; +- [X] audits Rust/exports/workspace et Markdown ; +- [X] `cargo check --workspace` ; +- [X] `cargo clippy --workspace --all-targets --all-features -- -D warnings` sans warning ; +- [X] `cargo test --workspace --all-targets --all-features` : 1 494 tests passés, 0 échec, 15 tests ignorés explicitement opt-in/operator-only ; +- [X] arbres normal/features de `ksp-app-backfill-desk` et `ksp-job-backfill-lib` produits ; +- [X] `cargo tree --duplicates` exécuté et revu ; +- [X] `cargo tauri build` final réussi ; +- [X] bundles Linux `.deb`, `.rpm` et `.AppImage` produits ; +- [X] aucun smoke live supplémentaire requis, les smokes Mainnet précédents ayant déjà prouvé Start, monitoring, Cancel et Resume réels. + +Aucun défaut technique n'est reporté vers la réconciliation documentaire. + +## 33. `pre.016` — réconciliation documentaire finale + +La surface candidate est réconciliée sans rouvrir le runtime : + +- [X] `crates/ksp-app-backfill-desk/README.md` décrit responsabilités, composition, frontières et build de manière durable ; +- [X] `crates/ksp-app-backfill-desk/USAGE.md` décrit l'utilisation sans journal de prerelease ni preuve de gate ; +- [X] le plan est réaligné sur les commandes réellement livrées et l'événement `ksp-backfill-status` ; +- [X] les index `docs/000-README.md` et `docs/validation/000-README.md` référencent `0.3.7` ; +- [X] l'inventaire d'architecture fixe `ksp-app-backfill-desk` comme composant implémenté ; +- [X] Layers/Contracts/Dependency Graph/Apps & Services décrivent la composition finale et les firewalls ; +- [X] README racine mentionne la surface desktop Backfill sans faire de la documentation durable un changelog ; +- [X] CHANGELOG et ROADMAP restent réservés à `pre.017` ; +- [X] aucun code, test, frontend, Config ou manifest de crate n'est modifié.