v0.0.3-pre.001

This commit is contained in:
2026-08-14 00:03:57 +02:00
parent 4032298589
commit 5a86808376
23 changed files with 1845 additions and 102 deletions

View File

@@ -0,0 +1,116 @@
<!-- file: deltas/0.0.3/pre.001-fix.001.md -->
<!-- version: 1 -->
# Delta 0.0.3-pre.001-fix.001
## Base requise
`0.0.3-pre.001`.
## Objectif
Corriger et préciser le premier plan `0.0.3` à partir du brainstorming suivant :
- confirmer `ksp-interface-lib` comme façade wire KSP ;
- confirmer `ksp-core-lib` comme propriétaire du type d'erreur commun et des Program IDs ;
- retenir le nom `ksp-program-lib` ;
- corriger la politique decoder/executor : le decoder ne déprécie pas les formats historiques décodables, tandis que l'executor peut conserver des opérations obsolètes marquées `deprecated` ;
- confirmer que la sécurité d'exécution appartient à un niveau supérieur ;
- borner W1 à l'acquisition raw live/quasi-live, avec adaptation à chaud et notification ;
- préciser la granularité des demos/scénarios ;
- confirmer la trajectoire managers spécialisés -> orchestrateur ;
- définir `ksp-offchain-transport-lib` comme transport externe général ;
- introduire explicitement un principe contract-first pour les futures couches ;
- affiner la ligne directrice `0.1.x` à `0.7.x`.
## Version Cargo
Aucune modification de `Cargo.toml`.
Ce correctif est exclusivement documentaire. Conformément aux règles KSP, `workspace.package.version` reste donc :
```text
0.0.3-pre.1
```
## Fichiers ajoutés
- `docs/architecture/003-COMPONENT_CONTRACTS.md`
- `deltas/0.0.3/pre.001-fix.001.md`
## Fichiers modifiés
- `docs/architecture/000-README.md`
- `docs/architecture/002-LAYERS_AND_DEPENDENCIES.md`
- `docs/rules/RULES_KSP.md`
- `docs/IDEAS.md`
- `docs/plans/001-V0_0_3_PLAN.md`
## Fichiers supprimés
Aucun.
## Décisions précisées
### Erreurs
La direction reste un type d'erreur public commun dans `ksp-core-lib`. La représentation interne doit éviter de rendre N1 dépendant conceptuellement de chaque futur domaine supérieur.
### Interfaces
`ksp-interface-lib` possède la façade wire KSP : réexports contrôlés des interfaces officielles jugées suffisamment stables et réimplémentations compatibles lorsque KSP ne veut pas importer une crate protocolaire runtime.
### Programmes
Le nom `ksp-program-lib` est retenu.
Le decoder vise toute surface décodable connue. Le statut `deprecated` ne retire pas le décodage d'une surface historique distinguable.
L'executor peut conserver une opération obsolète encore techniquement exécutable en la marquant `deprecated`.
La politique de sécurité d'exécution appartient à une couche supérieure.
### W1
W1 :
- utilise les contrats KSP de configuration, transport et stockage nécessaires ;
- ne travaille que sur du live/quasi-live ;
- persiste du raw ;
- notifie l'arrivée de nouvelles données ;
- peut faire évoluer à chaud ce qu'il écoute/rapatrie/stocke ;
- ne décode pas ;
- ne matérialise pas ;
- ne fait pas de replay.
### Demos/scénarios
Memo, SPL Token classique, ATA et Token-2022 restent dans des demos/scénarios séparés.
Les metadata d'assets/tokens peuvent regrouper Metaplex Token Metadata et Token-2022 Metadata.
Solana Program Metadata reste séparé.
### Contrats précoces
Les grandes interfaces/traits sont définis tôt pour empêcher les premières implémentations de créer des couplages ad hoc. Leur implémentation complète peut rester différée jusqu'au premier besoin concret.
## Ligne directrice confirmée
- `0.1.x` — core/logging/config + application config ;
- `0.2.x` — transport on-chain, wallet, interface wire, program framework ;
- `0.3.x` — materializer/store/W1 + manager ;
- `0.4.x` — premiers Core/SPL/metadata + matérialisations + demos/scénarios ;
- `0.5.x` — Anchor puis protocoles trading par releases bornées ;
- `0.6.x` — W2 + managers/orchestrateur + application globale ;
- `0.7.x` — Trading Intelligence incluant statistiques, features, risque, backtests et ML/XGBoost.
La ligne directrice est stable, tandis que les numéros de releases et le contenu exact restent révisables selon les dépendances et besoins découverts.
## Validations
Correctif documentaire uniquement :
- structure et présence des fichiers vérifiées lors de la génération ;
- aucune commande Cargo requise par le contenu de ce fix ;
- aucune modification fonctionnelle ou runtime.

View File

@@ -0,0 +1,103 @@
<!-- file: deltas/0.0.3/pre.001-fix.002.md -->
<!-- version: 1 -->
# Delta 0.0.3-pre.001-fix.002
## Base requise
`0.0.3-pre.001-fix.001`.
## Objectif
Compléter le premier plan `0.0.3` avec :
- la règle d'extensibilité publique des contrats communs ;
- la séparation stricte entre W1 live/quasi-live et le backfill historique ;
- la mise à jour du roadmap fonctionnel `0.1.x+` ;
- l'introduction d'une structure durable de prompts ;
- le démarrage du brouillon vivant du prompt `0.1.x`.
## 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
- `prompts/000-README.md`
- `prompts/001-PROMPT_STRUCTURE.md`
- `prompts/002-V0_1_X_START_PROMPT.md`
- `deltas/0.0.3/pre.001-fix.002.md`
## Fichiers modifiés
- `README.md`
- `ROADMAP.md`
- `docs/architecture/003-COMPONENT_CONTRACTS.md`
- `docs/rules/RULES_KSP.md`
- `docs/rules/FILE_CONTRACTS.md`
- `docs/IDEAS.md`
- `docs/plans/001-V0_0_3_PLAN.md`
## Fichiers supprimés
Aucun.
## Décisions ajoutées
### Contrats publics extensibles
Les traits/APIs communs tels que `decoder_api`, `executor_api` et `materializer_api` doivent être exposés publiquement et conçus pour pouvoir être implémentés dans des crates séparées.
Cette extensibilité doit permettre de développer/tester des Program IDs ou matérialisations externes avant décision d'intégration dans les crates officielles KSP.
### Backfill historique
Le backfill historique est séparé de W1.
W1 reste exclusivement live/quasi-live.
Le backfill possède sa propre pagination, progression, checkpoint/reprise et gouvernance. Son nom/formalisme exact sera décidé pendant l'inventaire des domaines/crates.
### Roadmap
Le `ROADMAP.md` décrit désormais la trajectoire actuelle :
- `0.1.x` — fondations ;
- `0.2.x` — accès Solana et fondation programmes ;
- `0.3.x` — données, stockage, W1 et backfill ;
- `0.4.x` — baseline Solana/SPL/metadata ;
- `0.5.x` — Anchor et protocoles trading ;
- `0.6.x` — processing autonome/orchestration ;
- `0.7.x` — Trading Intelligence ;
- `0.8.x+` — extension continue.
Le plan détaillé reste volontairement souple et peut faire évoluer le contenu exact des releases sans changer la ligne directrice du court terme.
### Prompts
Un répertoire racine `prompts/` est introduit.
Le prompt `0.1.x` commence maintenant sous forme de brouillon vivant. Il sera mis à jour au fil des prereleases `0.0.3` et finalisé pendant la phase documentaire de clôture avant ouverture du développement fonctionnel.
## Questions restant ouvertes
- nom et forme exacte du composant de backfill historique ;
- nomenclature détaillée des futures APIs publiques ;
- règles d'arborescence/réexports à définir avec les premières APIs réelles ;
- représentation interne du type `ksp_core_lib::Error` ;
- liste complète des crates candidates et graphe de dépendances ;
- contenu exact du plan `0.1.x`.
## Validations
Correctif documentaire uniquement :
- structure et présence des fichiers vérifiées lors de la génération ;
- aucune commande Cargo requise par le contenu de ce fix ;
- aucune modification fonctionnelle ou runtime.

View File

@@ -0,0 +1,118 @@
<!-- file: deltas/0.0.3/pre.001-fix.003.md -->
<!-- version: 1 -->
# Delta 0.0.3-pre.001-fix.003
## Base requise
`0.0.3-pre.001-fix.002`.
## Objectif
Finaliser le cadrage de `pre.001` concernant les prompts et le dimensionnement des futures phases :
- déplacer la convention des prompts sous la documentation normative ;
- conserver `prompts/` uniquement pour les prompts eux-mêmes ;
- ajouter l'état validé à préserver et les sources externes normatives ;
- définir un budget de complexité pour les prereleases intermédiaires ;
- imposer le découpage d'une session/version lorsque le prompt prévu devient trop lourd ;
- renuméroter le brouillon `0.1.x` après déplacement de la convention.
## 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
- `docs/rules/PROMPT_STRUCTURE.md`
- `prompts/001-V0_1_X_START_PROMPT.md`
- `deltas/0.0.3/pre.001-fix.003.md`
## Fichiers modifiés
- `RULES.md`
- `docs/000-README.md`
- `docs/rules/FILE_CONTRACTS.md`
- `docs/plans/001-V0_0_3_PLAN.md`
- `prompts/000-README.md`
## Fichiers supprimés
- `prompts/001-PROMPT_STRUCTURE.md`
- `prompts/002-V0_1_X_START_PROMPT.md`
Le contenu du premier est déplacé et renforcé sous `docs/rules/PROMPT_STRUCTURE.md`.
Le second est renommé en `prompts/001-V0_1_X_START_PROMPT.md` et mis à jour.
## Décisions ajoutées
### Emplacement des conventions de prompt
Les règles/conventions de rédaction des prompts sont normatives et appartiennent à `docs/rules/PROMPT_STRUCTURE.md`.
Le répertoire `prompts/` contient uniquement l'index pratique et les prompts de reprise.
### Première et dernière prerelease
Par défaut :
- `pre.001` = brainstorming/audit si nécessaire + planification + découpage ;
- dernière prerelease = validations finales + documentation + nettoyage/archivage + prompt suivant.
### Budget des prereleases
Lors de la planification, chaque prerelease intermédiaire après `pre.001` doit viser une charge bornée.
Une tranche estimée à plus d'environ 1520 minutes de travail effectif doit être scindée avant développement.
Cette durée est un budget de planification, pas une promesse d'exécution.
### Contrôle anti-saturation
Avant finalisation d'un prompt de session suivante, la charge totale de la session prévue doit être évaluée.
Si elle paraît trop importante pour conserver un contexte fiable et une qualité de travail correcte, le plan est réparti sur :
- plusieurs sessions ;
- et/ou plusieurs versions lorsque la frontière fonctionnelle le justifie.
Le roadmap conserve sa ligne directrice même si son découpage initial évolue.
### Qualité des prompts
La structure KSP inclut désormais explicitement :
- base requise ;
- état validé à préserver ;
- sources de vérité internes ;
- sources externes normatives lorsqu'elles existent ;
- décisions acquises ;
- objectifs/hors périmètre ;
- plan souple ;
- validations ;
- critères de sortie ;
- préparation de la suite.
Cette structure reprend les qualités utiles observées dans les prompts historiques tout en évitant de recopier les règles et l'architecture déjà normalisées dans le dépôt.
## Questions ouvertes
Aucune nouvelle question bloquante pour `pre.001`.
Les questions architecturales restantes sont poursuivies dans `pre.002+`.
## Validations
Correctif documentaire uniquement :
- présence des en-têtes `file:` / `version:` vérifiée sur les fichiers livrés ;
- cohérence des chemins `prompts/` / `docs/rules/` vérifiée dans cette livraison ;
- aucune commande Cargo requise ;
- aucune modification fonctionnelle ou runtime.

View File

@@ -0,0 +1,124 @@
<!-- 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.

95
deltas/0.0.3/pre.001.md Normal file
View File

@@ -0,0 +1,95 @@
<!-- file: deltas/0.0.3/pre.001.md -->
<!-- version: 1 -->
# Delta 0.0.3-pre.001
## Base requise
Release `v0.0.2`.
## Objectif
Ouvrir la phase de brainstorming/planification `0.0.3` sans développement fonctionnel.
Cette tranche formalise les objectifs produits déjà discutés, le premier modèle de couches, les règles de dépendances externes, les responsabilités des applications/demos/workers et une prévision souple des prereleases nécessaires pour terminer la fondation avant `0.1.x`.
## Version Cargo
`workspace.package.version` passe à :
```text
0.0.3-pre.1
```
Cette synchronisation est obligatoire pour toute nouvelle prerelease non-fix, même lorsque la tranche est essentiellement documentaire.
Le fichier livré utilise `# version: 7`, en supposant que la publication finale `v0.0.2` a synchronisé le `Cargo.toml` de la base vers la version fichier 6 conformément aux règles. Si la base locale ne correspond pas à cette hypothèse, la version de fichier doit être réconciliée avant commit sans changer l'identifiant fonctionnel `0.0.3-pre.1`.
## Fichiers ajoutés
- `docs/architecture/000-README.md`
- `docs/architecture/001-PROJECT_OBJECTIVES.md`
- `docs/architecture/002-LAYERS_AND_DEPENDENCIES.md`
- `docs/plans/000-README.md`
- `docs/plans/001-V0_0_3_PLAN.md`
- `docs/rules/RULES_DEPENDENCIES.md`
- `deltas/0.0.3/pre.001.md`
## Fichiers modifiés
- `Cargo.toml`
- `README.md`
- `RULES.md`
- `ROADMAP.md`
- `docs/000-README.md`
- `docs/IDEAS.md`
- `docs/rules/FILE_CONTRACTS.md`
- `docs/rules/RULES_KSP.md`
## Fichiers supprimés
Aucun.
## Décisions enregistrées
- `ksp-config-lib` et `ksp-logging-lib` sont positionnés en N1 avec `ksp-core-lib` et la future crate d'interface/wire.
- Les niveaux servent à déterminer responsabilité et sens des dépendances ; ils ne forcent pas un passage par toutes les couches.
- Une application spécialisée peut dépendre directement de la bibliothèque KSP qu'elle manipule.
- Les applications et demos sont des interfaces/compositions et ne réimplémentent pas les opérations réutilisables.
- Une demo réutilise une bibliothèque de scénarios lorsqu'un scénario correspondant existe.
- Les workers peuvent posséder l'orchestration runtime nécessaire mais ne contournent pas les bibliothèques KSP.
- Applications, demos et workers ne dépendent pas directement de crates externes liées à Solana ou à un protocole Solana.
- Les dépendances Solana externes sont confinées aux bibliothèques KSP propriétaires appropriées.
- `solana-pubkey`, `solana-keypair`, `solana-signer`, `solana-hash` et `solana-nonce` sont retenues comme primitives fondamentales autorisées dans les bibliothèques appropriées.
- `mpl-token-metadata`, `spl-elgamal-registry-interface` et les crates protocolaires analogues sont interdites par défaut comme dépendances runtime ; KSP préfère posséder les contrats wire nécessaires.
- L'objectif court terme est une application de trading monoposte ; les objectifs moyen/long terme incluent un explorer Solana et une application d'exploration/analyse DEX plus complète.
## Questions ouvertes
- nom définitif et périmètre exact de `ksp-interface-lib` ;
- découpage decoder / construction / exécution ;
- liste candidate et responsabilité précise des crates N2/N3 ;
- position exacte de wallet, transport, store, pipeline, replay et scénarios ;
- méthode de conformité wire contre les projets externes ;
- éventuel usage de crates protocolaires externes uniquement comme dépendances de test ;
- nomenclature finale de toutes les applications et workers ;
- plan exact des versions fonctionnelles `0.1.x+`.
## Validations exécutées
- vérification statique de la syntaxe TOML du `Cargo.toml` livré ;
- vérification de présence des en-têtes `file:` et `version:` des fichiers Markdown/TOML livrés ;
- vérification de l'arborescence et de l'identifiant du delta.
## Validations non exécutées
Les commandes Cargo doivent être exécutées sur le dépôt cible après application :
```bash
cargo fmt --all
cargo check --workspace
cargo test --workspace
cargo clippy --workspace --all-targets
```
Aucun code fonctionnel n'est ajouté dans cette tranche.