v0.1.1-pre.005

This commit is contained in:
2026-08-14 16:04:45 +02:00
parent b01fb3fa53
commit 11ca53ba48
8 changed files with 595 additions and 56 deletions

191
deltas/0.1.1/pre.005.md Normal file
View File

@@ -0,0 +1,191 @@
<!-- file: deltas/0.1.1/pre.005.md -->
<!-- version: 1 -->
# Delta `0.1.1-pre.005` — clôture Core et prompt Logging
## Base requise
`v0.1.1-pre.004` au sens du commit de livraison correspondant, avec :
```text
workspace.package.version = "0.1.1-pre.4"
```
Le présent delta ouvre :
```text
workspace.package.version = "0.1.1-pre.5"
```
## Objectif
Clôturer la phase de développement `0.1.1` sans élargir la surface Core : enregistrer les validations finales de `pre.004`, confirmer la politique de features `solana-pubkey`, réaligner les documents de référence et produire le prompt final de démarrage `0.1.2`.
La publication stable reste un delta `0.1.1-rel.001` séparé après validation de cette prerelease.
## Validation de la base précédente
Le user a exécuté avec succès le 2026-08-14 :
```bash
cargo fmt --all
cargo check --workspace
cargo test --workspace
cargo clippy --workspace --all-targets
cargo tree -p ksp-core-lib
cargo tree -p ksp-core-lib -d
cargo tree -p ksp-core-lib -e features
```
Résultats communiqués :
- 14 tests unitaires passent ;
- 3 tests d'intégration publics passent ;
- Clippy passe sans warning communiqué ;
- `cargo tree` conserve `solana-pubkey 4.3.0` comme unique dépendance externe directe de `ksp-core-lib` ;
- `solana-pubkey` résout `solana-address 2.7.0` puis ses dépendances fondamentales ;
- `cargo tree -d` ne rapporte aucun doublon ;
- `cargo tree -e features` a été inspecté.
## Décision finale sur les features `solana-pubkey`
Aucune feature optionnelle supplémentaire n'est activée dans `0.1.1`.
La déclaration workspace reste :
```toml
solana-pubkey = { version = "^4.3", default-features = false }
```
Les features optionnelles `alloc`, `borsh`, `bytemuck`, `curve25519`, `rand`, `serde`, `sha2`, `std` et `wincode` ne correspondent à aucun besoin du contrat Core actuellement livré.
Les features `solana-address` visibles dans le graphe résolu (`copy`, `decode`, `error`, `sanitize`, `syscalls`, `default`) appartiennent à la composition interne de la génération actuelle de `solana-pubkey`/`solana-address`. Elles ne justifient pas une activation KSP supplémentaire.
Les futures releases activent une feature uniquement lorsque leur propriétaire fonctionnel démontre un besoin concret. En particulier, `borsh`/`wincode` ne sont pas activées dans Core par anticipation d'une future surface wire.
## Documentation finale
Le plan `0.1.1` est consolidé pour :
- refléter la surface réellement implémentée ;
- enregistrer les validations réussies de `pre.004` ;
- fermer la question des features `solana-pubkey` ;
- confirmer qu'aucune primitive N1 supplémentaire n'est nécessaire ;
- confirmer qu'aucun `README.md`/`USAGE.md` spécifique à la crate n'est nécessaire pour cette petite surface ;
- confirmer que le dépôt ne possède actuellement aucun changelog général à synchroniser.
La séquence fonctionnelle est mise à jour pour remplacer le périmètre candidat de `0.1.1` par la surface effectivement stabilisée et son lifecycle réellement suivi.
Les index de documentation/plans/prompts sont réalignés avec les fichiers présents.
## Prompt `0.1.2`
Ajout :
```text
prompts/002-V0_1_2_START_PROMPT.md
```
Ce prompt ouvre :
```text
0.1.2 — Logging foundation
```
après publication stable de `0.1.1`.
Il conserve notamment les décisions suivantes :
- `ksp-logging-lib` est la façade KSP unique de logging/tracing runtime ;
- Logging peut dépendre de `ksp-core-lib`, jamais l'inverse ;
- `pre.001` de Logging reste une phase d'audit/brainstorming/planification ;
- la stack `tracing` et ses features sont revérifiées depuis les sources officielles avant ajout ;
- l'API doit préserver les callsites réels ;
- Logging possède ses settings runtime sans dépendre de Config ;
- les secrets ne sont jamais loggés automatiquement ;
- les dépendances externes restent centralisées sous `[workspace.dependencies]`.
## Fichiers ajoutés
```text
deltas/0.1.1/pre.005.md
prompts/002-V0_1_2_START_PROMPT.md
```
## Fichiers modifiés
```text
Cargo.toml
docs/000-README.md
docs/plans/000-README.md
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
docs/plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md
prompts/000-README.md
```
## Fichiers supprimés
Aucun.
## Nettoyage/archivage
Aucun fichier temporaire ou obsolète supplémentaire n'est identifié comme devant être supprimé dans cette tranche.
Les deltas historiques et le prompt `0.1.1` restent conservés comme historique utile.
## Validations exécutées pendant la préparation
Contrôles statiques hors Cargo :
- parsing TOML ;
- headers `file:` / `version:` des fichiers modifiés/ajoutés ;
- terminaison EOF ;
- liens Markdown locaux ;
- cohérence des index documentaires ;
- cohérence de la version `0.1.1-pre.5` ;
- absence d'ajout de feature `solana-pubkey` ;
- intégrité de l'archive delta.
## Validations non exécutées pendant la préparation
L'environnement de préparation ne fournit pas `cargo`/`rustc`.
Après application du delta, exécuter sur le dépôt cible :
```bash
cargo fmt --all
cargo check --workspace
cargo test --workspace
cargo clippy --workspace --all-targets
cargo tree -p ksp-core-lib
cargo tree -p ksp-core-lib -d
cargo tree -p ksp-core-lib -e features
```
Aucune de ces validations de `pre.005` n'est déclarée réussie avant exécution par le user.
## Publication suivante
Si `pre.005` est propre, préparer :
```text
0.1.1-rel.001
```
avec :
```text
workspace.package.version = "0.1.1"
```
Le commit de `rel.001` validé comme stable reçoit ensuite le tag :
```text
v0.1.1
```
La session suivante peut alors démarrer avec :
```text
prompts/002-V0_1_2_START_PROMPT.md
```