<!-- file: deltas/0.0.3/pre.008.md -->
<!-- version: 1 -->

# Delta 0.0.3-pre.008

## Base requise

`v0.0.3-pre.007`.

## Objectif

Formaliser applications spécialisées, workers autonomes, control plane et convention des scenarios sans créer prématurément une application globale ou une infrastructure IPC générique.

## Version Cargo

`workspace.package.version` passe de :

```text
0.0.3-pre.7
```

à :

```text
0.0.3-pre.8
```

Le header de `Cargo.toml` passe de version 13 à 14.

## Fichiers ajoutés

- `docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md`
- `docs/rules/SCENARIO_CONVENTION.md`
- `deltas/0.0.3/pre.008.md`

## Fichiers modifiés

- `Cargo.toml`
- `ROADMAP.md`
- `docs/architecture/000-README.md`
- `docs/architecture/003-COMPONENT_CONTRACTS.md`
- `docs/architecture/004-COMPONENT_INVENTORY.md`
- `docs/architecture/005-DEPENDENCY_GRAPH.md`
- `docs/rules/RULES_DEPENDENCIES.md`
- `docs/rules/RULES_KSP.md`
- `docs/IDEAS.md`
- `docs/plans/001-V0_0_3_PLAN.md`
- `prompts/001-V0_1_X_START_PROMPT.md`

## Fichiers supprimés

Aucun.

## Décisions principales

### Applications spécialisées d'abord

KSP ne planifie pas actuellement d'application globale de contrôle.

Les applications spécialisées et demos doivent d'abord permettre de développer, tester et valider chaque capacité.

La future application globale est conservée dans `docs/IDEAS.md` comme produit attendu mais non planifié.

### Workers services indépendants

Chaque worker doit pouvoir fonctionner comme service/processus autonome afin de pouvoir être arrêté, redémarré ou mis à jour sans imposer l'arrêt des autres.

Direction de packaging préférée :

```text
package ksp-worker-<role>
├── library target
└── binary target
```

La bibliothèque porte le runtime/logique du worker ; le binaire reste un bootstrap/service wrapper mince.

### Pas de dépendance worker-to-worker

Les workers se synchronisent via Store D1–D4 et notifications de wake-up.

Ils ne transportent pas les données directement entre processus.

### Pas d'ordre global strict figé

Aucun ordre obligatoire de démarrage des workers n'est inscrit dans les contrats.

Un futur manager/orchestrateur pourra adopter un ordre pratique, mais les workers restent conçus pour tolérer un upstream temporairement absent.

### Data plane / control plane

Data plane :

```text
transport -> D1 -> D2 -> D3 -> D4
```

Control plane :

```text
worker-api
worker-control-lib
job-api
future IPC
future managers/orchestrator
```

Les payloads de processing ne transitent pas dans le control plane.

### `ksp-worker-control-lib`

Il reste la gouvernance commune des workers et doit pouvoir, à terme, travailler avec un handle local ou un proxy distant conforme aux mêmes contrats Worker.

### IPC

Le besoin d'IPC est reconnu pour piloter les services autonomes.

Aucun `ksp-ipc-api` générique n'est créé maintenant.

Le premier manager/service réel déterminera le mécanisme et dira s'il faut un adapter interne à `ksp-worker-control-lib` ou une bibliothèque spécialisée.

### Scenarios

La logique du scenario appartient exclusivement à :

```text
ksp-scenario-<domain>-lib
```

L'app desktop demo appelle cette bibliothèque et ne recrée pas le workflow.

La même crate scenario doit pouvoir être appelée depuis test, futur CLI/tool ou CI lorsque pertinent.

### Convention scenario

`docs/rules/SCENARIO_CONVENTION.md` remplace pour l'instant le besoin d'un `ksp-scenario-api`.

Elle définit notamment :

- indépendance de Tauri ;
- environnement explicite ;
- utilisation des capacités KSP ;
- execution policy explicite ;
- résultat exploitable par le caller ;
- validation/evidence dans la crate scenario ;
- logging via `ksp-logging-lib`.

### Future orchestration

`ksp-orchestrator-lib` reste un concept futur seulement.

La future application globale reste également une idée future seulement.

## Roadmap

La tâche « application globale de supervision/contrôle » est retirée du roadmap concret.

Le roadmap conserve les applications spécialisées et le mode service autonome des workers.

## Plan restant

- `pre.009` — découpage des premières releases fonctionnelles concrètes ;
- `pre.010` — clôture fondatrice et prompt final.

## Questions reportées

- mécanisme IPC concret ;
- discovery/authentication/framing du control plane ;
- nom exact des apps worker manager ;
- packaging/exécution des jobs ;
- graceful service update/restart ;
- éventuel ordre pratique de démarrage ;
- futur orchestrateur ;
- nom/scope/release de l'application globale.

## Validations

- headers `file:` / `version:` vérifiés ;
- `Cargo.toml` parsé et version `0.0.3-pre.8` vérifiée ;
- référence vers `010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md` vérifiée ;
- `SCENARIO_CONVENTION.md` ajouté ;
- application globale retirée des tâches roadmap et conservée dans IDEAS ;
- packaging lib + bin des workers documenté ;
- absence d'un ordre global strict documentée ;
- plan conservé jusqu'à `pre.010` ;
- aucune commande Cargo build/test exécutée : ce delta reste documentaire.