khadhroony-solana-project/prompts/031-V0_3_12_START_PROMPT.md

<!-- file: prompts/031-V0_3_12_START_PROMPT.md -->
<!-- version: 1 -->

# Prompt de démarrage `0.3.12` — Yellowstone + hydration HTTP + continuité de run du Worker `RawTransaction`

## 1. Identité de la release et base exacte requise

Ouvrir **uniquement** `0.3.12` depuis la release stable/taggée :

```text
v0.3.11
```

La base de travail fournie par l'opérateur est autoritaire sur les souvenirs de session, snippets, anciennes archives et deltas intermédiaires. Avant toute modification, vérifier au minimum :

```text
workspace.package.version = 0.3.11
deltas/0.3.11/rel.001.md présent
crates/ksp-worker-raw-transaction-ingest-lib présent et documenté
crates/ksp-worker-raw-transaction-ingest-lib sans source réseau productive dans le stable 0.3.11
crates/ksp-raw-transaction-lib présent et stable
crates/ksp-onchain-transport-lib présent avec moteur Yellowstone générique
crates/ksp-store-lib présent comme seule façade Store du Worker
ksp-job-backfill-lib indépendant du Worker
```

Release ouverte :

```text
0.3.12
```

Première livraison attendue :

```text
0.3.12-pre.001
```

`pre.001` est obligatoirement un gate de **lecture + audit interne/externe + brainstorming + sizing + planification**. Il ne commence pas directement l'intégration Yellowstone productive. Si le périmètre réel n'est pas clôturable dans une seule session ou si une tranche intermédiaire paraît dépasser environ 15–20 minutes de travail effectif, rescinder la release avant l'implémentation lourde.

## 2. Mission et résultat attendu

### 2.1 Mission de `0.3.12`

Étendre la fondation source-neutral de :

```text
ksp-worker-raw-transaction-ingest-lib
```

avec la première famille live productive, centrée sur **Yellowstone gRPC + hydration HTTP** et la continuité propre au run du Worker.

Résultat cible à réauditer pendant `pre.001` :

```text
edge Worker -> ksp-onchain-transport-lib seulement si réellement nécessaire
adapter Yellowstone transaction/block/status vers le pipeline privé existant
réutilisation du moteur Yellowstone générique existant
projection fidèle du transaction wire vers ksp-raw-transaction-lib
hydration HTTP lorsque le matériau Yellowstone ne suffit pas au RAW v1 complet
provenance sûre de la route réellement observée
source tasks intégrées au supervisor existant
frontier de run live explicite et borné
from_slot / replay info exploités uniquement pour continuité du run
reconnexion distinguée du replay/repair
snapshots/health enrichis seulement par dimensions réellement prouvées
fixtures déterministes cross-layer
smokes live uniquement sur providers/réseaux réellement accessibles
```

`0.3.12` ne doit pas ouvrir les voies WS standard, Helius `transactionSubscribe`, HTTP live block polling multi-source complet ni le gap repair multi-source final ; ces responsabilités restent réparties sur `0.3.13` et `0.3.14`.

### 2.2 Principe de correction RAW à préserver

Le pipeline durable reste :

```text
source live
    -> matériau source/protocole
    -> hydration si nécessaire
    -> ksp-raw-transaction-lib
    -> RawTransaction + RawTransactionObservation
    -> ksp-store-lib
```

Aucune source ne doit inventer un RAW complet à partir d'un signal incomplet.

Décision conservative déjà qualifiée :

```text
Yellowstone Transaction/Block -> transaction wire fidèle + métadonnées disponibles
RAW v1 complet                -> hydration HTTP tant que block_time/meta parity n'est pas prouvée suffisante
```

Si `pre.001` démontre qu'un sous-ensemble Yellowstone peut désormais produire un RAW v1 direct sans hydration, cette évolution doit être prouvée par fixture/canari byte-exact avant de modifier cette décision.

## 3. Sources de vérité internes obligatoires — ordre de lecture

### 3.1 Gouvernance générale

Lire intégralement, dans cet ordre :

```text
RULES.md
ROADMAP.md
CHANGELOG.md
docs/000-README.md

docs/rules/RULES_GENERAL.md
docs/rules/RULES_KSP.md
docs/rules/RULES_RUST.md
docs/rules/RULES_DEPENDENCIES.md
docs/rules/RULES_DOCUMENTATION.md
docs/rules/FILE_CONTRACTS.md
docs/rules/VERSION_WORKFLOW.md
docs/rules/PROMPT_STRUCTURE.md
```

Le prompt complète ces règles ; il ne les remplace pas.

Rappels Rust bloquants :

```text
Rust 2024
unsafe interdit
unwrap / expect / panic interdits selon les règles KSP
? interdit en production
retours explicites ; clippy::implicit_return deny
#![warn(missing_docs)]
#![deny(unreachable_pub)]
#![forbid(unsafe_code)]

pas de pub mod
pub/pub(crate) partagés reexportés jusqu'à la crate root
accès partagés via crate::Item, y compris intra-crate
item strictement module-local => private
unit tests sous unit_tests/
integration tests sous tests/
```

Après toute modification Rust :

```bash
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
```

Pour tout Markdown touché :

```bash
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas
```

Une commande non exécutée n'est jamais déclarée PASS.

### 3.2 Handoff stable `0.3.11`

Lire intégralement :

```text
docs/plans/032-V0_3_11_RAW_TRANSACTION_INGEST_WORKER_FOUNDATION_PLAN.md
docs/validation/028-V0_3_11_RAW_TRANSACTION_INGEST_WORKER_FOUNDATION.md
crates/ksp-worker-raw-transaction-ingest-lib/Cargo.toml
crates/ksp-worker-raw-transaction-ingest-lib/README.md
crates/ksp-worker-raw-transaction-ingest-lib/USAGE.md
crates/ksp-worker-raw-transaction-ingest-lib/src/
crates/ksp-worker-raw-transaction-ingest-lib/tests/
crates/ksp-worker-raw-transaction-ingest-lib/unit_tests/
```

La fondation stable est une contrainte, pas un brouillon à remplacer.

### 3.3 Acquisition RAW et qualification cross-source

Lire intégralement :

```text
docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md
docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md
docs/plans/031-V0_3_10_RAW_TRANSACTION_INGEST_PLAN.md
docs/validation/027-V0_3_10_RAW_TRANSACTION_INGEST.md
crates/ksp-raw-transaction-lib/README.md
crates/ksp-raw-transaction-lib/USAGE.md
crates/ksp-raw-transaction-lib/src/
crates/ksp-raw-transaction-lib/tests/
```

Porter une attention particulière aux sections de `011` concernant :

```text
Yellowstone transactions / transactions_status / blocks / blocks_meta / slots
from_slot
SubscribeReplayInfo / continuity snapshots
hydration HTTP
reconnexion != replay
Worker continuity repair != campagne historique
qualification transaction wire Legacy/V0/V1
limites de la preuve RAW-direct Yellowstone actuelle
```

### 3.4 Transport Yellowstone et HTTP existants

Lire au minimum :

```text
crates/ksp-onchain-transport-lib/Cargo.toml
crates/ksp-onchain-transport-lib/README.md
crates/ksp-onchain-transport-lib/USAGE.md
crates/ksp-onchain-transport-lib/src/grpc_*.rs
crates/ksp-onchain-transport-lib/src/rpc_transactions.rs
crates/ksp-onchain-transport-lib/src/rpc_blocks.rs
crates/ksp-onchain-transport-lib/tests/
```

Réutiliser le moteur générique existant ; ne pas créer un second client Yellowstone, un actor gRPC Worker parallèle ou un SDK provider.

Les primitives HTTP observées existantes à réauditer incluent notamment :

```text
get_transaction_observed
get_block_observed
```

L'hydration doit conserver la provenance réellement observée du winner HTTP plutôt qu'un endpoint supposé.

### 3.5 Store, Worker API et Config comme frontières

Lire au minimum :

```text
crates/ksp-store-lib/README.md
crates/ksp-store-lib/USAGE.md
crates/ksp-store-lib/src/
crates/ksp-worker-api/README.md
crates/ksp-worker-api/USAGE.md
crates/ksp-worker-api/src/
crates/ksp-config-lib/README.md
crates/ksp-config-lib/USAGE.md
crates/ksp-config-lib/src/
```

Le Worker continue d'écrire via `ksp-store-lib` uniquement.

`ksp-config-lib` reste propriétaire des profils, endpoints, providers/protocoles, secrets et activation/composition. **Le Worker ne lit jamais Config ou l'environnement directement.** L'éventuelle adaptation Config de `0.3.12` doit être décidée après audit de l'injection de ressources runtime ; ne pas créer automatiquement un edge Worker -> Config.

## 4. Sources externes normatives et fraîcheur à réauditer

La fraîcheur est importante dans `0.3.12`. `pre.001` doit consulter les sources primaires courantes avant toute décision d'API ou de capability :

```text
Yellowstone gRPC upstream : proto geyser + solana-storage + README + changelog
Solana JSON-RPC officiel : getTransaction / getBlock et champs nécessaires à l'hydration
providers Yellowstone réellement envisagés/accessibles : documentation endpoint/auth/replay/from_slot
versions stables actuelles des crates externes touchées
```

Réauditer en particulier :

```text
shape courante SubscribeRequest/from_slot
SubscribeReplayInfo et sémantique de replay exposée par le moteur/proto courant
Transaction / TransactionStatus / Block / BlockMeta wire actuel
profondeur et disponibilité réelle du replay provider-specific
réseaux réellement servis
mode d'authentification actuel
limitations/tier actuels
```

Ne pas recopier comme vérité actuelle les prix, limites ou profondeurs de replay historiques présents dans `docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md`. Cette architecture conserve les décisions KSP ; les paramètres provider temporels doivent être revérifiés.

Préférer les sources primaires. Aucun SDK provider n'est ajouté pour une simple compatibilité Yellowstone standard.

## 5. État validé à préserver

### 5.1 Fondation Worker stable

Le stable `0.3.11` possède déjà :

```text
RawTransactionIngestSettings bornés
RawTransactionIngestWorker::start
RawTransactionIngestHandle
request_stop idempotent
terminal future
supervisor privé
JoinSet sources/persistences privés
mpsc central borné
backpressure observée
canonicalisation/assembly Common RAW
persistence atomique Store mode Normal
content conflict terminal
snapshots concrete + WorkerSnapshotSource
source/store/counter/drain faults classifiés
shutdown deadline + abort/join avant terminal timeout
```

`0.3.12` étend cette fondation ; il ne crée pas un second lifecycle, un second pipeline d'admission ou un second système de snapshots.

### 5.2 Dependency firewall

État `0.3.11` :

```text
Worker -> ksp-core-lib
Worker -> ksp-logging-lib
Worker -> ksp-raw-transaction-lib
Worker -> ksp-store-lib default-features=false
Worker -> ksp-worker-api
Worker -> sha2
Worker -> tokio
Worker -X-> ksp-onchain-transport-lib
Worker -X-> ksp-config-lib
Worker -X-> ksp-job-backfill-lib
Worker -X-> backend Store physique
```

`0.3.12` peut matérialiser l'edge `Worker -> ksp-onchain-transport-lib` si `pre.001` confirme qu'il est la frontière correcte pour la source Yellowstone/hydration. Aucun autre edge interdit n'est ouvert par simple commodité.

### 5.3 Identité et persistence

```text
RawTransaction identity = (network, signature)
mainnet = identité KSP canonique
mainnet-beta = alias legacy/externe seulement
```

La convergence Store reste : une entité canonique + observations/provenances distinctes. Un contenu canonique divergent reste `content_conflict`, jamais une règle « premier provider gagne » ou « dernier provider gagne ».

### 5.4 Séparation Job / Worker

```text
Job Backfill = historique paramétré, borné, terminable
Worker Ingest = acquisition continue start/stop, sans requête historique métier
```

Le Worker peut utiliser `from_slot`/replay pour restaurer **sa propre continuité de run**. Cela ne l'autorise pas à recevoir un scope historique arbitraire du caller ni à appeler `ksp-job-backfill-lib`.

## 6. Décisions acquises et questions réellement ouvertes

### 6.1 Décisions acquises

Conserver :

```text
un seul runtime Worker existant
un seul pipeline admission -> common RAW -> Store
sources réseau privées au supervisor
aucune API publique enqueue arbitraire
Transport générique réutilisé, aucun client Yellowstone dupliqué
HTTP est une capability normale du Worker pour hydration/repair live
Config/secrets restent hors Worker
provenance HTTP = route réellement observée
channels bornés
aucun drop silencieux
reconnect gRPC != replay/continuité restaurée
from_slot/replay du Worker limité à son frontier de run
Job et Worker indépendants
pas de RAW-direct Yellowstone complet sans preuve nouvelle
```

### 6.2 Questions à fermer dans `pre.001`

Auditer avant codage :

```text
forme exacte d'injection des ressources Transport dans RawTransactionIngestWorker::start ou une API voisine
si la surface publique actuelle doit évoluer ou si un objet runtime/source bundle privé suffit
ownership exact des source ids/capabilities/priorités
rôle de Config dans 0.3.12 et direction de dépendance correcte
quelles familles Yellowstone sont P0 réellement productives : transactions, blocks, status, blocks_meta, slots
stratégie d'hydration transaction vs block
clé de coalescence entre signal Yellowstone et résultat HTTP hydraté
provenance finale quand signal et hydration proviennent de transports/providers distincts
frontier exact : slot observed, slot persisted, contiguous slot, ou plusieurs dimensions
sémantique exacte de from_slot au démarrage/reconnect
traitement de SubscribeReplayInfo et absence de preuve provider
états source health/degraded/unhealthy/faulted réellement nécessaires
politique lorsque l'hydration renvoie missing/not-available temporaire
bornes de retry/backoff et ownership entre Transport et Worker
stop pendant reconnect/replay/hydration
besoin de nouveaux compteurs/snapshot fields sans fuite de matériel
smokes live réellement accessibles et secrets opérateur disponibles
```

Ne pas figer ces réponses dans l'API avant le gate `pre.001`.

## 7. Objectifs/livrables et hors périmètre

### 7.1 Livrables attendus de `0.3.12`

Sous réserve du sizing `pre.001` :

```text
adapter(s) Yellowstone productifs dans le Worker
projection Transport DTO -> common wire/material dans le producer Worker
hydration HTTP explicite lorsque requise
source tasks Yellowstone intégrées au supervisor existant
provenance sûre source + hydration
frontier de run et continuité bornée
from_slot/replay info exploités sans campagne historique
snapshots/health adaptés seulement si nécessaire
fixtures déterministes transaction/block/status/hydration
canaris de dependency firewall et redaction
smokes live opt-in sur accès réellement disponible
plan 0.3.12
validation 0.3.12
README/USAGE réconciliés en fin de release
```

Le `USAGE.md` reste version-neutral.

### 7.2 Hors périmètre de `0.3.12`

```text
WS logsSubscribe productif
WS blockSubscribe productif dans le Worker
Helius transactionSubscribe productif
HTTP live block polling multi-source complet
convergence simultanée de toutes les familles 0.3.13
gap repair multi-source complet 0.3.14
source redondante/failover final
EARLY shreds/deshred/feed vendor-specific
Desk d'ingestion 0.3.15
Backfill multi-source 0.3.16
D2 STRUCTURAL
backend Store direct
nouvelle migration Store sauf défaut réellement démontré et release rescindée si nécessaire
```

Si une responsabilité de `0.3.13+` devient indispensable pour rendre Yellowstone correct, `pre.001` doit expliquer le couplage et rescinder la trajectoire avant développement lourd.

## 8. Contraintes sécurité/API/architecture spécifiques

Le runtime live doit garantir au minimum :

```text
aucune URL/token/header/API key dans Debug/Display/snapshot/error public
aucun payload transaction/meta/log provider dans diagnostics
aucun remote status/message arbitraire recopié dans Error context
source ids/codes bornés et non secrets
provenance safe sans endpoint secret
frontier/replay state sans signature/payload
counter arithmetic checked/non-wrapping
queues bornées
aucun task leak après terminal
stop préemptif pendant connect/reconnect/hydration/replay
pas de double retry incontrôlé Transport + Worker
pas de busy loop en indisponibilité provider
pas de claim de continuité si un gap n'est pas prouvé réparé
```

L'hydration doit être explicitement classifiée :

```text
signal incomplet -> pending hydration
hydration complète -> admission RAW
missing temporaire -> état/retry borné défini par la tranche
matériau contradictoire -> fault/content conflict selon frontière réellement concernée
stop -> aucune nouvelle hydration/admission après frontière de stop
```

Le tracing reste via `ksp-logging-lib` et n'expose jamais la signature, le raw body, la meta, l'URL ou le credential.

## 9. Première mission `pre.001` — audit/sizing obligatoire

`pre.001` doit produire **avant toute implémentation lourde** :

1. vérification exacte de la base stable `v0.3.11` et du `rel.001` ;
2. lecture complète des sources internes listées ci-dessus ;
3. inventaire réel des surfaces Worker/Transport/Common RAW/Store/Config ;
4. audit externe courant Yellowstone/Solana/provider et versions de crates concernées ;
5. matrice exacte `Transaction / TransactionStatus / Block / BlockMeta / Slot / from_slot / ReplayInfo` : matériau disponible, gaps RAW, besoin d'hydration, preuve actuelle ;
6. architecture d'injection des ressources Transport sans Worker -> Config ni API publique enqueue ;
7. modèle de frontier/continuité du run et distinction reconnect/replay/repair ;
8. stratégie d'hydration HTTP et provenance cross-transport ;
9. threat model live : secrets, remote errors, saturation, duplicate signals, retry storms, reconnect races, stop during hydration/replay, stale frontier ;
10. inventaire des smokes réellement accessibles et conditions opérateur ;
11. graphe Cargo cible et features minimales ;
12. sizing de chaque tranche sous le budget 15–20 minutes ;
13. décision explicite : `0.3.12` reste clôturable dans une session ou doit être rescindée avant codage ;
14. création/révision des documents de release.

Documents attendus :

```text
docs/plans/033-V0_3_12_YELLOWSTONE_HYDRATION_CONTINUITY_PLAN.md
docs/validation/029-V0_3_12_YELLOWSTONE_HYDRATION_CONTINUITY.md
```

Le delta `pre.001` consigne les décisions fermées, les questions reportées, les dépendances réellement requises, les gates live possibles et le forecast recalibré.

Critère de sortie : la première tranche technique doit pouvoir être implémentée sans décider simultanément l'API source, l'hydration, le frontier et la stratégie de replay pendant le codage.

## 10. Prévision souple initiale des prereleases

Cette prévision est un **point de départ à recalibrer par `pre.001`**, pas un engagement de numérotation.

### `pre.001` — audit / brainstorming / sizing

Base stable, matrice Yellowstone, fraîcheur provider/proto, injection Transport, hydration, frontier, replay semantics, threat model, smokes accessibles, plan/validation et décision de maintien/rescission.

### `pre.002` — dependency/source contract

Matérialiser uniquement les edges/types runtime réellement nécessaires, en particulier l'edge Worker -> Transport si confirmé, sans encore ouvrir toutes les familles Yellowstone.

### `pre.003` — adapter Yellowstone transaction

Brancher la première tâche source `transactions`, projeter le transaction wire vers Common et prouver les gaps qui imposent l'hydration. Aucun RAW-direct non prouvé.

### `pre.004` — hydration HTTP transaction

Fermer signal Yellowstone -> `get_transaction_observed` -> common RAW -> admission/persistence, avec provenance sûre et comportement missing/error borné.

### `pre.005` — blocks / block metadata

Ajouter les formes Yellowstone block/block_meta réellement nécessaires, réutiliser la même canonicalisation et comparer leur matériau à l'hydration HTTP sans dupliquer le pipeline.

### `pre.006` — transaction status + source supervision

Intégrer `transactions_status` uniquement pour le rôle réellement démontré (discovery/status/hydration), source health et failures sans exposer de matériau provider.

### `pre.007` — frontier de run + from_slot / replay info

Matérialiser la continuité propre au run : frontier explicite, reconnexion distincte du replay, `from_slot` et replay info utilisés uniquement lorsqu'ils sont réellement supportés/provables.

### `pre.008` — races/retry/backpressure hardening live

Stop pendant connect/reconnect/hydration/replay, saturation, duplicate signals, retry ownership, Store slow/fault et absence de tâches orphelines. Scinder si nécessaire.

### `pre.009` — fixtures/cross-layer completeness

Canaris déterministes exacts sur les familles Yellowstone admises, hydration, provenance, common RAW, API root, dependency firewall et security scans.

### `pre.010` — gate live/technique final

Smokes accessibles si réellement configurés, workspace complet, Clippy strict, suites ciblées, arbres Cargo Worker normal/features et duplicate tree. Aucun nouveau scope fonctionnel.

### `pre.011` — réconciliation documentaire

README/USAGE, plan, validation et architecture/références réellement affectées. Aucun CHANGELOG/ROADMAP/prompt suivant.

### `pre.012` — préparation de publication

Prompt `0.3.13`, CHANGELOG, ROADMAP et fichiers mécaniques uniquement.

### `rel.001`

Publication stable mécanique sans rattrapage.

Si `pre.001` conclut que les familles Yellowstone + hydration + continuité dépassent une session, rescinder `0.3.12` avant `pre.002` au lieu de forcer ce forecast.

## 11. Versionnement, deltas, commits et tags

Règles obligatoires :

```text
livraison prerelease : 0.3.12-pre.NNN
Cargo               : 0.3.12-pre.N
fix code/runtime     : 0.3.12-pre.N.fix.M
fix doc-only         : ne bump pas Cargo
delta                : deltas/0.3.12/pre.NNN.md ou pre.NNN-fix.NNN.md
commit               : v0.3.12-pre.NNN[-fix.NNN]
tag prerelease       : aucun
tag stable final     : v0.3.12 seulement après rel.001 validée
```

Toute nouvelle prerelease non-fix synchronise `workspace.package.version`, même documentaire. Tout fichier modifié incrémente son header de version selon les règles du dépôt.

Les archives d'échange restent des deltas minimaux.

## 12. Procédure d'application et validation opérateur

Après application d'un delta technique :

```bash
cargo fmt --all -- --check
python3 scripts/audit_rust_workspace_rules.py
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings
```

Puis exécuter les tests ciblés de la tranche et conserver les logs opérateur réels. Une commande non lancée n'est jamais déclarée PASS.

Si un gate révèle un défaut, créer un fix appartenant strictement à la responsabilité de la tranche fautive. Ne pas absorber un défaut runtime dans le couloir documentaire ou publication.

## 13. Validations Rust / Transport / live / graphes pertinentes

À partir de l'activation Transport dans le Worker, le gate cible inclut progressivement :

```bash
cargo test -p ksp-worker-raw-transaction-ingest-lib
cargo test -p ksp-onchain-transport-lib
cargo test -p ksp-raw-transaction-lib
cargo test -p ksp-store-lib
cargo test -p ksp-worker-api
```

Selon les changements Config réellement retenus :

```bash
cargo test -p ksp-config-lib
```

Graphes à auditer lorsque l'edge Transport ou ses features sont matérialisés :

```bash
cargo tree -p ksp-worker-raw-transaction-ingest-lib --edges normal
cargo tree -p ksp-worker-raw-transaction-ingest-lib -e features
cargo tree --duplicates
```

À la fermeture technique :

```bash
cargo test --workspace --all-targets --all-features
```

Les smokes live sont **opt-in** et ne lisent jamais de secrets depuis le code/source. Le prompt `pre.001` doit déterminer ceux qui sont réellement accessibles. Une incapacité de tier/provider doit être documentée comme telle, pas transformée en fausse preuve PASS.

## 14. Critères de clôture de `0.3.12`

La release peut se fermer lorsque, sur la base réellement obtenue :

```text
fondation Worker 0.3.11 préservée sans second runtime
edge Transport minimal et justifié
au moins les familles Yellowstone retenues par pre.001 intégrées productivement
projection transaction wire -> common prouvée
hydration HTTP appliquée partout où le RAW complet l'exige
aucun RAW-direct Yellowstone revendiqué sans preuve byte/semantic exacte
provenance source/hydration sûre
frontier de run explicite et borné
reconnect distinct de replay/continuité
from_slot/replay info utilisés sans transformer le Worker en moteur historique
stop/fault/backpressure pendant tâches live durcis
aucune URL/token/remote payload dans diagnostics
Store uniquement via ksp-store-lib
aucun edge Worker -> Config/Job/backend physique
fixtures et canaris cross-layer verts
smokes accessibles exécutés ou blocage provider/tier explicitement qualifié
gates workspace/clippy/tests/trees verts
README/USAGE/plan/validation réconciliés
prompt 0.3.13 produit dans la dernière prerelease
```

## 15. Release suivante envisagée

`0.3.13` doit reprendre uniquement après publication stable de `0.3.12` et réauditer la mission :

```text
WS logsSubscribe + HTTP hydration
WS blockSubscribe direct sur le sous-ensemble déjà qualifié
Helius transactionSubscribe + hydration
HTTP live block polling
convergence simultanée multi-source
observations multiples/coalescence
backpressure et content conflict sous sources concurrentes
```

Le gap repair/hardening multi-source final reste `0.3.14`.

## 16. Instruction d'ouverture

Au début de la prochaine session :

1. vérifier que la base correspond exactement au tag stable `v0.3.11` et que `deltas/0.3.11/rel.001.md` est présent ;
2. lire les règles, le handoff `0.3.11`, l'architecture RAW acquisition et les sources Worker/Transport/Common/Store avant toute modification ;
3. réauditer les sources Yellowstone/Solana/provider actuelles et les versions de dépendances réellement concernées ;
4. produire `0.3.12-pre.001` avec matrice Yellowstone, architecture d'hydration/frontier, threat model, sizing, plan `033` et validation `029` ;
5. **ne pas ajouter l'edge Transport au Worker, ne pas coder une source Yellowstone productive et ne pas modifier Config avant fermeture de ce gate** ;
6. rescinder `0.3.12` immédiatement si le périmètre réel n'est pas clôturable dans une seule session.