211 lines
7.7 KiB
Markdown
211 lines
7.7 KiB
Markdown
<!-- file: deltas/0.2.0/pre.003.md -->
|
||
<!-- version: 2 -->
|
||
|
||
# Delta `0.2.0-pre.003`
|
||
|
||
## Identité
|
||
|
||
```text
|
||
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 :
|
||
|
||
```text
|
||
KSP-TRANSPORT-001
|
||
KSP-DATA-001
|
||
KSP-DATA-002
|
||
```
|
||
|
||
Correction :
|
||
|
||
```text
|
||
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 :
|
||
|
||
```text
|
||
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 :
|
||
|
||
```text
|
||
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+` :
|
||
|
||
```text
|
||
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 :
|
||
|
||
```text
|
||
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
|
||
|
||
```text
|
||
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
|
||
|
||
```text
|
||
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 :
|
||
|
||
```bash
|
||
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 :
|
||
|
||
```text
|
||
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 :
|
||
|
||
```text
|
||
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`.
|