<!-- file: deltas/0.0.3/pre.001-fix.004.md -->
<!-- version: 1 -->

# Delta 0.0.3-pre.001-fix.004

## Base requise

`0.0.3-pre.001-fix.003`.

## Objectif

Formaliser les dernières décisions de nomenclature et d'extensibilité :

- utiliser `ksp-<domain>-api` plutôt que `ksp-<domain>-api-lib` ;
- séparer contrats publics et implémentations officielles ;
- séparer strictement APIs workers et jobs ;
- retenir `ksp-job-backfill` pour l'acquisition historique à la demande ;
- normaliser les notifications de données indépendamment du producteur ;
- confirmer PostgreSQL comme implémentation de référence dans `ksp-store-lib` ;
- confirmer l'absence de pipeline/scenario monolithique ;
- confirmer Trading Intelligence avant la couche/application de trading opérationnelle.

## Version Cargo

Aucune modification de `Cargo.toml`.

Ce correctif est exclusivement documentaire. `workspace.package.version` reste :

```text
0.0.3-pre.1
```

## Fichiers ajoutés

- `deltas/0.0.3/pre.001-fix.004.md`

## Fichiers modifiés

- `README.md`
- `ROADMAP.md`
- `docs/architecture/003-COMPONENT_CONTRACTS.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 ajoutées

### Nomenclature des APIs

Les crates de contrats publics extensibles utilisent :

```text
ksp-<domain>-api
```

Elles restent techniquement des bibliothèques Rust mais n'utilisent pas le suffixe `-lib`, réservé par défaut aux bibliothèques d'implémentation.

Premiers couples :

```text
ksp-program-api        / ksp-program-lib
ksp-materializer-api   / ksp-materializer-lib
ksp-store-api          / ksp-store-lib
```

Un unique `ksp-api-lib` monolithique est rejeté.

### Store

`ksp-store-api` porte les contrats backend-agnostic.

`ksp-store-lib` contient PostgreSQL comme implémentation officielle de référence.

### Workers et jobs

Les contrats communs sont strictement séparés :

```text
ksp-worker-api
ksp-job-api
```

Aucune API universelle worker+job n'est prévue.

`ksp-worker-control-lib` reste candidat pour l'implémentation de contrôle des workers uniquement.

`ksp-job-backfill` est retenu comme candidat du backfill historique à la demande.

D'autres jobs pourront apparaître pour metadata, quotes ou autres travaux ponctuels.

### Notifications de données

Une notification de donnée décrit la donnée disponible, pas son producteur.

Le même type de donnée utilise le même contrat de notification qu'il provienne d'un worker, d'un job ou d'une autre source.

`ksp-store-api` est le propriétaire candidat de ces contrats lorsque la notification concerne une donnée persistée.

Le contrat de notification reste séparé du mécanisme de transport.

### Pipelines

Pas de `ksp-pipeline-lib` monolithique. Les pipelines sont introduits séparément à la demande avec un périmètre concret.

### Scénarios

Pas de `ksp-scenarios-lib` monolithique. Les scénarios sont séparés en crates `ksp-scenario-<domain>-lib`.

### Trading

Trading Intelligence est introduit avant la couche/application de trading opérationnelle.

## Validations

Correctif documentaire uniquement :

- présence des en-têtes `file:` / `version:` vérifiée lors de la génération ;
- aucune commande Cargo requise ;
- aucune modification fonctionnelle ou runtime.