# Prompt de démarrage `0.3.10` — normalisation RAW commune + Worker `RawTransaction` live multi-source ## 1. Identité de la release et base exacte Ouvrir **uniquement** `0.3.10` depuis la release stable/taggée : ```text v0.3.9 ``` La base de travail fournie par l'opérateur est autoritaire sur les souvenirs de session, snippets, anciens deltas ou copies intermédiaires. Avant toute modification, vérifier qu'elle correspond bien à `v0.3.9` et lire les règles/documents obligatoires listés ci-dessous. La mission de `0.3.10` est double mais cohérente : ```text 1. matérialiser la lower-layer commune ksp-raw-transaction-lib 2. introduire ksp-worker-raw-transaction-ingest-lib comme worker live multi-source V1 ``` Ces deux crates servent le même cœur durable `Store / RawTransaction`, mais **ne créent aucune relation fonctionnelle entre Job Backfill et Worker Ingest**. ## 2. Mission et résultat attendu ### 2.1 Centre du modèle Le résultat durable recherché reste : ```text sources d'acquisition | v normalisation RAW v1 | v ksp-store-lib | v RawTransaction + RawTransactionObservation ``` `RawTransaction` est la vérité RAW persistée. Les observations/provenances décrivent les acquisitions multiples possibles d'une même transaction. Identité canonique : ```text RawTransaction identity = (network, signature) network canonique Mainnet KSP = mainnet mainnet-beta = alias legacy/externe seulement ``` Un même RAW peut être observé depuis plusieurs providers/protocoles. L'idempotence doit converger vers une seule entité canonique et plusieurs observations ; une divergence de contenu canonique reste un conflit explicite. ### 2.2 `ksp-raw-transaction-lib` La canonicalisation RAW v1 aujourd'hui prouvée dans `ksp-job-backfill-lib` doit être extraite vers une lower-layer source-neutral commune au Job existant et au nouveau Worker, sans duplication et sans edge Job ↔ Worker. Responsabilités cibles à confirmer pendant `pre.001` : ```text format id/version RAW matériau source-neutral de transaction complète canonical payload bytes content hash construction RawTransaction construction/projection RawTransactionObservation validation réseau/signature/slot/meta/version/index ``` Responsabilités interdites : ```text runtime HTTP / WS / gRPC Config/env/secrets scheduler Job lifecycle/checkpoint/campagne Worker lifecycle/source loop backend Store physique ``` La migration du Job existant doit préserver **byte-for-byte** les golden bytes/hash RAW v1 déjà validés. Aucun RAW v2 n'est justifié par cette extraction. ### 2.3 `ksp-worker-raw-transaction-ingest-lib` Le Worker est un service continu. Son contrat fonctionnel cible est : ```text start -> ouvre les sources techniques activées par la composition -> acquiert à partir de son démarrage -> normalise/persiste continuellement -> publie snapshots/notifications concrètes indépendamment de leurs lecteurs -> répare uniquement ses propres pertes de continuité live stop -> arrêt coopératif/borné ``` Le démarrage **ne reçoit pas** de requête métier historique telle que : ```text signature program_id address slot range before/after historical limit ``` Ces entrées appartiennent au Job Backfill. Le Worker ne lance, n'appelle, n'attend ni ne supervise `ksp-job-backfill-lib`. Le Worker peut néanmoins utiliser HTTP, replay Yellowstone ou une autre primitive lorsqu'elle sert **son acquisition live ou la réparation de son propre frontier live**. La frontière Worker/Job est définie par l'intention et le lifecycle, jamais par le protocole. ## 3. Sources de vérité internes obligatoires — ordre de lecture ### 3.1 Gouvernance générale Lire d'abord : ```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 directement bloquants : ```text Rust 2024 unsafe / 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 consommés via crate::Item item seulement 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/0.3.10 ``` Une commande non exécutée n'est jamais déclarée PASS. ### 3.2 Architecture acquisition autoritaire Lire intégralement, dans cet ordre : ```text docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md docs/architecture/002-LAYERS_AND_DEPENDENCIES.md docs/architecture/003-COMPONENT_CONTRACTS.md docs/architecture/004-COMPONENT_INVENTORY.md docs/architecture/005-DEPENDENCY_GRAPH.md docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md ``` `011-RAW_TRANSACTION_ACQUISITION.md` est le handoff fonctionnel principal de `0.3.9`. Ne pas revenir à la juxtaposition des anciens audits A/B et ne pas réduire sa matrice aux seules sources actuellement testables. Décisions déjà fermées : ```text centre = Store / RawTransaction Job Backfill = historique paramétré, borné, terminable Worker Ingest = acquisition continue start/stop sans requête métier historique Job et Worker = producteurs indépendants HTTP / WS / gRPC / archive = capabilities, pas rôles Worker repair = seulement continuité de son run live support architectural != preuve live provider model = ouvert/capability-driven mainnet = identité KSP canonique mainnet-beta = alias legacy/externe canonicalisation RAW = lower-layer commune ``` ### 3.3 Worker API figée en `0.3.9` Lire : ```text crates/ksp-worker-api/Cargo.toml crates/ksp-worker-api/README.md crates/ksp-worker-api/USAGE.md crates/ksp-worker-api/src/ crates/ksp-worker-api/tests/ docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md ``` Surface générique acquise : ```text WorkerId WorkerKindCode WorkerState WorkerHealth WorkerActivity WorkerLifecycle WorkerStopToken WorkerSnapshotSequence WorkerSnapshot WorkerSnapshotFuture WorkerSnapshotSource ``` `ksp-worker-api` est **runtime-neutral**. Il ne fournit pas de `start()/stop()` universel et ne doit pas être élargi pour les besoins Solana du premier worker concret sauf défaut réellement générique démontré. ### 3.4 Backfill et canonicalisation RAW v1 existante Lire intégralement : ```text crates/ksp-job-backfill-lib/Cargo.toml crates/ksp-job-backfill-lib/README.md crates/ksp-job-backfill-lib/USAGE.md crates/ksp-job-backfill-lib/src/conversion.rs crates/ksp-job-backfill-lib/src/ crates/ksp-job-backfill-lib/unit_tests/ crates/ksp-job-backfill-lib/tests/ docs/plans/027-V0_3_6_JOB_API_BACKFILL_PLAN.md docs/validation/023-V0_3_6_JOB_API_BACKFILL.md ``` Inventorier avant extraction : ```text RAW_TRANSACTION_FORMAT_ID/version canonical bytes exacts digest/hash exact mapping getTransaction -> RawTransaction mapping provenance/observation golden vectors network/signature/slot/block_time guards error codes/Debug/redaction ``` Le changement autorisé dans Backfill en `0.3.10` est la **migration vers la lower-layer commune** avec comportement inchangé. L'ajout de nouvelles stratégies historiques reste `0.3.12`. ### 3.5 Store Lire : ```text crates/ksp-store-api/README.md crates/ksp-store-api/USAGE.md crates/ksp-store-api/src/ crates/ksp-store-lib/README.md crates/ksp-store-lib/USAGE.md crates/ksp-store-lib/src/ ``` Préserver : ```text RawTransaction identity = network + signature RawTransactionObservation séparée de l'entité canonique persistance acquisition atomique/idempotente conflit de contenu explicite rétention/tombstone existants Store façade uniquement pour les consumers ordinaires aucun backend PostgreSQL direct dans Worker/Common RAW ``` La lower-layer commune doit utiliser la façade/les reexports Store approuvés par l'architecture actuelle et ne doit pas introduire arbitrairement une nouvelle dépendance directe à `ksp-store-api` sans audit de frontière. ### 3.6 Transport Lire les surfaces actuelles de `ksp-onchain-transport-lib`, notamment : ```text HTTP observed getTransaction getBlock / getBlocks / getBlocksWithLimit WS logsSubscribe WS signatureSubscribe WS blockSubscribe Helius transactionSubscribe Yellowstone transactions Yellowstone transaction_status Yellowstone blocks Yellowstone blocks_meta / slots Yellowstone from_slot / replay info / reconnect snapshots ``` Réauditer explicitement les gaps `011` : ```text TR-B = get_block_observed TR-C = projection source-neutral des transactions full WS/Yellowstone TR-D = métadonnées sûres d'acquisition live pour observation uniforme TR-E = exploitation du from_slot/replay existant sans second moteur Yellowstone TR-F = adapters EARLY seulement lorsque le protocole est réellement implémenté ``` Ne pas ajouter un second client Yellowstone ou Helius si la surface existante suffit. ### 3.7 Config et composition Lire : ```text crates/ksp-config-lib/README.md crates/ksp-config-lib/USAGE.md crates/ksp-config-lib/src/transport.rs config/std.transport.json config/schemas/std.transport.schema.json config/examples/std.transport.example.json .env.example ``` Config reste propriétaire des endpoints, credentials et secrets. Le Worker ne lit jamais directement l'environnement. Cible conceptuelle à auditer : ```text source id network endpoint ref capabilities priority enabled settings techniques ``` Une composition peut activer plusieurs sources simultanément. Les paramètres de campagne historique ne doivent pas entrer dans cette configuration Worker. Le graphe cible actuel de `009` ne suppose pas une dépendance directe Worker -> Config : la composition/adapter supérieur résout la Config en settings source-neutral. Toute divergence doit être argumentée pendant `pre.001` avant codage. ## 4. Sources externes à réauditer pour fraîcheur La matrice `0.3.9` est une photographie documentée au 4 septembre 2026. `0.3.10-pre.001` doit revalider uniquement ce qui peut avoir changé et qui affecte l'implémentation réelle : ```text Solana JSON-RPC / PubSub actuels Yellowstone gRPC upstream/proto actuel Helius standard WSS / transactionSubscribe / LaserStream PublicNode Yellowstone OrbitFlare Yellowstone providers/tier réellement utilisés dans les smokes QuickNode / Alchemy / Shyft / Triton / dRPC lorsque leur capability influence le modèle DoubleZero/feeds EARLY seulement si une intégration réelle est envisagée ``` Utiliser les sources primaires. Distinguer systématiquement : ```text capability protocolaire capability documentée provider support implémenté KSP preuve live KSP ``` Une branche connue mais inaccessible sur le compte opérateur reste admissible et doit être testable par fixtures/mocks lorsque cela a du sens. Le workspace stable `v0.3.9` utilise notamment `yellowstone-grpc-proto ^12.7`; vérifier la version réellement courante au début de la tranche avant toute nouvelle dépendance ou adaptation protobuf. Ne pas confondre mise à jour de dépendance et objectif fonctionnel de la release. ## 5. État validé à préserver `v0.3.9` ferme notamment : ```text Worker API Core-only/générique RawTransaction Store backend-neutral + PostgreSQL RawTransactionObservation/provenance Backfill HTTP historique existant Transport HTTP/WS/Helius/Yellowstone existant Config Transport V3 et profils publics actuels mainnet canonique jsonschema ^0.53 yellowstone-grpc-proto ^12.7 ``` Les gates `0.3.9` ont validé le workspace complet `--all-targets --all-features`, les 385 tests unitaires Transport, 43 canaries de release Transport, Worker API complet et les arbres Cargo. Ne pas affaiblir ces canaris pour faire passer le nouveau code. ## 6. Architecture cible et dépendances ### 6.1 Lower-layer commune Cible à confirmer : ```text ksp-raw-transaction-lib -> ksp-core-lib # seulement si nécessaire directement -> ksp-store-lib # façade ; default-features=false -> serde_json / sha2 # seulement si RAW v1 les requiert encore ``` Pas de Transport, Config, Job API, Worker API, runtime async ou backend physique. ### 6.2 Worker concret Cible à confirmer : ```text ksp-worker-raw-transaction-ingest-lib -> ksp-worker-api -> ksp-onchain-transport-lib -> ksp-raw-transaction-lib -> ksp-store-lib # façade ; default-features=false -> ksp-logging-lib ``` `ksp-interface-lib` n'est ajouté que si un fait passif réellement partagé apporte une valeur démontrée ; ne pas créer une dépendance par anticipation. Interdits : ```text ksp-worker-raw-transaction-ingest-lib -> ksp-job-api ksp-worker-raw-transaction-ingest-lib -> ksp-job-backfill-lib ksp-worker-raw-transaction-ingest-lib -> ksp-store-postgres-lib ksp-worker-raw-transaction-ingest-lib -> provider SDK lower layer -> Worker/Job ``` ### 6.3 Job existant Après extraction : ```text ksp-job-backfill-lib -> ksp-raw-transaction-lib -> ksp-onchain-transport-lib -> ksp-store-lib -> ses dépendances Job/runtime existantes ``` Le Job conserve seul scopes, limites, campagnes, frontier historique, checkpoint et reprise. ## 7. Sources/capabilities Worker V1 Le modèle V1 doit pouvoir représenter au minimum les voies admises par `011`, même lorsque certaines ne peuvent pas être prouvées live immédiatement : ```text Yellowstone transactions full Yellowstone blocks full Yellowstone transaction_status + hydration WS logsSubscribe + HTTP getTransaction WS blockSubscribe full Helius transactionSubscribe full HTTP live block polling HTTP transaction hydration Yellowstone replay/from_slot pour continuité du run source EARLY via adapter extensible ``` Ne pas coder la sélection sous forme d'un enum fermé de providers. La composition se fait par capabilities et settings techniques. Une source peut être : ```text alternative complémentaire redondante spécialisée ``` Plusieurs sources peuvent être actives simultanément. ## 8. Continuité, déduplication et persistence Le Worker doit distinguer : ```text reconnect physique resubscribe replay adressable hydration scan blocs live repair du frontier live ``` Un reconnect WS ne vaut pas replay. Le Worker ne cherche pas l'historique arbitraire antérieur à son run. Lorsqu'un gap apparaît pendant son activité, il peut réparer la zone perdue jusqu'à son frontier live avec les capabilities disponibles. Ordre conceptuel de repair, à auditer/sizer : ```text replay natif qualifié source live redondante scan HTTP blocs hydration signatures découvertes fail/degraded explicite si la continuité ne peut pas être prouvée ``` Ne jamais déclarer lossless sans preuve suffisante. La persistence doit utiliser l'idempotence Store existante. Les duplicates multi-source sont attendus ; une observation supplémentaire n'est pas une seconde entité RAW. ## 9. Notifications et supervision Le Worker concret doit exposer un état observable compatible avec `ksp-worker-api` : ```text identity/kind state health activity sequence snapshot latest-value stop request partagé ``` Les notifications/snapshots sont produits indépendamment de la présence de lecteurs. Un consumer lent ou absent ne doit pas devenir propriétaire du lifecycle du Worker. `pre.001` doit décider le minimum de projection concrète nécessaire pour rates/source health/gap state/compteurs sans élargir `ksp-worker-api` ni inventer un event bus global. ## 10. Hors périmètre `0.3.10` Ne pas implémenter : ```text ksp-app-raw-transaction-ingest-desk # 0.3.11 nouvelles stratégies Job Backfill # 0.3.12 campagnes historiques dans le Worker checkpoint Backfill dans le Worker Program decode / DEX / materialization RawAccountState ingest worker backend PostgreSQL direct dans le Worker provider SDK control plane global nouveau format RAW v2 sans nécessité démontrée ``` Les adaptations du Job autorisées sont limitées à la migration vers la canonicalisation commune et aux tests de non-régression correspondants. ## 11. Première mission `pre.001` — audit, brainstorming et sizing **Ne pas commencer l'implémentation lourde du Worker en arrivant dans la session.** `pre.001` doit d'abord produire un plan détaillé de `0.3.10` à partir de la base réelle. ### 11.1 Vérification de base - vérifier la base/tag/archive `v0.3.9` ; - lire les règles et sources obligatoires ; - inventorier les crates/manifests/features réellement présents ; - exécuter les audits statiques disponibles ; - ne déclarer aucun gate Cargo PASS sans l'avoir réellement exécuté. ### 11.2 Audit de l'extraction RAW commune Comparer précisément le code actuel Backfill avec la cible `ksp-raw-transaction-lib` : ```text items à déplacer items à laisser Job-owned dépendances exactes nécessaires golden bytes/hash à préserver public API minimale de la common crate erreurs/validation/redaction absence de cycle de dépendances ``` Décider le découpage avant de déplacer du code. ### 11.3 Audit Transport/Config pour chaque capability live Construire une matrice implementation-ready avec au moins : ```text capability méthode/protocole surface KSP existante gap exact donnée complète ou hydration requise provenance disponible continuity/replay semantics network/provider testable aujourd'hui adaptation Transport nécessaire adaptation Config nécessaire fixture test live smoke possible ``` Réutiliser les IDs `TR-B` à `TR-F` de `011` ou les superséder explicitement si l'audit montre une meilleure découpe. ### 11.4 Audit du runtime Worker Décider avant codage : ```text ownership du runtime/task start/stop concret source supervisor multi-source concurrency bounded channels/backpressure source health latest-value status admission/dedup/persistence flow gap detection + repair shutdown order terminal fault policy ``` Aucun paramètre métier historique ne doit apparaître dans le contrat start. ### 11.5 Audit des preuves Séparer : ```text unit/fixture deterministic integration local provider live gratuit provider live bloqué par tier preuve de replay preuve de continuity repair Store persistence proof ``` Les tests live restent opt-in/ignored si secrets, endpoint externe, tier ou coût sont requis. ### 11.6 Sizing et planification Produire un plan dédié `0.3.10` et une validation dédiée avant implémentation lourde. Chaque prerelease intermédiaire visée à plus d'environ 15-20 minutes de travail effectif doit être scindée. Réserver explicitement les couloirs finaux : ```text gate technique/live réconciliation documentaire préparation de publication rel.001 ``` ### 11.7 Critères de sortie de `pre.001` Le gate `pre.001` est fermé seulement si les points suivants sont explicites : ```text boundary exacte ksp-raw-transaction-lib migration Backfill sans changement RAW v1 surface publique minimale du Worker concret runtime/source supervision décidés capability matrix Worker implementation-ready TR-B..TR-F réévalués Config/source settings décidés sans secret leak continuité/gap repair bornés notification/snapshot contract concret multi-source dedup/provenance/persistence décidés provider/access/proof matrix revalidée liste de tests/smokes dependency graph cible prévision souple détaillée et dimensionnée aucune implémentation lourde commencée avant cohérence du plan ``` ## 12. Prévision souple initiale des prereleases Cette prévision est un point de départ à recalibrer par `pre.001`, pas un calendrier rigide. ### `pre.001` — audit/sizing/plan Lecture complète, audit lower-layer/Transport/Config/Worker runtime, fraîcheur providers, dependency graph, threat model, tests et plan détaillé. ### `pre.002` — `ksp-raw-transaction-lib` foundation Créer la common crate, déplacer la canonicalisation RAW v1 sans changer les golden bytes/hash, migrer Backfill vers elle et verrouiller les frontières de dépendances. ### `pre.003` — Worker foundation/runtime Créer `ksp-worker-raw-transaction-ingest-lib`, lifecycle concret, start/stop, source supervision abstraite, snapshots/latest-value, persistence pipeline minimal et shutdown borné sans source live complexe. ### `pre.004` — Transport/Common acquisition gaps P0 Matérialiser les adaptations source-neutral indispensables : `get_block_observed`, transaction material/provenance commune et autres gaps réellement confirmés par `pre.001`. ### `pre.005` — Yellowstone live Brancher transactions/blocks/status+hydration, multi-source admission, continuity metadata et replay `from_slot` uniquement pour le frontier live du Worker. ### `pre.006` — WS/HTTP live Brancher logs+hydration, blockSubscribe, HTTP live block polling/hydration et Helius `transactionSubscribe` existant selon Config/capabilities. ### `pre.007` — multi-source hardening Déduplication, observations multiples, backpressure, source health, failure isolation, continuity/gap repair et adversarial tests. ### `pre.008` — providers/config/smokes accessibles Compléter les profils/capabilities réellement nécessaires, exécuter les smokes gratuits disponibles Mainnet/Devnet/Testnet et conserver les branches payantes derrière fixtures/opt-in. ### `pre.009` — extensions EARLY réellement accessibles ou tranche de consolidation N'implémenter une source EARLY vendor-specific que si son protocole, son accès et son rôle sont suffisamment prouvés. Sinon utiliser cette tranche pour consolidation/hardening plutôt que créer un faux support. ### `pre.010` — gate technique/live final Workspace complet, graphes de dépendances, tests live pertinents, continuité/recovery et preuves Store. ### `pre.011` — réconciliation documentaire finale README/USAGE/architecture/plan/validation uniquement. ### `pre.012` — préparation de publication Prompt `0.3.11`, CHANGELOG, ROADMAP uniquement, plus fichiers mécaniques de version/delta. ### `rel.001` — publication mécanique stable Publication `v0.3.10` sans rattrapage fonctionnel ou documentaire. `pre.001` peut scinder, fusionner ou insérer des tranches/fixes selon le résultat réel de l'audit. Il doit préserver l'ordre des responsabilités de fermeture. ## 13. Sécurité et hardening spécifiques Préserver au minimum : ```text aucun secret/URL/header/token dans Debug ou erreurs publiques aucun raw transaction payload dans tracing par défaut bornes explicites sur queues/buffers/filter sets pas de panic/unwrap/expect/unsafe pas de provider body/message copié dans ErrorContext aucune rétention d'un endpoint secret dans snapshot source failure isolée lorsque possible shutdown/reconnect bornés conflit de contenu canonique terminal/explicite selon policy décidée no-loss claim interdit sans preuve ``` Les diagnostics Worker doivent être utiles sans exposer signatures/payloads lorsque leur exposition n'est pas nécessaire. ## 14. Validation Rust et dépendances Pendant les tranches Rust : ```bash cargo fmt --all python3 scripts/audit_rust_workspace_rules.py python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas/0.3.10 cargo check --workspace cargo clippy --workspace --all-targets ``` Puis tests ciblés des crates touchées. Pour les gates techniques : ```bash cargo test --workspace --all-targets --all-features cargo tree -p ksp-raw-transaction-lib --edges normal 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 ``` Adapter les graphes si le plan `pre.001` modifie réellement les noms/edges, sans supprimer le contrôle de dépendances. Les smokes live doivent être explicitement opt-in lorsqu'ils nécessitent réseau externe, secrets ou accès payant. ## 15. Versionnement, deltas et publication - chaque nouvelle prerelease non-fix synchronise `workspace.package.version` selon `VER-ID-009` ; - `0.3.10-pre.001` correspond à Cargo `0.3.10-pre.1` ; - les correctifs utilisent la forme Cargo `0.3.10-pre.N.fix.M` ; - chaque livraison a son delta minimal sous `deltas/0.3.10/` ; - les archives d'échange suivent `VER-ARCHIVE-*` ; - aucun lockfile/cache/secret/build output dans les deltas ; - chaque delta est commité selon les règles Git KSP ; - seul le stable final reçoit le tag `v0.3.10`. Ne jamais réécrire un delta déjà publié pour masquer un défaut ; ouvrir un fix ou une tranche appropriée. ## 16. Critères de clôture de `0.3.10` La release peut fermer lorsque : ```text ksp-raw-transaction-lib possède une canonicalisation RAW v1 unique et prouvée Backfill utilise cette common crate sans changement fonctionnel de campagne Worker live démarre/s'arrête sans paramètres métier historiques plusieurs sources peuvent être actives simultanément les voies P0 Yellowstone + WS/HTTP admises sont représentées/implémentées selon plan les adaptations Transport/Config sont capability-driven et minimales RawTransaction + observations convergent correctement dans Store multi-source duplicates et conflits sont traités explicitement repair ne dépasse pas la continuité du run live snapshots/notifications sont receiver-independent et sûrs les branches non testables live restent testées déterministiquement quand possible aucun edge Job <-> Worker aucun backend physique/provider SDK dans le Worker gate technique/live final vert réconciliation documentaire séparée prompt 0.3.11/CHANGELOG/ROADMAP préparés séparément ``` ## 17. Release suivante envisagée `0.3.11` introduira `ksp-app-raw-transaction-ingest-desk` pour sélectionner et superviser une ou plusieurs sources/méthodes offertes par le Worker `0.3.10`, sans recopier discovery, hydration, dedup, persistence ou recovery. `0.3.12` reviendra ensuite sur `ksp-job-backfill-lib`/Desk pour les stratégies historiques multi-source/multi-protocole. Ne pas anticiper ce travail dans `0.3.10`. ## 18. Instruction d'ouverture Au début de la prochaine session : 1. vérifier que la base fournie correspond exactement à `v0.3.9` ; 2. lire les règles, `009`, `011`, Worker API, Backfill conversion, Store, Transport et Config dans l'ordre prescrit ; 3. réauditer les dépendances/provider capabilities dont la fraîcheur affecte réellement l'implémentation ; 4. produire **`pre.001` comme audit/sizing/plan**, avec dependency graph, capability matrix, threat model et stratégie de tests ; 5. **ne pas commencer l'implémentation lourde de `ksp-raw-transaction-lib` ou du Worker avant fermeture cohérente de ce gate**. L'objectif n'est pas de coder le chemin le plus facile avec les comptes gratuits actuels. L'objectif est de construire un socle live multi-source maximal, capability-driven et extensible, tout en distinguant clairement support architectural, support implémenté et preuve live disponible.