Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.1.1-pre.005

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-14 16:04:45 +02:00
parent b01fb3fa53
commit 11ca53ba48
8 changed files with 595 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 8 -->
<!-- version: 9 -->
# Documentation KSP
@@ -34,7 +34,8 @@ docs/
├── plans/
│ ├── 000-README.md
│ ├── 001-V0_0_3_PLAN.md
│ └── 002-FUNCTIONAL_RELEASE_SEQUENCE.md
│ ├── 002-FUNCTIONAL_RELEASE_SEQUENCE.md
│ └── 003-V0_1_1_CORE_FOUNDATION_PLAN.md
└── rules/
├── FILE_CONTRACTS.md
├── PROMPT_STRUCTURE.md
@@ -51,7 +52,7 @@ D'autres sous-répertoires seront ajoutés uniquement lorsque leur rôle aura é
## Documents de planification
Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md).
Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la première release fonctionnelle est conservé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md).
`IDEAS.md` conserve les pistes et questions qui ne sont pas encore des engagements du roadmap ni des décisions architecturales.

6
docs/plans/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/000-README.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Plans KSP
@@ -10,8 +10,8 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou
## Plans de référence
- [`001-V0_0_3_PLAN.md`](001-V0_0_3_PLAN.md) — plan historique de la phase fondatrice `0.0.3`, clôturée ;
- [`002-FUNCTIONAL_RELEASE_SEQUENCE.md`](002-FUNCTIONAL_RELEASE_SEQUENCE.md) — séquence active de référence des premières releases fonctionnelles, dont `0.1.1`.
- [`003-V0_1_1_CORE_FOUNDATION_PLAN.md`](003-V0_1_1_CORE_FOUNDATION_PLAN.md) — plan actif détaillé de `0.1.1`, établi par `0.1.1-pre.001`.
- [`002-FUNCTIONAL_RELEASE_SEQUENCE.md`](002-FUNCTIONAL_RELEASE_SEQUENCE.md) — séquence active de référence des premières releases fonctionnelles ;
- [`003-V0_1_1_CORE_FOUNDATION_PLAN.md`](003-V0_1_1_CORE_FOUNDATION_PLAN.md) — plan détaillé de `0.1.1`, établi par `0.1.1-pre.001` et consolidé jusqu'à sa tranche de clôture.
Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre.

58
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Séquence des releases fonctionnelles KSP
@@ -48,27 +48,24 @@ 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
### Surface stabilisée
À auditer précisément dans `0.1.1-pre.001`, avec comme candidats acquis :
`0.1.1` stabilise :
- 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.
- `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.
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.
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
@@ -87,20 +84,20 @@ Une primitive Solana/Anza officiellement stable peut être ajoutée seulement lo
### Lifecycle de la release
Le nombre de prereleases n'est pas figé avant `pre.001`.
Trajectoire candidate :
Trajectoire réellement suivie :
```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
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 après validation de pre.005
```
Cette séquence est indicative. `pre.001` peut la modifier.
## `0.1.2` — Logging foundation
### Dépendances
@@ -325,7 +322,7 @@ Les directions restent celles du roadmap :
Ces séries sont des objectifs fonctionnels, pas un calendrier contractuel.
# Sélection de la première release
# Progression de la série `0.1.x`
La première release fonctionnelle est :
@@ -333,10 +330,15 @@ La première release fonctionnelle est :
0.1.1 — Core foundation
```
Le prompt de démarrage associé est :
Son prompt historique d'ouverture reste :
```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`.
À la clôture de `0.1.1-pre.005`, la surface Core est prête pour validation puis publication stable via `0.1.1-rel.001`. Après 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
```

45
docs/plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md
View File

@@ -1,13 +1,13 @@
<!-- file: docs/plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md -->
<!-- version: 8 -->
<!-- version: 9 -->
# Plan KSP 0.1.1 — Core foundation
## Statut
Plan de travail de `0.1.1`, établi par `0.1.1-pre.001`.
Plan de travail de `0.1.1`, établi par `0.1.1-pre.001` puis consolidé jusqu'à la tranche de clôture `0.1.1-pre.005`.
Cette première prerelease reste une tranche de brainstorming, audit et planification. Elle ne développe pas encore la surface fonctionnelle Core.
La surface fonctionnelle Core prévue par ce plan est désormais implémentée et validée jusqu'à `pre.004`. `pre.005` finalise la documentation, le prompt `0.1.2` et la préparation de publication ; la version stable `0.1.1` reste à publier par un delta `rel.001` après validation de cette dernière prerelease.
## Base auditée
@@ -185,6 +185,10 @@ Décision pour `0.1.1` :
- n'activer ni Borsh, ni Wincode, ni Serde, ni Rand, ni feature cryptographique par anticipation ;
- réexporter le type `Pubkey` depuis `ksp_core_lib` afin que son utilisation fasse partie intentionnellement du contrat Core.
L'audit final `pre.005` confirme qu'aucune feature optionnelle de `solana-pubkey` ne doit être activée dans `0.1.1`. La surface Core actuelle utilise uniquement l'identité `Pubkey`, la construction compile-time des Program IDs et les opérations déjà disponibles avec la dépendance retenue. Les features `alloc`, `borsh`, `bytemuck`, `curve25519`, `rand`, `serde`, `sha2`, `std` et `wincode` restent need-driven et seront activées uniquement dans la crate propriétaire lorsqu'un contrat réel l'exigera.
Le `cargo tree -p ksp-core-lib -e features` exécuté par le user montre des features de `solana-address` telles que `copy`, `decode`, `error`, `sanitize`, `syscalls` et `default`. Elles proviennent de la composition interne résolue de `solana-pubkey`/`solana-address` et ne justifient pas d'activer une feature optionnelle KSP supplémentaire sur `solana-pubkey`.
Depuis `pre.003-fix.001`, la règle générale KSP impose la centralisation des dépendances externes sous `[workspace.dependencies]` et l'héritage `.workspace = true` dans les crates membres. La résolution Cargo observée pour la contrainte `^4.3` reste `solana-pubkey 4.3.0` au moment de cette tranche.
### `solana-address`
@@ -628,23 +632,30 @@ Résultat de l'audit d'intégration :
- aucune primitive N1 supplémentaire n'est démontrée nécessaire ;
- les modules d'implémentation restent privés et les contrats consommables sont réexportés explicitement au crate-root ;
- le test d'intégration public vérifie aussi qu'un consommateur peut déclarer un `const ErrorCode`, usage requis par les futures crates propriétaires de domaines ;
- la rustdoc crate-level est complétée pour expliciter la frontière Core ;
- les validations de `pre.003-fix.001` communiquées par le user confirment 14 tests unitaires, 3 tests d'intégration, un `cargo tree` limité à `solana-pubkey` et ses dépendances fondamentales, et aucun doublon avec `cargo tree -d`.
- la rustdoc crate-level est complétée pour expliciter la frontière Core.
La tranche ne change ni le contrat Error, ni la taxonomie, ni l'inventaire des 18 Program IDs. Le contrôle résolu des features reste à confirmer sur le dépôt cible avec `cargo tree -p ksp-core-lib -e features` en complément des validations Cargo usuelles.
Validations `pre.004` exécutées avec succès par le user le 2026-08-14 :
- `cargo fmt --all` ;
- `cargo check --workspace` ;
- `cargo test --workspace` : 14 tests unitaires et 3 tests d'intégration publics réussis ;
- `cargo clippy --workspace --all-targets` : succès sans warning communiqué ;
- `cargo tree -p ksp-core-lib` : dépendance directe unique `solana-pubkey 4.3.0`, résolvant `solana-address 2.7.0` ;
- `cargo tree -p ksp-core-lib -d` : aucun doublon ;
- `cargo tree -p ksp-core-lib -e features` : graphe des features inspecté, sans besoin d'activer une feature optionnelle `solana-pubkey` supplémentaire pour le contrat Core actuel.
La tranche ne change ni le contrat Error, ni la taxonomie, ni l'inventaire des 18 Program IDs.
### `0.1.1-pre.005` — clôture
Objectifs :
Résultat de clôture préparé :
- validations finales workspace ;
- audits documentaires applicables ;
- correction des écarts résiduels ;
- documentation finale et éventuel `USAGE.md` de Core si l'API justifie alors un exemple durable ;
- nettoyage/archivage des éléments temporaires ;
- mise à jour du changelog général s'il existe alors ;
- production du prompt final de démarrage `0.1.2` ;
- préparation de la publication stable et du tag `v0.1.1`.
- aucune nouvelle primitive Core et aucune nouvelle feature `solana-pubkey` ne sont ajoutées ;
- les documents de référence de `0.1.1` sont réalignés avec la surface effectivement livrée ;
- aucun `README.md`/`USAGE.md` spécifique à la crate n'est ajouté : la rustdoc crate-level et les tests publics couvrent suffisamment la petite surface actuelle ;
- aucun changelog général n'existe dans la base actuelle, donc aucun fichier de changelog artificiel n'est créé uniquement pour cette release ;
- le prompt final `prompts/002-V0_1_2_START_PROMPT.md` est créé pour ouvrir Logging après publication stable de `0.1.1` ;
- la publication stable reste volontairement séparée dans un futur delta `0.1.1-rel.001`, conformément au workflow de versionnement.
Un `pre.NNN-fix.NNN` corrige la tranche correspondante sans réécrire son historique.
@@ -669,6 +680,4 @@ Un `pre.NNN-fix.NNN` corrige la tranche correspondante sans réécrire son histo
## Questions ouvertes non bloquantes
- Décider en `pre.005`, à partir de l'API réellement stabilisée, si un `README.md`/`USAGE.md` de crate apporte suffisamment de valeur pour être créé maintenant.
Aucune de ces questions ne justifie d'élargir le périmètre fonctionnel de `0.1.1`.
Aucune question ouverte ne bloque la publication de `0.1.1`. Les capacités volontairement différées restent soumises à la règle need-driven des releases futures plutôt qu'à des placeholders Core.