khadhroony-solana-project/docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md

Validation v0.3.15 — Raw Transaction Ingest Desk

1. Rôle

Ce document enregistre les preuves et non-claims de 0.3.15. En pre.001, aucune crate Desk, aucun Start/Stop Worker et aucune extension lower-layer ne sont encore implémentés : la tranche est exclusivement le gate de lecture, audit, brainstorming, external re-audit, sizing et planification imposé par prompts/034-V0_3_15_START_PROMPT.md.

2. Archive stable contrôlée

archive : khadhroony-solana-project-v0.3.14.zip
SHA-256 : 897bd30b0d06c00abc120a7459250b78c11629e84825ac29adbe151d60a668ed
bytes : 8591925
entries : 2046
files : 1851
absolute entries : 0
parent traversal entries : 0
duplicate entries : 0
symlink entries : 0
workspace members : 21
crate manifests : 21
workspace.package.version : 0.3.14
edition : 2024
stable delta : deltas/0.3.14/rel.001.md

Artefacts interdits recherchés :

Cargo.lock : absent
package-lock.json : absent
pnpm-lock.yaml : absent
yarn.lock : absent
rust-toolchain.toml : absent
.env : absent
target/ : absent
node_modules/ : absent
dist/ : absent
.git/ : absent

Résultat archive : PASS.

L'absence de .git empêche de comparer l'objet du tag v0.3.14; aucune équivalence cryptographique au tag n'est revendiquée.

3. Preuve opérateur stable fournie

Le journal opérateur joint à la demande contient notamment l'exécution stable 0.3.14 de :

cargo clean
cargo fmt --all
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
cargo test -p ksp-worker-raw-transaction-ingest-lib --all-targets --all-features
cargo test --workspace --all-targets --all-features
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

Les sorties fournies montrent notamment :

General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
KSP workspace Rust rule audit: clean
Markdown table audit: clean (340 table(s), 886 file(s))
Worker unit tests: 152 passed / 0 failed
Worker cross-layer completeness: 12 passed / 0 failed
Worker dependency boundary: 21 passed / 0 failed
Worker hardening: 38 passed / 0 failed
Worker public API: 22 passed / 0 failed
Worker release completeness: 15 passed / 0 failed

Le journal continue avec le gate workspace stable et ses tests. Cette preuve qualifie l'entrée 0.3.14; elle n'est pas réutilisée comme prétendue exécution post-bump 0.3.15-pre.1.

4. Audits locaux de la base avant modification

Exécuté localement :

python3 scripts/audit_rust_workspace_rules.py

Résultat :

General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
KSP workspace Rust rule audit: clean

Exécuté localement :

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

Résultat :

Markdown table audit: clean (340 table(s), 886 file(s))

cargo/rustfmt ne sont pas présents dans l'environnement d'assemblage courant. Aucune commande Cargo locale n'est déclarée PASS.

5. Audit des règles

Documents relus :

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

Scan des définitions normatives :

489 définitions
489 IDs uniques
0 doublon

Les deltas publiés antérieurs ne sont pas réécrits. Le gate pre.001 modifie uniquement Cargo.toml et ajoute les trois livrables exigés.

6. Handoff stable et Worker audités

Les documents 0.3.14, README/USAGE Worker et les sources/tests Worker ont été audités.

API publique pertinente confirmée :

RawTransactionIngestRuntimeResources
RawTransactionIngestYellowstoneSource
RawTransactionIngestStandardLogsSource
RawTransactionIngestStandardBlockSource
RawTransactionIngestHeliusTransactionSource
RawTransactionIngestHttpBlockPollingSource
RawTransactionIngestWorker::start_with_runtime_resources
RawTransactionIngestHandle
RawTransactionIngestSnapshotSource

Frontières confirmées :

Worker -X-> Config
Worker -X-> Job Backfill
Worker -X-> ksp-store-postgres-lib
Worker -> ksp-store-lib
Worker -> ksp-onchain-transport-lib

Plusieurs Workers peuvent recevoir le même Arc<Store> ; leurs lifecycle/gaps/TargetCoverage restent indépendants.

7. Requirements exacts des cinq familles Worker

Route V1	Network	Required capability	Optional capability	Config evidence	Worker resource	Composable aujourd’hui ?	Missing contract	Live-testable ?
yellowstone-hydrated	réseau du profil	Yellowstone gRPC Block Subscribe + HTTP getBlock même réseau	reconciliation HTTP bloc multi-provider	gRPC + HTTP role	RawTransactionIngestYellowstoneSource	oui sur profil complet et secrets résolus	aucun contrat essentiel	provider-gated selon profil
standard-logs-hydrated	réseau du profil	WS Solana standard logsSubscribe + HTTP getTransaction	scan HTTP repair si rôle compatible	WS + HTTP role	RawTransactionIngestStandardLogsSource	non prouvable strictement avant capability WS explicite	Transport + Config + enforcement Worker minimaux	oui, notamment Devnet keyless après extension
standard-block-direct	réseau du profil	WS Solana standard blockSubscribe explicitement déclaré	aucune hydration obligatoire	WS capability Block	RawTransactionIngestStandardBlockSource	non prouvable aujourd’hui	Transport + Config + enforcement Worker minimaux	seulement endpoint prouvé compatible
helius-transaction-hydrated	réseau du profil	WS Helius transactionSubscribe + HTTP getTransaction	scan HTTP repair si rôle compatible	Helius WS + HTTP role	RawTransactionIngestHeliusTransactionSource	non dans les profils committed actuels	Config data/composite + capability WS explicite	provider-gated Helius
http-block-polling	réseau du profil	HTTP getSlot + getBlocksWithLimit + getBlock	getTransaction pour known-reference hydration	HTTP role	RawTransactionIngestHttpBlockPollingSource	oui lorsque le rôle résolu annonce les trois méthodes	aucun contrat essentiel	oui sur endpoint public compatible

Qualification importante : Composable aujourd'hui ? signifie « prouvable à partir de la Config stable telle qu'elle est structurée », pas « le provider distant répond actuellement ».

8. Audit Config

ResolvedTransportConfig fournit des settings typed HTTP/WS/gRPC et ResolvedStoreConfig fournit les settings Store sans exiger une lecture JSON frontend.

HTTP : rôles et request_kinds sont déjà projetables côté Rust.

WS : le protocol kind est projetable, mais WsEndpointSettings ne porte pas de liste de WsSubscriptionKind. C'est le gap déterminant de pre.001.

Profils Transport sources audités (ils ne constituent pas les profils applicatifs du Desk) :

Profil/config	Réseau	Surfaces	Secret requis	Committed ?	Observation
devnet_public	devnet	HTTP + WS Solana standard	non	oui	pas de capability WS fine aujourd’hui
orbitflare_devnet	devnet	HTTP + WS standard + Yellowstone gRPC	token gRPC secret	conditionnel	profil complet seulement si secret résolu
mainnet_public	mainnet	HTTP + WS Solana standard	non	oui	pas de capability WS fine aujourd’hui
mainnet_backfill_pool	mainnet	plusieurs HTTP + WS standard	selon endpoint/config	oui si profil résolu	priorités/rôles restent Transport-owned
publicnode_mainnet	mainnet	HTTP + WS standard + Yellowstone gRPC	x-token secret	conditionnel	source Yellowstone same-network
testnet_public	testnet	HTTP + WS Solana standard	non	oui	socle keyless Testnet
publicnode_testnet	testnet	HTTP + WS standard + Yellowstone gRPC	x-token secret	conditionnel	source Yellowstone same-network
helius_devnet	devnet	HTTP public + WS Helius	API key secret	conditionnel	source Helius same-network
helius_mainnet	mainnet	HTTP public + WS Helius	API key secret	conditionnel	source Helius same-network

Ces profils sont des sources Transport. Le composite applicatif Raw Ingest les agrège désormais sous devnet, mainnet et testnet; un provider n'est jamais une identité réseau.

9. Audit Store

Chemin validé :

ResolvedStoreConfig -> StoreSettings -> ksp-store-lib::Store::open

Aucun besoin de nouvelle API Store n'est identifié pour inventaire, Start/Stop ou partage du Store entre Workers du même réseau.

10. Audit gabarit Desk

Les cinq Desk KSP existantes ont été utilisées comme références de structure et non comme code à copier pendant pre.001.

Socle confirmé :

splash KSP commun
fonts/style KSP
backend Tauri Rust propriétaire des ressources
frontend sans accès direct réseau/Store/secrets
@fltsci/tauri-plugin-tracing
@fortawesome/fontawesome-free
@tauri-apps/api
bootstrap
resize-observer-polyfill
simplebar

Aucun upgrade npm opportuniste n'est retenu.

11. External re-audit pre.001

Sources primaires/courantes consultées pour qualifier les capabilities :

Solana JSON-RPC WebSocket blockSubscribe
Solana JSON-RPC WebSocket logsSubscribe
Yellowstone gRPC upstream Subscribe/proto/changelog
Helius WebSocket standard + transactionSubscribe + unsupported methods
PublicNode Solana RPC/WS/Yellowstone offre actuelle
OrbitFlare Yellowstone gRPC offre actuelle

Constats utilisés :

blockSubscribe est unstable et dépend de l'activation côté validator/provider
logsSubscribe est standard
Helius distingue les méthodes Solana standard de son extension transactionSubscribe
Helius indique blockSubscribe non supporté
Yellowstone expose les filtres Subscribe et le replay/from_slot lower-layer

Aucune de ces informations Web n'est convertie directement en route sélectionnable : Config locale reste l'autorité de composabilité.

12. Gap classification

Sujet	Classification	Owner	Décision
Catalogue de cinq routes et IDs applicatifs	adaptation app seulement	Desk	catalogue borné, pas de nouvelle crate
Projection HTTP request_kinds / rôles / réseau	aucun gap	Config + Transport	déjà exploitable côté Rust
Projection gRPC Yellowstone / metadata sûre	aucun gap	Config + Transport	secrets restent Rust-only
Capability WS exacte par subscription	extension Transport minimale	Transport	ajouter une déclaration typed réutilisant WsSubscriptionKind
Mapping schema/config des capabilities WS	extension Config minimale	Config	Config reste propriétaire de la déclaration
Refus Worker si capability WS requise absente	extension Worker minimale	Worker	enforcement avant I/O, pas de logique provider dans Desk
Composite dédié Raw Ingest Desk	extension Config minimale	Config	profils app dédiés et cohérents Store/Transport
Store open / network / partage Arc<Store>	aucun gap	Store + app	ksp-store-lib suffit
Lifecycle / stop / snapshots Worker	aucun gap	Worker + app	handles publics existants
Backfill / historical repair	hors scope	Job Backfill	aucune orchestration automatique
Taille release	pas de split de release	plan	forecast étendu jusqu’à pre.016

Résultat : 0.3.15 reste une release cohérente. Aucun split vers 0.3.16 n'est nécessaire avant implémentation, mais le forecast interne est élargi.

13. Décisions UX / architecture validées au gate

catalogue de routes V1 app-owned
cinq route IDs bornés
réseau dérivé d'un composite/profil app cohérent Store+Transport
changement de profil interdit pendant Workers actifs
inventaire Config sans I/O réseau
Start revalide toute la Config
multiple endpoints satisfaisant une route : sélection Transport selon rôles/priorités
1 Worker par route
fault d'une route n'arrête pas les autres
Store partagé seulement si réseau strictement identique
fermeture app : stop/join de tous les Workers détenus
frontend sans endpoints/secrets/handles/source keys/payloads bruts

États UI retenus :

État UI	Sémantique	Action principale
Unavailable	requirements incomplets ou incohérents	non
Configured	requirements Config complètes, aucune preuve runtime	oui
Starting	revalidation + reconstruction + ouverture Store + start Worker	non
Running	Worker actif, snapshots reçus	Stop
Stopping	stop demandé, attente terminale bornée	non
Stopped	Worker terminal propre, handle retiré	Start après nouvelle revalidation
Faulted	échec Start/runtime avec code sûr	Start après correction/revalidation

14. IPC et tracing planifiés

DTO candidat	Sens	Contenu autorisé	Exclusions
RawIngestDeskOptionsDto	backend -> frontend	profils logiques sûrs, réseaux, commitments supportés, génération inventaire	URL, secret, Store URI
RawIngestRouteDto	backend -> frontend	route_id, family, label, network, state, selectable, reason code	endpoint name/URL/token/source key
RawIngestRouteStartRequestDto	frontend -> backend	profile_id, route_id, inventory_generation, commitment	endpoint/credential/client
RawIngestRouteStopRequestDto	frontend -> backend	route_id	Worker handle
RawIngestRouteRuntimeDto	backend -> frontend	route_id, lifecycle/health/activity, compteurs source-neutral	payload brut, erreur provider arbitraire
CommandErrorDto	backend -> frontend	code stable + contexte whiteliste	texte remote arbitraire
FrontendLogPayloadDto	frontend -> backend	target/level/action IDs bornés	valeurs config/route sensibles

Interaction	Trace autorisée	Interdit
Navigation/tab	control_id + action	aucun profil, endpoint ou secret
Sélection profil/réseau	action + résultat code + counts	pas de valeur de secret ni URL
Sélection route	route family/route_id sûr + booléen	pas de source key
Start/Stop	route_id sûr + lifecycle outcome code	pas de payload Worker
Refresh/resync snapshots	action + sequence/count	pas de transactions
IPC success/failure	command id + stable code + durée éventuelle	pas d’erreur remote brute

Ces tables décrivent le contrat de sécurité à implémenter ; elles ne revendiquent aucune commande Tauri existante en pre.001.

15. Sizing / forecast souple

Le forecast durable est porté par la section 20 du plan 036 sous forme hiérarchique éditable, et non par un tableau. La validation conserve ici la même séquence afin que le statut de chaque tranche puisse être complété sans réécrire la structure documentaire.

pre.001 — cadrage

Statut : réalisé. Audit, route model, external re-audit, sizing et plan/validation, sans code fonctionnel Desk.

pre.001-fix.001 — forme du forecast

Statut : réalisé ; documentaire uniquement. Le tableau de forecast initial est remplacé par la convention KSP ### pre.NNN / #### pre.NNN-fix.MMM. Aucun contenu fonctionnel du sizing n'est changé.

pre.002 — Transport WS capability

Statut : réalisé après pre.002-fix.001. Capability WS typed par subscription + tests, sans app. Le gate opérateur du fix passe cargo check, Clippy -D warnings et la suite Transport complète.

pre.003 — Config capability/composite

Statut : réalisé et gate opérateur PASS. Schema/mapping capabilities WS + composite/profils Raw Ingest Desk. Les profils standard committed déclarent la surface stable sans Block, les profils Helius déclarent explicitement HeliusTransaction sans Block/Vote, et les profils du composite Raw Ingest Desk couplent Transport+Store sur le même réseau. Le gate opérateur passe cargo check, Clippy -D warnings, cargo test -p ksp-config-lib --all-targets --all-features (130 tests unitaires PASS) et cargo test --workspace --all-targets --all-features.

pre.004 — Worker enforcement

Statut : réalisé et gate opérateur PASS. Les trois constructeurs de routes WS (Standard Logs, Standard Block, Helius Transaction) exigent la capability Transport exacte via supports_subscription(...) et refusent l'état undeclared/capability absente avant toute I/O. Le protocole reste validé avant la capability afin de conserver des diagnostics stables. Yellowstone et HTTP Block Polling ne sont pas concernés. Des canaris unitaires prouvent le refus undeclared/mauvaise capability et l'acceptation de la capability exacte ; les canaris hardening/release-completeness prouvent l'ordre avant connect, l'absence de logique provider et l'absence de croissance de surface publique. Le gate opérateur passe les audits, cargo check, Clippy strict, 153/153 tests unitaires Worker, les suites Worker d'intégration et le workspace all-targets/all-features complet.

pre.005 — scaffold Desk

Statut : réalisé et gate opérateur PASS après deux fixes. ksp-app-raw-transaction-ingest-desk existe comme crate Tauri mixte lib/bin, ports 1440/1441, splash/assets/fonts communs, Config/Logging et tracing frontend. pre.005-fix.001 retire un import Rust inutilisé détecté par Clippy. pre.005-fix.002 restaure le template clair commun des Desk KSP, corrige le débordement de #routeFoundation et le retour explicite du canari release-completeness. Le gate final passe audits, cargo check, Clippy strict, tests Desk, cargo test --workspace --all-targets --all-features et cargo tauri dev; le parcours visuel confirme le shell corrigé. Aucun script npm applicatif n'est lancé directement : Tauri déclenche ses hooks conformément à KSP-APP-034.

pre.006 — inventaire composable

Statut : gate opérateur de pre.006 en échec fonctionnel, puis corrections pre.006-fix.001, pre.006-fix.002 et pre.006-fix.003. Le premier inventaire classait encore les capabilities par profil Transport fournisseur : Yellowstone + HTTP hydration Mainnet n'était donc Configured que sous publicnode_mainnet. Le fix remplace cette projection par trois profils réseau (devnet, mainnet, testnet) qui agrègent les sources Transport same-network. PublicNode, Helius et OrbitFlare restent des sources de capabilities et ne deviennent jamais des identités réseau. Un secret optionnel absent n'invalide que la route dépendante. Le canari qui dépendait du Config utilisateur de la machine est remplacé par un moteur Config committé et un environnement injecté. Aucun I/O runtime n'est ajouté.

pre.006-fix.001 — correction classification réseau

Attendus : mainnet expose Yellowstone dès que la source PublicNode Mainnet est effectivement résolue, quelle que soit la source HTTP/WS standard retenue dans le même profil réseau ; mainnet reste utilisable pour Standard Logs et HTTP Block Polling lorsque les secrets Helius/PublicNode sont absents. Le même principe s'applique à Devnet et Testnet.

pre.006-fix.002 — Standard Block réellement composable

Le gate de pre.006-fix.001 révèle deux points : les canaris Desk ne compilent pas car ils appellent ConfigEnvironment::from_maps, helper pub(crate)/cfg(test) de ksp-config-lib, et standard-block-direct reste systématiquement indisponible parce qu'aucun endpoint standard committed ne déclare Block.

Le fix déclare explicitement Block sur les endpoints solana-public Standard WS committés de Devnet, Mainnet et Testnet, sans toucher Helius LaserStream. L'inventaire réseau-centrique projette donc standard-block-direct en Configured sur les trois réseaux. Cette classification reste une preuve Config de composabilité, pas une preuve live permanente : blockSubscribe reste unstable et validator/provider-gated, donc pre.007/Start devra reconstruire et revalider la ressource exacte avant exécution.

Les canaris Desk n'utilisent plus l'API crate-private de Config. Ils valident les routes standard à partir de ConfigEnvironment::load() et acceptent que les routes optionnelles Helius/Yellowstone soient soit Configured, soit missing_required_secret selon l'environnement opérateur.

pre.006-fix.003 — Helius Testnet non applicable

Le parcours visuel de pre.006-fix.002 montre toutes les routes composables en vert sauf helius-transaction-hydrated sur Testnet. Ce rouge était trompeur : le composite Testnet ne déclare aucune source transport.helius, et Helius Enhanced WebSocket transactionSubscribe n'est pas une capability Testnet configurée. Le fix ne falsifie donc pas la capability ; il retire cette route provider-specific de l'inventaire Testnet. Devnet/Mainnet continuent à la projeter et à la qualifier selon leur source Helius.

Le catalogue global reste exactement cinq IDs V1, mais l'inventaire d'un profil réseau contient uniquement les routes applicables à ses sources déclarées. Le canari frontend obsolète logical profile selected est également réaligné sur le tracing réseau-centrique logical network selected.

pre.007 — ressources Start

Statut : réalisé et gate opérateur PASS après pre.007-fix.001 et pre.007-fix.002. Le préflight backend validate_route_start est generation-bound et revalide la sélection contre un inventaire Config reconstruit avant toute ressource. La requête contient désormais profile_id + route_id + inventory_generation + commitment : profile_id est nécessaire depuis que les profils applicatifs sont réseau-centriques et qu'un même route ID existe sur plusieurs réseaux.

La preuve Start-time exige ensuite :

Store Config résolu et réseau identique
Transport de base résolu et same-network
source provider-specific résolue seulement pour Helius/Yellowstone
HTTP role unique satisfaisant l'ensemble des méthodes requises
WS/gRPC endpoint unique correspondant au protocole/capability/réseau
constructeur public Worker de la famille exacte accepté

Les cinq constructeurs source Worker sont effectivement réutilisés. HttpTransportPool::new et YellowstoneGrpcChannel::prepare restent sans requête réseau ; la source reconstruite est détruite immédiatement après validation. Sont encore interdits dans cette tranche : Store::open, connexion WS/gRPC active, RawTransactionIngestRuntimeResources, RawTransactionIngestWorker::start_with_runtime_resources, handle Worker, Start/Stop réel et état Running.

Attendus de sécurité : la réponse de préflight ne contient que profil logique, réseau, route, génération et commitment ; les erreurs lower-layer sont remappées derrière des codes/messages app bornés. Aucun endpoint, URL, credential, metadata secrète, URI Store, source key ou payload RAW ne traverse IPC.

pre.007-fix.001 corrige deux erreurs syntaxiques de l'assemblage initial (double visibilité pub(crate) et littéraux de canari mal échappés). pre.007-fix.002 rend le canari de reconstruction hermétique en l'adossant explicitement aux racines Config committées du workspace au lieu des racines par défaut de la machine. Le gate opérateur final de 0.3.15-pre.7.fix.2 passe audits Rust/Markdown, cargo check --workspace, Clippy workspace strict, les 34 tests unitaires Raw Ingest Desk, ses suites d'intégration et le workspace --all-targets --all-features; cargo tauri dev compile et lance ensuite l'application.

pre.008 — runtime mono-route

Implémenté dans l'assemblage de tranche : Start réutilise la revalidation pre.007, réserve un slot runtime unique, ouvre le Store exclusivement via ksp-store-lib, exige StoreHealthState::Ready, construit un WorkerId backend-owned puis appelle RawTransactionIngestWorker::start_with_runtime_resources. Le handle est installé avant l'accusé IPC.

Stop demande l'arrêt coopératif au handle et attend son état terminal. Un monitor backend indépendant attend également le terminal, récupère de manière bornée l'unique Arc<Store>, appelle explicitement Store::close() puis libère le slot. Les échecs avant installation du handle rollbackent le slot et ferment le Store déjà ouvert.

Surface IPC sûre ajoutée : start_route et stop_route, avec RawIngestRouteRuntimeDto limité à profile_id, network, route_id, inventory_generation, commitment et state. Aucune URL, credential, URI Store, source key, WorkerId, handle ou payload RAW n'est projeté.

Le frontend fournit un contrôle minimal Start/Stop mono-route et le choix confirmed/finalized. Il ne prétend pas encore fournir le monitoring continu : une terminaison spontanée est nettoyée backend-side mais sa projection temps réel demeure pre.010. Multi-route, Store partagé entre Workers et isolation inter-route demeurent pre.009.

pre.008-fix.004 — preuve live Mainnet et correction PublicNode

Le parcours live pre.008-fix.003 prouve que le channel Yellowstone PublicNode Mainnet s'ouvre et produit des transactions, mais que l'hydration était construite depuis le Transport de base mainnet_public. Les traces montraient donc le gRPC publicnode_solana_mainnet_yellowstone suivi de requêtes getTransaction via solana_mainnet_public, puis rate-limit/cooldown et overflow de queue.

Le fix corrige la composition : prepare_yellowstone prend désormais son role/pool HTTP dans le même ResolvedTransportConfig optionnel qui fournit le gRPC. Le profil publicnode_mainnet expose publicnode_solana_mainnet_rpc sur https://solana-rpc.publicnode.com, provider publicnode, sans recopier la limite locale 5 req/s du profil Solana-public. La concurrence locale reste bornée à 8 et le cooldown Transport sur 429 reste actif.

Non-claim : ce changement réduit une erreur de composition mais ne garantit pas qu'une hydration HTTP unitaire puisse suivre le firehose Mainnet. pre.009 choisit finalement Yellowstone Block -> getBlock multi-provider comme optimisation sûre ; la projection protobuf -> RAW directe reste non revendiquée.

pre.009 — optimisation Mainnet et runtime multi-route

La tranche matérialise un Worker indépendant par route, Stop ciblé, Store partagé uniquement sur identité réseau exacte et fermeture Store par la dernière route. Les faults restent route-local et aucune TargetCoverage/gap/frontier n'est partagée entre Workers.

La route Yellowstone bascule sur un filtre Block sans transactions embarquées puis reconcile le slot par getBlock Full/Base64. Le Worker distingue explicitement son ancien mode transaction-hydration du mode block-reconciliation ; ce dernier n'entre plus dans la registry d'hydration getTransaction. La récupération bloc est interruptible par Stop et retente de façon bornée lorsque le bloc n'est pas encore visible ou qu'un endpoint du pool échoue.

Le profil publicnode_mainnet contient deux endpoints HTTP de même rôle : PublicNode et Solana public repair. La validation doit prouver que Config conserve leurs limites séparées et que la route exige désormais getBlock, pas getTransaction. Le direct protobuf -> RAW n'est pas revendiqué.

pre.010 — monitoring

Snapshots/events/monitoring lifecycle-health-activity-backpressure-reconnect-replay-gaps-repair.

pre.011 — frontend

Frontend fonctionnel complet + tracing TypeScript sûr.

pre.012 — hardening

Races, shutdown app, sécurité IPC, hardening hostile/stale inventory.

pre.013 — completeness

Cross-layer completeness + canaris système sans expansion de frontières.

pre.014 — gate technique/live

Gate technique/live accessible + frontend/Tauri + build final de validation technique.

pre.015 — réconciliation documentaire

Plan/validation/README/USAGE uniquement selon les surfaces réellement affectées.

pre.016 — préparation publication

Prompt suivant + CHANGELOG + ROADMAP + mécanique minimale de publication.

rel.001 — stable

Publication mécanique uniquement, aucun rattrapage fonctionnel.

Le forecast initial du prompt n'est pas recopié : trois tranches lower-layer précèdent volontairement le scaffold UI.

16. Modifications pre.001

Ajouts :

docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md
docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md
deltas/0.3.15/pre.001.md

Modification :

Cargo.toml
header 593 -> 594
workspace.package.version 0.3.14 -> 0.3.15-pre.1

Aucun fichier de production Rust, Config, frontend ou Tauri n'est modifié par le gate.

17. Validations post-modification

Exécuté localement après le bump et l’ajout des trois livrables :

python3 scripts/audit_rust_workspace_rules.py

Résultat :

General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
KSP workspace Rust rule audit: clean

Exécuté localement :

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

Résultat :

Markdown table audit: clean (354 table(s), 889 file(s))

Contrôles complémentaires :

rule definitions : 489
unique rule IDs : 489
duplicates : 0
stable -> worktree : 3 additions / 1 modification / 0 deletion
modified stable file : Cargo.toml seulement

Non exécuté localement :

cargo fmt --all -- --check : NON EXÉCUTÉ — cargo absent du sandbox
cargo check --workspace : NON EXÉCUTÉ — cargo absent du sandbox
cargo clippy --workspace --all-targets --all-features -- -D warnings : NON EXÉCUTÉ — cargo absent du sandbox
cargo test : NON EXÉCUTÉ — cargo absent du sandbox

Aucun de ces gates Cargo n’est déclaré PASS. Ils restent dans le gate opérateur après application du delta.