27 KiB
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 :
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 :
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 :
0.3.14
Première livraison attendue :
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 :
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 :
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 :
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 :
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 :
RULES.md
ROADMAP.md
CHANGELOG.md
docs/000-README.md
docs/rules/RULES_GENERAL.md
docs/rules/RULES_KSP.md
docs/rules/RULES_RUST.md
docs/rules/RULES_DEPENDENCIES.md
docs/rules/RULES_DOCUMENTATION.md
docs/rules/FILE_CONTRACTS.md
docs/rules/VERSION_WORKFLOW.md
docs/rules/PROMPT_STRUCTURE.md
Le prompt complète ces règles ; il ne les remplace pas.
Rappels Rust bloquants :
Rust 2024
unsafe interdit
unwrap / expect / panic interdits selon les règles KSP
? interdit en production
retours explicites ; clippy::implicit_return deny
#![warn(missing_docs)]
#![deny(unreachable_pub)]
#![forbid(unsafe_code)]
pas de pub mod
pub/pub(crate) partagés reexportés jusqu'à la crate root
accès partagés via crate::Item, y compris intra-crate
item strictement module-local => private
unit tests sous unit_tests/
integration tests sous tests/
Après toute modification Rust :
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
Pour tout Markdown touché :
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas
Une commande non exécutée n'est jamais déclarée PASS.
3.2 Handoff stable 0.3.13
Lire intégralement :
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 :
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 à :
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 :
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 :
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 :
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 :
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à :
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 :
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
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
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é, à :
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
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 :
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 :
- vérification exacte de la base stable
v0.3.13et dedeltas/0.3.13/rel.001.md; - lecture complète des sources internes listées ci-dessus ;
- inventaire du modèle actuel de frontier/reconnect/replay/continuity counters dans Worker et Transport ;
- audit externe courant Solana/Yellowstone/providers réellement concernés ;
- matrice par famille live : capacité à détecter un gap, rejouer, prouver coverage, hydrater, scanner, reprendre ;
- distinction formelle reconnect / replay attempt / replay covered / repair / unresolved gap ;
- modèle cible minimal de gap/range/coverage run-local, privé ou public selon consumer réel ;
- algorithme borné de sélection du mécanisme de repair sans campagne historique ;
- sémantique skipped slots / missing block / Missing transaction / provider retention ;
- politique de concurrence entre trafic nominal et repair, avec backpressure/fairness ;
- politique de health required/redundant et critères de retour à Healthy ;
- threat model : reconnect storms, overlapping gaps, stale redundant source, replay truncation, HTTP holes, duplicate repair, content disagreement, slow Store, stop/fault pendant repair ;
- inventaire des smokes provider réellement accessibles avec les ressources opérateur ;
- décision explicite sur EARLY : hors scope confirmé ou tranche dédiée justifiée par preuve ;
- graphes Cargo/features cibles et éventuels changements Transport/Config strictement nécessaires ;
- sizing de chaque tranche sous le budget 15–20 minutes ;
- décision explicite : maintien de
0.3.14ou rescission avant codage ; - création du plan et de la validation de release.
Documents attendus :
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 :
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 :
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 :
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 :
cargo test -p ksp-config-lib
Graphes à auditer si le graphe de dépendances/features change, et à la fermeture technique :
cargo tree -p ksp-worker-raw-transaction-ingest-lib --edges normal
cargo tree -p ksp-worker-raw-transaction-ingest-lib -e features
cargo tree --duplicates
À la fermeture technique :
cargo test --workspace --all-targets --all-features
Smokes live possibles uniquement après audit pre.001 et lorsqu'ils sont réellement provisionnés :
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 :
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 :
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 :
- vérifier que la base correspond exactement au tag stable
v0.3.13et quedeltas/0.3.13/rel.001.mdest présent ; - 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 ; - réauditer les capacités actuelles Solana/Yellowstone/providers de replay, rétention et historique réellement adressable ;
- produire
0.3.14-pre.001avec matrice gap/replay/coverage/repair, threat model, health policy candidate, smokes accessibles, sizing, plan035et validation031; - ne pas coder de scan repair, failover/degraded policy, modification Transport/Config ni adapter EARLY avant fermeture de ce gate ;
- rescinder
0.3.14immédiatement si le périmètre réel n'est pas clôturable dans une seule session.