khadhroony-solana-project/prompts/034-V0_3_15_START_PROMPT.md

<!-- file: prompts/034-V0_3_15_START_PROMPT.md -->
<!-- version: 1 -->

# 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-<delivery-id>.zip
archive doc-only : ksp-doc-<delivery-id>.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.