343 lines
8.8 KiB
Markdown
343 lines
8.8 KiB
Markdown
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
|
|
<!-- version: 2 -->
|
|
|
|
# Séquence des releases fonctionnelles KSP
|
|
|
|
## Objet
|
|
|
|
Ce document formalise la sortie principale de `0.0.3-pre.009`.
|
|
|
|
Il transforme les séries fonctionnelles du roadmap en une première séquence de développement concrète sans prétendre connaître trop tôt tous les numéros des séries futures.
|
|
|
|
Principes :
|
|
|
|
- une série `X.Y.x` est une famille fonctionnelle ;
|
|
- une release concrète `X.Y.Z` est une unité de travail/session dimensionnée ;
|
|
- chaque release concrète possède ses propres prereleases ;
|
|
- une release trop grosse est scindée au lieu d'être forcée dans une session ;
|
|
- les numéros futurs sont confirmés lorsque leur série approche et que les dépendances réelles sont connues.
|
|
|
|
# Première série fonctionnelle : `0.1.x`
|
|
|
|
La série `0.1.x` construit les fondations N1 dans l'ordre de dépendances réel.
|
|
|
|
Séquence par défaut :
|
|
|
|
```text
|
|
0.1.1 ksp-core-lib
|
|
|
|
|
v
|
|
0.1.2 ksp-logging-lib
|
|
|
|
|
v
|
|
0.1.3 ksp-config-lib
|
|
|
|
|
v
|
|
0.1.4 ksp-app-config-desk
|
|
```
|
|
|
|
`0.1.1` et `0.1.2` sont fixées.
|
|
|
|
`0.1.3` et `0.1.4` sont la séquence par défaut. Si le `pre.001` de Config démontre qu'une seule release ne permet pas un développement propre, Config est scindé et les numéros suivants sont décalés.
|
|
|
|
## `0.1.1` — Core foundation
|
|
|
|
### Mission
|
|
|
|
Stabiliser `ksp-core-lib` comme fondation N1 minimale et durable.
|
|
|
|
Le Core possède uniquement les contrats réellement transversaux nécessaires aux couches supérieures.
|
|
|
|
### Périmètre initial
|
|
|
|
À auditer précisément dans `0.1.1-pre.001`, avec comme candidats acquis :
|
|
|
|
- type public commun `ksp_core_lib::Error` ;
|
|
- alias public commun `Result<T>` ou forme équivalente validée ;
|
|
- architecture d'erreur permettant aux domaines supérieurs d'ajouter du contexte sans faire connaître tous les futurs domaines à Core ;
|
|
- Program IDs fondamentaux appartenant à KSP Core ;
|
|
- primitives/identités réellement communes et déjà justifiées ;
|
|
- conventions de version/provenance N1 uniquement si un besoin concret existe ;
|
|
- exports crate-root et documentation publique ;
|
|
- tests unitaires/integration appropriés ;
|
|
- respect complet des règles Rust/workspace.
|
|
|
|
### Dépendances
|
|
|
|
Core ne dépend pas de `ksp-logging-lib`, Config, Wallet, Store, Transport, Program ou Materializer.
|
|
|
|
Une primitive Solana/Anza officiellement stable peut être ajoutée seulement lorsqu'un item Core concret en a besoin.
|
|
|
|
`solana-pubkey` est un candidat naturel pour les Program IDs ; les autres primitives autorisées ne sont pas ajoutées par anticipation.
|
|
|
|
### Hors scope
|
|
|
|
- logging ;
|
|
- configuration ;
|
|
- Tauri ;
|
|
- wallet/signing ;
|
|
- codecs wire ;
|
|
- decoders/Program registry ;
|
|
- transaction execution ;
|
|
- transport ;
|
|
- Store ;
|
|
- Materializer ;
|
|
- workers/jobs ;
|
|
- scenarios.
|
|
|
|
### Lifecycle de la release
|
|
|
|
Le nombre de prereleases n'est pas figé avant `pre.001`.
|
|
|
|
Trajectoire candidate :
|
|
|
|
```text
|
|
pre.001 brainstorming + audit + plan détaillé
|
|
pre.002 Error/Result + fondation API
|
|
pre.003 primitives/Program IDs réellement retenus
|
|
pre.004 compléments/tests/audits
|
|
pre.005 validation finale/docs/cleanup/prompt 0.1.2
|
|
```
|
|
|
|
Cette séquence est indicative. `pre.001` peut la modifier.
|
|
|
|
## `0.1.2` — Logging foundation
|
|
|
|
### Dépendances
|
|
|
|
```text
|
|
ksp-logging-lib
|
|
-> ksp-core-lib
|
|
-> tracing
|
|
-> tracing-appender
|
|
-> tracing-subscriber
|
|
```
|
|
|
|
### Mission
|
|
|
|
Faire de `ksp-logging-lib` la façade KSP unique de logging/tracing pour les composants runtime.
|
|
|
|
### Périmètre candidat
|
|
|
|
- initialisation ;
|
|
- settings runtime propres au logging ;
|
|
- `error`, `warn`, `info`, `debug`, `trace` ;
|
|
- target/domain/component/champs structurés selon API validée ;
|
|
- fonctions, macros ou combinaison permettant de préserver correctement les callsites ;
|
|
- console/fichiers ;
|
|
- filtering ;
|
|
- appender/rotation selon besoin concret ;
|
|
- tests ;
|
|
- protection contre logging de secrets.
|
|
|
|
`ksp-logging-lib` ne dépend pas de `ksp-config-lib`.
|
|
|
|
Config pourra plus tard convertir ses documents résolus en settings de Logging.
|
|
|
|
## `0.1.3` — Configuration foundation
|
|
|
|
### Dépendances candidates
|
|
|
|
```text
|
|
ksp-config-lib
|
|
-> ksp-core-lib
|
|
-> ksp-logging-lib
|
|
```
|
|
|
|
### Mission
|
|
|
|
Introduire la configuration générale KSP.
|
|
|
|
Périmètre candidat à revalider dans son `pre.001` :
|
|
|
|
- documents spécialisés ;
|
|
- profils ;
|
|
- `default_profile` autonome ;
|
|
- valeurs globales hors profils lorsqu'elles ne varient pas ;
|
|
- résolution ;
|
|
- validation ;
|
|
- modification/sauvegarde ;
|
|
- variables d'environnement `KS_*` / `KB_*` ;
|
|
- secret/public/debug exposure policy ;
|
|
- `logging.config.json` séparé ;
|
|
- schemas sous `config/schemas/` ;
|
|
- examples sous `config/`.
|
|
|
|
### Règle de scission
|
|
|
|
Si le plan détaillé démontre que validation/schemas, résolution/profiles et mutation/persistence dépassent une release raisonnable, Config est réparti sur deux releases de `0.1.x`.
|
|
|
|
Aucun sous-périmètre n'est compressé artificiellement pour préserver le numéro `0.1.4` de l'application desktop.
|
|
|
|
## `0.1.4` — Config desktop par défaut
|
|
|
|
Sous réserve d'absence de scission de Config.
|
|
|
|
Mission :
|
|
|
|
```text
|
|
ksp-app-config-desk
|
|
-> ksp-config-lib
|
|
-> ksp-logging-lib
|
|
```
|
|
|
|
L'application doit valider réellement :
|
|
|
|
- lecture de documents ;
|
|
- profils/default profile ;
|
|
- résolution ;
|
|
- validation ;
|
|
- édition/sauvegarde ;
|
|
- env overrides exposables ;
|
|
- diagnostics/errors ;
|
|
- intégration logging ;
|
|
- conventions Tauri/DTO/TS-RS.
|
|
|
|
La logique Config reste dans `ksp-config-lib`.
|
|
|
|
# Règle Git à partir de `0.1.x`
|
|
|
|
À partir de la première release fonctionnelle, **chaque delta est commité**.
|
|
|
|
Exemples :
|
|
|
|
```text
|
|
0.1.1-pre.001
|
|
0.1.1-pre.002
|
|
0.1.1-pre.002-fix.001
|
|
...
|
|
0.1.1
|
|
```
|
|
|
|
Une étape intermédiaire erronée n'est pas supprimée de l'historique pour reconstruire artificiellement un développement parfait. Elle est corrigée par un delta/commit suivant.
|
|
|
|
Seul le commit de release stable reçoit le tag :
|
|
|
|
```text
|
|
v0.1.1
|
|
```
|
|
|
|
# Lifecycle standard d'une release fonctionnelle
|
|
|
|
## Première prerelease
|
|
|
|
Par défaut :
|
|
|
|
- relire la base validée ;
|
|
- brainstorming ;
|
|
- audit des besoins ;
|
|
- vérification des dépendances externes actuelles depuis les sources officielles lorsque concernées ;
|
|
- plan détaillé ;
|
|
- inventaire des fichiers/API touchés ;
|
|
- dimensionnement des prereleases ;
|
|
- décision explicite sur les hors-scope.
|
|
|
|
La première prerelease ne doit pas se transformer automatiquement en une grosse phase d'implémentation.
|
|
|
|
## Prereleases intermédiaires
|
|
|
|
Chaque prerelease porte un objectif borné et cohérent.
|
|
|
|
Une tranche de travail de planification/développement manifestement trop grosse est scindée.
|
|
|
|
## Dernière prerelease
|
|
|
|
Par défaut :
|
|
|
|
- validations complètes ;
|
|
- tests de conformité/audits ;
|
|
- documentation finale ;
|
|
- nettoyage/archivage ;
|
|
- changelog ;
|
|
- prompt de la release suivante ;
|
|
- vérification de cohérence des versions.
|
|
|
|
# Série `0.2.x` — ordre candidat uniquement
|
|
|
|
`0.2.x` ouvre les capacités Solana N2.
|
|
|
|
L'ordre exact des numéros n'est **pas figé** en `0.0.3`.
|
|
|
|
Ordre candidat à réévaluer à l'approche de la série :
|
|
|
|
```text
|
|
wallet foundation
|
|
-> wallet specialized app
|
|
|
|
on-chain transport foundation
|
|
-> specialized transport/demo validation
|
|
|
|
interface/wire foundation
|
|
-> first concrete Program surface
|
|
|
|
program-api / program-lib
|
|
-> first real decoder + ProgramExecutionPreparer + registry validation
|
|
|
|
execution-policy-api / execution-lib
|
|
-> first real execution cycle
|
|
|
|
scenario/demo validating the complete path
|
|
```
|
|
|
|
Wallet, Transport et Interface sont en grande partie indépendants ; leur ordre précis peut donc être réordonné selon le premier cas fonctionnel choisi.
|
|
|
|
`ksp-offchain-transport-lib` reste need-driven.
|
|
|
|
# Série `0.3.x` — ordre candidat uniquement
|
|
|
|
Direction :
|
|
|
|
```text
|
|
store-api + PostgreSQL store foundation
|
|
|
|
|
v
|
|
D1 raw persistence
|
|
|
|
|
v
|
|
specialized Store app
|
|
|
|
|
v
|
|
worker-api / job-api
|
|
|
|
|
v
|
|
raw-ingestion pipeline
|
|
|
|
|
+--> raw-retriever service
|
|
|
|
|
+--> backfill job
|
|
```
|
|
|
|
Les contrats Materializer et les frontières D2/D3/D4 sont introduits lorsque les sorties Program/Core réelles nécessaires existent.
|
|
|
|
Store/D1/acquisition peuvent donc être validés avant une matérialisation complète.
|
|
|
|
# Séries suivantes
|
|
|
|
Les directions restent celles du roadmap :
|
|
|
|
```text
|
|
0.4.x Core/SPL/metadata + scenarios/demos
|
|
0.5.x Anchor + protocoles trading
|
|
0.6.x processing autonome D1 -> D4
|
|
0.7.x Trading Intelligence
|
|
0.8.x+ trading opérationnel + explorers + expansion produits
|
|
```
|
|
|
|
Ces séries sont des objectifs fonctionnels, pas un calendrier contractuel.
|
|
|
|
# Sélection de la première release
|
|
|
|
La première release fonctionnelle est :
|
|
|
|
```text
|
|
0.1.1 — Core foundation
|
|
```
|
|
|
|
Le prompt de démarrage associé est :
|
|
|
|
```text
|
|
prompts/001-V0_1_1_START_PROMPT.md
|
|
```
|
|
|
|
`0.0.3` est désormais la base fondatrice stable. La prochaine phase ouvre `0.1.1-pre.001` à partir du prompt final `prompts/001-V0_1_1_START_PROMPT.md`.
|