<!-- file: deltas/0.3.15/pre.007.md -->
<!-- version: 1 -->

# Delta `0.3.15-pre.007`

## Objet

Revalider au Start la sélection logique issue de l'inventaire `pre.006`, reconstruire les ressources Transport exactes attendues par les cinq familles Worker V1, puis les valider via les constructeurs publics du Worker sans ouvrir Store ni lancer de Worker.

## Requête Start sûre

Le préflight backend reçoit uniquement :

```text
profile_id
route_id
inventory_generation
commitment = confirmed | finalized
```

`profile_id` est ajouté au contrat candidat de `pre.001`. Depuis le passage réseau-centrique de `pre.006-fix.001`, un même `route_id` peut exister sur plusieurs réseaux ; le backend doit donc recevoir l'identité logique du profil réseau sélectionné pour reconstruire sans état frontend implicite.

Aucun endpoint, URL, provider choisi par le frontend, credential, token, metadata secrète, URI Store, source key ou handle runtime ne traverse IPC.

## Préflight `validate_route_start`

Le backend :

1. refuse une génération nulle ou différente de la génération courante avec `stale_inventory` ;
2. capture `ConfigEnvironment` ;
3. reconstruit l'inventaire avec le même snapshot d'environnement et la même génération ;
4. vérifie que le profil et la route existent encore et restent `Configured` ;
5. recharge le composite réseau explicite ;
6. résout Store et reproouve le réseau logique ;
7. résout le Transport de base et les sources provider-specific nécessaires ;
8. reconstruit la ressource exacte de la famille Worker ;
9. détruit immédiatement la ressource après validation ;
10. renvoie uniquement une projection sûre profil/réseau/route/génération/commitment.

Les erreurs lower-layer sont encapsulées derrière les codes/messages bornés du Desk ; les contextes physiques ne sont pas projetés au frontend.

## Reconstruction exacte des cinq routes

```text
yellowstone-hydrated
    YellowstoneGrpcChannel::prepare
    YellowstoneSubscribeRequest transaction-bearing
    HttpTransportPool same-network / getTransaction
    RawTransactionIngestYellowstoneSource::new

standard-logs-hydrated
    endpoint SolanaStandard + capability Logs
    SolanaLogsSubscribeFilter::AllWithVotes
    HttpTransportPool same-network / getTransaction
    RawTransactionIngestStandardLogsSource::new

standard-block-direct
    endpoint SolanaStandard + capability Block
    SolanaBlockSubscribeFilter::All
    RawTransactionIngestStandardBlockSource::new

helius-transaction-hydrated
    source transport.helius same-network
    endpoint HeliusLaserStream + capability HeliusTransaction
    filtre transaction général borné
    HttpTransportPool de base same-network / getTransaction
    RawTransactionIngestHeliusTransactionSource::new

http-block-polling
    HttpTransportPool same-network
    rôle unique composant getSlot + getBlocksWithLimit + getBlock
    RawTransactionIngestHttpBlockPollingSource::new
```

HTTP conserve la sélection physique de ses endpoints dans `HttpTransportPool`. Pour WS et Yellowstone gRPC, `pre.007` exige exactement un endpoint activé matching dans le profil source résolu ; une ambiguïté est refusée au lieu d'être arbitrée silencieusement par le Desk.

## Frontières maintenues

Cette tranche n'introduit pas :

```text
Store::open
connexion WebSocket active
YellowstoneGrpcChannel::connect
RawTransactionIngestRuntimeResources
RawTransactionIngestWorker::start_with_runtime_resources
Worker handle
request_stop
état Running
multi-route runtime
```

Le Store lifecycle et le Start/Stop mono-route réel restent la responsabilité de `pre.008`.

## Dépendances

Le Desk ajoute uniquement la dépendance directe :

```text
ksp-worker-raw-transaction-ingest-lib
```

Aucune dépendance directe vers `ksp-store-lib`, `ksp-store-api`, un backend Store physique, `ksp-worker-api`, Job Backfill, `reqwest`, `tonic` ou Yellowstone provider crate n'est ajoutée.

## Tests et canaris

Ajouts/corrections :

- canari génération stale avant toute reconstruction ;
- commitments strictement bornés à `confirmed` / `finalized` ;
- reconstruction sans I/O des routes Standard Block et HTTP Polling sur les profils réseau committés ;
- inventaire de modules mis à jour avec `route_start` ;
- surface publique toujours limitée à `run` ;
- vérification statique des cinq constructeurs Worker exacts ;
- vérification de l'absence de Store/Worker launch ;
- sécurité DTO Start/ack sans matériel physique ;
- accès aux helpers crate-shared via `crate::` conformément aux règles Rust KSP.

## Version

```text
header racine : 605 -> 606
workspace     : 0.3.15-pre.6.fix.3 -> 0.3.15-pre.7
```

## Validations disponibles dans l'environnement d'assemblage

```text
python3 scripts/audit_rust_workspace_rules.py
    General Rust rule audit: clean
    Rust export completeness audit: 0 candidate(s)
    KSP workspace Rust rule audit: clean

python3 scripts/audit_markdown_tables.py ...
    clean

JSON/TOML parse
    clean
```

La toolchain Cargo/rustfmt n'est pas disponible dans l'environnement d'assemblage ; aucune commande Cargo locale n'est donc déclarée PASS.

## Gate opérateur attendu

```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/0.3.15
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test -p ksp-app-raw-transaction-ingest-desk --all-targets --all-features
cargo test --workspace --all-targets --all-features
(cd crates/ksp-app-raw-transaction-ingest-desk && cargo tauri dev)
```

Aucun `npm run build` direct n'est exécuté ; Tauri possède le cycle frontend.