khadhroony-solana-project/CHANGELOG.md

Changelog KSP

0.3.13 — convergence live multi-source du Worker RawTransaction — 2026-09-10

0.3.13 généralise ksp-worker-raw-transaction-ingest-lib de la verticale Yellowstone de 0.3.12 vers une composition caller-owned de 1..32 sources logiques appartenant au même réseau. Cinq familles live convergent désormais vers le même pipeline Common RAW / admission / Store : Yellowstone, Standard Logs avec hydration getTransaction observed, Standard Block RAW-direct, Helius transactionSubscribe avec hydration et HTTP Block Polling run-local RAW-direct. Le Worker reste sans Config, Job Backfill, backend Store physique, client réseau direct ou SDK provider parallèle.

La convergence partage un registre global d'hydration entre Yellowstone, Standard Logs et Helius afin de coalescer (network, signature, commitment) avant fan-out HTTP. Après canonicalisation, les acquisitions de même (network, signature) sont sérialisées de manière bornée : un contenu identique conserve les observations/provenances distinctes, tandis qu'une divergence devient un content_conflict terminal explicite. Aucune majorité provider, préférence silencieuse ou stratégie first-provider-wins n'est introduite. Standard Block et HTTP Block Polling admettent directement les transactions Legacy/V0/V1 qualifiées avec maxSupportedTransactionVersion = 1.

Le supervisor multi-source possède toutes les tâches et applique des bornes source-neutral sur admission, pending signals, hydrations et persistence avec une fairness minimale entre sources reference-bearing. Les snapshots agrègent activity/health/backpressure/reconnect/replay/gap sans exposer le matériau provider. La politique reste conservative : une source configurée qui échoue est terminale faute d'équivalence de coverage prouvée ; le gap repair, les rôles degraded/failover et la preuve de couverture restent donc 0.3.14. Le shutdown stop/fault/drain/abort+join est durci contre les races, leaders d'hydration abandonnés, Store lent et publications tardives.

Le gate déterministe final passe cargo fmt, audits Rust/Markdown, cargo check --workspace, Clippy workspace/all-targets/all-features avec -D warnings, cargo test --workspace --all-targets --all-features et les graphes Cargo : 1 850 tests passent, 0 échoue et 15 restent ignored opt-in/operator-only. Les smokes keyless Solana HTTP Devnet et WebSocket Devnet passent 1/1 chacun. Yellowstone provider-gated, Helius transactionSubscribe live, blockSubscribe provider dédié, HTTP polling Worker end-to-end et Worker multi-source vers Store restent explicitement non exécutés faute de gate provisionné ; aucune fixture ne les requalifie en PASS.

prompts/033-V0_3_14_START_PROMPT.md ouvre 0.3.14 exclusivement depuis le futur tag stable v0.3.13. Cette release doit fermer le gap repair/hardening multi-source limité au run actif — replay adressable, coverage redondante, scan HTTP borné, hydration de réparation, unresolved gaps et health policy — sans transformer le Worker en moteur historique ni créer de dépendance vers ksp-job-backfill-lib.

0.3.12 — Yellowstone + hydration HTTP + continuité de run du Worker RawTransaction — 2026-09-09

0.3.12 ouvre la première source réseau productive de ksp-worker-raw-transaction-ingest-lib sans remettre en cause la fondation source-neutral de 0.3.11. Le Worker dépend désormais de la façade ksp-onchain-transport-lib mais reste sans Config, Job Backfill, backend Store physique, reqwest, tonic ou proto provider direct. RawTransactionIngestRuntimeResources reçoit une source Yellowstone caller-composed et un pool HTTP cohérent ; start conserve la fondation sans source, tandis que start_with_runtime_resources lance la verticale live supervisée.

Les updates Yellowstone Transaction, TransactionStatus et les transactions incluses dans Block sont projetées vers des signaux source-neutral, coalescées de manière bornée par (network, signature, commitment), hydratées via getTransaction observed puis converties par ksp-raw-transaction-lib avant admission/persistence Store. BlockMeta et Slot restent continuity-only. La provenance composite conserve les identités logiques sûres de la source et de la route d’hydration, sans URL, secret ni payload distant. Les gardes réseau/signature/slot/index/commitment empêchent les croisements de matériau avant admission.

La release matérialise une processing frontier strictement run-local : le Worker distingue travail pending/settled, n’avance jamais au travers d’un pending plus ancien et compacte ses états sans revendiquer une preuve de complétude durable. Le reconnect/replay reste Transport-owned : from_slot et SubscribeReplayInfo ne sont pas pilotés par le Worker. Le Worker projette un état source-neutral Active/Reconnecting/Closing/Closed/Failed, compte reconnect/replay-attempt/continuity-gap et fault avec source_failed lorsqu’une hausse du gap Transport prouve que la rétention ne permet plus la reprise demandée. Aucun Backfill ou repair automatique n’est déclenché.

Le hardening final ferme les duplicate storms, saturation/coalescence, Store lent/fautif, stop/fault pendant hydration/reconnect, overflow de compteurs, abandon des pending sans faux settled, abort/join des tâches privées et absence de retry HTTP possédé par le Worker. pre.010 ajoute les canaris cross-layer Transport -> Worker -> Common RAW -> Store et verrouille les dependency firewalls, fixtures Legacy/V0, redaction et inventaires publics.

Le gate déterministe pre.011 passe rustfmt check, audits Rust/Markdown, cargo check --workspace, Clippy strict, cargo test --workspace --all-targets --all-features, les suites ciblées et les trois inspections Cargo demandées. Les smokes live keyless HTTP Devnet et WebSocket Devnet sont exécutés séparément et passent ; les smokes Yellowstone token-gated et le Worker end-to-end Yellowstone + HTTP + Store restent explicitement non exécutés faute de ressources fournies, sans faux PASS. pre.012 réconcilie ensuite README/USAGE et les architectures concernées avec cette verticale réellement matérialisée.

La suite reste découpée : 0.3.13 ajoute WS standard, Helius transactionSubscribe, HTTP live polling et la convergence multi-source ; 0.3.14 ferme le gap repair/hardening multi-source. prompts/032-V0_3_13_START_PROMPT.md ouvre 0.3.13 uniquement depuis le tag stable v0.3.12 et impose un pre.001 d’audit/sizing avant toute extension productive.

0.3.11 — Fondation runtime source-neutral du Worker RawTransaction ingest — 2026-09-08

0.3.11 introduit ksp-worker-raw-transaction-ingest-lib comme premier Worker concret KSP pour l’acquisition continue de RawTransaction, tout en fermant volontairement la release sans source réseau productive. La crate consomme ksp-worker-api, ksp-raw-transaction-lib et la seule façade ksp-store-lib; elle ne dépend ni de Config, ni d’un Job, ni d’un backend Store physique, ni encore de ksp-onchain-transport-lib. Son identité stable est raw_transaction_ingest, ses settings bornent la capacité d’admission, la concurrence de persistence et la deadline de drain, et son start utilise exclusivement le runtime Tokio actif fourni par le caller.

Le runtime possède un supervisor privé, des tâches source/persistence détenues, une admission centrale mpsc bornée avec backpressure, la canonicalisation/assembly Common RAW, une observation key déterministe et la persistence atomique en mode Normal. Les outcomes distinguent insert, idempotence et tombstone purgée ; un contenu divergent devient worker_raw_transaction_ingest.content_conflict, les erreurs Store restent classifiées sans texte distant, et aucun provider gagnant n’est choisi implicitement. Les snapshots concrets latest-value se projettent directement sur WorkerSnapshotSource, utilisent séquences/compteurs checked et conservent le terminal pour les lecteurs tardifs.

Le hardening final ferme les races stop/fault, les source failures, la saturation observable, le Store lent/fautif et le shutdown borné. À l’expiration de shutdown_drain_timeout, le Worker ferme les admissions, abort les tâches restantes, les rejoint toutes puis publie drain_timeout; aucune tâche privée ne survit au terminal. Les tests externes de hardening/release verrouillent les sept codes d’erreur publics, les huit modules de production, les vingt-quatre exports crate-root, la redaction, le dependency firewall et l’absence de surface historique/Backfill/Transport/Config/backend direct.

Le gate technique final pre.011 passe rustfmt check, audits Rust/Markdown, cargo check --workspace, Clippy strict, 56 tests Worker, cargo test --workspace --all-targets --all-features, les arbres Cargo Worker normal/features et cargo tree --duplicates. La réconciliation pre.012 ajoute ensuite les README/USAGE durables du Worker et réaligne l’architecture sur l’état matériel : la fondation 0.3.11 n’a aucun adapter HTTP/WS/Yellowstone productif, aucune API publique d’enqueue/source registration et aucun replay/gap-repair live.

La trajectoire live reste découpée : 0.3.12 ouvre Yellowstone transactions/blocks/status + hydration HTTP + continuité de run, 0.3.13 ajoute WS standard/Helius/HTTP live et la convergence multi-source, puis 0.3.14 ferme le gap repair/hardening multi-source. prompts/031-V0_3_12_START_PROMPT.md ouvre 0.3.12 uniquement depuis le tag stable v0.3.11; son pre.001 doit réauditer les surfaces Yellowstone/Solana/provider actuelles, l’injection Transport, l’hydration, le frontier, from_slot/ReplayInfo, les smokes accessibles et le sizing avant toute implémentation lourde.

0.3.10 — Lower-layer RAW Transaction commune + qualification cross-source — 2026-09-08

0.3.10 introduit ksp-raw-transaction-lib comme lower-layer source-neutral commune aux producteurs RawTransaction. La canonicalisation RAW v1 auparavant locale à ksp-job-backfill-lib est extraite sans modifier les golden bytes/hash existants ; le Backfill consomme désormais cette common crate sans créer de dépendance vers un Worker. La bibliothèque construit les modèles RawTransaction/RawTransactionObservation de ksp-store-api, conserve l'identité canonique (network, signature), borne et redacted les entrées hostiles, et reste volontairement sans Transport, Config, runtime async, Job, Worker ou backend Store physique.

La common matérialise également un wire Solana source-neutral Legacy/V0/V1 avec sérialisation Base64 et extraction de signature depuis le matériau transactionnel complet. La représentation V1 couvre header, compiled instructions, configuration V1 et signatures terminales ; les gardes structurelles rejettent les états non supportés plutôt que d'inventer une compatibilité. ksp-onchain-transport-lib ajoute get_block_observed, qui conserve l'identité sûre de la route réellement gagnante tout en réutilisant la validation getBlock existante.

Les preuves cross-source ferment explicitement ce qui est qualifié et ce qui exige encore hydration. Un blockSubscribe standard full/base64 peut produire le même RAW v1 qu'un getBlock HTTP sur le sous-ensemble déterministe prouvé. Helius transactionSubscribe reste un signal nécessitant hydration HTTP lorsque blockTime/version manquent. Yellowstone qualifie le wire Transaction V1 et la conservation du block_time dans Block, mais Transaction nécessite hydration pour le temps de bloc et le chemin Block complet reste conservateur tant que l'identité byte-for-byte entre meta protobuf et meta JSON HTTP n'est pas prouvée. Aucun RAW-direct Yellowstone complet ni feed EARLY n'est revendiqué sans preuve.

Le gate technique final pre.007 passe les audits Rust/Markdown, cargo check --workspace, Clippy workspace/all-targets/all-features avec -D warnings, cargo test --workspace --all-targets --all-features, les suites ciblées common/Transport/Backfill et les graphes Cargo demandés ; les smokes live opt-in restent ignorés conformément à leur contrat. La réconciliation pre.008 aligne ensuite la terminologie durable des couches Store sur D1 RAW -> D2 STRUCTURAL -> D3 DECODED -> D4 DOMAIN, réserve N1–N4 aux niveaux architecturaux et complète README.md/USAGE.md de ksp-raw-transaction-lib. Son gate opérateur repasse format, audits, cargo check --workspace et Clippy strict sur 0.3.10-pre.8.

Le runtime concret a été volontairement retiré de 0.3.10 après recalibrage du sizing. La trajectoire devient 0.3.11 fondation runtime/persistence déterministe, 0.3.12 Yellowstone + hydration/continuité, 0.3.13 WS standard/Helius/HTTP live + convergence multi-source, 0.3.14 gap repair/hardening/smokes, 0.3.15 Desk d'ingestion et 0.3.16 extension Backfill multi-source. Le Job historique paramétré et le Worker continu restent des producteurs indépendants du même Store.

prompts/030-V0_3_11_START_PROMPT.md ouvre 0.3.11 uniquement depuis le tag stable v0.3.10. Son pre.001 doit auditer la base réelle, le graphe de dépendances, le runtime/supervision, les bornes de channels, la persistence/déduplication déterministe, les snapshots et le dimensionnement avant toute implémentation lourde ; aucune source live complexe n'est requise pour fermer cette release.

0.3.9 — Worker API générique + audit exhaustif d'acquisition RawTransaction — 2026-09-05

0.3.9 introduit ksp-worker-api comme façade générique, courte et runtime-neutral pour services continus. La surface stable reste Core-only et expose WorkerId, WorkerKindCode, WorkerState, WorkerHealth, WorkerActivity, WorkerLifecycle, WorkerStopToken, WorkerSnapshotSequence, WorkerSnapshot, WorkerSnapshotFuture et WorkerSnapshotSource. Les identités sont bornées et redacted, le lifecycle possède des transitions explicites avec terminaux immuables, le stop token est partagé/idempotent, la séquence ne wrappe pas et le snapshot source latest-value reste object-safe, Send + Sync et implémentable depuis l'extérieur. L'API ne possède aucun runtime start/stop universel, aucune sémantique Job/checkpoint, aucun domaine Solana et aucune dépendance Transport/Store/Config/Tauri.

Après freeze de cette API, la seconde moitié de la release réalise puis consolide l'audit exhaustif des voies d'acquisition RawTransaction. Le document durable docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md est réécrit comme une synthèse unique Store-centrique : RawTransaction est le cœur RAW durable, tandis que RawTransactionObservation conserve les provenances multiples. L'audit distingue systématiquement possibilité protocolaire/provider, support architectural KSP, support implémenté et preuve live ; il couvre HTTP, WebSocket standard, Helius transactionSubscribe, Yellowstone gRPC, acquisition par blocs/slots, discovery + hydration, replay/gap repair, archives et sources EARLY/pre-execution. Les matrices recensent aussi les principaux providers/réseaux/tier/coûts connus sans réduire l'architecture aux seuls comptes gratuits actuellement disponibles.

La séparation des producteurs RAW est figée. ksp-job-backfill-lib reste un producteur historique paramétré, borné et terminable ; le futur ksp-worker-raw-transaction-ingest-lib sera un producteur live continu start/stop sans requête métier historique. Ils ne s'appellent pas, ne se supervisent pas et ne collaborent pas : chacun alimente indépendamment le même Store. HTTP, WS, gRPC, replay et archive sont des capabilities orthogonales à ces rôles ; un Worker peut utiliser HTTP pour hydration ou réparation de sa propre continuité live, tandis qu'un Job pourra utiliser gRPC/replay si une campagne historique bornée le justifie. Le handoff 0.3.10 retient ksp-raw-transaction-lib comme lower-layer source-neutral commune afin d'extraire la canonicalisation RAW v1 aujourd'hui locale au Backfill sans duplication ni edge Job ↔ Worker ; les golden bytes/hash RAW v1 doivent rester inchangés.

La release normalise aussi l'identité réseau KSP : mainnet devient l'identité canonique dans Config/Store/Transport/tests et mainnet-beta reste seulement un alias legacy/externe lorsque la frontière provider l'exige. Les données Mainnet N1 encore utilisées comme données de test ne dictent aucune compatibilité durable et aucune migration SQL n'est introduite pour préserver l'ancien libellé. Pendant le gate final, les baselines workspace sont également relevées à jsonschema ^0.53 et yellowstone-grpc-proto ^12.7; Yellowstone 12.7 ajoute le RPC serveur SubscribeGossip, ce qui nécessite uniquement l'adaptation des fixtures Geyser avec une réponse UNIMPLEMENTED et n'ouvre aucune capability Gossip de production.

Le gate technique final passe les audits Rust/Markdown, cargo check --workspace, Clippy workspace/all-targets/all-features avec -D warnings, 385/385 tests unitaires ksp-onchain-transport-lib, 43/43 canaries release_completeness, cargo test --workspace --all-targets --all-features, le bundle complet ksp-worker-api et les graphes Cargo jusqu'à cargo tree --duplicates; seuls les smokes/probes explicitement opt-in restent ignorés. La réconciliation documentaire pre.008 réaligne ensuite README/USAGE/indexes/architecture/plan/validation et son gate opérateur repasse audits Rust/Markdown plus cargo check --workspace en 0.3.9-pre.8.

prompts/029-V0_3_10_START_PROMPT.md ouvre 0.3.10 exclusivement depuis le tag stable v0.3.9. La prochaine release doit d'abord matérialiser ksp-raw-transaction-lib, migrer le Backfill vers cette canonicalisation commune sans changement fonctionnel, puis construire ksp-worker-raw-transaction-ingest-lib multi-source dès V1. Son pre.001 est obligatoirement un gate d'audit/sizing : inventaire exact des gaps Transport/Config, runtime Worker, capabilities live, continuité, preuves provider et dépendances avant toute implémentation lourde.

0.3.8 — Store Desk V1 RAW, inspection backend-neutral et trajectoire Worker multi-source — 2026-09-04

0.3.8 introduit ksp-app-store-desk, application Tauri KSP read-only dédiée à l'inspection du Store. Le package reprend le gabarit Desk commun (splash/shell/assets/styles/tracing), compose ksp-config-lib, ksp-logging-lib et la seule façade ksp-store-lib, et interdit à l'application tout accès direct à ksp-store-api, ksp-store-postgres-lib, SQL, driver/pool PostgreSQL, Transport on-chain ou ressource physique. Le bootstrap ouvre un Store lié au profil/réseau composite, expose health/runtime backend-neutral et effectue un shutdown borné à la fermeture de la fenêtre principale.

Pour éviter de détourner la pagination machine existante, Store API ajoute une primitive d'inspection backend-neutral distincte : RawInspectionPageRequest/RawInspectionPage<T>, summaries RawTransaction/RawAccountState sans gros bytes et quatre capabilities d'inspection couvrant entités et observations. Le backend PostgreSQL implémente les vues d'inspection par COUNT exact + OFFSET/LIMIT contrôlé, tandis que les queries historiques RawPage restent keyset/cursor, sans OFFSET, pour workers, backfills et replays. La façade ksp-store-lib conserve ainsi le même ensemble de 14 capabilities RAW que le backend sans exposer de détail physique.

La Desk projette RawTransaction et RawAccountState via DataTables serverSide avec un seul pager visible, filtres Store explicites, tailles de page bornées et counts vérifiés avant conversion JavaScript. Les détails sont chargés à la demande avec preview RAW bornée à 512 octets ; les rows ne transportent pas le payload transactionnel ni les bytes account. Les observations Transaction/Account sont elles aussi paginées côté serveur dans les détails et n'exposent que la provenance sûre déjà normalisée par Store API : provider/protocol/method/origin, timestamps, endpoint/session/filter/commitment optionnels, hash/taille de payload source et metadata Yellowstone account lorsqu'elle existe, jamais les bytes source. Les identifiants longs utilisent affichage tronqué, tooltip et copie explicite ; le tracing frontend reste metadata-only et ne journalise aucune valeur métier copiée.

Le hardening final fige les inventaires Cargo/npm/modules/commands/capabilities Tauri, la composition Config, l'absence de réseau/browser-storage/SQL/backend physique dans le frontend, les DTO IPC sans curseur machine et la coexistence exacte entre navigation keyset et inspection random-access. Le correctif pre.012-fix.001 réaligne aussi tsconfig.json Store Desk byte-for-byte sur le gabarit TypeScript commun des autres Desk, ce qui rétablit le build tsc && vite build des imports CSS DataTables et ajoute un canari de non-divergence.

Le gate technique autoritaire passe cargo fmt --all -- --check, audits Rust/Markdown, cargo check --workspace, Clippy workspace/all-targets/all-features avec -D warnings, cargo test --workspace --all-targets --all-features, ksp-store-lib --no-default-features, graphes Cargo et build Tauri Store Desk ; il comptabilise 1 592 tests passés, 0 échec et 15 tests opt-in/operator-only ignorés. Après la réconciliation documentaire, un rerun propre depuis cargo clean confirme encore les audits/check/Clippy/tests et reconstruit avec succès les cinq Desk KSP Config, SOL Prices, Wallet, Backfill et Store en bundles Linux .deb + .rpm, sans rouvrir le runtime.

La trajectoire suivante est explicitement redécoupée pour éviter de répéter l'hypothèse HTTP du premier backfill. 0.3.9 introduira d'abord ksp-worker-api comme abstraction générique de service continu, puis seulement après fermeture fonctionnelle de cette API produira un audit exhaustif des sources/méthodes RawTransaction. Cet audit couvrira HTTP, WS standard, extensions provider, Yellowstone gRPC, block/slot, discovery + hydration, replay/gap-repair et multi-provider, et classera les sources comme alternatives, complémentaires, redondantes ou spécialisées. Il servira d'entrée architecturale à 0.3.10, qui introduira ksp-worker-raw-transaction-ingest-lib multi-source dès V1 et ne modifiera Transport/Config que pour les adaptations réellement justifiées par l'audit. Les futures sources Helius HTTP/WS Mainnet/Devnet devront réutiliser KSP_SECRET_HELIUS_API_KEY via Config ; aucune URL Helius n'est ajoutée par 0.3.8. La terminologie mainnet/mainnet-beta sera auditée avant tout changement afin de préserver une identité KSP unique pour le même cluster.

0.3.11 ouvrira ensuite ksp-app-raw-transaction-ingest-desk, capable de choisir/superviser une ou plusieurs sources/méthodes sans dupliquer la logique du worker. 0.3.12 reviendra sur ksp-job-backfill-lib et ksp-app-backfill-desk pour ajouter les autres stratégies historiques/catch-up pertinentes issues du même audit ; la verticale getSignaturesForAddress + getTransaction de 0.3.6/0.3.7 reste une première stratégie HTTP valide, pas la définition générale du backfill KSP. kbot3 reste uniquement une référence fonctionnelle pour ces audits, jamais une source de code, DTO, Config, URL ou dépendance.

prompts/028-V0_3_9_START_PROMPT.md ouvre 0.3.9 sur cette base : Worker API doit rester Core-only/générique et être stabilisée avant l'audit RAW Transaction, lequel prépare 0.3.10 sans ajouter de worker concret ni d'endpoints provider pendant 0.3.9.

0.3.7 — Backfill Desk : contrôle, monitoring, Cancel/Resume et autocomplete — 2026-09-03

0.3.7 introduit ksp-app-backfill-desk, première application Tauri KSP spécialisée dans le contrôle d'un ksp-job-backfill-lib historique RawTransaction. L'application reste une couche de composition : ksp-config-lib possède les profils/composites/secrets, ksp-onchain-transport-lib le pool HTTP et les politiques provider/retry/rate-limit, ksp-store-lib la persistence backend-neutral, ksp-job-backfill-lib la découverte/hydratation/frontier/checkpoint/runtime et ksp-job-api le lifecycle commun. La Desk ne dépend ni d'un backend Store physique, ni de SQL, ni d'un SDK provider.

Le package reprend le gabarit Tauri KSP courant avec cible lib + bin, launcher mince, splash commun, bridge tracing, frontend sous frontend/, bindings TS-RS applicatifs, ports stricts 1436/1437 et packaging Config/Schemas distribué. Le composite cfg.composite.ksp-app-backfill-desk couvre mainnet, devnet et testnet; Mainnet est le profil par défaut et la cohérence réseau Transport/Store est vérifiée avant ouverture d'une campagne. Les profils Store committed ont été réconciliés sur TLS PostgreSQL disabled pour l'environnement local de validation, sans retirer le support verify_full du Store/schema.

Le formulaire Backfill couvre LatestAddress, BeforeAddress, AfterAddress et ExplicitSignatures, les commitments finalized/confirmed, la sélection d'un rôle HTTP logique, min_context_slot lorsque le scope l'autorise, ainsi que les bornes publiques de page/candidats/concurrence. Le frontend ne choisit ni réseau physique, ni endpoint/provider, ni JobId; le réseau dérive de la composition Store et les validations finales restent déléguées à BackfillRequest.

Le Start réel conserve un seul run actif, génère le JobId côté backend et installe le handle de contrôle avant le spawn asynchrone. Le monitoring est latest-value : BackfillSnapshotSource est projeté via l'événement ksp-backfill-status, avec commande de resynchronisation explicite et rétention du dernier terminal. La projection expose lifecycle, phase, scope, boundary, compteurs de candidats/entités/observations, missing/conflicts/holes, concurrence maximale, frontier contiguë, présence de checkpoint et codes d'échec sûrs, sans adresse/signatures de campagne, payload RAW, URL, credential, contexte d'erreur arbitraire ni cursor/checkpoint concret.

Le Cancel est coopératif, ciblé par le JobId backend et idempotent : un Cancel IPC retardé ne peut pas annuler le run suivant, un terminal gagné reste autoritaire et la fermeture de l'application bloque d'abord les nouveaux Starts puis demande best-effort l'annulation avant le shutdown Store. Le Resume est limité à la session courante : la Desk conserve en mémoire Rust la requête terminale et le checkpoint opaque, ksp-job-backfill-lib valide puis réémet le checkpoint pour un nouveau JobId sans changer le scope fingerprint/frontier, et aucun checkpoint durable n'est promis après redémarrage.

Le polish final ajoute une saisie d'adresse libre avec autocomplete HTML datalist dérivé exclusivement de ksp-core-lib::entries()/ProgramIdEntry; aucune liste de Program IDs n'est hardcodée côté frontend et la sélection n'est jamais une allow-list. Les canaris de hardening figent ensuite l'inventaire des dépendances, modules, commandes Tauri, contrôles frontend, profils Config, frontières Store/provider, sécurité IPC et discipline crate-root des DTO partagés.

Le gate final passe cargo fmt --all -- --check, audits Rust/Markdown, 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 cargo tauri build. Le run workspace enregistre 1 494 tests passés, 0 échec et 15 tests ignorés explicitement opt-in/operator-only; le build produit les bundles Linux .deb, .rpm et .AppImage.

prompts/027-V0_3_8_START_PROMPT.md ouvre 0.3.8 sur ksp-app-store-desk V1. Le gabarit, le visuel, la structure Tauri et les dépendances npm de base viennent exclusivement des Desk KSP actuelles; DataTables reprend le pattern déjà utilisé par Config/Wallet Desk. L'archive kbot3 reste obligatoire uniquement comme référence fonctionnelle/UX des anciens diagnostics et tableaux RAW : aucune source, DTO, commande, SQL, gabarit ou version npm kbot3 n'est reprise. La première tranche doit auditer les capabilities Store existantes et les gaps éventuels de listing/diagnostic avant d'ouvrir des tableaux RawTransaction, RawAccountState, observations et rétention/tombstones via la seule façade ksp-store-lib.

0.3.6 — Job API + backfill RAW historique observable — 2026-09-01

0.3.6 introduit ksp-job-api comme contrat passif et runtime-neutral pour les traitements bornés/terminables : identité JobId/JobKindCode, lifecycle explicite, annulation coopérative partagée, snapshots typés et notifications latest-value consommables par plusieurs listeners sans transformer l'API en scheduler, runtime Tokio ou bus d'événements. La surface reste Core-only et sert immédiatement au premier consumer concret ksp-job-backfill-lib.

ksp-job-backfill-lib ferme une première verticale historique RawTransaction sur les abstractions KSP existantes. Les scopes LatestAddress, BeforeAddress, AfterAddress et ExplicitSignatures sont bornés par pages/candidats/concurrence, dédupliqués de manière stable et liés à un fingerprint sémantique réseau/scope qui exclut volontairement provider, endpoint, rôle Transport et JobId. La découverte utilise les wrappers typés de ksp-onchain-transport-lib; l'hydratation passe exclusivement par get_transaction_observed, conserve la provenance du provider/endpoint gagnant et transforme la réponse en RAW v1 canonique avec hash SHA-256 exact, sans SDK provider ni modèle wire dupliqué.

La persistance passe uniquement par ksp-store-lib et son écriture atomique RawTransaction + RawTransactionObservation en mode normal. Les résultats distinguent insertion, présence idempotente, tombstone purgé, transaction manquante et conflit de contenu ; aucun read-before-write, ForceRehydrate, SQL, backend PostgreSQL direct ou décision de rétention n'est déplacé dans Job. Le réseau Store est vérifié avant écriture et l'identité logique de transaction reste (RawNetworkId, Signature) indépendamment de la source d'acquisition.

Le runtime Backfill ajoute concurrence bornée, réconciliation des terminaisons hors ordre, frontier strictement contiguë et checkpoint caller-owned. Les reprises Latest, Before, After et ExplicitSignatures ne sautent que le préfixe durable réellement prouvé. BackfillJobRuntime expose un BackfillJobHandle clonable avec annulation coopérative et BackfillSnapshotSource latest-value ; les opérations pré-Store peuvent être abandonnées, tandis qu'une persistance déjà soumise est toujours drainée avant la décision terminale. Les snapshots conservent phase, compteurs, holes/conflicts/missing, maximum in-flight, frontier/checkpoint et code d'échec sans projeter payload RAW, secret, URL ou état runtime interne.

Le hardening externe verrouille les codes d'erreur, bornes adversariales, redaction Debug, indépendance du fingerprint, absence de fuite Tokio/Futures/backend dans la façade, dépendances backend-neutral et discipline d'import/visibilité crate-root. La réconciliation documentaire finale ajoute les README/USAGE durables de Job API et Backfill et aligne les architectures Jobs/Workers/Apps sans transformer les guides d'utilisation en journal de release.

Les gates de clôture passent cargo fmt --all -- --check, audits Rust/Markdown, cargo check --workspace, Clippy workspace --all-targets --all-features -- -D warnings, cargo test --workspace --all-targets --all-features, tests ciblés Job/Backfill et graphes Cargo. Les smokes réseau/Tauri déjà explicitement opt-in restent ignorés par défaut ; aucune preuve non exécutée n'est déclarée PASS.

0.3.5 — Interface acquisition events partagés — 2026-08-31

0.3.5 étend ksp-interface-lib avec deux familles passives d'acquisition réellement partagées, sans transformer Interface en runtime, en event bus ou en seconde couche RAW. SlotLifecycleEvent expose un slot et un SlotLifecycleStage non exhaustif limité à Processed, FirstShredReceived, Completed, CreatedBank, Dead, OptimisticallyConfirmed et Rooted. La normalisation conserve la sémantique commune : les notifications Solana optimisticConfirmation et Yellowstone Confirmed convergent vers OptimisticallyConfirmed, tandis que Solana root et Yellowstone Finalized convergent vers Rooted; les différences d'ordre, de complétude, de replay et de transport restent la responsabilité du producteur/Transport.

La seconde famille matérialise le fait minimal d'exécution transactionnelle partagé par plusieurs sources. TransactionSignature possède exactement 64 octets et un Debug redacted, TransactionExecutionOutcome distingue seulement Succeeded et Failed, et TransactionExecutionEvent transporte uniquement slot + signature + outcome. Les logs, erreurs provider détaillées, commitments, indexes, timestamps, filtres et payloads complets restent Transport-owned. Les snapshots HTTP getSignatureStatuses, les transitions one-shot signatureSubscribe, un éventuel TransactionLogEvent, les votes et les entrées Yellowstone ne sont pas fusionnés artificiellement dans ce contrat.

La frontière d'ownership reste stricte : les DTOs wire/provider demeurent dans ksp-onchain-transport-lib, les événements passifs provider-neutral sont Interface-owned, et les modèles persistants/replayables RawTransaction / RawAccountState restent ksp-store-api. ksp-interface-lib conserve exactement ksp-core-lib comme seule dépendance normale, sans feature propre, dev/build dependency, serde, codec, logging ou runtime. Les canaris publics, external consumer, inventaires exacts et hardening vérifient également qu'aucun second RAW, metadata source ou payload hostile n'entre dans la surface Interface.

Les gates de clôture passent audits Rust/Markdown, cargo check --workspace, Clippy all-targets, tests ciblés Interface/Program API, cargo test --workspace et graphes Cargo. cargo tree -p ksp-interface-lib --edges normal confirme le chemin ksp-interface-lib -> ksp-core-lib -> solana-pubkey -> solana-address; le graphe features ne montre aucune feature propre Interface et les doublons éventuels restent ceux du workspace global. La documentation durable a été réconciliée et TransactionLogEvent est conservé comme idée différée soumise à un nouveau gate consumer/bornes.

prompts/025-V0_3_6_START_PROMPT.md ouvre 0.3.6 sur le développement parallèle de ksp-job-api et ksp-job-backfill-lib. La release doit reprendre fonctionnellement le backfill historique kbot3 sans en copier le code : audit obligatoire de l'archive historique, RawTransaction par adresse via getSignaturesForAddress + getTransaction, directions/anchors et déduplication, hydratation/persistence via les façades KSP, frontier/checkpoint/reprise, cancellation/concurrency bornées, idempotence et distinctions missing/conflit. ksp-job-api doit en parallèle stabiliser lifecycle/progress/outcome et un contrat de notifications/listeners borné pour qu'une couche supérieure puisse visualiser l'état sans parser les logs. Le ROADMAP enchaîne ensuite l'app de backfill/inspection 0.3.7, ksp-worker-api 0.3.8, ksp-worker-live-transactions-retriever-lib 0.3.9 puis une application de monitoring/visualisation Jobs + Workers 0.3.10, avec reprise du même pattern d'observabilité côté Worker sans fusionner les sémantiques Job/Worker/Store.

0.3.4 — Store/PostgreSQL RawAccountState + complétude RAW — 2026-08-31

0.3.4 complète la seconde vertical slice RAW physique sur le couple ksp-store-lib / ksp-store-postgres-lib et ferme la conformance PostgreSQL des 10 capabilities backend-agnostic de ksp-store-api : les six capabilities RawTransaction* acquises en 0.3.3 restent intactes et les quatre capabilities RawAccountStateRead, RawAccountStateWrite, RawAccountObservationRead et RawAccountObservationWrite sont désormais implémentées par PostgresBackend puis dispatchées par la façade Store. La séparation reste stricte : les consommateurs ordinaires passent par ksp-store-lib, le backend PostgreSQL conserve SQL/driver/pool/TLS/migrations privés, et la façade reste compilable/testable sans backend via --no-default-features.

La migration additive V002 introduit ksp_raw_account_states et ksp_raw_account_observations au-dessus de V000/V001 sans modifier leurs bytes. L'identité canonique account est (pubkey, slot, state_hash) : plusieurs états d'un même compte dans un même slot restent représentables lorsque state_hash diffère, tandis qu'une collision sur la référence complète déclenche une comparaison exacte de lamports, owner, executable, rent_epoch et data avant de conclure à l'idempotence ou à store_api.raw_conflict. Les u64 physiques utilisent NUMERIC(20,0), les clés/hashes/signatures utilisent des BYTEA de largeur contrainte, et les bytes account restent complets jusqu'à la borne KSP de 16 MiB. V002 contient exactement 32 ressources gérées et son checksum final est ff21605ed45f7ab4c0f92bbb692700b4118a9488b04d50a31d259ac59bdb550e; V000 et V001 restent respectivement d29068b8c13b9dc0cc9ef6aaadd0fa12d41e0fe4c56541a1118c4bfc846a1450 et 31488cda2f08f3f46c4cdbdbb6c18c243662fada02eac4487040c8735d72cc51.

L'acquisition RawAccountState + RawAccountObservation est transactionnelle : INSERT ... ON CONFLICT DO NOTHING, lecture/verrouillage du canonical en collision, comparaison exacte et rollback complet lorsque l'observation diverge. Une observation supplémentaire vérifie la référence existante sous transaction et ne crée jamais implicitement son state. Les métadonnées Yellowstone is_startup, transaction_signature et write_version restent optionnelles et observation-only ; aucune FK transaction n'est inventée. La navigation account utilise une keyset (slot, pubkey, state_hash) ASC/DESC, avec filtre pubkey optionnel et cursor KSPA V1 opaque de 109 octets lié au réseau, au filtre, au range, à la direction et à la famille afin d'empêcher les replays cross-query/cross-family. Aucun OFFSET, plafond métier de batch, index owner/provider/time ou lifecycle destructif account n'est introduit.

Les gates de clôture valident audits Rust/Markdown, cargo check --workspace, Clippy all-targets, tests ciblés Store/API/PostgreSQL/Config, cargo test --workspace, façade sans feature PostgreSQL et graphes Cargo. Le live postgres_raw_account_live passe sur PostgreSQL 17 avec bootstrap V000/V001/V002, round-trip des bytes et du domaine u64, idempotence/conflit, états distincts même pubkey+slot, observations/metadata optionnelles, pagination/cursors, concurrence, annulation/rollback et coexistence RawTransaction. La réconciliation documentaire finale est ensuite validée sans réouvrir code ni migrations.

prompts/024-V0_3_5_START_PROMPT.md ouvre 0.3.5 sur ksp-interface-lib uniquement. Cette release doit réauditer les surfaces d'acquisition actuelles et matérialiser seulement les modèles passifs/event-only réellement partagés, sans recopier RawTransaction/RawAccountState, sans créer un event bus et sans déplacer les DTOs provider/transport. Les candidats logs, slot/root/slotsUpdates, transaction status et vote sont traités par matrice sémantique ; une famille reste reportée si la convergence ou le consumer réel n'est pas démontré. L'archive historique kbot3 n'est pas requise pour ce gate : les sources de vérité sont la base KSP stable et les contrats officiels actuels des transports concernés.

0.3.3 — Store/PostgreSQL RawTransaction vertical slice — 2026-08-30

0.3.3 complète la première vertical slice RAW physique sur le couple ksp-store-lib / ksp-store-postgres-lib sans modifier les contrats backend-agnostic acquis dans ksp-store-api. PostgresBackend et la façade Store implémentent désormais les six capabilities RawTransactionRead, RawTransactionWrite, RawTransactionObservationRead, RawTransactionObservationWrite, RawTransactionRetentionRead et RawTransactionRetentionWrite. Une base PostgreSQL reste liée à un unique RawNetworkId par ksp_store_identity; le mauvais réseau est refusé avant I/O, les slots u64 sont conservés exactement en NUMERIC(20,0), et la migration logique V001 reste découpée en ressources tables/contraintes/indexes avec vérification de compatibilité du schéma effectif.

La persistence canonique utilise une transaction PostgreSQL unique pour RawTransaction + observation, tente l'insert sous contrainte d'unicité puis compare le contenu réel sous verrou en cas de collision : contenu identique -> idempotence, divergence -> store_api.raw_conflict. Les observations supplémentaires conservent leur provenance complète et ne créent jamais implicitement un canonical absent. La lecture reconstruit Full depuis le payload chaud et Archived depuis la relation archive ; Purged reste un tombstone minimal. La navigation est une keyset stricte (slot, signature) ASC/DESC sans OFFSET, avec cursor V1 opaque de 109 octets lié au réseau, à la direction, aux bornes et à la dernière clé. Aucun plafond métier de batch n'est introduit : seule la borne physique PostgreSQL de LIMIT requested + 1 est appliquée.

La rétention physique supportée est Full -> Archived -> Purged, sérialisée par FOR UPDATE, avec outcomes Applied, AlreadyAtTarget et ExpectedStateMismatch. Le mode normal respecte le tombstone après purge ; ForceRehydrate reste explicite et atomique. Compacted demeure volontairement non supporté physiquement et retourne store.postgres_retention_compaction_unsupported plutôt que de présenter TOAST ou une compression implicite comme contrat KSP. Les erreurs backend sont réduites à des classes/phases statiques puis projetées vers des codes Store/API stables, sans URI, SQL, SQLSTATE, bind ni texte serveur.

La preuve PostgreSQL réelle a conduit à durcir l'introspection de schéma PostgreSQL 17 : canonicalisation ciblée des CHECK numériques reconstruits par le catalogue, conservation des littéraux texte, restauration des helpers de classification de schéma et distinction d'un drift d'une migration déjà enregistrée lorsque schema_autoupdate=false. Les ressources SQL V000/V001 et leurs checksums sont restés inchangés pendant ces corrections (V000 d29068b8c13b9dc0cc9ef6aaadd0fa12d41e0fe4c56541a1118c4bfc846a1450, V001 31488cda2f08f3f46c4cdbdbb6c18c243662fada02eac4487040c8735d72cc51).

Le gate technique final pre.011 passe audits Rust/Markdown, cargo check --workspace, Clippy all-targets, les tests ciblés Store/API/PostgreSQL/Config, les tests et checks façade avec --no-default-features, cargo test --workspace et les graphes Cargo. Le live postgres_raw_transaction_live est ensuite rejoué avec succès sur PostgreSQL 17, couvrant bootstrap/drift-repair, atomicité, concurrence identique/divergente, rollback sur collision et annulation, pagination/cursor, rétention/races, ForceRehydrate et réouverture durable. Aucun build Tauri supplémentaire n'est requis : 0.3.3 ne change ni resources applicatives ni packaging desktop. RawAccountState PostgreSQL et la complétude RAW restent réservés à 0.3.4. prompts/023-V0_3_4_START_PROMPT.md ouvre cette slice suivante sur les quatre capabilities RawAccount*, une migration additive au-dessus de V000/V001, puis la conformance finale des dix capabilities RAW ; l'archive historique kbot3 y reste une source de comparaison ciblée account/observation, jamais une architecture à recopier.

0.3.2 — Store/PostgreSQL runtime foundation — 2026-08-30

0.3.2 introduit ensemble ksp-store-lib et ksp-store-postgres-lib comme fondation runtime/backend PostgreSQL au-dessus des contrats backend-agnostic de ksp-store-api, sans encore implémenter de capability RAW métier. La façade Store conserve un backend connu Postgres activé par défaut via Cargo feature, reste compilable avec --no-default-features, lie chaque instance à exactement un RawNetworkId et n'expose aucun Pool, Client, Row, Statement, driver ou SQL physique. ksp-config-lib possède désormais std.store avec trois targets nommés devnet, mainnet et testnet, chacun associé à un réseau explicite et à une URI PostgreSQL Secret indépendante ; Store/backend ne lisent directement ni .env, ni KSP_*, ni PG*, ni .pgpass.

Le backend de référence utilise tokio-postgres 0.7.18, deadpool-postgres 0.14.2, tokio-postgres-rustls 0.14.0, Rustls 0.23 avec roots système/AWS-LC et des modes TLS KSP limités à Disabled et VerifyFull. Les URI sont parsées puis normalisées sous la policy typée KSP, le pool et les deadlines connect/wait/create/recycle/shutdown sont bornés, et une ouverture réussie exige une connexion physique puis un bootstrap valide. Le moteur de migrations privé commence par V000__bootstrap.sql, enregistre version/nom/SHA-256 dans ksp_store_schema_migrations, sérialise les runners par advisory transaction lock borné et refuse checksum mismatch ou schema plus récent sans down automatique. La façade fournit également runtime_snapshot() et health().await avec une projection portable/redacted de readiness et des compteurs pool sûrs.

Les canaris de hardening verrouillent 84 exports crate-root côté façade, la frontière backend/Config, l'absence de bypass environnement, la redaction des URI/erreurs, la matrice de features et l'absence de persistence RawTransaction/RawAccountState. Le gate technique final a été rejoué après cargo clean : audits Rust/Markdown, cargo check --workspace, Clippy, tests ciblés de toutes les crates, cargo test --workspace, graphes Cargo et les trois builds Tauri Linux passent. Le smoke PostgreSQL réel passe sur PostgreSQL 17 et prouve bootstrap initial/idempotent/concurrent, mismatch/recovery checksum, rollback transactionnel, health Ready et fermeture bornée ; la policy de fondation reste PostgreSQL >= 15 sans maximum KSP artificiel.

prompts/022-V0_3_3_START_PROMPT.md ouvre ensuite uniquement la vertical slice PostgreSQL RawTransaction complète sur les mêmes crates et la même fondation : six capabilities transaction/observation/rétention, atomicité, idempotence/conflit, get/list cursorisé, tombstone et ForceRehydrate. RawAccountState PostgreSQL et la complétude RAW restent réservés à 0.3.4. L'archive historique khadhroony-bot3_v0.5.3-pre.005-fix010.zip reste obligatoire au pre.001 de 0.3.3, mais seulement pour réauditer l'ancien schéma/repository RAW transaction comme source d'héritage, jamais comme autorité KSP.

0.3.1 — Store API RAW foundation — 2026-08-29

0.3.1 introduit ksp-store-api comme contrat backend-agnostic de persistence N1 RAW, sans runtime Store ni backend physique. La release stabilise deux familles réellement convergentes : RawTransaction avec payload canonique opaque/versionné, identité réseau+signature et observations d’acquisition séparées, puis RawAccountState avec bytes complets, identité réseau+pubkey+slot+hash et observations pouvant conserver les enrichissements Yellowstone sans les confondre avec l’état canonique. TransactionStatusObservation reste reporté faute de convergence sémantique suffisante entre snapshot HTTP, transition WebSocket et update Yellowstone ; logsSubscribe, slot/root/slotsUpdates et vote restent event-only candidats, RawBlock reste une idée conditionnelle et Yellowstone Entry reste rejeté de la taxonomie active.

La façade publique conserve un modèle objet sans SQL ni rows backend, des primitives de provenance/hash/timestamps bornées, des queries cursorisées sans plafond métier KSP arbitraire, des outcomes d’idempotence/conflit, dix capabilities fines object-safe et un lifecycle logique de rétention transactionnelle Full -> Compacted -> Archived -> Purged. Le tombstone minimal empêche le rebackfill normal après purge tandis que ForceRehydrate reste une intention distincte ; une course de compare-and-transition est représentée par ExpectedStateMismatch plutôt que par un overwrite silencieux. Le backlog, le batch-size, la priorité, la policy de processing, la compression/archive physique, les notifications runtime et les couches STRUCTURAL/DECODED/DOMAIN restent hors Store API. Le graphe normal final de ksp-store-api reste strictement limité à ksp-core-lib; aucun PostgreSQL, Tokio, serde, Config, Transport, Program, Logging ou backend concret n’entre dans la crate.

Les canaris de clôture verrouillent 60 exports crate-root, 10 capabilities, l’inventaire exact des modules RAW, l’implémentabilité par un backend externe, les bornes adversariales, la redaction des Debug, la frontière Interface/Store et l’absence de surface N2/N3/N4. Le gate technique de référence a été exécuté après cargo clean et passe audits Rust/Markdown, cargo check --workspace, Clippy, tests ciblés des crates, cargo test --workspace, builds Tauri des trois Desk et graphes Cargo ; les gates documentaires suivants restent également verts. Le redécoupage final prépare trois releases Store/PostgreSQL où ksp-store-lib et ksp-store-postgres-lib avancent toujours ensemble : 0.3.2 pour la fondation runtime/backend, 0.3.3 pour la vertical slice RawTransaction, puis 0.3.4 pour RawAccountState et la complétude RAW. prompts/021-V0_3_2_START_PROMPT.md ouvre donc uniquement la fondation conjointe Store/PostgreSQL, avec tokio-postgres comme driver retenu mais pooling, TLS, migrations et Config à réauditer avant implémentation lourde.

0.2.14 — Program API foundation — 2026-08-28

0.2.14 introduit ksp-program-api comme première API publique extensible du domaine Program, volontairement limitée au décodage d’instructions et indépendante des runtimes supérieurs. La façade réexporte les contrats Core/Interface nécessaires puis possède ProgramInstructionRecognition (NoMatch, ProgramMatch, ExactMatch), ProgramInstructionDecodeOutcome<Decoded> (Decoded, Unsupported) et le trait ProgramInstructionDecoder: Send + Sync. L’output Decoded reste possédé par l’implémentation et ne reçoit aucun bound implicite Debug, Clone, Send ou Sync; les erreurs réelles restent dans le Result Core. Les Program IDs sont des Pubkey opaques : une implémentation externe peut prendre en charge un programme absent du registry Core sans enum centrale fermée, Any, JSON, descriptor global ni registry runtime.

Le graphe normal final reste strictement ksp-program-api -> ksp-core-lib + ksp-interface-lib, Interface dépendant elle-même de Core. Aucun ksp-program-lib, codec, serde, logging, réseau, filesystem, environnement, Store, Materializer, Wallet, Config ou Tauri n’entre dans cette foundation. Les canaris public API, implémentation externe, dependency firewall, release completeness et hardening couvrent notamment l’inventaire exact de dix exports crate-root, les trois modules de production, un Program Pubkey non enregistré, l’input Interface maximal de 255 accounts / 10 240 bytes, l’absence d’echo automatique d’un payload hostile et l’absence de claim dyn hétérogène. pre.005-fix.001 corrige uniquement un faux positif cross-crate du scanner Logging provoqué par le motif de test recherché, sans changement fonctionnel. Les gates pre.006 et pre.007 passent ensuite audits Rust/Markdown, cargo check, Clippy, les 18 tests Program API, ownership Logging et le workspace complet avant la réconciliation documentaire finale.

prompts/020-V0_3_1_START_PROMPT.md ouvre 0.3.1 — Store RAW foundation exclusivement depuis le tag stable v0.2.14. Le gate pre.001 exige également l’archive historique khadhroony-bot3_v0.5.3-pre.005-fix010.zip afin d’auditer l’ancien ks-store, ses migrations PostgreSQL et ses contrats N1/N2/N3 sous une matrice REPRENDRE / REDESSINER / REPORTER / REJETER. L’archive reste une source historique uniquement : 0.3.1 doit créer ksp-store-api et ksp-store-lib avec PostgreSQL de référence et persistence RAW seulement, sans aspirer les contrats CORE/DECODE/SPECIALIZED, les jobs/workers, l’Interface 0.3.2 ni la configuration produit.

0.2.13 — Interface / wire foundation — 2026-08-28

0.2.13 introduit ksp-interface-lib comme première façade wire officielle KSP, volontairement passive et Program-facing. La surface stable réexporte le Pubkey canonique de Core, ajoute ProgramAccountMeta et ProgramInstruction à champs privés avec accessors explicites, conserve l’ordre et les doublons des account metas, accepte les Program Pubkeys opaques et borne l’admission à 255 account metas et 10 240 octets de data. Les deux bornes sont des limites d’admission Interface et ne prétendent pas garantir à elles seules le fit d’une transaction Solana top-level. Les erreurs réutilisent le contrat Core Error/Result avec uniquement field, actual_len et maximum_len, tandis que le Debug de l’instruction n’expose que program_id, account_count et data_len.

La dependency direction finale reste strictement ksp-interface-lib -> ksp-core-lib -> solana-pubkey. Aucun serde, codec générique (borsh, wincode, bincode), solana-instruction, runtime réseau ou logging n’est ajouté à cette foundation. Les canaris public API, consumer externe, dependency firewall et release completeness verrouillent les six exports crate-root, les quatre modules de production, l’absence de narrowing/codec caché, le transfert des Vec admis sans réallocation interne et la non-répétition de matériel hostile dans les erreurs. pre.005-fix.001 corrige uniquement un faux positif du scanner Logging provoqué par le littéral de test tracing::, sans changement de production ni de dépendance. Les gates pre.006 et pre.007 passent ensuite audits Rust/Markdown, cargo check, Clippy, tests Interface, ownership Logging, workspace complet et graphes Cargo avant la réconciliation documentaire finale.

prompts/019-V0_2_14_START_PROMPT.md ouvre 0.2.14 — Program API foundation exclusivement depuis le tag stable v0.2.13. Le gate pre.001 de cette prochaine release exige aussi l’archive historique khadhroony-bot3_v0.5.3-pre.005-fix010.zip afin d’auditer les anciens contrats decoder/executor sous une matrice REPRENDRE / REDESSINER / REPORTER / REJETER, sans faire de kbot3 une autorité architecturale ni recréer son monolithe ks-lib.

0.2.12 — SOL Prices Desk + projection prix Wallet — 2026-08-27

0.2.12 ajoute ksp-app-solprices-desk, troisième Desk Tauri spécialisé de KSP, comme HID strictement provider-neutral au-dessus de ksp-offchain-transport-lib. Son composite dédié sélectionne std.logging et std.offchain_transport; la vue Prices expose l’inventaire des huit providers SOL/USD, disponibilité, sémantique, auth, prix exact sous forme de chaîne, timestamps provider/KSP distincts et retry deadline sans inventer de fraîcheur. Les refresh manuel individuel, sélectionné et global passent exclusivement par MarketPriceService; les batchs sont bornés à 1..=64, les états in_flight restent backend-owned et aucun polling, scheduler, fallback, moyenne ou prix canonique n’est introduit dans le Desk. Le frontend conserve l’absence de réseau/persistence navigateur et journalise les interactions sans prix, credential, URL, header ou payload provider.

La même release étend ksp-app-wallet-desk de façon volontairement minimale. Le refresh de balance lance getBalance et le refresh SOL/USD générique, puis calcule côté Rust une moyenne arithmétique uniquement à partir des observations réussies du refresh courant et l’équivalent USD exact du solde, sans f64/f32. Le prix reste auxiliaire : une indisponibilité Off-chain n’invalide jamais une balance Solana réussie et produit simplement N.A.. Le Wallet ne connaît aucun provider concret, n’expose aucune commande Market Price dédiée au frontend et n’ajoute aucune valorisation persistée ou logique de consensus.

Le hardening final ajoute une garde IPC hostile avant parsing pour les sélections de plus de 64 providers, un smoke live de composition SOL Prices composite -> Config -> MarketPriceService -> refresh_all, les canaris de frontières et les builds Tauri Linux. pre.009-fix.001 corrige en outre la politique de version desktop : la version KSP/bundle est Cargo-owned, tauri.conf.json omet désormais version et les package.json privés ne sont plus forcés à suivre chaque bump workspace. Le gate opérateur passe audits Rust/Markdown, cargo check, Clippy, tests ciblés, cargo test --workspace, smoke live, puis builds .deb/.rpm/.AppImage pour SOL Prices, Wallet et Config Desk.

La clôture documentaire réconcilie README/USAGE, architectures, plan et validation, puis prépare prompts/018-V0_2_13_START_PROMPT.md. Ce prompt ouvre 0.2.13 — Interface foundation exclusivement depuis le tag stable v0.2.12. Une reconnaissance préalable de l’archive historique khadhroony-bot3 fournit des idées de contrats wire et d’extension, mais 0.2.13-pre.001 doit les réauditer contre l’architecture KSP actuelle avant toute implémentation : ksp-interface-lib porte les données/wires publics, ksp-program-api reste réservé au comportement extensible de 0.2.14, et les implémentations officielles ksp-program-lib arrivent plus tard.

0.2.11 — Off-chain price transport — 2026-08-26

0.2.11 crée ksp-offchain-transport-lib avec une première surface volontairement bornée à SOL/USD et huit adapters REST V1 : CoinGecko, CoinMarketCap, CoinPaprika, Kraken, Coinbase Exchange, Jupiter Price V3, Birdeye et DexScreener. Les adapters utilisent reqwest directement, sans SDK provider, avec origines HTTPS possédées par la crate, DTOs wire privés et prix normalisés par MarketPriceDecimal sans passage canonique par f64. MarketPriceObservation conserve paire, sémantique, provenance et timestamps réellement disponibles afin de ne pas confondre prix agrégé, dernier trade d'exchange, heuristique Solana, spot provider et prix DEX pair. DexScreener exige une paire Solana explicite et ne réalise aucune discovery ou sélection automatique de pool.

La crate possède désormais le registry provider-neutral, les descriptors/capabilities, les limites et quotas informatifs, les états MarketPriceProviderAvailability, le cooldown et le service générique MarketPriceService. Les consumers disposent de registry, refresh, refresh_many et refresh_all; le batch V1 reste séquentiel et déterministe, ne dort jamais pour attendre un rate limit et n'introduit ni fallback, ni consensus, ni moyenne KSP. Les erreurs provider sont normalisées en états génériques et les credentials/endpoints/raw bodies restent absents des projections et diagnostics publics.

Config ajoute std.offchain_transport V1, son schema, les profils public_keyless et all_free, ainsi que ResolvedOffchainTransportConfig qui construit le service sans dépendance inverse. Les credentials CoinGecko/CoinMarketCap/Jupiter/Birdeye restent sous KSP_SECRET_*; la paire DexScreener utilise une provenance KSP_PUBLIC_*. Les deux applications desktop existantes embarquent les nouvelles resources Config sans encore consommer fonctionnellement le prix. Les canaris de sécurité verrouillent notamment l'absence d'URL/rate-limit provider configurable au-dessus de Config, de lecture directe d'environnement dans Off-chain Transport et de fuite de clés par Debug.

Le gate technique final a passé les audits Rust/Markdown, cargo check, Clippy, les tests ciblés Config/Off-chain, le workspace complet et les graphes Cargo. Le premier smoke live keyless a isolé une erreur de query CoinMarketCap (ids=5426 au lieu de id=5426); pre.011-fix.001 la corrige pour les modes Keyless et Basic, puis le re-smoke passe 7/7 providers keyless. Le smoke keyed Birdeye/CoinGecko Demo/CoinMarketCap Basic/Jupiter Free reste explicitement SKIP opérateur. prompts/017-V0_2_12_START_PROMPT.md ouvre ensuite 0.2.12 — SOL Prices Desk + intégration prix Wallet Desk uniquement depuis le tag stable v0.2.11, avec audit/sizing desktop strict avant toute implémentation UI lourde.

0.2.10 — OrbitFlare Yellowstone gRPC — 2026-08-25

0.2.10 ajoute OrbitFlare comme provider Yellowstone gRPC sur le moteur N1 et le standard N2 acquis dans 0.2.9, sans modifier le moteur gRPC ni créer de façade provider inutile. L'audit et le smoke live ont établi le contrat réel du service Solana Free Devnet : endpoint http://devnet.rpc.orbitflare.com:10000, authentification par metadata gRPC secrète x-token portant la License Key OrbitFlare, et émission du Ping Yellowstone standard. Config Transport V3 représente ce provider avec provider = orbitflare, cluster = devnet, protocol = solana_yellowstone et secret_metadata, tandis que .env.example inventorie KSP_SECRET_ORBITFLARE_DEVNET_GRPC_X_TOKEN sans valeur réelle.

La première tentative live sans metadata a volontairement échoué avec Unauthenticated, ce qui a conduit à pre.002-fix.001 après audit des sources OrbitFlare actuelles. Le smoke corrigé reçoit la License Key uniquement par stdin opérateur, ouvre Subscribe, observe un Slot non nul et un SubscribeUpdate::Ping, puis ferme la session proprement. Le même smoke est repassé au gate technique final pre.003. La clôture conserve donc N1/N2 inchangés, n'ajoute ni heartbeat OrbitFlare, ni SDK provider, ni Config V4, et confirme que la réponse automatique au Ping standard existante suffit.

Le gate final conserve l'ensemble du workspace vert : audits Rust/Markdown, cargo check, Clippy, tests Config et Transport, cargo test --workspace, canaris de dépendances et graphes Cargo. Helius LaserStream gRPC, audité comme largement wire-compatible Yellowstone mais non raisonnablement live-testable sans abonnement payant, est reporté dans les TODO provider sans numéro de release. La séquence active passe donc à 0.2.11 — off-chain price transport; prompts/016-V0_2_11_START_PROMPT.md l'ouvre exclusivement depuis le tag stable v0.2.10 avec audit actuel des sources de prix, de leurs sémantiques et de leur testabilité avant toute implémentation lourde.

Ce changelog résume uniquement les releases KSP considérées comme stables, dans l'ordre chronologique décroissant. Les détails de chaque livraison restent dans deltas/.

0.2.9 — Yellowstone gRPC standard/provider-neutral — 2026-08-24

0.2.9 ajoute à ksp-onchain-transport-lib un moteur Yellowstone gRPC partagé construit directement sur Tonic/Protobuf, avec yellowstone-grpc-proto comme contrat wire upstream et sans yellowstone-grpc-client dans le runtime KSP. La surface Solana standard reste provider-neutral et couvre les sept unary retenues (SubscribeReplayInfo, Ping, GetLatestBlockhash, GetBlockHeight, GetSlot, IsBlockhashValid, GetVersion), Subscribe bidi, les familles accounts/slots/transactions/transaction status/blocks/block meta/entry, les neuf variantes d'update standard retenues, les filtres/common fields actuels, le backpressure, les limites de messages, le half-close/shutdown, ainsi qu'un reconnect/replay prudent depuis le dernier slot observé. Aucune garantie exactly-once, lossless ou d'ordre global gapless n'est introduite ; gaps et duplicates restent observables. SubscribeDeshred reste explicitement hors du standard KSP de cette release.

Config passe à std.transport V3, backward-readable avec V1 HTTP et V2 HTTP+WebSocket, et sépare les axes provider / protocol ainsi que metadata / secret_metadata sans créer de dépendance Transport -> Config/env. PublicNode constitue la première intégration provider : profils Yellowstone Mainnet et Testnet sur https://solana-yellowstone-grpc.publicnode.com:443 et https://solana-testnet-yellowstone-grpc.publicnode.com:443, avec authentification x-token résolue par Config depuis des variables KSP_SECRET_*. Le smoke Transport pur reçoit les credentials uniquement par stdin opérateur, n'en journalise aucun et valide en live Subscribe -> Slot sur les deux réseaux ; le même personal token a été utilisé avec succès pour Mainnet et Testnet, tout en conservant deux entrées Config distinctes par flexibilité opérationnelle.

La clôture conserve les surfaces antérieures HTTP (52 current typed + 14 historiques), WebSocket Solana standard (9 familles / 18 opérations) et Helius LaserStream WebSocket. Le gate final comprend 383/383 tests unit Transport, 49/49 public API, 43/43 release completeness, 4/4 doctests, cargo test --workspace, les canaris de dépendances, le smoke PublicNode live 2/2 PASS et l'inspection des graphes Cargo (yellowstone-grpc-proto 12.6.0, tonic / tonic-prost 0.14.6, prost / prost-types 0.14.4). prompts/015-V0_2_10_START_PROMPT.md ouvre ensuite 0.2.10 — OrbitFlare Yellowstone gRPC uniquement depuis le tag stable v0.2.9, avec audit provider actuel, threat model et sizing en pre.001 avant toute extension provider lourde.

0.2.8 — Helius LaserStream WebSocket — 2026-08-23

0.2.8 étend ksp-onchain-transport-lib avec une façade HeliusLaserStreamWsSession dédiée qui réutilise le même WsSession physique/actor que le WebSocket Solana standard, sans second client, socket, registry ou scheduler. La surface stable Helius réutilise les sept familles standard actuellement retenues (account, logs, program, root, signature, slot, slotsUpdates) et ajoute l’extension typée transactionSubscribe / transactionUnsubscribe; block et vote restent absents de la façade Helius et slotsUpdates conserve son statut unstable. Le heartbeat provider est possédé par l’actor partagé et émet un WebSocket Ping control frame toutes les 60 secondes uniquement pour WsProtocolKind::HeliusLaserStream.

La release ajoute le mapping Config V2 helius_laserstream, les profils Helius mainnet/devnet et le secret KSP_SECRET_HELIUS_API_KEY avec provenance/redaction segmentaire, sans dépendance inverse Transport -> Config ni lecture directe de l’environnement par Transport. Les canaris couvrent erreurs RPC provider, payload oversized, mismatch de notification, reconnect/remap/unsubscribe races, backpressure isolé et diagnostics sans payload brut. La compliance finale conserve simultanément 52 méthodes HTTP courantes + 14 historiques, 9 familles / 18 opérations WebSocket Solana standard, et la surface Helius 7 standard + transaction. Le smoke Helius live cross-crates est volontairement reporté vers une future surface d’intégration/orchestration afin de préserver l’ownership Config du secret. Les graphes Cargo finaux n’introduisent aucun SDK Helius/gRPC ni nouvelle duplication bloquante. prompts/014-V0_2_9_START_PROMPT.md ouvre ensuite 0.2.9 — Yellowstone gRPC standard/provider-neutral uniquement depuis le tag stable v0.2.8, avec audit service/proto/crates/licences/MSRV/features et sizing strict en pre.001 avant toute implémentation lourde.

0.2.7 — WebSocket Solana standard — 2026-08-23

0.2.7 stabilise dans ksp-onchain-transport-lib le moteur WebSocket Solana standard en complément de la surface HTTP déjà complète. La release couvre exactement les 9 familles subscribe + 9 unsubscribe de l’inventaire officiel ciblé : account, block, logs, program, root, signature, slot, slotsUpdates et vote. Les wrappers sont typés, les IDs KSP de session/subscription restent locaux et stables, les IDs serveur restent internes/remappables, et plusieurs sessions physiques peuvent coexister explicitement sur la même URL sans introduire de pool/scheduler automatique. Les familles block, slotsUpdates et vote restent identifiées comme unstable selon l’audit normatif courant et utilisent le warning KSP centralisé.

Le lifecycle WebSocket est borné : actor unique propriétaire du socket, pending JSON-RPC et queues de notifications bornés, WsSession::close().await, control frames Ping/Pong/Close, reconnect fini avec backoff borné, resubscribe déterministe par ID local, continuity_gap_count, isolation des erreurs applicatives et du backpressure par subscription, nettoyage des late ACK/notifications et terminaison one-shot de signatureSubscribe. Config passe à std.transport V2 pour composer HTTP + WebSocket tout en gardant la lecture V1 HTTP-only ; la direction reste Config -> Transport. La compliance finale conserve simultanément 52 méthodes HTTP courantes + 14 historiques, les canaries Transport (309 unit, 36 public API, 24 release completeness), le smoke WebSocket Devnet opt-in slotSubscribe -> notification -> unsubscribe -> close, les frontières de dépendances et la redaction des URLs/credentials. prompts/013-V0_2_8_START_PROMPT.md, renforcé par 0.2.7-pre.014-fix.001, ouvre ensuite 0.2.8 — Helius LaserStream WebSocket uniquement depuis le tag stable v0.2.7.

0.2.6 — Wallet Desk + .kspwallet V2 — 2026-08-22

0.2.6 stabilise ksp-app-wallet-desk comme seconde application Tauri KSP spécialisée et étend ksp-wallet-lib avec le wire binaire .kspwallet V2. Wallet Desk compose Config, Wallet, Transport HTTP et Logging sans déplacer leurs responsabilités : inventory root-scoped et symlink-safe, création/import V2 par défaut, ouverture VIEW/OWNER V1/V2, candidats secrets résolus exclusivement par Config, getBalance Devnet via Transport, administration alias/notes, rotations OWNER/VIEW, disable/recreate VIEW fort et export Solana CLI JSON/Base58. Les secrets, keypairs, handles, chemins complets import/export et credentials Config restent côté Rust ; le frontend ne reçoit que des projections sûres et utilise des modals Bootstrap pour les opérations privilégiées.

Le format V1 JSON reste stable et lisible ; V2 ajoute un framing binaire KSP canonique, des IDs numériques, longueurs big-endian et domains/transcripts distincts tout en conservant Argon2id, XChaCha20-Poly1305 et l'autorité Ed25519 OWNER. Les APIs génériques créent/importent explicitement en V2 et auto-détectent V1/V2 à la lecture, tandis que les variantes _v1/_v2 imposent un format exact et que DEFAULT_WALLET_FORMAT reste indépendant de LATEST_SUPPORTED_WALLET_FORMAT. La migration V1 -> V2 est explicite, OWNER-authentifiée, no-clobber ou atomique in-place avec protection stale-state ; aucune ouverture ne migre silencieusement. La release ferme également le runtime Tauri distribué : les documents Config/schemas sont embarqués comme resources, ksp-config-lib prépare une racine KSP user-writable commune sans écraser les Config utilisateur ni embarquer .env, et les bundles Linux .deb, .rpm et .AppImage ont été produits avec succès après le gate final pre.018-fix.001. Le prompt prompts/012-V0_2_7_START_PROMPT.md ouvre 0.2.7 — WebSocket Solana standard par lectures, audit officiel, threat-model et sizing avant implémentation lourde.

0.2.5 — Wallet foundation — 2026-08-20

0.2.5 publie ksp-wallet-lib et le format natif interopérable .kspwallet V1. La release stabilise les capacités cryptographiquement indépendantes VIEW/OWNER, le masquage de la Pubkey/alias/notes à l’état verrouillé, Argon2id v19 avec paramètres sérialisés et profil de création 65 536 KiB / 3 / 1, XChaCha20-Poly1305, une autorité Ed25519 OWNER distincte de la keypair Solana, les compartiments owner_control/metadata/secret, la création et l’ouverture mémoire/fichier, la persistence no-clobber, la signature Solana OWNER sans getter secret, l’administration alias/notes, les rotations OWNER/VIEW, la révocation forte VIEW avec rekey metadata, la détection de handles stale et les adapters Solana CLI JSON/Base58 pour inspection/import/export. Le wire V1 est documenté indépendamment de Rust dans docs/formats/KSPWALLET_V1.md et couvert par des vecteurs publics ainsi que des canaris adversariaux et une reproduction externe. La release conserve Wallet indépendant de Config/Transport/ExecutionPolicy/Store/Tauri et expose la Pubkey via ksp-core-lib tandis que solana-keypair reste encapsulée dans Wallet.

La clôture technique pre.010-fix.001 à fix.003 met la dépendance directe KSP à ed25519-dalek 3.0.0, accepte la génération 2.2.0 transitive encore imposée par solana-keypair 3.1.2, normalise les sources Rust du workspace et introduit python3 scripts/audit_rust_workspace_rules.py comme gate structurel complémentaire à rustfmt/Clippy. Le checkpoint final pre.010-fix.003 est validé avec audit Python clean, cargo check, Clippy, tests Wallet et workspace complet verts. Le prompt prompts/011-V0_2_6_START_PROMPT.md ouvre ensuite 0.2.6 — Wallet Desk par audit/sizing avant implémentation.

0.2.4 — HTTP Blocks + Economics + compliance HTTP finale — 2026-08-18

0.2.4 achève la surface HTTP Solana standard de ksp-onchain-transport-lib : les 10 wrappers Blocks et 5 wrappers Economics portent la couverture typée à 52/52 méthodes HTTP courantes, tandis que les 14/14 méthodes historiques Deprecated/runtime Removed restent conservées pour compliance. La release stabilise notamment getBlock moderne avec sa forme bare encoding legacy dépréciée, les quatre variantes transactionDetails, les versions transaction numériques génériques, numRewardPartitions (SIMD-0118), commissionBps (SIMD-0291), les overloads de ranges/performance, getBlockProduction, les valeurs Economics fournies par le runtime et getInflationReward positionnel sans plafond d'adresses inventé. Le réaudit final confirme l'égalité exacte entre l'inventaire HTTP officiel courant et le registre KSP, applique KSP-TRANSPORT-007 aux 52/52 wrappers, et ne matérialise aucune extension spéculative issue de la watchlist SIMD. Les canaries de frontières, le workspace complet et les deux smokes Devnet — Transport pur couvrant Accounts/Tokens/Cluster/Transactions/Blocks/Economics et composition Config -> Transport transitoire — sont validés avant publication. Le prompt prompts/010-V0_2_5_START_PROMPT.md, enrichi par pre.009-fix.001, ouvre 0.2.5 — Wallet foundation avec threat model, interopérabilité .kspwallet et capacités indépendantes VIEW/OWNER.

0.2.3 — HTTP Transactions — 2026-08-18

0.2.3 complète la famille HTTP Transactions de ksp-onchain-transport-lib avec 11 wrappers typés, portant la surface HTTP typée courante à 37 méthodes : 4 foundation, 22 Accounts/Tokens/Cluster et 11 Transactions. La release stabilise la classification exacte 8 Read / RetrySafe, 2 WriteSubmission / NeverAfterDispatch (requestAirdrop, sendTransaction) et 1 Simulation / RetrySafe (simulateTransaction), avec preuves end-to-end qu'une write submission n'est jamais resoumise après dispatch ambigu mais peut retenter lorsqu'un échec est prouvé NotDispatched. getTransaction couvre la config moderne complète et la forme bare encoding legacy dépréciée ; les variantes de transaction, metadata, version et transactionIndex restent préservées losslessly. simulateTransaction couvre sa config complète, ses invariants déterministes et son résultat riche sans introduire de client RPC Solana haut niveau ni de décodage transactionnel dans Transport. La release formalise KSP-TRANSPORT-007 et réaudite rétroactivement les 37 wrappers courants sans remédiation fonctionnelle. Les canaries conservent 52 méthodes HTTP courantes, 14 historiques Deprecated/Removed et 15 Blocks/Economics réservées à 0.2.4. Les graphes Cargo et les deux smokes Devnet — Transport pur read-only et composition Config -> Transport transitoire — ont été validés avant publication. Le prompt prompts/009-V0_2_4_START_PROMPT.md ouvre 0.2.4 — HTTP Blocks + Economics + compliance HTTP finale.

0.2.2 — HTTP Accounts + Tokens + Cluster — 2026-08-18

0.2.2 complète la surface HTTP typée de ksp-onchain-transport-lib avec 22 wrappers supplémentaires : 5 Accounts, 5 Tokens et 12 Cluster, portant la couverture typée totale à 26 méthodes avec les quatre canaris foundation de 0.2.1. La release stabilise les DTOs/configs wire communs, préserve les formes Account encodées/jsonParsed, les null et champs optionnels, les selectors Token exclusifs, les contextes RPC, les structures Cluster/leader/vote et les limites locales auditées (getMultipleAccounts <= 100, getProgramAccounts <= 4 filtres, memcmp raw <= 128 octets, getSlotLeaders entre 1 et 5000). Les 22 descriptors restent Read / RetrySafe et passent exclusivement par le flux central descriptor -> execute_standard_rpc -> pool/admission -> executor HTTP. La release n'ajoute aucune dépendance externe, ne crée aucun client HTTP parallèle et conserve le firewall Transport -> Config/Store/Program. Elle ajoute un smoke Devnet pur à Transport avec settings programmatiques couvrant Accounts/Tokens/Cluster, conserve séparément le smoke historique Config -> Transport comme exception transitoire, et valide les deux explicitement avant publication. Les canaries figent toujours 52 méthodes HTTP courantes, 14 historiques Deprecated/Removed et la partition typed 4 / 22 / 11 / 15. Le prompt prompts/008-V0_2_3_START_PROMPT.md ouvre 0.2.3 — HTTP Transactions.

0.2.1 — HTTP Solana foundation — 2026-08-17

0.2.1 stabilise ksp-onchain-transport-lib comme foundation HTTP JSON-RPC Solana provider-neutral : settings publics, endpoints/pool/rôles, priorités et fairness, RPS/burst/concurrence/cooldown, deadline commune, retry/backoff, classification no-resend après dispatch ambigu, snapshots sûrs et exécution HTTP réelle via reqwest/rustls. La release fige un registre audité de 52 méthodes HTTP courantes et 14 méthodes historiques Deprecated/Removed, avec quatre wrappers typés canari (getBalance, getGenesisHash, getHealth, getVersion) et une partition explicite des 48 méthodes restantes sur 0.2.2–0.2.4. Elle ajoute std.transport, son schema/exemple et l'adapter ksp-config-lib -> ksp-onchain-transport-lib, sans dépendance inverse, ainsi que la redaction des URLs/provider credentials, la neutralisation des URLs contenues dans les reqwest::Error, un sink Logging Transport dédié à info, des fixtures HTTP déterministes, des canaries de complétude et un smoke Devnet opt-in validant la composition Config -> Transport. Le smoke cross-crates reste temporairement hébergé dans Config et doit migrer vers une future surface d'intégration/orchestration ; ce placement n'est pas un modèle pour les futurs smokes Config + autre crate. Le prompt prompts/007-V0_2_2_START_PROMPT.md ouvre 0.2.2 — HTTP Accounts + Tokens + Cluster.

0.2.0 — Audit bot3 et planification de la série 0.2.x — 2026-08-17

0.2.0 stabilise le cadrage de la prochaine phase fonctionnelle de KSP après audit de khadhroony-bot3. La release fixe l'ordre 0.2.1+ autour du transport HTTP Solana, du Wallet .kspwallet, de Wallet Desk, des transports WebSocket/LaserStream/Yellowstone, du transport off-chain de prix, de ksp-interface-lib et de ksp-program-api; elle impose la couverture exhaustive des surfaces Transport documentées avec warnings KSP pour les opérations deprecated/obsolete encore fonctionnelles et unstable/experimental. Elle stabilise également la progression durable RAW -> CORE -> DECODE -> SPECIALIZED, RAW/CORE sans décodage Program, puis des vertical slices complets par groupe à partir de DECODE, avec priorité Solana Core, SPL token/trading, metadata token, Anchor, Meteora/Raydium/Pump/Orca, routing et Market Desk progressive. Le prompt prompts/006-V0_2_1_START_PROMPT.md ouvre 0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation avec un gate de sizing imposant qu'une release concrète reste clôturable dans une seule session.

0.1.4 — Config Desk — 2026-08-17

0.1.4 stabilise ksp-app-config-desk comme première application desktop/Tauri spécialisée et modèle de référence des futures applications KSP. La release valide de bout en bout les contrats de ksp-config-lib et le lifecycle de ksp-logging-lib : shell splash/main, inventaire et diagnostics des documents Config, profils et provenance sûre, management .env avec shadowing et reveal Secret privilégié, éditeur Logging typé multi-profils/multi-sinks, persistence atomique, hot reload transactionnel, rollback, sélection runtime explicite, génération observable, fichiers de logs distincts par lancement, bridge frontend vers la façade KSP et panneau Test Logging pour démontrer le routing niveau/target/domain. Elle ajoute également les audits desktop/ownership/sécurité, un registre extensible file_id -> éditeur spécialisé, une baseline Logging de release info/warn, et prépare 0.2.0 comme release intermédiaire d’audit de khadhroony-bot3 et de planification du reste de 0.2.x.

0.1.3 — Configuration foundation — 2026-08-16

0.1.3 stabilise ksp-config-lib comme propriétaire KSP unique des documents Config, schemas, profils, compositions, variables KSP_*/KSPB_*, .env, placeholders et persistence autorisée. La release introduit le bootstrap non récursif cfgpath/schemapath, le registre logique file_id -> filename, JSON Schema, globals/profils/default_profile, compositions par file_id, priorité process env > .env > fallback, sensibilité Public/Internal/Secret, représentations real/safe avec provenance, management/persistence atomique JSON et .env, ainsi que l'adapter vers ksp_logging_lib::LoggingSettings et les audits d'ownership. Elle complète également ksp-logging-lib avec les contrats/runtime multi-sink, routing structuré domain et hot reload nécessaires au premier document std.logging.json, puis prépare 0.1.4 — ksp-app-config-desk comme validation desktop/Tauri extensible de cette fondation.

0.1.2 — Logging foundation — 2026-08-14

0.1.2 stabilise ksp-logging-lib comme façade KSP unique de logging/tracing runtime. La release introduit les événements et spans KSP, le takeover des targets, le subscriber global unique, LoggingSettings, les sorties console/fichier non bloquantes, rotation, stripping ANSI, compteurs de lignes abandonnées, hot reload transactionnel et instrumentation async indépendante de l'executor. La stack tracing, tracing-subscriber et tracing-appender reste possédée exclusivement par Logging ; Tokio est limité aux tests réels d'instrumentation async.

0.1.1 — Core foundation — 2026-08-14

0.1.1 stabilise ksp-core-lib avec le contrat commun ErrorCode / ErrorContext / Error / Result<T>, la primitive Pubkey, les Program IDs Solana fondamentaux possédés par KSP et leur registre canonique recherché/filtrable. La release fixe également la taxonomie de classification et la politique Cargo workspace utilisée par les crates suivantes.

0.0.3 — Fondation architecture et règles — 2026-08-14

0.0.3 clôt la phase fondatrice : nomenclature KSP, règles Rust/Cargo/documentation, architecture en couches, contrats des composants, workers/jobs/pipelines/scénarios/apps, politique de versions/deltas et séquence des premières releases fonctionnelles. Elle prépare explicitement l'ouverture de 0.1.1 sans ajouter de fonctionnalité métier Solana.