v0.2.11-pre.001-fix.001

This commit is contained in:
2026-08-25 18:37:51 +02:00
parent a8e980b225
commit f42fa8f4f1
2 changed files with 227 additions and 19 deletions

View File

@@ -0,0 +1,131 @@
<!-- file: deltas/0.2.11/pre.001-fix.001.md -->
<!-- version: 1 -->
# Delta `0.2.11-pre.001-fix.001` — forecast souple éditable
## 1. Base
Ce fix s'applique exclusivement à :
```text
v0.2.11-pre.001
```
Commit attendu :
```text
v0.2.11-pre.001-fix.001
```
Aucun tag prerelease n'est attendu.
Le fix est documentaire :
```text
workspace.package.version reste 0.2.11-pre.1
aucun code Rust modifié
aucune dépendance modifiée
aucun provider ajouté ou retiré
aucun contrat technique modifié
```
## 2. Objet du fix
Le forecast de `docs/plans/018-V0_2_11_OFFCHAIN_PRICE_TRANSPORT_PLAN.md` était présenté sous forme de tableau. Cette forme est correcte pour une vue statique mais peu pratique pendant une release active : elle rend moins naturelle la modification du statut d'une tranche et l'ajout de fixes rattachés à une prerelease.
Le forecast est donc remplacé par une suite de petits paragraphes structurés par titres `###`.
Chaque prerelease possède désormais :
```text
un titre ### stable
un statut directement modifiable
un court paragraphe de responsabilité
la possibilité d'ajouter des #### pour pre.xxx-fix.yyy
```
Le présent fix est lui-même ajouté sous `pre.001` comme premier exemple de sous-section `####`.
## 3. Clarification de durée
Le plan précise désormais que la cible historique de :
```text
15 à 20 minutes
```
est une **cible de granularité**, pas une durée maximale contractuelle.
Une tranche peut dépasser cette durée lorsqu'un build, un live test, un diagnostic ou une difficulté réelle le justifie. À l'inverse, des tranches peuvent être fusionnées ou recalibrées si cela améliore le découpage sans mélanger des responsabilités incompatibles.
## 4. Clarification de session
Le nombre de prereleases du forecast n'implique pas une session de conversation par prerelease.
Le plan autorise explicitement plusieurs prereleases au cours d'une même session de travail. Aucune scission de session n'est requise structurellement par le forecast ; elle ne devient nécessaire que si une contrainte réelle l'impose, par exemple un blocage opérateur, un changement de scope ou une limite de contexte de l'outil de conversation.
## 5. Forecast technique inchangé
La séquence fonctionnelle reste la même :
```text
pre.001 audit/sizing
pre.002 crate + contrats + décimal
pre.003 HTTP commun + errors + rate limiter
pre.004 CoinGecko + CMC + CoinPaprika
pre.005 Kraken + Coinbase
pre.006 Jupiter + DexScreener
pre.007 Birdeye + registry availability
pre.008 refresh single/multiple cross-provider
pre.009 Config std.offchain_transport
pre.010 hardening/API/tests + docs techniques draft
pre.011 gate technique/live final
pre.012 réconciliation documentaire finale
pre.013 publication minimale prompt 0.2.12 + CHANGELOG + ROADMAP
rel.001 stable
```
Seule sa représentation éditoriale change.
## 6. Validations opérateur de la base `pre.001`
Les validations fournies par l'opérateur avant ce fix sont toutes positives :
```text
cargo fmt --all PASS
python3 scripts/audit_rust_workspace_rules.py PASS / clean / 0 candidate export
python3 scripts/audit_markdown_tables.py ... deltas/0.2.11 PASS / 115 tables / 100 files
cargo check --workspace PASS
cargo clippy --workspace --all-targets PASS
cargo test --workspace PASS
```
Les tests explicitement `ignored` dans la sortie restent les smokes/live ou probes opt-in déjà prévus par leurs contrats ; aucun échec de test n'est signalé.
## 7. Fichiers modifiés
```text
docs/plans/018-V0_2_11_OFFCHAIN_PRICE_TRANSPORT_PLAN.md
```
## 8. Fichiers ajoutés
```text
deltas/0.2.11/pre.001-fix.001.md
```
## 9. Fichiers supprimés
```text
aucun
```
## 10. Validation attendue après application
Le fix étant documentaire, le minimum attendu est :
```bash
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas/0.2.11
```
`cargo fmt/check/clippy/test` n'ont pas besoin d'être rejoués pour ce seul changement documentaire sauf choix opérateur de refaire un gate complet.

View File

@@ -1,9 +1,9 @@
<!-- file: docs/plans/018-V0_2_11_OFFCHAIN_PRICE_TRANSPORT_PLAN.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Plan `0.2.11` — Off-chain price transport SOL/USD multi-provider
**Statut courant : `0.2.11-pre.001` ouvre la release par le gate obligatoire de lecture, réaudit externe, comparaison des sémantiques de prix, threat model, sizing et planification. Aucun client provider n'est encore implémenté. Le scope V1 est volontairement limité à SOL/USD via HTTP REST `reqwest`, sans SDK provider, avec huit providers gratuits retenus pour implémentation progressive.**
**Statut courant : `0.2.11-pre.001-fix.001` conserve intégralement le cadrage technique de `pre.001` et corrige uniquement la forme du forecast souple afin de rendre chaque tranche éditable par statut et extensible par sous-sections `####` pour ses fixes. Aucun client provider n'est encore implémenté. Le scope V1 reste limité à SOL/USD via HTTP REST `reqwest`, sans SDK provider, avec huit providers gratuits retenus pour implémentation progressive.**
## 1. Base et autorité
@@ -596,24 +596,101 @@ Le fait que Jupiter/Birdeye/DexScreener soient capables de couvrir d'autres toke
## 20. Forecast souple des prereleases
Chaque tranche technique vise environ 15 à 20 minutes de travail effectif, hors build lent ou attente provider. Le découpage pourra être réorganisé par delta si la réalité l'exige.
Chaque tranche technique vise **environ 15 à 20 minutes de travail effectif** lorsque le sujet s'y prête. Cette durée est une cible de granularité et **pas une durée maximale** : un build lent, un live test, un diagnostic ou une difficulté réelle peut légitimement prolonger une tranche.
| Prerelease | Objectif principal |
|------------|----------------------------------------------------------------------------------------------------------------|
| `pre.001` | audit externe, sémantiques, scope SOL/USD, architecture HID, threat model, numeric design, sizing et plan |
| `pre.002` | création crate, modèle SOL/USD, décimal KSP, descriptors/settings/états provider-neutral |
| `pre.003` | client HTTP REST commun, classification d'erreurs, body/timeouts/redaction, limiter/cooldown générique |
| `pre.004` | adapters CoinGecko, CoinMarketCap et CoinPaprika avec tests wire |
| `pre.005` | adapters Kraken et Coinbase Exchange avec sémantique exchange et tests |
| `pre.006` | adapters Jupiter et DexScreener, pair SOL/USD DexScreener explicite et validée |
| `pre.007` | adapter Birdeye, auth provider, registry complet et états d'indisponibilité |
| `pre.008` | service refresh single/multiple, orchestration rate-limit-aware et tests cross-provider |
| `pre.009` | document Config `std.offchain_transport`, schema/examples/env secrets et adapter Config -> Off-chain Transport |
| `pre.010` | hardening public API, tests adversariaux/completeness, README/USAGE draft technique sans réconciliation finale |
| `pre.011` | gate technique/live final, smokes gratuits possibles, graphes Cargo et caractérisation finale des providers |
| `pre.012` | réconciliation documentaire finale plan/validation/README/USAGE/architecture et références durables |
| `pre.013` | préparation publication minimale : prompt `0.2.12`, CHANGELOG, ROADMAP et version mécanique |
| `rel.001` | publication stable `v0.2.11` |
Le forecast reste volontairement souple. Une tranche peut être scindée, fusionnée ou réordonnée par delta si la réalité technique l'exige, à condition de préserver les responsabilités de clôture. Le nombre de prereleases prévu n'impose ni une session de conversation par tranche, ni une scission de session : plusieurs prereleases peuvent être réalisées dans une même session de travail.
Chaque entrée porte désormais un statut directement modifiable. Lorsqu'un fix d'une tranche est nécessaire, il peut être ajouté sous la prerelease concernée avec un titre `####`, sans transformer le forecast en tableau ni casser sa lisibilité.
### `pre.001` — Audit, sizing et cadrage multi-provider
**Statut : réalisé.**
Audit externe des providers, comparaison des sémantiques, réduction du scope V1 à SOL/USD, architecture HID de la future application, threat model, numeric design, sizing et planification.
#### `pre.001-fix.001` — Forecast souple éditable
**Statut : réalisé.**
Remplacement du forecast tabulaire par des sous-sections éditables, clarification de la cible de 15 à 20 minutes et de l'absence de relation obligatoire entre prerelease et session de conversation. Aucun changement du scope technique de `0.2.11`.
### `pre.002` — Fondation de `ksp-offchain-transport-lib`
**Statut : planifié.**
Création de la crate, modèle SOL/USD, type décimal KSP, descriptors, settings et états provider-neutral.
### `pre.003` — HTTP REST commun et rate limiting
**Statut : planifié.**
Client HTTP REST commun, classification d'erreurs, bornes de body et timeouts, redaction, limiter et cooldown génériques.
### `pre.004` — CoinGecko, CoinMarketCap et CoinPaprika
**Statut : planifié.**
Implémentation des trois adapters d'agrégateurs avec leurs DTOs wire privés et tests dédiés.
### `pre.005` — Kraken et Coinbase Exchange
**Statut : planifié.**
Implémentation des deux adapters exchange, conservation de leur sémantique de marché propre et tests dédiés.
### `pre.006` — Jupiter et DexScreener
**Statut : planifié.**
Implémentation des adapters Jupiter et DexScreener. DexScreener reste limité en V1 à la paire SOL/USD explicite configurée et validée.
### `pre.007` — Birdeye, registry et availability
**Statut : planifié.**
Implémentation de Birdeye avec son auth provider, finalisation du registry multi-provider et des états génériques d'indisponibilité.
### `pre.008` — Refresh individuel et multiple
**Statut : planifié.**
Service de refresh single/multiple, orchestration rate-limit-aware et tests cross-provider sans scheduling provider dans les consumers.
### `pre.009` — Config Off-chain Transport
**Statut : planifié.**
Document standard `std.offchain_transport`, schema, exemples, secrets d'environnement nécessaires et adapter Config -> Off-chain Transport conforme aux capacités de chaque provider.
### `pre.010` — Hardening et complétude technique
**Statut : planifié.**
Hardening de l'API publique, tests adversariaux/completeness et brouillons techniques README/USAGE sans réconciliation documentaire finale.
### `pre.011` — Gate technique et live final
**Statut : planifié.**
Smokes gratuits possibles, graphes Cargo, validations techniques finales et caractérisation actuelle des providers.
### `pre.012` — Réconciliation documentaire finale
**Statut : planifié.**
Réconciliation finale du plan, de la validation, des README/USAGE, de l'architecture et des références durables après les gates techniques.
### `pre.013` — Préparation minimale de publication
**Statut : planifié.**
Prompt `0.2.12`, `CHANGELOG.md`, `ROADMAP.md` et mécanique de version uniquement, sans reprendre les responsabilités techniques ou documentaires des deux tranches précédentes.
### `rel.001` — Publication stable `v0.2.11`
**Statut : planifié.**
Publication stable après validation de la dernière prerelease et vérification de la cohérence de release.
Les responsabilités de clôture restent strictement séparées :