From 5c3c8b3fef16dff2536a69d2bacf20c6a193a82d Mon Sep 17 00:00:00 2001 From: SinuS Von SifriduS Date: Sat, 5 Sep 2026 17:39:50 +0200 Subject: [PATCH] v0.3.9-pre.008 --- Cargo.toml | 2 +- README.md | 6 +- crates/ksp-worker-api/README.md | 10 ++-- crates/ksp-worker-api/USAGE.md | 12 +++- deltas/0.3.9/pre.008.md | 42 ++++++++++++++ docs/000-README.md | 10 +++- docs/architecture/000-README.md | 6 +- .../009-ACQUISITION_WORKERS_AND_JOBS.md | 57 +++++++++++-------- ...9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md | 10 ++-- ...V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md | 46 ++++++++++----- 10 files changed, 145 insertions(+), 56 deletions(-) create mode 100644 deltas/0.3.9/pre.008.md diff --git a/Cargo.toml b/Cargo.toml index 662f1e4..2e25393 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -6,7 +6,7 @@ resolver = "3" members = ["crates/ksp-app-backfill-desk", "crates/ksp-app-config-desk", "crates/ksp-app-solprices-desk", "crates/ksp-app-store-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", "crates/ksp-worker-api"] [workspace.package] -version = "0.3.9-pre.7.fix.2" +version = "0.3.9-pre.8" edition = "2024" license = "MIT" repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project" diff --git a/README.md b/README.md index eb6cbc1..725c1a6 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ - + # Khadhroony Solana Project @@ -55,7 +55,9 @@ La couche RAW dispose d'une façade Store backend-neutral et d'un premier job hi `ksp-app-store-desk` fournit l'inspection desktop read-only du Store RAW via `ksp-store-lib` : health/runtime backend-neutral, tables server-side `RawTransaction` et `RawAccountState`, observations associées, détails avec previews bornées et lecture des états de rétention/tombstones. DataTables possède l'unique pagination visible de l'inspection random-access ; la pagination cursor/keyset des consumers machine reste distincte et intacte. -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. +`ksp-worker-api` fournit désormais la fondation générique des services continus : identité Worker, lifecycle borné, health/activity, intention de stop coopératif et observation latest-value. Cette API reste Core-only, runtime-neutral et sans connaissance Solana, Transport, Store ou Job. Elle ne démarre ni n'arrête elle-même un runtime concret. + +Le futur `ksp-worker-raw-transaction-ingest-lib` sera un consumer concret distinct du Job Backfill : il fonctionnera en continu entre Start et Stop, sans scope historique métier, afin d'acquérir et persister des `RawTransaction` selon les sources/capabilities configurées. `ksp-job-backfill-lib` conserve de son côté son rôle historique paramétré et borné. Les deux producteurs restent indépendants et convergent uniquement vers les mêmes contrats RAW/Store. ## Points d'entrée diff --git a/crates/ksp-worker-api/README.md b/crates/ksp-worker-api/README.md index 9687eaa..cda2b7d 100644 --- a/crates/ksp-worker-api/README.md +++ b/crates/ksp-worker-api/README.md @@ -1,9 +1,9 @@ - + # ksp-worker-api -`ksp-worker-api` fournit les contrats passifs et runtime-neutral communs aux services continus KSP. +`ksp-worker-api` fournit les contrats passifs et runtime-neutral communs aux services continus KSP. Elle décrit un Worker observable ; elle n'est ni un runtime de Worker ni une API métier d'acquisition. La crate possède l'identité logique d'un Worker, son lifecycle continu, une classification minimale de health/activity, l'intention de stop coopératif et un contrat latest-value fixe pour l'observation. Elle ne possède aucun runtime concret, aucune politique de restart, aucun Job, aucun Transport, aucun Store et aucun contrat Solana. @@ -45,9 +45,11 @@ Les mises à jour intermédiaires peuvent être coalescées : le contrat porte s `WorkerStopToken` représente uniquement une intention coopérative partagée. Il ne tue pas une tâche, ne ferme pas un socket et ne décide pas du résultat terminal. Le runtime concret observe cette intention puis pilote `WorkerLifecycle` selon sa politique de shutdown. -## Restart et contrôle +## Contrôle runtime et restart -La crate ne possède aucun `restart()`, scheduler, retry/backoff, process manager ou handle runtime générique. Un lifecycle/source terminal n'est jamais réanimé ni rebinding vers une nouvelle exécution. La recréation et la supervision appartiennent au caller ou à une couche de contrôle supérieure. +La crate ne possède aucune opération runtime générique `start()`, `stop()`, `restart()`, aucun scheduler, retry/backoff, process manager ou handle d'exécution. `WorkerLifecycle` expose uniquement les transitions d'état détenues par le producer concret ; `WorkerStopToken` exprime uniquement une intention coopérative. + +Un lifecycle/source terminal n'est jamais réanimé ni rebinding vers une nouvelle exécution. Démarrage, arrêt effectif, drain, join, recréation et supervision appartiennent au Worker concret, au caller ou à une couche de contrôle supérieure. ## Firewall diff --git a/crates/ksp-worker-api/USAGE.md b/crates/ksp-worker-api/USAGE.md index 982b356..d1f8d72 100644 --- a/crates/ksp-worker-api/USAGE.md +++ b/crates/ksp-worker-api/USAGE.md @@ -1,5 +1,5 @@ - + # Utilisation de ksp-worker-api @@ -25,8 +25,10 @@ fn worker_identity() -> ksp_worker_api::Result<(ksp_worker_api::WorkerId, ksp_wo ## Piloter un lifecycle passif +Le lifecycle ne démarre aucun runtime. L'exemple suivant représente uniquement les transitions publiées par un producer concret lorsqu'il entre en exécution : + ```rust -fn start_worker(id: ksp_worker_api::WorkerId, kind: ksp_worker_api::WorkerKindCode) -> ksp_worker_api::Result { +fn running_lifecycle(id: ksp_worker_api::WorkerId, kind: ksp_worker_api::WorkerKindCode) -> ksp_worker_api::Result { let mut lifecycle = ksp_worker_api::WorkerLifecycle::new(id, kind); if let std::result::Result::Err(error) = lifecycle.start() { return std::result::Result::Err(error); @@ -95,6 +97,12 @@ Le premier appel qui change l'intention retourne `true`. Les demandes suivantes Le token n'est pas une primitive de kill et ne garantit aucun délai de shutdown. Timeout, drain, join et retry appartiennent au runtime/caller. +## Démarrer et arrêter un Worker concret + +`ksp-worker-api` n'expose volontairement aucune commande runtime universelle. Une crate concrète peut fournir une surface `start`/`stop` adaptée à son domaine, mais elle utilise les contrats communs pour publier son identité, ses transitions, son état courant et l'intention de stop. + +Un Worker concret ne doit donc pas transformer `WorkerLifecycle` en handle d'exécution ni ajouter des paramètres métier au contrat générique. Les paramètres/configurations propres à une famille de Workers restent dans cette famille ou dans sa couche de composition. + ## Observer un snapshot latest-value Un consumer portable peut travailler directement avec le trait object-safe : diff --git a/deltas/0.3.9/pre.008.md b/deltas/0.3.9/pre.008.md new file mode 100644 index 0000000..9028f94 --- /dev/null +++ b/deltas/0.3.9/pre.008.md @@ -0,0 +1,42 @@ + + + +# Delta 0.3.9-pre.008 — réconciliation documentaire finale + +## Objet + +Fermer la réconciliation documentaire de `0.3.9` après le gate technique PASS de `0.3.9-pre.7.fix.2`, sans rouvrir le runtime. + +## Version + +```text +workspace.package.version = 0.3.9-pre.8 +``` + +## Modifications + +- `README.md` : fondation Worker API et séparation durable Worker Ingest / Job Backfill. +- `crates/ksp-worker-api/README.md` : surface finale version-neutral et distinction lifecycle/runtime. +- `crates/ksp-worker-api/USAGE.md` : exemples durables et absence volontaire de commande runtime universelle. +- `docs/000-README.md` : index du plan/validation `0.3.9` et références durables. +- `docs/architecture/000-README.md` : descriptions `009`/`011` réconciliées. +- `docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md` : Worker API réelle, producteurs RAW indépendants et lower-layer `ksp-raw-transaction-lib` cible. +- `docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md` : fermeture technique `pre.007` et lane `pre.008`. +- `docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md` : preuves opérateur finales et checklist documentaire. + +`docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md` a été relu sans modification : sa synthèse Store-centrique et ses handoffs indépendants Worker/Backfill restent autoritaires. + +## Hors périmètre + +Aucun code Rust, test, Config, Store, Transport, Job runtime, Worker concret, CHANGELOG, ROADMAP ou prompt `0.3.10` n'est modifié. + +## Validation attendue + +```bash +cargo fmt --all -- --check +python3 scripts/audit_rust_workspace_rules.py +python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas +cargo check --workspace +``` + +La tranche est documentaire hors synchronisation mécanique de version Cargo ; aucun replay du gate workspace complet n'est requis sauf défaut détecté par ces contrôles. diff --git a/docs/000-README.md b/docs/000-README.md index 7e98d75..03b4994 100644 --- a/docs/000-README.md +++ b/docs/000-README.md @@ -1,5 +1,5 @@ - + # Documentation KSP @@ -66,7 +66,8 @@ docs/ │ ├── 026-V0_3_5_INTERFACE_ACQUISITION_EVENTS_PLAN.md │ ├── 027-V0_3_6_JOB_API_BACKFILL_PLAN.md │ ├── 028-V0_3_7_BACKFILL_DESK_PLAN.md -│ └── 029-V0_3_8_STORE_DESK_PLAN.md +│ ├── 029-V0_3_8_STORE_DESK_PLAN.md +│ └── 030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md ├── validation/ │ ├── 000-README.md │ ├── 001-V0_1_4_CONFIG_DESKTOP.md @@ -93,7 +94,8 @@ docs/ │ ├── 022-V0_3_5_INTERFACE_ACQUISITION_EVENTS.md │ ├── 023-V0_3_6_JOB_API_BACKFILL.md │ ├── 024-V0_3_7_BACKFILL_DESK.md -│ └── 025-V0_3_8_STORE_DESK.md +│ ├── 025-V0_3_8_STORE_DESK.md +│ └── 026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md └── rules/ ├── FILE_CONTRACTS.md ├── PROMPT_STRUCTURE.md @@ -116,6 +118,8 @@ La taxonomie durable des rôles d'acquisition `RawTransaction`, les audits daté 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. La candidate `0.3.8 — Store Desk V1 RAW` est réconciliée dans [`plans/029-V0_3_8_STORE_DESK_PLAN.md`](plans/029-V0_3_8_STORE_DESK_PLAN.md) avec [`validation/025-V0_3_8_STORE_DESK.md`](validation/025-V0_3_8_STORE_DESK.md) : `ksp-app-store-desk` compose Config, Logging et la façade `ksp-store-lib` pour l'inspection read-only des RAW Transactions/Accounts et de leurs observations, avec DataTables server-side, counts exacts, détails bornés et séparation stricte entre inspection random-access et pagination cursor/keyset machine. [`../crates/ksp-app-store-desk/README.md`](../crates/ksp-app-store-desk/README.md) et [`../crates/ksp-app-store-desk/USAGE.md`](../crates/ksp-app-store-desk/USAGE.md) deviennent les références applicatives durables. +La candidate `0.3.9 — Worker API générique + audit RAW Transaction` est réconciliée dans [`plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md`](plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md) avec [`validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md`](validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md). `ksp-worker-api` reste Core-only et runtime-neutral pour les services continus ; l'architecture RAW place Store/`RawTransaction` au centre et sépare strictement le Job Backfill historique paramétré du futur Worker Ingest continu start/stop. [`../crates/ksp-worker-api/README.md`](../crates/ksp-worker-api/README.md), [`../crates/ksp-worker-api/USAGE.md`](../crates/ksp-worker-api/USAGE.md), [`architecture/009-ACQUISITION_WORKERS_AND_JOBS.md`](architecture/009-ACQUISITION_WORKERS_AND_JOBS.md) et [`architecture/011-RAW_TRANSACTION_ACQUISITION.md`](architecture/011-RAW_TRANSACTION_ACQUISITION.md) constituent les références durables avant la lane de publication. + ## Spécifications de formats Les formats durables, interopérables et destinés à être réimplémentables hors de KSP sont indexés depuis [`formats/000-README.md`](formats/000-README.md). [`.kspwallet` V1](formats/KSPWALLET_V1.md) reste le format JSON historique stable publié par `0.2.5`. [`.kspwallet` V2](formats/KSPWALLET_V2.md), publié stable avec `0.2.6`, ajoute le wire binaire canonique KSP, le runtime multi-version/default V2 et la migration explicite OWNER-authentifiée V1 -> V2. diff --git a/docs/architecture/000-README.md b/docs/architecture/000-README.md index 2c98531..d8756ae 100644 --- a/docs/architecture/000-README.md +++ b/docs/architecture/000-README.md @@ -1,5 +1,5 @@ - + # Architecture KSP @@ -25,8 +25,8 @@ Ils ne remplacent ni `ROADMAP.md`, ni les plans de version, ni les deltas. 6. [`006-WIRE_AND_PROGRAM.md`](006-WIRE_AND_PROGRAM.md) — propriété des contrats wire, politique de dépendances codecs/interfaces, API Program ouverte, preparation d'exécution et extensibilité externe ; 7. [`007-EXECUTION_AND_POLICY.md`](007-EXECUTION_AND_POLICY.md) — policy multi-checkpoints, orchestration transactionnelle, wallet/transport, retry, approval externe et résultat d'exécution ; 8. [`008-DATA_MATERIALIZATION_AND_STORE.md`](008-DATA_MATERIALIZATION_AND_STORE.md) — niveaux durables D1–D4, Materialization, Store PostgreSQL de référence, provenance, idempotence, replay et notifications de données persistées ; -9. [`009-ACQUISITION_WORKERS_AND_JOBS.md`](009-ACQUISITION_WORKERS_AND_JOBS.md) — pipelines spécialisés, workers live, jobs de backfill/replay, backlog, claim/lease, reprise, concurrence et mécanisme de notification de référence ; +9. [`009-ACQUISITION_WORKERS_AND_JOBS.md`](009-ACQUISITION_WORKERS_AND_JOBS.md) — séparation durable pipelines/workers/jobs, Worker API générique, producteurs RAW indépendants, reprise, concurrence et frontières de composition ; 10. [`010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md`](010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md) — apps spécialisées, workers autonomes et need-driven, control plane, scenarios réutilisables, demos desktop et frontières IPC/orchestration. -11. [`011-RAW_TRANSACTION_ACQUISITION.md`](011-RAW_TRANSACTION_ACQUISITION.md) — taxonomie durable d'acquisition `RawTransaction`, audits datés des voies Solana/providers, convergence Store et handoff Worker/Backfill. +11. [`011-RAW_TRANSACTION_ACQUISITION.md`](011-RAW_TRANSACTION_ACQUISITION.md) — synthèse Store-centrique des sources/capabilities `RawTransaction`, matrices providers/réseaux/preuves et handoffs indépendants Worker live / Backfill historique. `004-COMPONENT_INVENTORY.md` et `005-DEPENDENCY_GRAPH.md` sont maintenus ensemble : une évolution du graphe qui change le propriétaire d'une responsabilité doit corriger l'inventaire au lieu de laisser deux descriptions contradictoires. diff --git a/docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md b/docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md index a1ef81e..24bf1aa 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 @@ -55,9 +55,7 @@ persistence D1 RAW notification after commit ``` -Une crate spécialisée `ksp-pipeline-raw-ingestion-lib` peut être introduite lorsque la réutilisation worker + job le justifie réellement. - -Elle ne choisit pas le provider réseau et ne pilote pas le range historique. +La canonicalisation `RawTransaction` réutilisable entre producteurs est désormais attribuée à une lower-layer source-neutral dédiée, `ksp-raw-transaction-lib`, à matérialiser avec le Worker RAW. Elle possède uniquement la normalisation/canonicalisation commune et la construction des modèles RAW/provenance ; elle ne possède ni lifecycle Worker/Job, ni provider, ni routing réseau, ni campagne historique. ### `ksp-job-backfill-lib` @@ -136,15 +134,15 @@ Une stratégie peut donc être : - **alternative** : une source choisie à la place d'une autre ; - **complémentaire** : une source découvre une signature/slot et une autre hydrate la transaction complète ; - **redondante** : plusieurs providers/transports observent la même transaction et produisent des observations distinctes ; -- **spécialisée** : une source live, une source de catch-up/gap repair et une source historique peuvent coexister avec des responsabilités différentes. +- **spécialisée** : une source live, une voie d'hydration et une voie de continuité/gap repair du run peuvent coexister avec des responsabilités différentes. Le worker ne doit pas être réduit à un enum superficiel `Http | WebSocket | Grpc`. La configuration/runtime doit exprimer les **capacités et rôles d'acquisition réellement nécessaires** : discovery, hydration, direct full transaction, live, replay/catch-up, gap repair, filtre, finality/commitment, reprise et limites. -#### Audit obligatoire avant `0.3.10` +#### Résultat de l'audit `0.3.9` -La fin de `0.3.9`, après fermeture fonctionnelle de `ksp-worker-api`, produit un audit exhaustif servant d'entrée architecturale à `0.3.10`. Cet audit ne doit pas déformer Worker API pour le premier consumer : un besoin découvert n'est remonté dans `ksp-worker-api` que s'il est réellement générique à des services continus non Solana. +L'audit exhaustif est synthétisé dans [`011-RAW_TRANSACTION_ACQUISITION.md`](011-RAW_TRANSACTION_ACQUISITION.md). Il confirme qu'un besoin d'acquisition Solana/provider ne remonte pas dans `ksp-worker-api` : le contrat générique reste fermé et le futur Worker concret porte ses propres capabilities de sources. -L'audit doit au minimum comparer : +Les familles admises par la synthèse couvrent notamment : ```text HTTP getSignaturesForAddress + getTransaction @@ -161,7 +159,7 @@ replay/from_slot/catch-up lorsqu'une implémentation/provider le permet combinaisons multi-provider et multi-transport ``` -La liste n'est pas une promesse d'implémentation. Chaque voie est évaluée avant admission et peut être rejetée, réservée au backfill, réservée au live ou nécessiter une adaptation Transport/Config. +La présence d'une voie dans l'architecture signifie qu'elle doit pouvoir être représentée lorsque son usage est pertinent ; son implémentation, son accessibilité commerciale et sa preuve live restent des dimensions séparées. Une même famille protocolaire peut servir au Worker, au Job ou aux deux selon l'intention, sans créer de relation entre ces producteurs. Pour chaque voie, l'audit couvre au minimum : @@ -343,26 +341,24 @@ Un satellite protocolaire reste avec son groupe : Meteora vaults avec Meteora, P Le pattern latest-value de `ksp-job-api` peut être réutilisé conceptuellement lorsqu'il convient, mais Worker et Job conservent des sémantiques distinctes : un worker est un service continu qui peut rester actif indéfiniment, tandis qu'un job représente un traitement borné/terminable. Une dépendance `ksp-worker-api -> ksp-job-api` n'est pas supposée ; la réutilisation concrète doit être justifiée par un contrat réellement commun. -Concepts candidats : +Contrats communs actuels : ```text WorkerId -WorkerDescriptor +WorkerKindCode WorkerState WorkerHealth -WorkerCapabilities +WorkerActivity +WorkerLifecycle +WorkerStopToken +WorkerSnapshotSequence +WorkerSnapshot +WorkerSnapshotSource ``` -Opérations minimales candidates : +Le snapshot commun est fixe et ne porte aucun payload métier. `WorkerSnapshotSource` suit une sémantique latest-value object-safe. `WorkerStopToken` exprime une intention coopérative partagée. -```text -start -stop -status -health -``` - -Une capability comme `reconfigure` n'est pas imposée à tous les workers. +La crate n'expose aucune opération runtime universelle `start`, `stop`, `restart` ou `reconfigure`. Le Worker concret possède son runtime et traduit ses opérations de contrôle en transitions `WorkerLifecycle` et snapshots communs. ## Job API @@ -458,6 +454,8 @@ Les événements utiles comprennent notamment : ### RAW backfill +État actuel avant extraction de la normalisation commune : + ```text ksp-job-backfill-lib -> ksp-job-api @@ -466,15 +464,26 @@ ksp-job-backfill-lib -> ksp-onchain-transport-lib -> ksp-store-lib # façade Store ; default-features=false côté Job -> futures-util/tokio # runtime privé de Backfill - -> serde_json/sha2 # RAW v1 canonique + digest + -> serde_json/sha2 # RAW v1 canonique + digest actuellement locaux ``` +Cible après matérialisation de la lower-layer commune : + +```text +ksp-job-backfill-lib + -> ksp-raw-transaction-lib + -> ksp-store-lib +``` + +Le Job conserve seul ses scopes, campagnes, checkpoints et lifecycle. + ### RAW worker ```text ksp-worker-raw-transaction-ingest-lib -> ksp-worker-api -> ksp-onchain-transport-lib + -> ksp-raw-transaction-lib -> ksp-interface-lib # seulement si un fait passif partagé aide réellement la composition live -> ksp-store-lib # façade Store ; aucun backend physique direct -> ksp-logging-lib @@ -486,6 +495,8 @@ composition supérieure / future Desk -> ksp-store-lib ``` +Le Worker conserve seul son runtime continu, ses sources actives, sa continuité et son lifecycle. Il n'appelle ni ne pilote le Job Backfill. + Les événements Interface peuvent servir de signal provider-neutral à la composition live, mais ne constituent jamais le backlog durable. Après crash ou perte d'un événement, la reprise s'appuie sur Store et sur les primitives de replay/hydratation appropriées. ### CORE replay/worker @@ -516,8 +527,6 @@ selon les capacités réellement introduites. ## Questions laissées ouvertes -- nom final de la crate pipeline RAW si la réutilisation worker + backfill justifie réellement une crate dédiée ; -- taxonomie exacte des stratégies/source capabilities de `ksp-worker-raw-transaction-ingest-lib`, à décider par l'audit de fin `0.3.9` ; - politique d'alias externe `mainnet-beta` à matérialiser uniquement aux frontières qui en ont réellement besoin, sans créer une seconde identité Store ; - modèle de claim/lease PostgreSQL pour les futurs processors continus ; - taille de batch et stratégie backpressure des workers de processing ; diff --git a/docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md b/docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md index df2bc72..1d1534d 100644 --- a/docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md +++ b/docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md @@ -1,5 +1,5 @@ - + # Plan v0.3.9 — Worker API générique + audit RAW Transaction @@ -632,15 +632,17 @@ Le premier gate `pre.007` a échoué sur une canary historique de `ksp-onchain-t #### `pre.007-fix.002` — baseline Yellowstone 12.7 + adaptation des fixtures Geyser -**Statut : livré ; correctif dépendances/tests, revalidation opérateur requise.** +**Statut : livré ; revalidation opérateur PASS, gate `pre.007` fermé.** Après `fix.001`, l'opérateur choisit explicitement les baselines workspace `jsonschema = ^0.53` et `yellowstone-grpc-proto = ^12.7`. Le check workspace confirme l'adoption de `jsonschema 0.53.0`; Yellowstone 12.7 conserve les surfaces KSP utilisées mais ajoute au service protobuf `Geyser` le RPC serveur `SubscribeGossip`, ce qui rend incomplètes les deux implémentations fixtures de `unit_tests/grpc_unary.rs` et `unit_tests/grpc_stream.rs`. Le correctif implémente uniquement l'associated stream type et `subscribe_gossip` dans ces fixtures avec réponse `UNIMPLEMENTED`, sans exposer Gossip dans l'API Transport ni ouvrir une fonctionnalité `0.3.9`. Le fixture `GetVersion` est aligné sur `12.7`. Cargo devient `0.3.9-pre.7.fix.2`. +La revalidation opérateur du 5 septembre 2026 est PASS : audits Rust/Markdown propres, `cargo check --workspace`, Clippy workspace/all-targets/all-features `-D warnings`, 385/385 tests unitaires Transport, 43/43 canaries `release_completeness`, workspace complet `--all-targets --all-features`, Worker API complet et arbres Cargo jusqu'à `cargo tree --duplicates`. Les smokes live/operator-only restent uniquement `ignored` conformément à leur politique. `pre.007` est donc techniquement fermé. + ### `pre.008` — réconciliation documentaire finale -**Statut : prévu.** +**Statut : livré ; gate documentaire opérateur requis.** -Budget cible : **10-15 min**. Réconcilier README, USAGE, plan, validation et architecture avec l’état technique déjà fermé, sans nouveau runtime. +Budget cible : **10-15 min**. La tranche passe mécaniquement Cargo à `0.3.9-pre.8` et réconcilie uniquement la documentation durable avec l'état technique fermé : README/USAGE Worker API, index documentation/architecture, séparation Worker/Job et ownership de la normalisation RAW, plan et validation. Aucun runtime, test Rust, Config, Store, Transport, CHANGELOG, ROADMAP ou prompt suivant n'est modifié. ### `pre.009` — préparation de publication diff --git a/docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md b/docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md index 74e057b..0ef7472 100644 --- a/docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md +++ b/docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md @@ -1,5 +1,5 @@ - + # Validation v0.3.9 — Worker API + audit RAW Transaction @@ -297,18 +297,38 @@ Le gate n'est donc pas fermé : l'unique défaut est traité par `pre.007-fix.00 - [X] Les deux fixtures implémentent le nouveau RPC avec réponse `UNIMPLEMENTED`; aucune API Gossip de production n'est ajoutée. - [X] Le fixture `GetVersion` est aligné sur `fixture-yellowstone-12.7`. - [X] `workspace.package.version = 0.3.9-pre.7.fix.2`. -- [ ] Rejouer `cargo clippy --workspace --all-targets --all-features -- -D warnings`. -- [ ] Rejouer `cargo test --workspace --all-targets --all-features`. -- [ ] Rejouer le gate Worker/API et les arbres de dépendances avant fermeture définitive de `pre.007`. +- [X] `cargo clippy --workspace --all-targets --all-features -- -D warnings` PASS. +- [X] `cargo test --workspace --all-targets --all-features` PASS ; smokes live/operator-only explicitement `ignored`. +- [X] Gate Worker/API PASS et arbres `--edges normal`, `-e features`, `--duplicates` exécutés jusqu'à leur terme. + +### Fermeture définitive de `pre.007` + +Le gate opérateur final sur `0.3.9-pre.7.fix.2` est fermé : + +- [X] audits Rust/Markdown propres avant le gate ciblé ; Markdown 332 tables / 746 fichiers ; +- [X] `cargo check --workspace` PASS ; +- [X] Clippy workspace/all-targets/all-features `-D warnings` PASS ; +- [X] `ksp-onchain-transport-lib --lib` : 385/385 PASS ; +- [X] `ksp-onchain-transport-lib --test release_completeness` : 43/43 PASS ; +- [X] `cargo test --workspace --all-targets --all-features` PASS ; seuls les smokes/probes explicitement opt-in restent `ignored` ; +- [X] `cargo test -p ksp-worker-api` PASS : 32 tests au total, doc-tests sans échec ; +- [X] graphe normal Worker : `ksp-worker-api -> ksp-core-lib` uniquement ; +- [X] feature tree Worker : feature `default` de Core uniquement ; +- [X] `cargo tree --duplicates` exécuté jusqu'à son terme. + +Aucun défaut technique ouvert ne subsiste pour `pre.007`. ### `pre.008` — réconciliation documentaire -- [ ] Worker API README version-neutral de surface/responsabilités. -- [ ] Worker API USAGE version-neutral avec exemples réutilisables. -- [ ] Plan/validation réconciliés sur preuves réelles. -- [ ] Architectures/index docs réconciliés. -- [ ] Audit RAW final relu comme handoff 0.3.10/0.3.12. -- [ ] Aucun CHANGELOG/ROADMAP/prompt suivant finalisé ici. +- [X] Worker API README version-neutral réconcilié sur la surface/responsabilités finales. +- [X] Worker API USAGE version-neutral réconcilié avec exemples réutilisables et distinction lifecycle/runtime. +- [X] Plan/validation réconciliés sur les preuves opérateur réelles de `pre.007-fix.002`. +- [X] Index documentation/architecture réconciliés avec le plan/validation `0.3.9`. +- [X] `009-ACQUISITION_WORKERS_AND_JOBS.md` aligné sur la Worker API figée et sur `ksp-raw-transaction-lib` comme lower-layer commune cible. +- [X] Audit RAW `011` relu comme handoff indépendant `0.3.10` Worker live / `0.3.12` Backfill historique ; aucune correction de contenu nécessaire. +- [X] Aucun CHANGELOG/ROADMAP/prompt suivant finalisé ici. +- [X] `workspace.package.version = 0.3.9-pre.8`. +- [ ] Gate documentaire opérateur post-delta à exécuter. ### `pre.009` — publication @@ -328,10 +348,10 @@ Le gate n'est donc pas fermé : l'unique défaut est traité par `pre.007-fix.00 La livraison initiale `pre.001` avait conservé `workspace.package.version = 0.3.8` en suivant l’exception du prompt 028. Cette exception est supplantée par la règle normative `VER-ID-009`. -Après la synthèse multi-source `pre.006`, l'état courant est : +Après la fermeture technique `pre.007` et la réconciliation documentaire `pre.008`, l'état courant est : ```text -workspace.package.version = 0.3.9-pre.6 +workspace.package.version = 0.3.9-pre.8 ``` -`pre.002` reste la tranche non-fix `0.3.9-pre.2`. Les correctifs de conformité/compilation portent successivement `0.3.9-pre.2.fix.1` puis `0.3.9-pre.2.fix.2` conformément à `VER-ID-007` et `VER-ID-010`. `pre.003` reprend ensuite la séquence prerelease normale avec `0.3.9-pre.3`; son gate opérateur est PASS et freeze Worker API. `pre.004` poursuit avec `0.3.9-pre.4` sans changement runtime, uniquement l'audit standard Solana/KSP et la création de l'owner durable d'acquisition. `pre.005` passe à `0.3.9-pre.5` et enrichit cet owner avec l'audit Helius/Yellowstone/providers/kbot3 sans modifier le runtime. `pre.006` passe à `0.3.9-pre.6` et ferme la synthèse exhaustive possibilités/support/preuve ainsi que les handoffs `0.3.10`/`0.3.12`. `pre.006-fix.001` réécrit ensuite l'owner d'architecture comme synthèse Store-centrique et corrige la séparation Worker live / Job historique sans modifier Cargo ; `pre.006-fix.002` fixe `mainnet` comme identité canonique sans runtime. `pre.006-fix.003` matérialise finalement cette normalisation dans Config/Store/Transport/tests et porte la version Cargo `0.3.9-pre.6.fix.3`. `pre.007` ouvre ensuite le gate technique en `0.3.9-pre.7`; son premier passage révèle une canary Transport historique trop couplée au manifeste racine. `pre.007-fix.001` corrige cet ownership et porte Cargo en `0.3.9-pre.7.fix.1`. L'opérateur choisit ensuite les baselines `jsonschema ^0.53` et `yellowstone-grpc-proto ^12.7`; `pre.007-fix.002` adapte les fixtures serveur au nouveau RPC `SubscribeGossip` de Yellowstone 12.7 et porte Cargo en `0.3.9-pre.7.fix.2`. L'état précédent `0.3.9-pre.1.fix.2` reste documenté dans `pre.001-fix.002`. +`pre.002` reste la tranche non-fix `0.3.9-pre.2`. Les correctifs de conformité/compilation portent successivement `0.3.9-pre.2.fix.1` puis `0.3.9-pre.2.fix.2` conformément à `VER-ID-007` et `VER-ID-010`. `pre.003` reprend ensuite la séquence prerelease normale avec `0.3.9-pre.3`; son gate opérateur est PASS et freeze Worker API. `pre.004` poursuit avec `0.3.9-pre.4` sans changement runtime, uniquement l'audit standard Solana/KSP et la création de l'owner durable d'acquisition. `pre.005` passe à `0.3.9-pre.5` et enrichit cet owner avec l'audit Helius/Yellowstone/providers/kbot3 sans modifier le runtime. `pre.006` passe à `0.3.9-pre.6` et ferme la synthèse exhaustive possibilités/support/preuve ainsi que les handoffs `0.3.10`/`0.3.12`. `pre.006-fix.001` réécrit ensuite l'owner d'architecture comme synthèse Store-centrique et corrige la séparation Worker live / Job historique sans modifier Cargo ; `pre.006-fix.002` fixe `mainnet` comme identité canonique sans runtime. `pre.006-fix.003` matérialise finalement cette normalisation dans Config/Store/Transport/tests et porte la version Cargo `0.3.9-pre.6.fix.3`. `pre.007` ouvre ensuite le gate technique en `0.3.9-pre.7`; son premier passage révèle une canary Transport historique trop couplée au manifeste racine. `pre.007-fix.001` corrige cet ownership et porte Cargo en `0.3.9-pre.7.fix.1`. L'opérateur choisit ensuite les baselines `jsonschema ^0.53` et `yellowstone-grpc-proto ^12.7`; `pre.007-fix.002` adapte les fixtures serveur au nouveau RPC `SubscribeGossip` de Yellowstone 12.7 et porte Cargo en `0.3.9-pre.7.fix.2`. Le gate global `pre.007` est ensuite PASS. `pre.008` porte l'état documentaire candidat à `0.3.9-pre.8`. L'état précédent `0.3.9-pre.1.fix.2` reste documenté dans `pre.001-fix.002`.