khadhroony-solana-project/deltas/0.2.0/pre.003.md

Delta 0.2.0-pre.003

Identité

release : 0.2.0
prerelease : pre.003
identifiant de commit attendu : v0.2.0-pre.003
workspace.package.version : 0.2.0-pre.3
base : 0.2.0-pre.002

pre.003 est la dernière prerelease planifiée de la release de cadrage 0.2.0. Elle ne développe aucune capacité N2 runtime ; elle réalise l'audit de cohérence final demandé par le plan 007 avant rel.001.

Mission

Auditer la base Git complète 0.2.0-pre.002, éliminer les contradictions normatives/documentaires résiduelles, vérifier que les décisions bot3 utiles n'ont pas été perdues, compléter les fiches de releases 0.2.1+, finaliser le prompt 0.2.1 et fournir une matrice de clôture durable.

Écarts détectés et corrigés

Collisions d'identifiants normatifs

docs/rules/RULES_KSP.md utilisait deux fois :

KSP-TRANSPORT-001
KSP-DATA-001
KSP-DATA-002

Correction :

KSP-TRANSPORT-001  reste : pas de ksp-onchain-transport-api séparée
KSP-TRANSPORT-006  devient : couverture documentaire exhaustive + warnings de statut
KSP-DATA-001/002   restent : contrats de notifications de données
KSP-FLOW-001/002   deviennent : progression RAW/CORE/DECODE/SPECIALIZED + satellites de protocole

Un audit automatique des IDs normatifs ne trouve plus de doublon après correction.

Replay jobs historiques encore figés

KSP-JOB-009 imposait encore :

ksp-job-replay-core
ksp-job-replay-generic-materialization
ksp-job-replay-domain-projection

Cette règle contredisait la progression verticale fixée par pre.002.

La nouvelle règle ne fige plus de jobs DECODE/SPECIALIZED globaux. Un replay Core pourra être introduit avec CORE ; à partir de DECODE, les jobs de replay émergent avec les groupes/capacités réels et réutilisent la même logique que le processing live correspondant.

Les entrées IDEAS.md basées sur generic-materialization, domain-projection et un type global DomainProjector sont requalifiées en conséquence.

Diagramme global W1–W4 encore actif

docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md conservait encore :

W1 -> D1 -> W2 -> D2 -> W3 -> D3 -> W4 -> D4

Ce schéma pouvait contredire la décision de pre.002 en suggérant quatre workers globaux imposés. Il est remplacé par les frontières durables D1 RAW -> D2 CORE -> D3 DECODE -> D4 SPECIALIZED, avec workers RAW/CORE horizontaux et workers/processors DECODE/SPECIALIZED introduits need-driven par groupe vertical.

TODO Wallet bot3 incomplets dans KSP

L'audit du TODO/matrice Wallet bot3 montre que KSP avait conservé Solana CLI/Base58/Phantom/Solflare mais avait trop résumé plusieurs reports utiles.

IDEAS.md conserve maintenant explicitement :

• Solflare Keystore, seulement avec format suffisamment stable/testable ;
• Backpack, après caractérisation exacte du wire Solana Private key ;
• Trust Wallet, après caractérisation du wire Solana exact ;
• Base app / ex-Coinbase Wallet, sans synthèse de recovery phrase ;
• distinction entre Base app et Coinbase Developer Platform.

Ces entrées restent des idées/TODO, pas des dépendances ni engagements de 0.2.2.

Fiches de release manquantes

Le prompt d'ouverture 0.2.0 exigeait pour chaque release 0.2.1+ :

mission
périmètre
hors-périmètre
dépendances
critères de clôture
estimation souple des prereleases

pre.002 avait fixé la séquence mais n'avait pas regroupé ces six dimensions pour chaque release.

docs/plans/007-V0_2_0_SERIES_PLANNING.md contient maintenant une fiche pour 0.2.1 à 0.2.10.

Spot-check HTTP Solana

Un contrôle externe daté du 2026-08-17 a été effectué uniquement pour valider le sizing et la qualité du prompt 0.2.1 :

• l'index officiel HTTP Solana observé contient 52 méthodes courantes ;
• la section officielle Deprecated Methods expose séparément 14 noms ;
• l'inventaire bot3 ks-onchain-transport/src/standard_methods.rs contient les 52 noms courants observés ;
• bot3 ne couvre pas ces 14 anciennes méthodes deprecated comme surface standard ;
• l'égalité des noms courants ne garantit pas un contrat équivalent, bot3 distinguant notamment typed adapters et appels raw JSON.

Ces nombres ne deviennent pas une règle durable. 0.2.1-pre.001 doit refaire l'inventaire depuis la documentation officielle du jour et vérifier la disponibilité runtime des méthodes deprecated/obsolete avant de promettre leur support.

Prompt 0.2.1

prompts/006-V0_2_1_START_PROMPT.md passe en version 2 et est considéré finalisé côté contenu pour l'ouverture de 0.2.1 après v0.2.0 stable.

Il impose maintenant explicitement :

• index HTTP courant ;
• section officielle Deprecated Methods séparée ;
• toute surface HTTP unstable/experimental officiellement documentée ;
• vérification de disponibilité runtime des méthodes deprecated/obsolete ;
• comparaison nom par nom avec bot3 ;
• distinction du niveau de contrat bot3 typed vs raw/generic ;
• gate de sizing avant implémentation lourde.

Matrice de clôture ajoutée

Nouveau document :

docs/validation/002-V0_2_0_SERIES_PLANNING.md

Il trace les critères du prompt 0.2.0, les preuves documentaires, les écarts trouvés par pre.003, le spot-check HTTP et les conditions permettant de passer à rel.001.

Fichiers modifiés

Cargo.toml
ROADMAP.md
docs/000-README.md
docs/IDEAS.md
docs/architecture/000-README.md
docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md
docs/plans/000-README.md
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
docs/plans/007-V0_2_0_SERIES_PLANNING.md
docs/rules/RULES_KSP.md
docs/validation/000-README.md
prompts/000-README.md
prompts/006-V0_2_1_START_PROMPT.md

Fichiers ajoutés

docs/validation/002-V0_2_0_SERIES_PLANNING.md
deltas/0.2.0/pre.003.md

Validation statique réalisée dans l'environnement d'échange

• parsing TOML de Cargo.toml ;
• workspace.package.version = 0.2.0-pre.3 ;
• audit d'unicité des IDs normatifs sous docs/rules/ ;
• contrôle des en-têtes <!-- file: ... --> / versions des fichiers modifiés ;
• contrôle des fences Markdown équilibrées ;
• contrôle des liens Markdown locaux, en ignorant les exemples littéraux de syntaxe Markdown ;
• scan global des headers Markdown : un ancien delta livré deltas/0.1.4/pre.016-fix.002.md ne possède pas le header moderne ; il est volontairement laissé intact afin de ne pas réécrire silencieusement l'historique 0.1.4 ;
• recherche des anciennes décisions actives replay-generic-materialization / replay-domain-projection / DomainProjector ;
• recherche des diagrammes/contrats pouvant encore imposer mécaniquement un worker global par niveau D1–D4 ;
• comparaison ciblée avec les TODO Wallet et l'inventaire HTTP de bot3 ;
• spot-check de la documentation officielle Solana actuelle pour HTTP et Deprecated Methods.

Validations non exécutables dans cet environnement

Le conteneur d'échange ne fournit ni cargo ni rustc.

Avant commit de pre.003, exécuter sur le dépôt canonique :

cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test --workspace

Aucun build Tauri n'est requis par cette tranche documentaire : aucune application/frontend/runtime Tauri n'est modifié.

Commit attendu

Après application et validations :

v0.2.0-pre.003

Aucun tag Git stable n'est créé pour cette prerelease.

Suite

Si les validations de pre.003 sont propres, la prochaine livraison doit être :

0.2.0-rel.001

rel.001 doit rester minimal : version stable 0.2.0, statuts documentaires, entrée CHANGELOG, delta final, validations globales, commit de release puis tag v0.2.0.