Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.3.10-pre.006-fix.002

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-08 00:17:25 +02:00
parent 919b4ed46d
commit 1a352aa8d0
10 changed files with 288 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
Cargo.toml
View File

@@ -1,12 +1,12 @@
# file: Cargo.toml
# version: 500
# version: 501
[workspace]
resolver = "3"
members = ["crates/ksp-app-backfill-desk", "crates/ksp-app-config-desk", "crates/ksp-app-solprices-desk", "crates/ksp-app-store-desk", "crates/ksp-app-wallet-desk", "crates/ksp-config-lib", "crates/ksp-core-lib", "crates/ksp-interface-lib", "crates/ksp-job-api", "crates/ksp-job-backfill-lib", "crates/ksp-logging-lib", "crates/ksp-offchain-transport-lib", "crates/ksp-onchain-transport-lib", "crates/ksp-program-api", "crates/ksp-raw-transaction-lib", "crates/ksp-store-api", "crates/ksp-store-lib", "crates/ksp-store-postgres-lib", "crates/ksp-wallet-lib", "crates/ksp-worker-api"]
[workspace.package]
version = "0.3.10-pre.6.fix.1"
version = "0.3.10-pre.6.fix.2"
edition = "2024"
license = "MIT"
repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project"

4
crates/ksp-job-backfill-lib/tests/yellowstone_raw_parity.rs
View File

@@ -1,5 +1,7 @@
// file: crates/ksp-job-backfill-lib/tests/yellowstone_raw_parity.rs
// version: 2
// version: 3
//! Deterministic local Yellowstone gRPC parity canary for source-neutral RAW transaction v1 projection.
struct FixtureStream<T> {
receiver: tokio::sync::mpsc::Receiver<T>,

118
deltas/0.3.10/pre.006-fix.002.md Normal file
View File

@@ -0,0 +1,118 @@
<!-- file: deltas/0.3.10/pre.006-fix.002.md -->
<!-- version: 1 -->
# Delta `0.3.10-pre.006-fix.002` — rustdoc Yellowstone + réconciliation architecture/prompt handoff
## 1. Base requise
```text
0.3.10-pre.006-fix.001 appliquée
workspace.package.version = 0.3.10-pre.6.fix.1
```
Le gate opérateur du 7 septembre 2026 confirme que les erreurs Rust corrigées par `fix.001` ont disparu. Le seul blocage restant sous Clippy strict est le lint crate-level `missing_docs` de `crates/ksp-job-backfill-lib/tests/yellowstone_raw_parity.rs`.
## 2. Version technique
Le correctif modifie un test Rust compilé. Conformément à `VER-ID-007` / `VER-ID-010` :
```text
workspace.package.version = 0.3.10-pre.6.fix.2
commit attendu = v0.3.10-pre.006-fix.002
aucun tag prerelease
```
Aucune version npm/Tauri n'est modifiée : aucune application Desk n'est touchée.
## 3. Correction Rust
`tests/yellowstone_raw_parity.rs` reçoit la rustdoc crate-level manquante :
```text
//! Deterministic local Yellowstone gRPC parity canary for source-neutral RAW transaction v1 projection.
```
Aucun `#[allow(missing_docs)]` n'est ajouté. Le serveur fixture, la projection Yellowstone, les goldens, les assertions et les dépendances restent inchangés.
## 4. Inventaire des composants
`docs/architecture/004-COMPONENT_INVENTORY.md` :
```text
+ ksp-raw-transaction-lib comme common RAW Transaction implémentée en 0.3.10
CORE processor -> STRUCTURAL job
CORE worker -> STRUCTURAL worker
```
Le Job STRUCTURAL représente le traitement borné/rejouable RAW -> CORE ; le Worker STRUCTURAL représente le service continu backlog RAW -> CORE. Les références durables correspondantes dans `009-ACQUISITION_WORKERS_AND_JOBS.md`, `010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md` et la séquence fonctionnelle active sont synchronisées. Les noms/packagings concrets restent à fixer lors de l'ouverture de la couche CORE.
## 5. Graphe de dépendances
`docs/architecture/005-DEPENDENCY_GRAPH.md` matérialise la lower layer réelle :
```text
ksp-raw-transaction-lib
-> ksp-store-api
-> ksp-core-lib
-> base64 / serde_json / sha2
-X-> Transport
-X-> ksp-store-lib
-X-> Job / Worker
-X-> Config / runtime async / backend Store
```
Le graphe Backfill ajoute son edge réel vers `ksp-raw-transaction-lib`, et le graphe du futur Worker réserve la même common crate avant la persistence par `ksp-store-lib`.
## 6. Note de génération des prompts `0.3.12` à `0.3.15`
Le plan `031` n'introduit pas quatre prompts prématurés. Il fixe un handoff séquentiel :
```text
0.3.11 ferme -> génère le prompt 0.3.12
0.3.12 ferme -> génère le prompt 0.3.13
0.3.13 ferme -> génère le prompt 0.3.14
0.3.14 ferme -> génère le prompt 0.3.15
```
Chaque prompt doit partir de la base stable réellement obtenue, refaire son audit/sizing `pre.001`, rester sous le budget 15–20 min par tranche et rescinder sa release si la clôture dans une session devient incertaine. La note transfère les missions Yellowstone, WS/Helius/HTTP, gap repair/hardening puis Desk sans les figer comme vérité future.
Le plan corrige aussi l'ancienne référence résiduelle de la Desk `0.3.11` vers sa cible recalibrée `0.3.15`.
## 7. Validation opérateur requise
```bash
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test -p ksp-raw-transaction-lib
cargo test -p ksp-onchain-transport-lib
cargo test -p ksp-job-backfill-lib
cargo tree -p ksp-job-backfill-lib --edges normal
cargo tree -p ksp-job-backfill-lib --edges dev
cargo tree -p ksp-job-backfill-lib -e features
```
Aucune commande ne doit être déclarée PASS avant exécution réelle. Si ce gate est vert, `pre.006-fix.002` ferme le défaut technique restant de `pre.006` et `pre.007` peut rester le gate technique final recalibré de `0.3.10`.
## 8. Périmètre du delta
```text
Cargo.toml
crates/ksp-job-backfill-lib/tests/yellowstone_raw_parity.rs
docs/architecture/004-COMPONENT_INVENTORY.md
docs/architecture/005-DEPENDENCY_GRAPH.md
docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md
docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
docs/plans/031-V0_3_10_RAW_TRANSACTION_INGEST_PLAN.md
docs/validation/027-V0_3_10_RAW_TRANSACTION_INGEST.md
deltas/0.3.10/pre.006-fix.002.md
```
Aucun code de production, manifest de crate, dépendance, feature, golden RAW, Config, Store schema, frontend ou application n'est modifié.

13
docs/architecture/004-COMPONENT_INVENTORY.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/004-COMPONENT_INVENTORY.md -->
<!-- version: 35 -->
<!-- version: 36 -->
# Inventaire initial des composants KSP
@@ -19,7 +19,7 @@ Ce document maintient l'inventaire synthétique des composants retenus ou presse
## Inventaire synthétique
| Domaine | Composant | Type | Statut | Première cible actuelle | Mission |
|-------------------------|-----------------------------------------|---------------|--------------|---------------------------------|---------------------------------------------------------------------------------------------|
|-------------------------|-----------------------------------------|-------------|--------------|---------------------------------|---------------------------------------------------------------------------------------------|
| Core | `ksp-core-lib` | lib | Stable | `0.1.1` | Error/Result, Program IDs et primitives fondamentales |
| Logging | `ksp-logging-lib` | lib | Stable | `0.1.2` | façade unique tracing KSP |
| Config | `ksp-config-lib` | lib | Stable | `0.1.3` | documents, profils, env et persistence Config |
@@ -44,11 +44,12 @@ Ce document maintient l'inventaire synthétique des composants retenus ou presse
| Backfill | `ksp-job-backfill-lib` | lib | Implémenté | `0.3.6`, extension `0.3.16` | première verticale HTTP puis extension multi-source/historique sans changer l’identité RAW |
| Backfill Desk | `ksp-app-backfill-desk` | app | Implémenté | `0.3.7`, extension `0.3.16` | contrôle du backfill RAW ; sélection des stratégies/sources ajoutée après le worker live |
| Store Desk | `ksp-app-store-desk` | app | Implémenté | `0.3.8` | inspection RAW read-only Transaction/Account/Observation via façade Store |
| RAW transaction common | `ksp-raw-transaction-lib` | lib | Implémenté | `0.3.10` | canonicalisation/wire RAW Transaction v1 source-neutral partagé entre producteurs |
| Worker lifecycle | `ksp-worker-api` | API | Retenu | `0.3.9` | lifecycle/health/progression génériques des services continus |
| RAW transaction worker | `ksp-worker-raw-transaction-ingest-lib` | worker/lib | Retenu | `0.3.11`–`0.3.14` | ingestion continue `RawTransaction` multi-source, déduplication/provenance/recovery |
| RAW ingest Desk | `ksp-app-raw-transaction-ingest-desk` | app | Retenu | `0.3.15` | choix/supervision d’une ou plusieurs sources/méthodes sans réimplémenter le worker |
| CORE processor | nom à fixer | processor/lib | Retenu | couche CORE | normalisation Solana générique RAW -> CORE |
| CORE worker | nom à fixer | worker | Retenu | fin couche CORE | backlog RAW -> CORE continu |
| STRUCTURAL job | nom à fixer | job/lib | Retenu | couche CORE | normalisation Solana générique RAW -> CORE bornée/rejouable |
| STRUCTURAL worker | nom à fixer | worker/lib | Retenu | fin couche CORE | backlog RAW -> CORE continu |
| Materializer API | `ksp-materializer-api` | API | Retenu | premier groupe DECODE | contrats extensibles matérialisation |
| Materializer impl. | `ksp-materializer-lib` | lib | Retenu | premier groupe DECODE | implementations officielles communes |
| Execution policy | `ksp-execution-policy-api` | API | Retenu | premier vrai besoin execution | décision/safety multi-contexte |
@@ -114,7 +115,7 @@ RAW -> CORE -> DECODE -> SPECIALIZED
- DECODE : interpretation Program + matérialisation générique/journal ;
- SPECIALIZED : projections queryables de domaine.
## Progression des processors
## Progression structurelle
RAW et CORE sont complétés couche par couche avec jobs/workers/apps utiles.
@@ -154,5 +155,5 @@ Market Desk est progressive : V1 après les DEX prioritaires, puis enrichissemen
- nécessité future d'un pool automatique WS ;
- types exacts `ksp-materializer-api` lors de l'ouverture DECODE ;
- nom/packaging précis du premier RAW worker et du CORE normalizer ;
- nom/packaging précis des futurs STRUCTURAL job et STRUCTURAL worker ;
- granularité des workers DECODE/SPECIALIZED par groupe.

42
docs/architecture/005-DEPENDENCY_GRAPH.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/005-DEPENDENCY_GRAPH.md -->
<!-- version: 24 -->
<!-- version: 25 -->
# Graphe de dépendances KSP
@@ -251,19 +251,47 @@ D1 RAW
### RAW
La canonicalisation `RawTransaction` source-neutral est une lower layer explicite, séparée du Transport et de la persistence runtime :
```text
transport model
ksp-raw-transaction-lib
-> ksp-store-api
-> ksp-core-lib
-> base64 / serde_json / sha2
```
Interdictions :
```text
ksp-raw-transaction-lib -X-> ksp-onchain-transport-lib
ksp-raw-transaction-lib -X-> ksp-store-lib
ksp-raw-transaction-lib -X-> ksp-job-api / ksp-job-backfill-lib
ksp-raw-transaction-lib -X-> ksp-worker-api / concrete workers
ksp-raw-transaction-lib -X-> Config / runtime async / backend Store
```
Le flux de composition devient :
```text
transport model / fixture source-neutral
|
v
composition/RAW ingestion
producer adapter
|
v
ksp-store-api
ksp-raw-transaction-lib
|
+--> RawTransaction + RawTransactionObservation (types ksp-store-api)
|
v
producer concret
|
v
ksp-store-lib
```
Le Job Backfill et le Worker RAW peuvent donc partager exactement la canonicalisation et le wire sans que la common crate possède le runtime, le Transport ou le backend.
### CORE
```text
@@ -375,9 +403,10 @@ ksp-job-backfill-lib
-> ksp-core-lib
-> ksp-logging-lib
-> ksp-onchain-transport-lib
-> ksp-raw-transaction-lib # canonicalisation/wire RAW v1 partagés
-> ksp-store-lib # default-features = false ; aucun backend imposé
-> futures-util / tokio # runtime privé du job, jamais dans ksp-job-api
-> serde_json / sha2 # canonicalisation RAW v1 et digest
-> serde_json / sha2 # usages résiduels propres au job tant qu'ils existent
```
Il remplit RAW et ne décode aucun programme. Il ne dépend pas de Config : la composition supérieure construit explicitement Transport, Store et `BackfillRequest`. Le réseau appartient au scope/à l'identité durable `(network, signature)` ; rôle, provider, endpoint et protocole restent des choix ou provenances d'acquisition et ne deviennent jamais une clé de transaction.
@@ -393,6 +422,7 @@ ksp-worker-api
ksp-worker-raw-transaction-ingest-lib
-> ksp-worker-api
-> ksp-onchain-transport-lib
-> ksp-raw-transaction-lib
-> ksp-store-lib
-> ksp-logging-lib
# Config reste possédé par la composition supérieure ; aucune dépendance backend/provider physique
@@ -406,7 +436,7 @@ ksp-worker-control-lib
Le worker RAW Transaction n'est pas défini comme « un worker WebSocket » ou « un worker gRPC ». Il reçoit une ou plusieurs stratégies d'acquisition construites au-dessus des façades KSP réellement disponibles ; celles-ci peuvent être alternatives, complémentaires (discovery + hydration), redondantes entre providers ou spécialisées live/catch-up/gap-repair. La transaction canonique reste identifiée indépendamment de la source et chaque acquisition utile conserve sa propre observation/provenance Store.
RAW worker et CORE worker sont introduits à la fin de leur couche respective, lorsque persistence/backlog sont disponibles. Les workers DECODE/SPECIALIZED sont introduits avec les groupes Program concernés plutôt que tous anticipés en bloc.
RAW worker puis STRUCTURAL worker sont introduits à la fin de leur couche respective, lorsque persistence/backlog sont disponibles. Le traitement RAW -> CORE borné est porté par un STRUCTURAL job distinct du service continu. Les workers DECODE/SPECIALIZED sont introduits avec les groupes Program concernés plutôt que tous anticipés en bloc.
## Apps

12
docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md -->
<!-- version: 15 -->
<!-- version: 16 -->
# Acquisition, workers, jobs et pipelines spécialisés
@@ -263,7 +263,7 @@ CORE normalizer -X-> ksp-materializer-api
`ksp-interface-lib` peut fournir les wires Solana génériques nécessaires à la structure blockchain.
### Job replay CORE
### STRUCTURAL job
Un job borné peut rejouer :
@@ -279,9 +279,9 @@ D2 CORE
sans redemander les données au réseau.
### Worker CORE
### STRUCTURAL worker
Un worker CORE continu peut consommer le backlog RAW nouvellement persisté et produire CORE.
Le STRUCTURAL worker continu peut consommer le backlog RAW nouvellement persisté et produire CORE.
Le Store reste source de vérité du backlog ; les notifications ne sont qu'un wake-up.
@@ -499,10 +499,10 @@ Le Worker conserve seul son runtime continu, ses sources actives, sa continuité
Les événements Interface peuvent servir de signal provider-neutral à la composition live, mais ne constituent jamais le backlog durable. Après crash ou perte d'un événement, la reprise s'appuie sur Store et sur les primitives de replay/hydratation appropriées.
### CORE replay/worker
### STRUCTURAL job/worker
```text
CORE processor
STRUCTURAL job / STRUCTURAL worker
-> ksp-interface-lib si wires génériques nécessaires
-> ksp-store-api
-> ksp-core-lib

6
docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md -->
<!-- version: 12 -->
<!-- version: 13 -->
# Applications, services, scenarios et control plane
@@ -197,13 +197,13 @@ Exemples conceptuels :
```text
ksp-worker-raw-transaction-ingest-lib # premier runtime worker réutilisable retenu
future autonomous raw-ingest binary # seulement si un besoin de service séparé le justifie
future CORE worker
future STRUCTURAL worker
future group-specific DECODE/SPECIALIZED workers when justified
```
Le premier worker RAW est volontairement prévu comme bibliothèque réutilisable afin qu'une Desk ou un futur host puisse le construire sans dupliquer sa logique. Un binaire autonome n'est pas créé par convention seule ; s'il apparaît, il reste un host mince au-dessus de la même bibliothèque et de `ksp-worker-api`.
RAW et CORE reçoivent leurs workers à la fin de leur couche respective. Les workers DECODE/SPECIALIZED ne sont plus tous anticipés comme une chaîne globale fixe : leur granularité doit émerger des premiers vertical slices Program.
RAW reçoit son worker d’ingestion à la fin de sa couche ; CORE reçoit ensuite son STRUCTURAL worker lorsque sa persistence/backlog sont disponibles. Les workers DECODE/SPECIALIZED ne sont plus tous anticipés comme une chaîne globale fixe : leur granularité doit émerger des premiers vertical slices Program.
Le binaire, lorsqu'il existe, doit rester mince.

4
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
<!-- version: 95 -->
<!-- version: 96 -->
# Séquence des releases fonctionnelles KSP
@@ -591,7 +591,7 @@ RAW persisted
-> Solana generic normalization
-> CORE persistence
-> RAW->CORE replay/backfill
-> CORE worker/service
-> STRUCTURAL worker/service
-> CORE inspection/control app
```

43
docs/plans/031-V0_3_10_RAW_TRANSACTION_INGEST_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/031-V0_3_10_RAW_TRANSACTION_INGEST_PLAN.md -->
<!-- version: 11 -->
<!-- version: 12 -->
# Plan v0.3.10 — RAW Transaction commune + qualification cross-source
@@ -298,6 +298,7 @@ Cible retenue :
ksp-raw-transaction-lib
-> ksp-core-lib
-> ksp-store-api
-> base64
-> serde_json
-> sha2
```
@@ -832,7 +833,7 @@ gRPC protocol + metadata publique/secrète + session settings
Cela suffit comme handoff pour matérialiser et tester la bibliothèque Worker programmatiquement à partir de `0.3.11`. Aucune release Worker n’ajoute par défaut un `std.raw_transaction_ingest` qui forcerait `ksp-config-lib` à dépendre du Worker concret.
Le choix utilisateur/composition de « quelles sources activer » appartient naturellement au futur `ksp-app-raw-transaction-ingest-desk` `0.3.11`. Si `0.3.10` découvre un manque **Transport** indispensable (par exemple un profil Helius de preuve ou un rôle HTTP live), l’adaptation Config reste limitée au standard Transport et ne crée pas de dépendance inversée.
Le choix utilisateur/composition de « quelles sources activer » appartient naturellement au futur `ksp-app-raw-transaction-ingest-desk` `0.3.15`. Si `0.3.10` découvre un manque **Transport** indispensable (par exemple un profil Helius de preuve ou un rôle HTTP live), l’adaptation Config reste limitée au standard Transport et ne crée pas de dépendance inversée.
### 13.3 Secrets
@@ -1081,6 +1082,44 @@ Ancienne cible `0.3.11`, décalée après finalisation complète du Worker.
Ancienne cible `0.3.12`, décalée sans changer la frontière Job historique paramétré / Worker live.
### Note durable de génération des prompts `0.3.12` à `0.3.15`
Ne pas pré-générer maintenant quatre prompts complets qui figeraient des hypothèses avant leurs releases. Le prompt `0.3.11` reste produit dans la dernière prerelease de `0.3.10`; ensuite, chaque release produit **uniquement le prompt de la release suivante** depuis sa base stable réellement obtenue et conformément à `docs/rules/PROMPT_STRUCTURE.md`.
Chaîne de handoff obligatoire :
```text
fermeture 0.3.11 -> prompt 0.3.12 Yellowstone + hydration + continuity
fermeture 0.3.12 -> prompt 0.3.13 WS/Helius/HTTP live + convergence multi-source
fermeture 0.3.13 -> prompt 0.3.14 gap repair/hardening + smokes
fermeture 0.3.14 -> prompt 0.3.15 RAW ingest Desk
```
Chaque prompt doit reprendre comme **input**, pas comme vérité figée, les handoffs des sections 8 à 17 de ce plan et les références architecture/validation réellement réconciliées par la release précédente. Il doit obligatoirement :
```text
partir du dernier tag stable réel de la release précédente ;
relire RULES.md, PROMPT_STRUCTURE.md, architecture 004/005/009/010/011 et les plans/validations courants ;
réauditer les versions/capabilities provider et dépendances externes qui peuvent avoir changé ;
faire de pre.001 un audit + brainstorming + sizing, sans développement lourd ;
recalculer toutes les tranches sous le budget 15–20 min et rescinder la release si nécessaire ;
réserver les couloirs gate technique/live -> réconciliation documentaire -> préparation de publication ;
préserver ksp-raw-transaction-lib comme common lower layer sans runtime/Transport/Worker/Job ;
préserver la distinction Job borné / Worker continu et la persistence via ksp-store-lib ;
ne jamais transformer les objectifs ci-dessous en obligation si l'audit de la base réelle les invalide.
```
Contenu minimal à transférer :
| Prompt à produire | Mission de départ à réauditer | Frontière à préserver |
|:------------------|:------------------------------------------------------------------------|:----------------------------------------------------------------------------------|
| `0.3.12` | Yellowstone transaction/block/status + hydration HTTP + replay/frontier | aucun élargissement WS/Helius/HTTP multi-source non nécessaire au gate |
| `0.3.13` | WS standard, Helius et HTTP live + convergence multi-source | réutiliser l'actor Transport ; aucune duplication protocolaire dans le Worker |
| `0.3.14` | gap repair/hardening + smokes accessibles | aucune prétention lossless sans preuve ; unresolved gaps visibles |
| `0.3.15` | Desk Tauri de sélection/supervision | UI sans réimplémenter acquisition, canonicalisation, dedup, repair ou persistence |
Cette note sert de **pré-handoff de génération**. Elle ne remplace ni les futurs plans `pre.001`, ni les prompts autonomes effectivement produits à la fermeture de chaque release.
## 18. Gates Cargo futurs obligatoires
Dès création des nouvelles crates et à la fermeture technique :

36
docs/validation/027-V0_3_10_RAW_TRANSACTION_INGEST.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/027-V0_3_10_RAW_TRANSACTION_INGEST.md -->
<!-- version: 11 -->
<!-- version: 12 -->
# Validation v0.3.10 — RAW Transaction commune + qualification cross-source
@@ -978,7 +978,7 @@ Décision de qualification :
Yellowstone transaction wire = QUALIFIÉ
Yellowstone Transaction RAW = HYDRATION HTTP (block_time absent)
Yellowstone Block RAW complet = HYDRATION HTTP (meta JSON byte-identical non prouvée)
TR-C2 adapter productif = différé au Worker pre.007
TR-C2 adapter productif = différé au Worker 0.3.11
```
Le manifest Backfill ajoute uniquement en dev :
@@ -991,3 +991,35 @@ yellowstone-grpc-proto = { workspace = true, features = ["tonic"] }
`tests/dependency_boundary.rs` vérifie qu'elles ne figurent pas avant `[dev-dependencies]`, et le canari hardening attend exactement `{tokio, tokio-tungstenite, tonic, yellowstone-grpc-proto}` en dev tout en gardant l'inventaire normal inchangé.
L'environnement d'assemblage ne fournit ni `cargo`, ni `rustc`, ni `rustfmt`. Le gate Cargo/Clippy/tests reste donc opérateur. Les audits Python KSP et Markdown sont exécutés après fermeture du delta et leurs résultats sont enregistrés dans `deltas/0.3.10/pre.006.md`.
### 13.11 Rejeu opérateur de `pre.006-fix.001` et `pre.006-fix.002`
Le rejeu opérateur communiqué le 7 septembre 2026 confirme la correction des trois familles d'erreurs initiales de `pre.006-fix.001` :
```text
cargo check --workspace PASS
ksp-raw-transaction-lib 16 unit + 10 integration/public/security PASS
ksp-onchain-transport-lib 387 unit + 51 public + 43 release + doctests PASS
ksp-job-backfill-lib 51 unit + suites integration PASS hors lint strict
```
Le seul échec de `cargo clippy --workspace --all-targets --all-features -- -D warnings` restant est :
```text
crates/ksp-job-backfill-lib/tests/yellowstone_raw_parity.rs
missing documentation for the crate
```
Le fichier d'intégration Yellowstone était le seul test de la crate sans rustdoc de crate `//! ...`. `pre.006-fix.002` ajoute uniquement cette documentation crate-level et incrémente la version technique à `0.3.10-pre.6.fix.2`; aucune logique de fixture, aucun golden, aucune dépendance et aucun comportement de production ne changent.
Le même correctif réconcilie aussi l'architecture durable avec l'extraction common déjà effective :
```text
ksp-raw-transaction-lib est inventoriée explicitement ;
son graphe lower-layer est documenté ;
CORE processor / CORE worker deviennent STRUCTURAL job / STRUCTURAL worker ;
le plan conserve une note de génération séquentielle des prompts 0.3.12 -> 0.3.15.
```
Le gate opérateur à rejouer après application de `pre.006-fix.002` est le même que `pre.006-fix.001`, en priorité le Clippy strict puis `cargo test -p ksp-job-backfill-lib`.