345 lines
9.2 KiB
Markdown
345 lines
9.2 KiB
Markdown
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
|
|
<!-- version: 4 -->
|
|
|
|
# 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.
|
|
|
|
### Surface stabilisée
|
|
|
|
`0.1.1` stabilise :
|
|
|
|
- `ksp_core_lib::ErrorCode`, `ErrorContext`, `Error` et `Result<T>` comme contrat d'erreur ouvert aux domaines supérieurs ;
|
|
- `ksp_core_lib::Pubkey` comme primitive Solana réexportée par Core ;
|
|
- 18 Program IDs fondamentaux possédés par KSP avec paires `PRGID_*` / `PRGIDPK_*` ;
|
|
- `declare_program_id!` pour construire la représentation texte et `Pubkey` depuis une déclaration canonique unique ;
|
|
- `ProgramIdEntry`, `ProgramIdFilter`, `ProgramIdKind` et le registre enumerable/recherchable ;
|
|
- des vues par domaine/famille/protocole et `native_program_ids()` sans registres secondaires ;
|
|
- une taxonomie extensible séparant notamment `subfamily` et `program_version` ;
|
|
- les réexports crate-root, rustdocs et tests publics correspondants.
|
|
|
|
### Dépendances
|
|
|
|
Core ne dépend pas de `ksp-logging-lib`, Config, Wallet, Store, Transport, Program ou Materializer.
|
|
|
|
La seule dépendance externe directe de `ksp-core-lib` à la clôture est `solana-pubkey`, déclarée au workspace avec la génération `^4.3`, `default-features = false`, puis héritée par la crate avec `.workspace = true`. Aucune feature optionnelle supplémentaire n'est activée dans `0.1.1`.
|
|
|
|
### Hors scope
|
|
|
|
- logging ;
|
|
- configuration ;
|
|
- Tauri ;
|
|
- wallet/signing ;
|
|
- codecs wire ;
|
|
- decoders/Program registry ;
|
|
- transaction execution ;
|
|
- transport ;
|
|
- Store ;
|
|
- Materializer ;
|
|
- workers/jobs ;
|
|
- scenarios.
|
|
|
|
### Lifecycle de la release
|
|
|
|
Trajectoire réellement suivie :
|
|
|
|
```text
|
|
pre.001 brainstorming + audit + plan détaillé
|
|
pre.001-fix.001/.002 corrections de cadrage Program IDs/taxonomie
|
|
pre.002 Error/Result + fondation API
|
|
pre.002-fix.001 corrections de tests/lints
|
|
pre.003 Pubkey + Program IDs
|
|
pre.003-fix.001 politique Cargo workspace + corrections Clippy
|
|
pre.004 intégration Core + audits
|
|
pre.005 validation finale/docs/cleanup/prompt 0.1.2
|
|
rel.001 publication stable validée de 0.1.1
|
|
```
|
|
|
|
## `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.
|
|
|
|
# Progression de la série `0.1.x`
|
|
|
|
La première release fonctionnelle est :
|
|
|
|
```text
|
|
0.1.1 — Core foundation
|
|
```
|
|
|
|
Son prompt historique d'ouverture reste :
|
|
|
|
```text
|
|
prompts/001-V0_1_1_START_PROMPT.md
|
|
```
|
|
|
|
`0.1.1-rel.001` publie la surface Core stable après validation complète de `pre.005`. Le commit de release reçoit le tag `v0.1.1`. La release suivante s'ouvre avec :
|
|
|
|
```text
|
|
0.1.2 — Logging foundation
|
|
prompts/002-V0_1_2_START_PROMPT.md
|
|
```
|