# Prompt de démarrage `0.3.14` — gap repair / hardening multi-source du Worker `RawTransaction` ## 1. Identité de la release et base exacte requise Ouvrir **uniquement** `0.3.14` depuis la release stable/taggée : ```text v0.3.13 ``` La base de travail fournie par l'opérateur est autoritaire sur les souvenirs, snippets, anciennes archives et deltas intermédiaires. Avant toute modification, vérifier au minimum : ```text workspace.package.version = 0.3.13 deltas/0.3.13/rel.001.md présent ksp-worker-raw-transaction-ingest-lib présent avec composition 1..32 sources d'un même réseau cinq familles live productives présentes : Yellowstone / Standard Logs / Standard Block / Helius Transaction / HTTP Block Polling Yellowstone / Standard Logs / Helius partagent l'hydration globale getTransaction observed Standard Block / HTTP Block Polling restent RAW-direct sur Legacy/V0/V1 qualifiés convergence canonique network/signature + observations multiples + content conflict explicite source failure encore terminale faute d'équivalence de coverage prouvée processing frontier encore run-local, sans checkpoint durable ni campagne historique Worker sans dépendance Config/Job/backend Store direct ksp-store-lib reste la seule façade Store du Worker ``` Release ouverte : ```text 0.3.14 ``` Première livraison attendue : ```text 0.3.14-pre.001 ``` `pre.001` est obligatoirement un gate de **lecture + audit interne/externe + brainstorming + sizing + planification**. Il ne commence pas directement un moteur de repair, une politique degraded/failover ou un adapter EARLY. Si le périmètre réel n'est pas clôturable dans une seule session ou si une tranche paraît dépasser environ 15–20 minutes de travail effectif, rescinder avant l'implémentation lourde. ## 2. Mission et résultat attendu ### 2.1 Mission de `0.3.14` Fermer le Worker continu `RawTransaction` par la **réparation de continuité limitée au run actif** et le hardening multi-source qui restaient volontairement hors `0.3.13` : ```text replay natif lorsqu'il est réellement adressable par Transport/provider preuve de couverture par source live redondante scan HTTP de slots/blocs pour réparer une plage manquante du run hydration getTransaction des références manquantes lorsque nécessaire réconciliation explicite des gaps avant reprise normale unresolved gaps observables et bornés politiques Healthy / Degraded / Unhealthy / Faulted fondées sur des preuves de coverage backpressure/fairness pendant repair shutdown/fault pendant replay/scan/hydration/persistence smokes provider réellement accessibles adapter EARLY uniquement si pre.001 apporte une preuve actuelle suffisante et un périmètre borné ``` Le Worker ne devient pas un moteur historique paramétré. Une demande arbitraire telle que « récupère le programme X depuis le slot Y » reste la responsabilité indépendante de `ksp-job-backfill-lib` et de la trajectoire `0.3.16`. ### 2.2 Pipeline durable à préserver Le chemin nominal `0.3.13` reste le cœur unique : ```text source live -> signal ou matériau source/protocole -> hydration si nécessaire -> ksp-raw-transaction-lib -> RawTransaction + RawTransactionObservation -> admission centrale Worker -> ksp-store-lib ``` Le repair ajoute un chemin de continuité autour de ce cœur, pas un second pipeline : ```text preuve de gap du run -> qualification de la plage et des capabilities disponibles -> replay Transport OU coverage redondante OU scan HTTP borné -> hydration éventuelle -> même Common RAW / même admission / même Store -> preuve de réconciliation OU unresolved gap explicite -> reprise live ``` Ordre architectural déjà acquis pour un gap du run, sous réserve des capabilities réellement prouvées : ```text 1. replay adressable du stream depuis le frontier connu 2. source live redondante ayant réellement couvert la plage 3. HTTP getBlock/getTransaction pour les slots/références manquants 4. reprise live après réconciliation ``` Aucune étape ne reçoit de requête historique arbitraire du caller. ## 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.13` Lire intégralement : ```text docs/plans/034-V0_3_13_MULTI_SOURCE_LIVE_CONVERGENCE_PLAN.md docs/validation/030-V0_3_13_MULTI_SOURCE_LIVE_CONVERGENCE.md deltas/0.3.13/pre.013.md deltas/0.3.13/pre.014.md deltas/0.3.13/pre.015.md deltas/0.3.13/rel.001.md 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 convergence multi-source `0.3.13` est une base à préserver, pas un prototype à remplacer. ### 3.3 Architecture RAW, continuité et séparation Worker/Job Lire intégralement : ```text docs/architecture/004-COMPONENT_INVENTORY.md docs/architecture/005-DEPENDENCY_GRAPH.md docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md crates/ksp-job-backfill-lib/README.md crates/ksp-job-backfill-lib/USAGE.md crates/ksp-raw-transaction-lib/README.md crates/ksp-raw-transaction-lib/USAGE.md crates/ksp-store-api/src/ crates/ksp-store-lib/src/ ``` Porter une attention particulière à : ```text continuité Worker limitée au run courant reconnect réussi != absence de gap replay attempt != preuve de repair réussi processing frontier != blockchain completeness Store durable != coverage du réseau Worker -X-> Job Backfill Job Backfill -X-> Worker aucun checkpoint partagé Worker/Job même identité + même contenu -> idempotence + observations distinctes même identité + contenu divergent -> content conflict explicite ``` ### 3.4 Transport et capabilities de replay/repair 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/yellowstone_*.rs crates/ksp-onchain-transport-lib/src/ws_*.rs crates/ksp-onchain-transport-lib/src/rpc_transactions.rs crates/ksp-onchain-transport-lib/src/rpc_blocks.rs crates/ksp-onchain-transport-lib/src/http_*.rs crates/ksp-onchain-transport-lib/tests/ ``` Réutiliser les sessions/actors Transport existants. Il est interdit de recréer dans le Worker : ```text socket WebSocket bas niveau parallèle client Yellowstone/Helius parallèle client reqwest direct reconnect/resubscribe actor concurrent seconde boucle de retry autour des primitives Transport SDK provider pour contourner Transport ``` Le Worker ne doit pas écrire arbitrairement `from_slot` ni interpréter un message provider brut lorsque Transport possède déjà la sémantique correspondante. ### 3.5 Config, providers et secrets Lire : ```text crates/ksp-config-lib/src/transport.rs config/std.transport.json config/examples/std.transport.example.json config/schemas/std.transport.schema.json .env.example ``` Config reste l'unique propriétaire des endpoints, profils, capabilities et secrets. Le Worker ne lit jamais l'environnement et ne reçoit jamais une clé API comme payload métier. Une modification Config n'est autorisée que si `pre.001` prouve un besoin réel non satisfait par les profils existants. Aucun tier, quota ou prix provider n'est codé dans le Worker. ## 4. Sources externes normatives et fraîcheur à réauditer Au début de `pre.001`, réauditer les surfaces courantes depuis les sources primaires réellement actuelles : ```text Solana RPC / WebSocket getSlot getBlocks / getBlocksWithLimit getBlock getTransaction logsSubscribe / blockSubscribe et sémantique de reconnexion pertinente Yellowstone gRPC upstream Subscribe from_slot SubscribeReplayInfo / first_available lorsque présents dans la version réellement utilisée limites et sémantique de replay réellement exposées Providers réellement candidats/configurés profondeur de replay actuelle réseaux disponibles auth/tier/quota actuels comportement de first_available / rétention éventuelles APIs historiques distinctes du live Helius et autres surfaces EARLY seulement si elles sont réellement reconsidérées matériau disponible finalité/exécution prouvable nécessité d'hydration disponibilité/tier actuel ``` Les prix, profondeurs de replay, quotas et entitlements historiques de `docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md` sont des traces datées, pas des constantes à recopier sans revalidation. Si les crates/projets primaires concernés ont évolué, vérifier leurs versions stables courantes, features nécessaires et contraintes transitives avant toute modification. ## 5. État validé à préserver La base stable `0.3.13` apporte déjà : ```text RawTransactionIngestRuntimeResources : 1..32 sources logiques, même réseau, identités uniques Yellowstone productive Standard Logs -> getTransaction observed -> Common RAW Standard Block -> RAW-direct Legacy/V0/V1 qualifié Helius Transaction -> getTransaction observed -> Common RAW HTTP Block Polling -> RAW-direct Legacy/V0/V1, borne initiale du run registre global d'hydration Yellowstone / Standard Logs / Helius coalescence network/signature/commitment avant hydration sérialisation run-local des acquisitions network/signature observations multiples conservées content conflict explicite sans majorité ni first-provider-wins quotas/backpressure/fairness bornés health source-neutral conservative shutdown/fault/drain/abort/join bornés ``` Le gate technique `0.3.13` a qualifié le workspace déterministe et les smokes keyless HTTP/WebSocket Devnet. Les smokes provider/token/resource-gated non exécutés restent non exécutés ; `0.3.14` ne doit pas les réécrire comme PASS sans nouveau résultat réel. État de continuité à l'ouverture : ```text reconnect/replay natif reste Transport-owned processing_frontier_slot reste run-local continuity gap prouvé reste terminal dans 0.3.13 aucune preuve de coverage équivalent entre sources n'autorise encore un failover non terminal aucun moteur HTTP de repair rétroactif du run n'est encore fermé aucun unresolved-gap model public final n'est encore stabilisé aucun adapter EARLY n'est retenu par défaut ``` ## 6. Décisions acquises et questions réellement ouvertes ### 6.1 Décisions acquises ```text repair Worker = continuité de son run actif uniquement Backfill = historique paramétré/borné indépendant aucune dépendance Worker <-> Job Backfill Transport possède reconnect/resubscribe/retry et replay natif qu'il sait adresser Worker possède la réconciliation source-neutral de ses gaps observés Common RAW et Store restent le chemin unique de matérialisation/persistence content conflict reste terminal et explicite une source redondante ne prouve un repair que si sa coverage de la plage est démontrée un skipped/non-produced slot ne doit pas être inventé comme transaction manquante un gap non réparé doit rester visible et ne peut pas être effacé par une reprise live aucun exactly-once blockchain n'est revendiqué ``` ### 6.2 Questions ouvertes à fermer en `pre.001` ```text forme minimale du gap/range run-local et de son identité preuve de coverage par famille de source sans exposer le matériau provider preuve qu'un replay Transport a réellement couvert la plage demandée traitement exact des skipped slots et slots temporairement indisponibles bornes de scan HTTP et politique de retry sans doubler Transport critère atomique « repaired » vs « unresolved » interaction entre repair et processing frontier existante politique required/redundant et transitions Healthy/Degraded/Unhealthy/Faulted priorité entre plusieurs mécanismes de repair simultanément disponibles quotas/fairness entre trafic nominal et trafic de repair projection snapshot des gaps sans fuite d'identité provider sensible smokes réellement possibles avec les ressources opérateur EARLY : rejet confirmé ou adapter dédié réellement justifié/provable ``` Une question ouverte n'est pas résolue arbitrairement avant l'audit. ## 7. Objectifs, livrables et hors périmètre ### 7.1 Livrables de release `0.3.14` doit aboutir, selon le sizing validé, à : ```text modèle source-neutral de gap/coverage run-local repair par replay natif lorsque Transport le prouve adressable repair par source redondante lorsque sa coverage est démontrée repair HTTP borné par slots/blocs/références du run hydration de réparation via les façades Transport existantes réconciliation explicite repaired/unresolved avant reprise health policy multi-source fondée sur coverage réelle backpressure/fairness bornés avec trafic de repair observabilité source-neutral des gaps et repairs shutdown/fault déterministe pendant toute phase de repair canaris cross-layer/security/completeness smokes réellement accessibles ou statut NON EXÉCUTÉ explicite plan/validation/documentation réconciliés prompt 0.3.15 dans la dernière prerelease ``` ### 7.2 Hors périmètre ```text campagne historique arbitraire pilotée par le Worker appel ou orchestration automatique de ksp-job-backfill-lib checkpoint durable partagé Worker/Job Backfill multi-source/multi-stratégie 0.3.16 ksp-app-raw-transaction-ingest-desk 0.3.15 persistence STRUCTURAL/DECODED/DOMAIN exactly-once réseau/provider majorité provider ou overwrite d'un content conflict second actor/client Transport dans Worker provider SDK contournant ksp-onchain-transport-lib nouveau système de secrets hors Config EARLY sans preuve actuelle suffisante ``` ## 8. Contraintes sécurité / API / architecture spécifiques Les frontières suivantes sont bloquantes : ```text Worker -> ksp-onchain-transport-lib : autorisé Worker -> ksp-raw-transaction-lib : autorisé Worker -> ksp-store-lib : autorisé Worker -> ksp-config-lib : interdit Worker -> ksp-job-backfill-lib : interdit Worker -> backend Store physique : interdit Worker -> reqwest/tokio-tungstenite/tonic/proto provider direct : interdit ``` Le caller compose les ressources déjà résolues. Le Worker ne reçoit ni endpoint brut non validé, ni token, ni API key comme paramètre métier. Le repair doit être borné en mémoire, nombre de ranges, taille de plage, nombre de requêtes simultanées, hydrations in-flight et files d'attente. Toute nouvelle borne publique possède validation, tests de limites et diagnostics redacted. Une source perdue ne devient pas silencieusement optionnelle. Toute transition non terminale après perte d'une source doit être justifiée par une preuve explicite que les autres mécanismes couvrent réellement le même intervalle pertinent. Un mécanisme de repair ne contourne jamais l'idempotence/conflit Store : tout matériau réparé repasse par Common RAW et l'admission centrale. ## 9. Première mission `pre.001` — audit / brainstorming / sizing `pre.001` doit exécuter et documenter, avant codage lourd : 1. vérification exacte de la base stable `v0.3.13` et de `deltas/0.3.13/rel.001.md` ; 2. lecture complète des sources internes listées ci-dessus ; 3. inventaire du modèle actuel de frontier/reconnect/replay/continuity counters dans Worker et Transport ; 4. audit externe courant Solana/Yellowstone/providers réellement concernés ; 5. matrice par famille live : capacité à détecter un gap, rejouer, prouver coverage, hydrater, scanner, reprendre ; 6. distinction formelle reconnect / replay attempt / replay covered / repair / unresolved gap ; 7. modèle cible minimal de gap/range/coverage run-local, privé ou public selon consumer réel ; 8. algorithme borné de sélection du mécanisme de repair sans campagne historique ; 9. sémantique skipped slots / missing block / Missing transaction / provider retention ; 10. politique de concurrence entre trafic nominal et repair, avec backpressure/fairness ; 11. politique de health required/redundant et critères de retour à Healthy ; 12. threat model : reconnect storms, overlapping gaps, stale redundant source, replay truncation, HTTP holes, duplicate repair, content disagreement, slow Store, stop/fault pendant repair ; 13. inventaire des smokes provider réellement accessibles avec les ressources opérateur ; 14. décision explicite sur EARLY : hors scope confirmé ou tranche dédiée justifiée par preuve ; 15. graphes Cargo/features cibles et éventuels changements Transport/Config strictement nécessaires ; 16. sizing de chaque tranche sous le budget 15–20 minutes ; 17. décision explicite : maintien de `0.3.14` ou rescission avant codage ; 18. création du plan et de la validation de release. Documents attendus : ```text docs/plans/035-V0_3_14_MULTI_SOURCE_GAP_REPAIR_HARDENING_PLAN.md docs/validation/031-V0_3_14_MULTI_SOURCE_GAP_REPAIR_HARDENING.md ``` Critère de sortie : aucun mécanisme de repair n'est implémenté tant que sa source de preuve du gap, sa plage, ses bornes, son propriétaire de retry/reconnect, son critère de succès et son échec unresolved ne sont pas définis. ## 10. Prévision souple initiale des prereleases Cette prévision est un point de départ à recalibrer par `pre.001`. ### `pre.001` — audit / brainstorming / sizing Base stable, audit replay/coverage/provider courant, modèle gap/range, stratégie repair, health, threat model, smokes, graphes, plan/validation et décision de maintien/rescission. ### `pre.002` — contrats gap / range / coverage Stabiliser les identités et invariants run-local nécessaires à la réparation, avec bornes et distinction repaired/unresolved, sans encore lancer tous les mécanismes. ### `pre.003` — replay natif + coverage redondante Intégrer la preuve source-neutral d'un replay Transport réellement exploitable et la preuve de couverture par une source redondante, sans faire écrire `from_slot` au Worker ni supposer l'équivalence des sources. ### `pre.004` — scan HTTP de réparation Réparer une plage du run via les primitives HTTP Transport existantes, avec découverte de slots/blocs bornée, skipped slots explicites et aucune plage historique arbitraire. ### `pre.005` — hydration de réparation Fermer les références/signatures manquantes via `getTransaction observed`, partager les bornes/coalescences pertinentes et conserver Common RAW comme unique canonicalizer. ### `pre.006` — réconciliation et reprise live Unifier replay/redondance/HTTP/hydration dans une machine de réparation run-local qui ne reprend le nominal qu'après preuve repaired ou publie unresolved/fault selon la politique décidée. ### `pre.007` — health policy multi-source Fermer les rôles required/redundant réellement justifiés, les transitions Healthy/Degraded/Unhealthy/Faulted et les conditions de récupération sans masquer une perte de coverage. ### `pre.008` — backpressure et fairness pendant repair Borner ranges, scans, hydrations et persistence sous concurrence avec le trafic nominal ; prévenir starvation, duplicate storms et repair fanout non borné. ### `pre.009` — snapshots / observabilité gaps et repair Projeter uniquement les dimensions source-neutral nécessaires : gaps détectés, pending/repaired/unresolved, activité de repair, health et compteurs checked, sans payload provider sensible. ### `pre.010` — races / shutdown hardening Stop/fault pendant replay, coverage wait, scan HTTP, hydration, admission et persistence ; tâches orphelines, deadlines, abort+join, counters et terminalité. Si `pre.001` retient réellement une source EARLY, insérer **une tranche dédiée avant le gate de completeness**. Ne pas la mélanger à un fix ou à une tranche de fermeture. Si aucune preuve suffisante n'existe, EARLY reste hors release sans prerelease artificielle. ### `pre.011` — completeness/security cross-layer Canaris Worker/Transport/Common RAW/Store, dépendances, API publique, redaction, Legacy/V0/V1, non-régression des cinq familles `0.3.13` et preuves de non-confusion Worker/Backfill. ### `pre.012` — gate technique/live Workspace complet, Clippy strict, suites ciblées, graphes/duplicates et smokes réellement accessibles. Aucun nouveau scope. ### `pre.013` — réconciliation documentaire README/USAGE, plan, validation et architectures/références réellement affectées. Pas de CHANGELOG/ROADMAP/prompt suivant. ### `pre.014` — préparation publication Prompt `0.3.15`, CHANGELOG, ROADMAP et fichiers mécaniques uniquement. ### `rel.001` Publication stable mécanique après gate validé. Le forecast peut être allongé par une tranche EARLY réellement justifiée, des fixes ou des tranches dédiées ; il ne doit jamais être compressé en mélangeant les responsabilités de fermeture. ## 11. Versionnement, deltas, commits et tags Règles obligatoires : ```text livraison prerelease : 0.3.14-pre.NNN Cargo : 0.3.14-pre.N fix : 0.3.14-pre.N.fix.M delta : deltas/0.3.14/pre.NNN.md ou pre.NNN-fix.NNN.md commit : v0.3.14-pre.NNN[-fix.NNN] tag prerelease : aucun tag stable final : v0.3.14 seulement après rel.001 validée ``` Toute prerelease non-fix synchronise `workspace.package.version`, même documentaire. Une correction strictement doc-only portée par un fix ne bump pas la version Cargo racine. 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. Si un gate devient rouge, produire un fix strictement rattaché à la responsabilité fautive avant d'avancer. Aucune commande non exécutée ne peut être déclarée PASS. ## 13. Validations Rust / Transport / Config / live / graphes pertinentes Selon les couches modifiées : ```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-api cargo test -p ksp-store-lib --no-default-features ``` Si Config/profils provider sont réellement modifiés : ```bash cargo test -p ksp-config-lib ``` Graphes à auditer si le graphe de dépendances/features change, et à la fermeture technique : ```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 ``` Smokes live possibles uniquement après audit `pre.001` et lorsqu'ils sont réellement provisionnés : ```text Solana HTTP Devnet Solana WebSocket Devnet Yellowstone provider avec replay/from_slot si credential/tier/rétention disponibles Helius transactionSubscribe si credential/tier disponible blockSubscribe provider réellement accessible Worker repair end-to-end vers Store sur environnement de test approprié source redondante réellement composée si deux voies comparables sont disponibles ``` Un smoke indisponible est `NON EXÉCUTÉ`, pas PASS. Aucun secret n'est écrit dans une commande persistée, un log, un delta ou un fichier source. ## 14. Critères de clôture de `0.3.14` La release peut se fermer lorsque : ```text base multi-source 0.3.13 non régressée gap du run possède identité/plage/bornes explicites replay natif utilisé seulement lorsque Transport/provider le rend adressable et prouvable coverage redondante ne vaut repair que si la plage est réellement démontrée scan HTTP repair reste borné au run et ne devient pas Backfill hydration de réparation repasse par Transport/Common RAW/admission/Store skipped/missing/unavailable sont distingués sans invention de complétude repaired et unresolved possèdent des critères explicites reprise live n'efface jamais un unresolved gap health policy ne masque pas une perte de coverage backpressure/fairness restent bornés pendant repair aucun second actor/client/retry Transport dans le Worker aucun Worker -> Config/Job/backend physique shutdown/fault pendant repair sans tâche orpheline ni late persistence diagnostics redacted EARLY absent ou réellement prouvé dans une tranche dédiée fixtures/canaris cross-layer verts smokes accessibles exécutés ou impossibilité qualifiée gates workspace/clippy/tests/trees verts documentation réconciliée prompt 0.3.15 produit dans la dernière prerelease ``` ## 15. Release suivante envisagée `0.3.15` doit reprendre uniquement après publication stable de `0.3.14` et introduire : ```text ksp-app-raw-transaction-ingest-desk composition Config + Logging + Worker finalisé sélection/supervision d'une ou plusieurs sources réellement admises lifecycle start/stop health et source state sûrs rates/backpressure/reconnect/recovery/gap state compteurs et diagnostics source-neutral ``` La Desk ne réimplémente ni discovery, hydration, déduplication, replay/repair, persistence ou logique provider. Elle reste une surface de composition/contrôle Tauri sur les APIs stables de la couche Worker/Config/Transport. Elle doit réutiliser le gabarit Desk KSP courant : splash, fonts, style, dépendances frontend de base et tracing TypeScript des interactions significatives sans valeurs sensibles. ## 16. Instruction d'ouverture Au début de la prochaine session : 1. vérifier que la base correspond exactement au tag stable `v0.3.13` et que `deltas/0.3.13/rel.001.md` est présent ; 2. lire les règles, le handoff `0.3.13`, l'architecture RAW acquisition et les sources Worker/Transport/Common/Store/Backfill/Config avant toute modification ; 3. réauditer les capacités actuelles Solana/Yellowstone/providers de replay, rétention et historique réellement adressable ; 4. produire `0.3.14-pre.001` avec matrice gap/replay/coverage/repair, threat model, health policy candidate, smokes accessibles, sizing, plan `035` et validation `031` ; 5. **ne pas coder de scan repair, failover/degraded policy, modification Transport/Config ni adapter EARLY avant fermeture de ce gate** ; 6. rescinder `0.3.14` immédiatement si le périmètre réel n'est pas clôturable dans une seule session.