# Prompt de démarrage `0.3.15` — Raw Transaction Ingest Desk / composition et supervision de routes live ## 1. Identité de la release et base exacte requise Ouvrir **uniquement** `0.3.15` depuis la release stable/taggée : ```text v0.3.14 ``` La base 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.14 deltas/0.3.14/rel.001.md présent ksp-worker-raw-transaction-ingest-lib stable et consommable depuis sa crate root ksp-config-lib possède la résolution Transport HTTP / WS / Yellowstone gRPC ksp-onchain-transport-lib possède les façades réellement utilisées par le Worker ksp-store-lib reste l'unique façade Store du consumer cinq familles live Worker préservées : Yellowstone / Standard Logs / Standard Block / Helius Transaction / HTTP Block Polling gaps run-local, TargetCoverage, health, fairness et shutdown 0.3.14 présents snapshots publics gap/repair source-neutral présents aucun edge Worker -> Config / Job Backfill / backend Store physique ``` Release ouverte : ```text 0.3.15 ``` Première livraison attendue : ```text 0.3.15-pre.001 ``` `pre.001` est obligatoirement un gate de **lecture + audit de composition Config/Transport/Store/Worker + audit du gabarit Desk KSP + brainstorming + sizing + planification**. Il est interdit de commencer directement par l'UI, par des commandes Tauri Start/Stop ou par la copie d'une application Desk existante avant fermeture de ce gate. ## 2. Mission et résultat attendu Créer : ```text crates/ksp-app-raw-transaction-ingest-desk ``` comme application Tauri KSP spécialisée dans la **composition, le démarrage, l'arrêt et la supervision de routes live `RawTransaction` réellement supportées par la configuration et le Worker finalisé**. Le Desk doit permettre à l'opérateur de : ```text charger/utiliser la configuration KSP choisir le réseau logique disponible voir les routes live composables pour ce réseau comprendre pourquoi une route non composable est désactivée sélectionner une ou plusieurs routes composables démarrer une instance Worker par route sélectionnée arrêter chaque Worker proprement observer lifecycle / health / activité / backpressure / reconnect / replay / gaps / repair via les snapshots Worker vérifier que les données convergent réellement vers le même Store RawTransaction ``` Le Desk ne devient pas une seconde implémentation de l'acquisition. La chaîne d'ownership cible est : ```text Frontend Tauri -> route_id / action Start-Stop / DTO sûrs -> backend Rust de ksp-app-raw-transaction-ingest-desk -> ksp-config-lib -> ksp-onchain-transport-lib -> ksp-store-lib -> ksp-worker-raw-transaction-ingest-lib -> ksp-raw-transaction-lib -> même Store RawTransaction ``` ### 2.1 Règle fondamentale : route != source != endpoint Une **route** est une stratégie d'acquisition complète. Elle peut nécessiter plusieurs ressources/capacités techniques pour devenir exécutable. Exemples conceptuels, à réauditer contre la base réelle : ```text Yellowstone transaction stream + HTTP getTransaction hydration Standard WS logsSubscribe + HTTP getTransaction hydration Standard WS blockSubscribe RAW-direct Helius transactionSubscribe + HTTP getTransaction hydration HTTP Block Polling RAW-direct ``` Une route n'est pas sélectionnable parce qu'un seul endpoint portant le bon provider existe. Elle est sélectionnable uniquement si **toutes ses capacités obligatoires** peuvent être composées depuis la Config pour le même réseau logique. Exemple : ```text route exige Yellowstone gRPC + HTTP getTransaction gRPC disponible = oui HTTP compatible = non => route NON SÉLECTIONNABLE ``` Autre exemple : ```text endpoint Helius disponible uniquement comme WS standard route Standard WS Logs compatible = potentiellement sélectionnable route exigeant Helius transactionSubscribe = NON sélectionnable si cette capability spécifique n'est pas disponible ``` Il est interdit de déduire une capability uniquement à partir du nom du provider. ### 2.2 Une instance Worker par route sélectionnée Décision acquise : ```text 1 route sélectionnée = 1 instance ksp-worker-raw-transaction-ingest-lib N routes sélectionnées = N Workers indépendants ``` Ce n'est **pas** un Worker par source physique. Une même route peut composer plusieurs ressources internes nécessaires à sa stratégie : gRPC + HTTP, WS + HTTP, ou d'autres ressources réellement requises par les contrats Worker. Toutes ces ressources appartiennent au Worker de cette route. Plusieurs Workers de routes différentes peuvent écrire vers le même Store `RawTransaction`. Ils restent indépendants pour : ```text lifecycle gaps / TargetCoverage health repair shutdown ``` Aucun partage implicite de gap ledger ou de preuve de coverage entre Workers distincts n'est introduit. La convergence durable passe par les contrats Store/idempotence/observations existants. ### 2.3 Composable avant Start, opérationnelle après Start Deux niveaux sont obligatoirement distingués : ```text COMPOSABLE toutes les capacités/configurations requises existent et sont cohérentes décision déterministe à partir de Config et des contrats connus OPÉRATIONNELLE les ressources sélectionnées fonctionnent réellement au runtime preuve obtenue lors du Start / runtime Worker-Transport-Store ``` La liste des routes ne doit pas lancer des probes réseau arbitraires pour fabriquer artificiellement une disponibilité. Le backend Desk détermine d'abord la composabilité à partir de la configuration résolue. Au `Start`, le Worker et les façades Transport/Store valident réellement les ressources, les réseaux, les connexions et les capacités runtime nécessaires. Une route peut donc rester visible comme `Configured/Composable` puis passer `Starting -> Running` ou `Starting -> Faulted` selon le runtime réel. ## 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 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 via 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.14` Lire intégralement : ```text prompts/033-V0_3_14_START_PROMPT.md 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 deltas/0.3.14/pre.014.md deltas/0.3.14/pre.015.md deltas/0.3.14/pre.016.md deltas/0.3.14/rel.001.md crates/ksp-worker-raw-transaction-ingest-lib/README.md crates/ksp-worker-raw-transaction-ingest-lib/USAGE.md ``` Puis auditer le code réel de : ```text 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/ ``` `0.3.15` consomme le Worker finalisé ; il ne le recode pas dans l'application. ### 3.3 Config et composition Lire : ```text crates/ksp-config-lib/README.md crates/ksp-config-lib/USAGE.md crates/ksp-config-lib/src/ config/std.transport.json config/examples/std.transport.example.json config/schemas/std.transport.schema.json config/std.store.json config/schemas/std.store.schema.json config/composite.ksp-app-backfill-desk.json config/composite.ksp-app-store-desk.json .env.example ``` Inventorier réellement : ```text profils HTTP configurés rôles HTTP et request_kinds profils WS et protocol kind profils Yellowstone gRPC réseaux logiques credentials/secrets requis Store targets et réseau associé mécanismes de composite/profil sélectionné ``` Ne pas confondre un exemple sous `config/examples/` avec un profil réellement actif dans `config/std.transport.json`. ### 3.4 Transport et Worker runtime resources Lire : ```text crates/ksp-onchain-transport-lib/README.md crates/ksp-onchain-transport-lib/USAGE.md crates/ksp-onchain-transport-lib/src/ crates/ksp-onchain-transport-lib/tests/ crates/ksp-worker-raw-transaction-ingest-lib/src/runtime.rs crates/ksp-worker-raw-transaction-ingest-lib/src/runtime_resources.rs crates/ksp-worker-raw-transaction-ingest-lib/src/snapshot.rs ``` Auditer précisément les constructeurs publics actuellement disponibles : ```text RawTransactionIngestRuntimeResources RawTransactionIngestYellowstoneSource RawTransactionIngestStandardLogsSource RawTransactionIngestStandardBlockSource RawTransactionIngestHeliusTransactionSource RawTransactionIngestHttpBlockPollingSource RawTransactionIngestWorker::start_with_runtime_resources RawTransactionIngestHandle RawTransactionIngestSnapshotSource ``` Le résultat de cet audit doit montrer, route par route, quelles capacités Transport/Config sont nécessaires pour construire le Worker sans bypass. ### 3.5 Store Lire : ```text crates/ksp-store-lib/README.md crates/ksp-store-lib/USAGE.md crates/ksp-store-lib/src/ crates/ksp-store-api/src/ ``` Le Desk dépend de `ksp-store-lib`, jamais de `ksp-store-postgres-lib` ni d'un client SQL. Un run Worker et le Store doivent porter exactement le même réseau logique. `mainnet` reste l'identité KSP canonique ; `mainnet-beta` est uniquement un alias historique/externe lorsqu'il est accepté par une lower-layer. ### 3.6 Gabarit Desktop KSP Le Desk doit reprendre le gabarit **KSP actuel**, jamais une application historique externe. Lire au minimum : ```text crates/ksp-app-config-desk/ crates/ksp-app-wallet-desk/ crates/ksp-app-solprices-desk/ crates/ksp-app-backfill-desk/ crates/ksp-app-store-desk/ ``` Préserver le pattern déjà décidé : ```text même splash KSP, seul le titre change mêmes fonts même style général même discipline frontend/backend Tauri tracing TypeScript des clics, boutons, tabs, filtres, refresh et IPC aucun secret/endpoints sensibles dans les logs frontend ``` Le `package.json` doit au minimum partir du socle courant des Desk KSP, incluant lorsque toujours présent après audit : ```text @fltsci/tauri-plugin-tracing @fortawesome/fontawesome-free @tauri-apps/api bootstrap resize-observer-polyfill simplebar ``` et les mêmes devDependencies de base compatibles que les Desk KSP actuelles. Ne pas lancer une mise à niveau opportuniste du workspace frontend sans justification de `pre.001`. ## 4. Sources externes à réauditer en `pre.001` La Desk elle-même ne doit pas dépendre de connaissances provider codées depuis une page marketing. Néanmoins, si la construction d'une route dépend d'une capability Transport/provider dont la sémantique ou la disponibilité a changé, réauditer les sources primaires réellement actuelles : ```text Solana JSON-RPC / WebSocket pour méthodes/subscriptions utilisées Yellowstone gRPC upstream pour Subscribe / replay réellement exposé Helius pour la distinction standard WS vs transactionSubscribe/provider-specific lorsque nécessaire PublicNode / OrbitFlare uniquement si un profil actif et un smoke réel les utilisent Tauri 2 / plugins réellement employés si une adaptation desktop est nécessaire ``` Les résultats externes servent à qualifier les capabilities. Ils ne doivent jamais rendre sélectionnable une route que la Config locale ne peut pas composer. ## 5. État validé à préserver depuis `v0.3.14` ### 5.1 Worker Préserver : ```text une admission/persistence Common RAW unique par Worker five live source families existantes hydratation globale/coalescence interne au Worker idempotence et content conflict explicite processing frontier distinct de continuity frontier gaps run-local bornés TargetCoverage conservative reconnect != replay_attempt != replay_covered != repaired fairness nominal/repair shutdown/drain/abort+join borné snapshots source-neutral avec gap observability aucun Backfill automatique ``` ### 5.2 Ownership Préserver : ```text Config possède profiles/endpoints/secrets Transport possède clients/sessions/retry/reconnect/resubscribe/replay natif Worker possède logique continue RawTransaction, continuity et repair du run Store possède persistence/idempotence/observations Desk compose et supervise ; il ne réimplémente aucune de ces couches ``` ### 5.3 Producteurs indépendants Préserver : ```text ksp-worker-raw-transaction-ingest-lib = acquisition continue ksp-job-backfill-lib = acquisition historique bornée/paramétrée Worker -X-> Backfill Backfill -X-> Worker ``` `0.3.15` n'introduit aucune orchestration Backfill automatique depuis la Desk ingest. ## 6. Décisions acquises — ne pas redébattre sans contradiction réelle ```text release : 0.3.15 application : ksp-app-raw-transaction-ingest-desk gabarit : Desk KSP courant frontend : UI/DTO/actions sûres uniquement backend Rust Tauri : composition Config + Transport + Store + Worker route != source != endpoint route = stratégie complète + ensemble de capabilities obligatoires route sélectionnable uniquement si toutes ses requirements sont composables depuis Config provider name seul != capability composabilité Config != opérabilité runtime validation réseau/connexion/capabilities réelles au Start 1 route sélectionnée = 1 Worker pas 1 Worker par source physique une route peut nécessiter plusieurs ressources Transport internes plusieurs Workers/Routes peuvent écrire dans le même Store pas de partage implicite des gaps/TargetCoverage entre Workers distincts endpoints/secrets/handles restent Rust-only et hors IPC Store via ksp-store-lib uniquement aucun SQL/backend physique aucune logique Backfill ``` ## 7. Questions réellement ouvertes à trancher pendant `pre.001` ### 7.1 Catalogue exact des routes V1 Construire une matrice à partir des contrats réellement existants : ```text route_id stable objectif de la route network admissible capabilities obligatoires capabilities optionnelles ressources Worker construites source family interne RAW-direct ou reference-bearing hydration requirement repair capabilities internes raison de non-composabilité projetable en DTO sûr ``` Le catalogue V1 doit être borné aux routes réellement constructibles sans bypass. ### 7.2 Lieu du catalogue de routes Auditer si le catalogue reste légitimement app-owned dans le backend Desk ou si un petit contrat réutilisable manque dans une lower-layer existante. Règle : ```text ne pas créer une nouvelle crate intermédiaire par défaut ne pas déplacer de logique d'ingestion vers l'app si une extension lower-layer minimale est indispensable, la faire dans la crate propriétaire pendant 0.3.15 avec tests dédiés ``` ### 7.3 Projection de capabilities Config Décider comment obtenir une vue déterministe et sûre des capabilities configurées sans exposer : ```text URL credential secret metadata header sensible client Transport Store URI ``` Si les APIs publiques Config/Transport ne permettent pas de déterminer proprement la composabilité d'une route, identifier l'extension minimale backend-neutral au lieu de parser arbitrairement le JSON Config depuis le frontend. ### 7.4 Sélection réseau Décider l'UX exacte : réseau explicitement choisi parmi les configurations disponibles, ou réseau dérivé d'un composite/Store target sélectionné. Dans tous les cas : ```text route.network == Worker.settings.network == Store.network ``` est obligatoire avant Start. ### 7.5 Multiples compositions pour une même route Si plusieurs endpoints/rôles peuvent satisfaire une même route, décider avant UI lourde si : ```text Config/Transport choisit automatiquement selon priorités existantes ou le Desk expose plusieurs compositions logiques sûres ``` Le frontend ne doit pas devenir un éditeur de connexions physiques et ne reçoit pas les URLs. ### 7.6 Lifecycle de plusieurs Workers Définir l'état applicatif pour : ```text 0..N routes sélectionnées 0..N Workers actifs Start individuel / Stop individuel Start sélection globale éventuellement fermeture application route déjà Running Start concurrent de deux routes fault d'une route sans arrêt implicite des autres Store partagé ``` Chaque handle doit rester associé de façon non ambiguë à un `route_id` applicatif sûr. ### 7.7 Validation finale réelle Planifier les scénarios live réellement accessibles. Le Desk doit servir de validation système des couches existantes, mais aucun provider non provisionné ne reçoit un faux PASS. ## 8. Objectifs et livrables de `0.3.15` À la clôture, viser : ```text crate Tauri ksp-app-raw-transaction-ingest-desk intégrée au workspace composite/config app dédié si réellement nécessaire inventaire de routes source-neutral et borné projection selectable / unavailable + raison sûre sélection réseau cohérente sélection d'une ou plusieurs routes 1 Worker réel par route sélectionnée construction réelle des RawTransactionIngestRuntimeResources nécessaires Start / Stop réels via ksp-worker-raw-transaction-ingest-lib Store partagé via ksp-store-lib snapshots Worker projetés vers l'UI sans données sensibles lifecycle/health/activity/backpressure/reconnect/replay/gaps/repair visibles fermeture application arrêtant/joinant proprement les Workers détenus tracing frontend KSP README/USAGE de l'application plan + validation de release gates Rust/frontend/Tauri complets smokes live accessibles documentés ``` Une route marquée sélectionnable par l'UI doit être réellement constructible depuis la Config résolue ; une route incomplète reste désactivée avec une raison sûre. ## 9. Hors périmètre explicite ```text nouveau moteur Worker nouvelle campagne historique extension multi-stratégie Backfill 0.3.16 Worker par endpoint/source physique partage de gap ledger entre Workers distincts orchestrateur global de failover cross-Worker scheduler durable de Workers persistance des sélections/runs au-delà de ce que pre.001 décide explicitement SQL/backend Store direct lecture directe .env depuis l'app saisie/édition de secrets dans le frontend éditeur arbitraire d'endpoints provider exposition URL/token/header/client handle via IPC réimplémentation retry/reconnect/replay/hydration/discovery/persistence dans la Desk nouveau provider SDK sans besoin prouvé ``` ## 10. Contraintes sécurité, API et architecture spécifiques ### 10.1 IPC Le frontend peut connaître des identifiants logiques sûrs, par exemple : ```text route_id network label route family selectable unavailable reason code Worker lifecycle/health compteurs/snapshots déjà source-neutral ``` Il ne doit pas recevoir : ```text endpoint URL API key/token secret metadata Store URI Transport client/session source key privée transaction payload brut par simple monitoring error text provider arbitraire ``` ### 10.2 Availability La disponibilité affichée doit distinguer clairement : ```text Unavailable / Not composable Configured / Composable Starting Running Stopping Stopped Faulted ``` Ne pas afficher `Running` ou `Ready` à partir de la seule présence d'une configuration. ### 10.3 Composition et validation La composition affichée peut être calculée sans I/O réseau. Avant démarrage, le backend doit **revalider** la Config et reconstruire les ressources ; il ne fait jamais confiance à une sélection frontend obsolète. Le Start doit échouer proprement si la configuration a changé ou si une ressource n'est plus valide. ### 10.4 Plusieurs Workers, même Store Les routes actives écrivent dans le même Store logique lorsque leur réseau correspond. Les règles existantes de canonical identity, idempotence, observation et content conflict restent autoritaires. Le Desk ne choisit jamais un « provider gagnant » et ne fusionne pas lui-même des RawTransactions. ## 11. Première mission `0.3.15-pre.001` — gate obligatoire `pre.001` doit rester essentiellement audit/planification. Produire avant tout scaffold lourd : ### 11.1 Inventaire réel ```text API publique Worker exacte constructeurs RuntimeResources exacts capabilities exigées par chaque famille Worker APIs Config disponibles pour HTTP/WS/gRPC/Store profils réellement committed vs exemples uniquement mécanismes de rôles/priorités HTTP kinds WS et protocoles gRPC pattern de composition du Backfill Desk pattern lifecycle/handle/snapshot dans les apps existantes socle Tauri/TS/npm courant des Desk ``` ### 11.2 Matrice route/capability Produire une table complète : ```text Route Network Required capability Optional capability Config evidence Worker constructor/resource Composable aujourd'hui ? Missing contract éventuel Live-testable ? ``` Exiger au moins l'analyse de : ```text Yellowstone + HTTP hydration Standard Logs + HTTP hydration Standard Block direct Helius transactionSubscribe + HTTP hydration HTTP Block Polling ``` et distinguer explicitement une utilisation Helius en WS standard d'une route Helius `transactionSubscribe` provider-specific. ### 11.3 Audit gap Classer chaque gap : ```text aucun gap adaptation app seulement extension Config minimale extension Transport minimale extension Worker minimale split de release nécessaire ``` Une extension lower-layer réellement nécessaire peut appartenir à `0.3.15`, mais elle doit rester minimale, propriétaire de sa sémantique et testée avant l'UI qui la consomme. ### 11.4 Gabarit et UX Produire : ```text screen map route list mock contract states selectable/unavailable/running/faulted Start/Stop flow snapshot mapping UI IPC DTO matrix frontend tracing matrix ``` sans encore implémenter toutes les vues. ### 11.5 Sizing Chaque tranche intermédiaire doit viser environ 15–20 minutes de travail effectif. Si une extension Config/Transport/Worker ou l'UI prévue rend la session trop grande, rescinder `0.3.15` avant l'implémentation lourde. ### 11.6 Livrables `pre.001` Préparer au minimum : ```text docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md deltas/0.3.15/pre.001.md ``` Le plan doit fixer la prévision souple réelle après audit, et non recopier mécaniquement celle du présent prompt. ## 12. Prévision souple initiale des prereleases Prévision de départ, à recalibrer en `pre.001` : ### pre.001 — audit / route model / sizing Audit complet Config/Transport/Store/Worker/Desk, matrice route-capability, gaps, UX et plan. ### pre.002 — contrats applicatifs de route et scaffold Desk Créer la crate/app Tauri sur le gabarit KSP, DTO sûrs, route IDs/states et composite minimal sans Start Worker. ### pre.003 — Config -> route inventory Résoudre réseau/profils/capabilities et produire les routes composables/non composables avec raisons sûres ; aucune sonde réseau arbitraire. ### pre.004 — composition RuntimeResources Mapper chaque route réellement supportée vers ses ressources Worker/Transport sans bypass et revalider au Start. ### pre.005 — Store + Start/Stop mono-route Ouvrir Store via façade, lancer/arrêter un Worker réel pour une route et fermer proprement les ressources. ### pre.006 — multi-route / un Worker par route Gérer plusieurs routes sélectionnées, handles indépendants et Store partagé sans cross-Worker gap coordination. ### pre.007 — snapshots / monitoring Projeter lifecycle, health, activity, backpressure, reconnect/replay, gap/repair et compteurs sûrs. ### pre.008 — frontend fonctionnel / tracing Finaliser choix réseau/routes, Start/Stop, états, feedback, tracing frontend et ergonomie KSP. ### pre.009 — races/security/hardening Config change entre inventory et Start, double Start/Stop, fermeture app, fault isolé, secrets/IPC/redaction et bornes. ### pre.010 — completeness / validation end-to-end Canaris cross-layer Desk -> Config/Transport/Worker/Store, routes V1 complètes et scénarios système sans fake provider success. ### pre.011 — gate technique/live/Tauri Workspace complet, Clippy strict, tests all-targets/all-features, npm/tsc/vite/Tauri build et smokes live réellement accessibles. ### pre.012 — réconciliation documentaire README/USAGE, plan, validation, architectures réellement affectées. Pas de CHANGELOG/ROADMAP/prompt suivant. ### pre.013 — préparation publication Prompt `0.3.16`, CHANGELOG, ROADMAP et mécanique de version/delta uniquement. ### rel.001 Publication stable mécanique après gate validé. Cette numérotation est une prévision, pas une contrainte. Insérer/séparer des tranches si `pre.001` montre qu'un élément dépasse le budget ou appartient à une lower-layer. ## 13. Versionnement, deltas, commits, archives et tags Appliquer `docs/rules/VERSION_WORKFLOW.md`. Rappels : ```text prerelease Cargo : 0.3.15-pre.N livraison : 0.3.15-pre.NNN fix livraison : 0.3.15-pre.NNN-fix.NNN fix Cargo code/runtime : 0.3.15-pre.N.fix.N archive générale : ksp-general-.zip archive doc-only : ksp-doc-.zip seulement si réellement limitée à docs/prompts ``` À partir de `0.1.x`, chaque delta est commité. Aucun tag n'est requis pour prerelease/fix/rel. Après `rel.001` validée : ```text commit : v0.3.15-rel.001 tag : v0.3.15 ``` Le delta ZIP contient uniquement les fichiers ajoutés/modifiés de la livraison plus son delta ; aucun lockfile/cache/build output. ## 14. Procédure d'application et validation opérateur Pour chaque delta : ```text partir exactement de la base requise appliquer le ZIP à la racine du dépôt vérifier le diff avant exécution ne jamais recopier un worktree complet à la place du delta ne jamais modifier silencieusement un delta déjà livré ``` Gate Rust minimal après modification : ```bash cargo fmt --all cargo fmt --all -- --check python3 scripts/audit_rust_workspace_rules.py python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas cargo check --workspace cargo clippy --workspace --all-targets --all-features -- -D warnings ``` Les tests ciblés suivent selon les crates modifiées. ## 15. Validations frontend/Tauri/réseau attendues ### 15.1 Rust/workspace Avant fermeture technique : ```bash cargo test --workspace --all-targets --all-features cargo tree -p ksp-app-raw-transaction-ingest-desk --edges normal cargo tree -p ksp-app-raw-transaction-ingest-desk -e features cargo tree -p ksp-worker-raw-transaction-ingest-lib --edges normal cargo tree --duplicates ``` ### 15.2 Frontend Depuis la crate Desk, exécuter réellement les commandes correspondant au package courant, typiquement : ```bash npm run build ``` ou les commandes workspace réellement retenues après audit. Le build frontend doit démontrer `tsc`/Vite sans réseau direct frontend, storage secret ou imports hors gabarit. ### 15.3 Tauri Le gate final inclut : ```bash cargo tauri build ``` pour la nouvelle Desk, avec bundles réellement supportés par l'environnement opérateur. ### 15.4 Live/system Prévoir des scénarios réellement accessibles, par exemple : ```text route composable -> Start -> Running -> RawTransaction/observations progressent -> Stop propre route Config incomplète -> non sélectionnable sans I/O route composable mais endpoint runtime indisponible -> Start fault propre plusieurs routes -> plusieurs Workers -> même Store -> observations/idempotence cohérentes ``` Les profils/provider-gated ne sont PASS que si les credentials et capacités correspondantes sont réellement disponibles et le test a été exécuté. Un exemple PublicNode Mainnet ou Helius Devnet n'est jamais considéré prouvé uniquement parce qu'un profil/exemple Config existe. ## 16. Critères de clôture de `0.3.15` `0.3.15` est clôturable seulement si : ```text ksp-app-raw-transaction-ingest-desk existe et build route/source/endpoint sont distingués dans le modèle catalogue V1 borné et documenté toute route sélectionnable possède toutes ses capabilities Config obligatoires aucune capability n'est déduite du seul provider composabilité et opérabilité runtime sont distinguées Config est revalidée au Start 1 route active = 1 Worker aucun Worker par source physique imposé par la Desk une route peut assembler plusieurs ressources Transport nécessaires plusieurs Workers peuvent partager le même Store sans coordination de gaps cross-Worker Start/Stop réel utilise ksp-worker-raw-transaction-ingest-lib Transport/Config/Store ownership restent respectés aucun endpoint/secret/Store URI ne traverse l'IPC snapshots Worker utiles sont visibles sans source key privée fault d'une route n'impose pas arbitrairement le fault des autres fermeture app draine/arrête proprement tous les Workers détenus aucun Backfill automatique aucune persistence/RAW canonicalization réimplémentée dans la Desk workspace/Clippy/tests/frontend/Tauri gates verts smokes accessibles exécutés ou explicitement NON EXÉCUTÉ README/USAGE/plan/validation réconciliés prompt 0.3.16 produit dans la dernière prerelease ``` ## 17. Release/session suivante envisagée La trajectoire actuelle prévoit : ```text 0.3.16 étendre ksp-job-backfill-lib et ksp-app-backfill-desk vers les stratégies historiques/catch-up multi-source réellement pertinentes ``` `0.3.15` ne doit pas préimplémenter ce backfill. Le Desk ingest reste un gestionnaire de routes live continues. ## 18. Instruction d'ouverture La prochaine session doit commencer par : ```text 1. vérifier la base stable v0.3.14 et workspace.package.version = 0.3.14 2. lire les règles normatives dans l'ordre demandé 3. lire le handoff 0.3.14 et le Worker final 4. auditer Config HTTP/WS/gRPC + Store réellement committed 5. auditer les constructeurs RuntimeResources Worker et le pattern Backfill Desk 6. construire la matrice route -> capabilities -> Config evidence -> Worker resources 7. vérifier les Desk KSP servant de gabarit 8. brainstormer les gaps/frontières/risques 9. recalibrer la prévision des prereleases 10. produire plan 036 + validation 032 + delta pre.001 ``` Ne pas commencer avant ce gate : ```text scaffold UI lourd Start/Stop Worker nouvelle API Config/Transport/Worker nouveau provider nouvelle logique de retry/hydration/repair ``` sauf correction triviale indispensable pour rendre l'audit lui-même exécutable.