26 KiB
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 :
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 :
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 :
0.3.12
Première livraison attendue :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
Pour tout Markdown touché :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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à :
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 :
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
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
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 :
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 :
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 :
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
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 :
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 :
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 :
- vérification exacte de la base stable
v0.3.11et durel.001; - lecture complète des sources internes listées ci-dessus ;
- inventaire réel des surfaces Worker/Transport/Common RAW/Store/Config ;
- audit externe courant Yellowstone/Solana/provider et versions de crates concernées ;
- matrice exacte
Transaction / TransactionStatus / Block / BlockMeta / Slot / from_slot / ReplayInfo: matériau disponible, gaps RAW, besoin d'hydration, preuve actuelle ; - architecture d'injection des ressources Transport sans Worker -> Config ni API publique enqueue ;
- modèle de frontier/continuité du run et distinction reconnect/replay/repair ;
- stratégie d'hydration HTTP et provenance cross-transport ;
- threat model live : secrets, remote errors, saturation, duplicate signals, retry storms, reconnect races, stop during hydration/replay, stale frontier ;
- inventaire des smokes réellement accessibles et conditions opérateur ;
- graphe Cargo cible et features minimales ;
- sizing de chaque tranche sous le budget 15–20 minutes ;
- décision explicite :
0.3.12reste clôturable dans une session ou doit être rescindée avant codage ; - création/révision des documents de release.
Documents attendus :
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 :
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 :
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 :
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 :
cargo test -p ksp-config-lib
Graphes à auditer lorsque l'edge Transport ou ses features sont matérialisés :
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 :
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 :
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 :
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 :
- vérifier que la base correspond exactement au tag stable
v0.3.11et quedeltas/0.3.11/rel.001.mdest présent ; - lire les règles, le handoff
0.3.11, l'architecture RAW acquisition et les sources Worker/Transport/Common/Store avant toute modification ; - réauditer les sources Yellowstone/Solana/provider actuelles et les versions de dépendances réellement concernées ;
- produire
0.3.12-pre.001avec matrice Yellowstone, architecture d'hydration/frontier, threat model, sizing, plan033et validation029; - 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 ;
- rescinder
0.3.12immédiatement si le périmètre réel n'est pas clôturable dans une seule session.