khadhroony-solana-project/prompts/029-V0_3_10_START_PROMPT.md

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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/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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

alternative
complémentaire
redondante
spécialisée

Plusieurs sources peuvent être actives simultanément.

8. Continuité, déduplication et persistence

Le Worker doit distinguer :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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.