v0.2.0-pre.002
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: prompts/000-README.md -->
|
||||
<!-- version: 8 -->
|
||||
<!-- version: 9 -->
|
||||
|
||||
# Prompts KSP
|
||||
|
||||
@@ -26,3 +26,5 @@ Le prompt générique `0.1.x` a été affiné pendant `0.0.3` puis remplacé par
|
||||
- [`003-V0_1_3_START_PROMPT.md`](003-V0_1_3_START_PROMPT.md) — prompt historique destiné à ouvrir `0.1.3 — Configuration foundation` après publication stable de `0.1.2` ;
|
||||
- [`004-V0_1_4_START_PROMPT.md`](004-V0_1_4_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.4 — ksp-app-config-desk` après publication stable de `0.1.3`.
|
||||
- [`005-V0_2_0_START_PROMPT.md`](005-V0_2_0_START_PROMPT.md) — prompt de reprise préparé à la clôture de `0.1.4`; il ouvre `0.2.0-pre.001`, release intermédiaire d'audit de `khadhroony-bot3`, de comparaison avec KSP et de planification/découpage du reste de `0.2.x`.
|
||||
|
||||
- [`006-V0_2_1_START_PROMPT.md`](006-V0_2_1_START_PROMPT.md) — prompt préparatoire destiné à ouvrir `0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation` après publication stable de `0.2.0`; il impose l'audit exhaustif de la documentation HTTP Solana, la séparation Config/Transport, les pools/rôles et le gate de sizing « une release = une session ».
|
||||
|
||||
655
prompts/006-V0_2_1_START_PROMPT.md
Normal file
655
prompts/006-V0_2_1_START_PROMPT.md
Normal file
@@ -0,0 +1,655 @@
|
||||
<!-- file: prompts/006-V0_2_1_START_PROMPT.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Prompt de démarrage `0.2.1` — `ksp-onchain-transport-lib` HTTP Solana foundation
|
||||
|
||||
## 1. Contexte de reprise
|
||||
|
||||
La base attendue est la release stable `v0.2.0` de `khadhroony-solana-project`.
|
||||
|
||||
`0.2.0` a audité `khadhroony-bot3`, refondu la roadmap et décidé que la première capacité fonctionnelle de `0.2.x` doit être le transport HTTP Solana, car les capacités suivantes — en particulier `ksp-wallet-lib` puis `ksp-app-wallet-desk` — doivent pouvoir interroger réellement le réseau, par exemple pour lire le solde d'un wallet.
|
||||
|
||||
Les fondations stables à préserver sont :
|
||||
|
||||
```text
|
||||
ksp-core-lib
|
||||
ksp-logging-lib
|
||||
ksp-config-lib
|
||||
ksp-app-config-desk
|
||||
```
|
||||
|
||||
La release à ouvrir est :
|
||||
|
||||
```text
|
||||
0.2.1 — ksp-onchain-transport-lib / Solana HTTP foundation
|
||||
```
|
||||
|
||||
La première tranche est :
|
||||
|
||||
```text
|
||||
0.2.1-pre.001
|
||||
```
|
||||
|
||||
`pre.001` est une tranche d'**audit, conception, inventaire exhaustif et dimensionnement**. Elle ne doit pas devenir automatiquement une grosse implémentation.
|
||||
|
||||
## 2. Mission de `0.2.1`
|
||||
|
||||
Créer la première version stable de `ksp-onchain-transport-lib` pour le transport **HTTP JSON-RPC Solana**, avec une API publique KSP indépendante de Config, du Store et des futures couches Program.
|
||||
|
||||
La release doit fournir :
|
||||
|
||||
- transport HTTP async ;
|
||||
- JSON-RPC 2.0 ;
|
||||
- settings runtime publics possédés par le transport ;
|
||||
- endpoints nommés ;
|
||||
- metadata provider/cluster ;
|
||||
- pools logiques d'endpoints ;
|
||||
- rôles/capabilities/request kinds ;
|
||||
- priorités ;
|
||||
- limites de débit/burst/concurrence lorsque configurées ;
|
||||
- timeout ;
|
||||
- retry/backoff transport borné ;
|
||||
- observabilité via `ksp-logging-lib` ;
|
||||
- toutes les méthodes HTTP exposées par la documentation normative Solana ciblée par la release ;
|
||||
- méthodes read et méthodes write/execution technique ;
|
||||
- classification centralisée des méthodes selon leur statut documentaire ;
|
||||
- warnings runtime pour méthodes deprecated/obsolete encore fonctionnelles et unstable/experimental ;
|
||||
- premier document Config standard Transport dans `ksp-config-lib` et adapter Config -> settings publics Transport ;
|
||||
- tests, fixtures, documentation `README.md`/`USAGE.md` et preuve de complétude de la surface.
|
||||
|
||||
`0.2.1` doit être un transport générique KSP utilisable directement par une bibliothèque, une application, un job ou un worker. Il ne doit pas être conçu uniquement pour Wallet Desk.
|
||||
|
||||
## 3. Sources de vérité internes obligatoires
|
||||
|
||||
Avant toute modification, relire au minimum :
|
||||
|
||||
```text
|
||||
ROADMAP.md
|
||||
docs/000-README.md
|
||||
docs/IDEAS.md
|
||||
|
||||
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
|
||||
docs/plans/007-V0_2_0_SERIES_PLANNING.md
|
||||
|
||||
docs/architecture/002-LAYERS_AND_DEPENDENCIES.md
|
||||
docs/architecture/003-COMPONENT_CONTRACTS.md
|
||||
docs/architecture/004-COMPONENT_INVENTORY.md
|
||||
docs/architecture/005-DEPENDENCY_GRAPH.md
|
||||
docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md
|
||||
docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md
|
||||
|
||||
docs/rules/RULES_KSP.md
|
||||
docs/rules/RULES_DEPENDENCIES.md
|
||||
docs/rules/RULES_RUST.md
|
||||
docs/rules/PROMPT_STRUCTURE.md
|
||||
docs/rules/VERSION_WORKFLOW.md
|
||||
docs/rules/FILE_CONTRACTS.md
|
||||
```
|
||||
|
||||
Relire également les contrats publics actuels de :
|
||||
|
||||
```text
|
||||
crates/ksp-core-lib
|
||||
crates/ksp-logging-lib
|
||||
crates/ksp-config-lib
|
||||
```
|
||||
|
||||
Ne pas supposer leurs APIs à partir de bot3.
|
||||
|
||||
## 4. Référence historique bot3
|
||||
|
||||
Auditer la dernière archive bot3 fournie disponible, en particulier :
|
||||
|
||||
```text
|
||||
ks-onchain-transport/
|
||||
ks-config/src/transport.rs
|
||||
ks-config/src/settings.rs
|
||||
kb-app-demo-desktop/src/demo_http.rs
|
||||
kb-app-demo-desktop/src/demo_transport.rs
|
||||
```
|
||||
|
||||
Sur `ks-onchain-transport`, examiner au minimum :
|
||||
|
||||
```text
|
||||
client.rs
|
||||
endpoint_role.rs
|
||||
execution_rpc.rs
|
||||
get_signatures_for_address.rs
|
||||
get_transaction.rs
|
||||
http_client.rs
|
||||
http_pool.rs
|
||||
json_rpc.rs
|
||||
standard_http.rs
|
||||
standard_http_accounts.rs
|
||||
standard_http_blocks.rs
|
||||
standard_http_cluster.rs
|
||||
standard_http_economics.rs
|
||||
standard_http_tokens.rs
|
||||
standard_http_transactions.rs
|
||||
standard_methods.rs
|
||||
validation.rs
|
||||
README.md
|
||||
USAGE.md
|
||||
TODO.md
|
||||
```
|
||||
|
||||
Bot3 est une **source fonctionnelle et historique**, pas une source normative d'architecture.
|
||||
|
||||
Reprendre les besoins/invariants utiles ; ne pas reproduire :
|
||||
|
||||
- dépendance publique Transport -> Config ;
|
||||
- dépendance vers `ks-lib`/modèles canoniques ;
|
||||
- appels directs `tracing` ;
|
||||
- DTOs couplés au futur Store ;
|
||||
- anciens stacks de dépendances uniquement parce qu'ils existent ;
|
||||
- duplication inutile de modèles ou de codecs.
|
||||
|
||||
## 5. Sources externes normatives
|
||||
|
||||
Au début de `pre.001`, consulter la documentation **officielle et actuelle** de Solana pour JSON-RPC HTTP et identifier précisément la surface normative de la release.
|
||||
|
||||
Ne pas utiliser une liste mémorisée ou la liste bot3 comme vérité.
|
||||
|
||||
Pour chaque méthode HTTP documentée, relever au minimum :
|
||||
|
||||
```text
|
||||
nom RPC
|
||||
catégorie
|
||||
paramètres
|
||||
config/commitment/encoding éventuels
|
||||
forme du résultat
|
||||
erreurs/nullable/optional importants
|
||||
statut documentaire
|
||||
stable | deprecated/obsolete | unstable/experimental
|
||||
notes/version minimum éventuelles
|
||||
lien/source normative
|
||||
tests nécessaires
|
||||
```
|
||||
|
||||
Vérifier également les spécifications/projets officiels nécessaires pour JSON-RPC et les crates externes retenues.
|
||||
|
||||
Lorsque la documentation officielle Solana et une implementation/provider divergent, documenter l'écart au lieu de modifier silencieusement le contrat standard.
|
||||
|
||||
## 6. Règle de couverture exhaustive
|
||||
|
||||
`0.2.1` ne se limite pas aux méthodes actuellement utilisées par Wallet ou bot3.
|
||||
|
||||
Pour la surface Solana HTTP officiellement ciblée :
|
||||
|
||||
> **toute méthode exposée par la documentation normative doit être implémentée, sauf impossibilité technique explicitement documentée et validée.**
|
||||
|
||||
Le `pre.001` doit créer une matrice de conformité durable, par exemple dans le plan `0.2.1` ou un document de validation dédié, permettant de vérifier qu'aucune méthode n'a été oubliée.
|
||||
|
||||
Une méthode ne peut pas être déclarée couverte uniquement parce qu'un appel JSON générique existe : la release doit décider quelle surface publique typée/générique KSP est réellement promise et tester ce contrat.
|
||||
|
||||
## 7. Méthodes deprecated, obsolete et unstable
|
||||
|
||||
Chaque méthode possède une metadata de statut centralisée, conceptuellement :
|
||||
|
||||
```text
|
||||
Stable
|
||||
Deprecated
|
||||
Unstable
|
||||
```
|
||||
|
||||
Les noms Rust exacts sont décidés en `pre.001`.
|
||||
|
||||
### Deprecated / obsolete mais encore fonctionnelle
|
||||
|
||||
- implémenter/conserver la méthode ;
|
||||
- ne pas la masquer ;
|
||||
- émettre un `warn` via `ksp-logging-lib` lorsqu'elle est utilisée ;
|
||||
- inclure méthode, statut et contexte sûr dans le log ;
|
||||
- ne jamais logguer de secrets/tokens/provider credentials.
|
||||
|
||||
### Unstable / experimental
|
||||
|
||||
- implémenter la méthode lorsqu'elle appartient à la documentation ciblée ;
|
||||
- émettre un `warn` via `ksp-logging-lib` à l'utilisation ;
|
||||
- documenter que son contrat externe peut évoluer.
|
||||
|
||||
### Méthode réellement supprimée/non fonctionnelle
|
||||
|
||||
Ne pas simuler un succès. Documenter l'historique et l'absence de support runtime si la méthode n'existe plus dans la surface normative actuelle.
|
||||
|
||||
Les warnings ne doivent pas être dispersés à la main dans chaque méthode si une metadata/descripteur commun permet de garantir le comportement de manière centralisée.
|
||||
|
||||
## 8. Frontière Config / Transport
|
||||
|
||||
### Règle absolue
|
||||
|
||||
```text
|
||||
ksp-onchain-transport-lib -X-> ksp-config-lib
|
||||
```
|
||||
|
||||
Le transport doit pouvoir être construit et testé sans Config.
|
||||
|
||||
Il possède ses settings publics, conceptuellement :
|
||||
|
||||
```text
|
||||
HttpTransportSettings
|
||||
HttpEndpointSettings
|
||||
EndpointRoleSettings
|
||||
RetrySettings
|
||||
PoolSettings
|
||||
...
|
||||
```
|
||||
|
||||
Les noms/types exacts ne sont pas imposés par ce prompt.
|
||||
|
||||
### Document standard Config
|
||||
|
||||
`0.2.1` doit également introduire dans `ksp-config-lib` le premier document standard Transport HTTP et son schema, selon le moteur Config déjà stabilisé.
|
||||
|
||||
Direction :
|
||||
|
||||
```text
|
||||
config/std.transport.json
|
||||
config/schemas/std.transport.schema.json
|
||||
config/examples/std.transport.example.json # si la convention Config l'exige/retient
|
||||
```
|
||||
|
||||
Les `file_id` exacts suivent les conventions `ksp-config-lib` et sont décidés après audit des documents existants.
|
||||
|
||||
Le document Config :
|
||||
|
||||
- peut contenir plusieurs profils ;
|
||||
- sélectionne/configure endpoints, rôles et paramètres HTTP ;
|
||||
- utilise les placeholders d'environnement KSP pour URLs/tokens seulement selon le mécanisme Config existant ;
|
||||
- ne lit jamais directement l'environnement dans Transport ;
|
||||
- doit être extensible plus tard à WS/gRPC sans préremplir aujourd'hui des champs sans implementation ;
|
||||
- reste manageable par Config Desk grâce au moteur générique existant, sans développer une UI Transport dédiée dans `0.2.1`.
|
||||
|
||||
Adapter :
|
||||
|
||||
```text
|
||||
ksp-config-lib -> ksp-onchain-transport-lib public settings
|
||||
```
|
||||
|
||||
La dépendance inverse reste interdite.
|
||||
|
||||
Toute nouvelle variable d'environnement réellement utilisée est ajoutée à `.env.example` dans la même tranche, avec commentaire et namespace correct.
|
||||
|
||||
## 9. Pools, rôles et capabilities
|
||||
|
||||
Reprendre/refondre l'idée utile de bot3 sans figer ses structures exactes.
|
||||
|
||||
Un endpoint HTTP doit pouvoir déclarer :
|
||||
|
||||
- identité/name ;
|
||||
- enabled ;
|
||||
- provider ;
|
||||
- cluster/network ;
|
||||
- URL ;
|
||||
- timeout/settings connexion ;
|
||||
- rôles/capabilities ;
|
||||
- priorités ;
|
||||
- limites applicables.
|
||||
|
||||
Un rôle peut porter selon le design retenu :
|
||||
|
||||
- request kinds/méthodes supportées ;
|
||||
- priorité ;
|
||||
- requests per second ;
|
||||
- burst ;
|
||||
- max concurrent requests ;
|
||||
- pause après rate-limit ;
|
||||
- autres limites réellement justifiées.
|
||||
|
||||
Ne pas créer une enum centrale fermée si des rôles configurables/string descriptors permettent une extension plus propre.
|
||||
|
||||
Le pool HTTP sélectionne un **endpoint/client logique**, pas une socket brute.
|
||||
|
||||
Le client HTTP sous-jacent reste propriétaire de son propre pooling de connexions réseau.
|
||||
|
||||
Le `pre.001` doit décider explicitement :
|
||||
|
||||
- stratégie de sélection ;
|
||||
- comportement si aucun endpoint ne satisfait le rôle/méthode ;
|
||||
- comportement sur endpoint disabled ;
|
||||
- round-robin/priority/fallback éventuel ;
|
||||
- gestion d'un endpoint rate-limited ;
|
||||
- health/snapshot nécessaires ;
|
||||
- thread-safety/concurrence.
|
||||
|
||||
## 10. Retry, timeout et erreurs
|
||||
|
||||
Distinguer strictement :
|
||||
|
||||
### Retry transport
|
||||
|
||||
Peut concerner une requête HTTP qui n'a pas obtenu de résultat exploitable en raison d'un problème transport/provider clairement retryable.
|
||||
|
||||
### Retry d'exécution métier
|
||||
|
||||
N'appartient pas à `0.2.1` et ne doit pas être inventé dans Transport.
|
||||
|
||||
Le transport ne doit jamais décider de renvoyer une transaction Solana sur la seule base d'une erreur métier ou d'un timeout ambigu.
|
||||
|
||||
Définir une classification d'erreurs KSP suffisamment précise pour distinguer au minimum :
|
||||
|
||||
- invalid settings ;
|
||||
- endpoint selection ;
|
||||
- connection/HTTP ;
|
||||
- timeout ;
|
||||
- rate-limit ;
|
||||
- JSON encode/decode ;
|
||||
- JSON-RPC protocol ;
|
||||
- RPC application error ;
|
||||
- unsupported/deprecated status si nécessaire ;
|
||||
- invalid response/invariant.
|
||||
|
||||
Utiliser le type d'erreur KSP existant ; ne pas créer une deuxième hiérarchie publique incompatible.
|
||||
|
||||
## 11. Modèles et ownership des types
|
||||
|
||||
`0.2.1` ne doit pas dépendre du futur Store, de `ksp-program-api` ou de modèles DECODE/SPECIALIZED.
|
||||
|
||||
Les réponses du transport appartiennent au domaine Transport ou utilisent les primitives KSP/bas niveau explicitement admises.
|
||||
|
||||
Ne pas reproduire le couplage bot3 :
|
||||
|
||||
```text
|
||||
getTransaction -> ks_lib::MdCanonicalTransaction
|
||||
```
|
||||
|
||||
Le transport doit préserver les informations nécessaires à la future persistence RAW et à la normalisation CORE sans effectuer lui-même ces transformations.
|
||||
|
||||
Le `pre.001` doit inventorier les méthodes dont les réponses nécessitent une décision de représentation importante, notamment transactions/messages/accounts/blocks/token amounts/statuses, et fixer l'ownership avant code massif.
|
||||
|
||||
Éviter `solana-client` ou un SDK haut niveau uniquement pour obtenir des DTOs si cela réintroduit un graphe massif et empêche KSP de posséder son contrat transport. Toute dépendance Solana supplémentaire doit être justifiée par un besoin précis et compatible avec le firewall KSP.
|
||||
|
||||
## 12. Dépendances externes
|
||||
|
||||
Toutes les dépendances tierces communes sont déclarées au `Cargo.toml` racine sous `[workspace.dependencies]`, puis consommées avec `.workspace = true`.
|
||||
|
||||
Avant ajout, `pre.001` doit vérifier les versions actuelles et le graphe de dépendances des candidates.
|
||||
|
||||
Bot3 utilisait notamment :
|
||||
|
||||
```text
|
||||
reqwest
|
||||
serde
|
||||
serde_json
|
||||
tokio
|
||||
base64
|
||||
bs58
|
||||
```
|
||||
|
||||
Cette liste est une référence d'audit, **pas une décision automatique**.
|
||||
|
||||
Ne pas ajouter dans `0.2.1` les dépendances WebSocket/gRPC réservées aux releases suivantes, sauf nécessité technique démontrée pour le build HTTP.
|
||||
|
||||
Exécuter les `cargo tree` pertinents après ajout :
|
||||
|
||||
```bash
|
||||
cargo tree -p ksp-onchain-transport-lib
|
||||
cargo tree -p ksp-onchain-transport-lib -d
|
||||
cargo tree -p ksp-onchain-transport-lib -e features
|
||||
cargo tree -p ksp-onchain-transport-lib -e normal
|
||||
```
|
||||
|
||||
et auditer les doublons réellement significatifs.
|
||||
|
||||
## 13. Logging et observabilité
|
||||
|
||||
`ksp-onchain-transport-lib` utilise `ksp-logging-lib` et ne dépend pas directement de `tracing` pour ses événements KSP.
|
||||
|
||||
Target attendu : nom Cargo de la crate.
|
||||
|
||||
Événements utiles à couvrir :
|
||||
|
||||
- création client/pool ;
|
||||
- sélection endpoint/role ;
|
||||
- start/end d'une requête aux niveaux debug/trace appropriés ;
|
||||
- retry ;
|
||||
- timeout ;
|
||||
- rate-limit/backoff ;
|
||||
- endpoint unavailable/degraded ;
|
||||
- RPC error ;
|
||||
- méthode deprecated/unstable utilisée ;
|
||||
- snapshots/health importants.
|
||||
|
||||
Ne jamais logguer :
|
||||
|
||||
- API key ;
|
||||
- token provider ;
|
||||
- URL contenant un secret non redacted ;
|
||||
- transaction/signature payload sensible sans raison explicite ;
|
||||
- contenu massif de réponses par défaut.
|
||||
|
||||
Les informations provenant de `reqwest` ou d'autres dépendances sont réémises sous le target KSP lorsque réellement utiles ; ne pas ouvrir globalement leurs targets.
|
||||
|
||||
## 14. Tests obligatoires
|
||||
|
||||
### Tests unitaires
|
||||
|
||||
Prévoir au minimum :
|
||||
|
||||
- validation settings ;
|
||||
- endpoint/role matching ;
|
||||
- pool selection ;
|
||||
- priority/fallback ;
|
||||
- limiter/concurrence ;
|
||||
- retry/backoff borné ;
|
||||
- JSON-RPC request/response ;
|
||||
- RPC error mapping ;
|
||||
- nullable/optional responses ;
|
||||
- method status metadata ;
|
||||
- warning path deprecated/unstable ;
|
||||
- aucune fuite de secret dans Debug/loggable snapshots.
|
||||
|
||||
### Tests par méthodes
|
||||
|
||||
Chaque méthode documentée doit être couverte par au moins une preuve adaptée :
|
||||
|
||||
- request serialization ;
|
||||
- response deserialization ;
|
||||
- paramètres/configs ;
|
||||
- cas optional/null/error importants.
|
||||
|
||||
Utiliser des fixtures déterministes lorsque le réseau n'apporte aucune valeur au test.
|
||||
|
||||
### Tests réseau opt-in
|
||||
|
||||
Prévoir un petit nombre de smoke tests Devnet/Mainnet non destructifs si nécessaire pour démontrer l'interop réelle, sans rendre la suite par défaut dépendante d'Internet ou d'une clé provider.
|
||||
|
||||
Les tests réseau nécessitant un provider/secret doivent être opt-in et utiliser Config/env via les mécanismes KSP, jamais des secrets versionnés.
|
||||
|
||||
### Canaries architecturales
|
||||
|
||||
Ajouter des tests/audits empêchant au minimum :
|
||||
|
||||
```text
|
||||
ksp-onchain-transport-lib -> ksp-config-lib
|
||||
ksp-onchain-transport-lib -> ksp-store-*
|
||||
ksp-onchain-transport-lib -> ksp-program-*
|
||||
direct tracing ownership
|
||||
```
|
||||
|
||||
et vérifiant la complétude de la matrice de méthodes si elle peut être automatisée.
|
||||
|
||||
## 15. Hors périmètre strict de `0.2.1`
|
||||
|
||||
Ne pas ouvrir :
|
||||
|
||||
- WebSocket Solana — `0.2.4` ;
|
||||
- Helius LaserStream WebSocket — `0.2.5` ;
|
||||
- Yellowstone gRPC — `0.2.6` ;
|
||||
- providers gRPC avancés ;
|
||||
- Wallet — `0.2.2` ;
|
||||
- Wallet Desk — `0.2.3` ;
|
||||
- Store/persistence RAW — `0.3.1` ;
|
||||
- decoders Program ;
|
||||
- `ksp-interface-lib` fonctionnel complet ;
|
||||
- materializers ;
|
||||
- execution policy ;
|
||||
- orchestration d'exécution métier ;
|
||||
- worker/job d'acquisition ;
|
||||
- Tauri app Transport dédiée ;
|
||||
- trading/DEX/ML.
|
||||
|
||||
Une méthode HTTP permettant techniquement `sendTransaction`, `simulateTransaction`, `requestAirdrop` ou autre opération write peut appartenir au **transport standard** et doit être implémentée si documentée ; cela ne signifie pas que `0.2.1` construit l'orchestration d'exécution KSP.
|
||||
|
||||
## 16. Première mission : `0.2.1-pre.001`
|
||||
|
||||
`pre.001` doit livrer un plan détaillé de `0.2.1`, candidat :
|
||||
|
||||
```text
|
||||
docs/plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md
|
||||
```
|
||||
|
||||
Il doit contenir au minimum :
|
||||
|
||||
1. audit exact de la base stable `v0.2.0` ;
|
||||
2. audit détaillé de `ks-onchain-transport` bot3 ;
|
||||
3. inventaire **exhaustif** des méthodes HTTP Solana documentées actuellement ;
|
||||
4. statut `stable/deprecated/unstable` de chaque méthode ;
|
||||
5. matrice méthode -> module/API KSP -> request -> response -> tests -> prerelease candidate ;
|
||||
6. inventaire des contrats bot3 utiles à reprendre/adapter/refondre/abandonner ;
|
||||
7. décision exacte sur les settings publics Transport ;
|
||||
8. décision exacte pools/rôles/capabilities/priority/rate-limit/concurrence ;
|
||||
9. stratégie retry/backoff/timeout ;
|
||||
10. stratégie d'erreurs ;
|
||||
11. ownership des modèles de réponse difficiles ;
|
||||
12. dépendances externes retenues après vérification de versions/features ;
|
||||
13. design du document `std.transport` et de l'adapter Config -> Transport ;
|
||||
14. nouvelles variables `.env.example` réellement nécessaires, sans secret concret ;
|
||||
15. architecture de tests/fixtures/smoke tests ;
|
||||
16. canaries de dépendances/ownership ;
|
||||
17. hors-périmètre confirmés ;
|
||||
18. critères de clôture ;
|
||||
19. prévision souple des prereleases ;
|
||||
20. **gate de sizing de la release entière**.
|
||||
|
||||
### Gate de sizing obligatoire
|
||||
|
||||
À la fin de `pre.001`, répondre explicitement :
|
||||
|
||||
```text
|
||||
La release 0.2.1 peut-elle raisonnablement être entièrement clôturée dans cette session de chat
|
||||
avec des prereleases de ~15–20 minutes ?
|
||||
```
|
||||
|
||||
Si la réponse est non ou incertaine, **ne pas commencer la grosse implémentation**. Scinder immédiatement le périmètre en plusieurs releases `0.2.x`, mettre à jour ROADMAP/plan/prompt, puis seulement commencer la première release réduite.
|
||||
|
||||
La contrainte de couverture documentaire exhaustive ne doit jamais être contournée en masquant des méthodes pour faire tenir artificiellement la release.
|
||||
|
||||
## 17. Prévision souple initiale des prereleases
|
||||
|
||||
Cette prévision est un point de départ et doit être recalibrée par `pre.001` à partir de la matrice réelle des méthodes.
|
||||
|
||||
### `pre.001` — audit, matrice exhaustive, architecture et sizing
|
||||
|
||||
Aucune grosse implementation.
|
||||
|
||||
### `pre.002` — crate foundation + settings + JSON-RPC + method descriptors
|
||||
|
||||
Candidat :
|
||||
|
||||
- package/workspace ;
|
||||
- contrats settings ;
|
||||
- validation ;
|
||||
- JSON-RPC envelope/error ;
|
||||
- metadata de méthode/status ;
|
||||
- base Logging.
|
||||
|
||||
### Tranches méthodes HTTP
|
||||
|
||||
Répartir les méthodes par familles cohérentes **après inventaire officiel**, par exemple accounts/cluster, blocks/transactions, tokens/economics, write/execution technique ou toute meilleure découpe révélée par la documentation.
|
||||
|
||||
Aucune de ces tranches ne doit dépasser le budget 15–20 minutes ; ajouter des prereleases si nécessaire **uniquement si la release entière reste clôturable dans la session**.
|
||||
|
||||
### Tranche pools/rôles/resilience
|
||||
|
||||
- pools ;
|
||||
- role matching ;
|
||||
- priority/fallback ;
|
||||
- rate-limit ;
|
||||
- concurrency ;
|
||||
- retry/backoff ;
|
||||
- health/snapshots.
|
||||
|
||||
### Tranche Config standard
|
||||
|
||||
- schema/document/example ;
|
||||
- registration/file IDs ;
|
||||
- adapter Config -> Transport ;
|
||||
- env inventory ;
|
||||
- intégration tests.
|
||||
|
||||
### Dernière prerelease
|
||||
|
||||
- matrice de complétude 100 % de la surface ciblée ;
|
||||
- tests ciblés et workspace ;
|
||||
- cargo tree audits ;
|
||||
- README/USAGE ;
|
||||
- documentation durable ;
|
||||
- cleanup/TODO ;
|
||||
- prompt `0.2.2` Wallet ;
|
||||
- préparation `rel.001`.
|
||||
|
||||
## 18. Validation de chaque tranche Rust
|
||||
|
||||
Après toute modification Rust :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --workspace --all-targets
|
||||
```
|
||||
|
||||
Pendant le développement :
|
||||
|
||||
```bash
|
||||
cargo test -p ksp-onchain-transport-lib
|
||||
cargo test -p ksp-config-lib # lorsque Config est modifié
|
||||
```
|
||||
|
||||
`cargo test --workspace` est exécuté aux frontières globales prévues par les règles, notamment ouverture/fermeture de version et validation finale.
|
||||
|
||||
Exécuter les `cargo tree` pertinents pour les crates modifiées.
|
||||
|
||||
Ne jamais déclarer une commande réussie si elle n'a pas été exécutée.
|
||||
|
||||
## 19. Critères de clôture `0.2.1`
|
||||
|
||||
La release ne peut pas être déclarée stable tant que :
|
||||
|
||||
- `ksp-onchain-transport-lib` existe comme crate KSP propre ;
|
||||
- aucune dépendance Transport -> Config/Store/Program n'existe ;
|
||||
- les settings publics sont documentés ;
|
||||
- le document Config Transport + adapter fonctionnent sans inverser l'ownership ;
|
||||
- toutes les méthodes de la surface HTTP Solana normative ciblée sont présentes dans la matrice ;
|
||||
- toutes les méthodes supportables ciblées sont implémentées ;
|
||||
- deprecated/obsolete encore fonctionnel et unstable/experimental émettent le warning KSP prévu ;
|
||||
- pools/rôles/priority/limites/timeouts/retry retenus sont testés ;
|
||||
- les réponses restent transport/raw-compatible et ne produisent pas des modèles Program/Store ;
|
||||
- aucun secret/provider token n'est loggué ;
|
||||
- les tests ciblés passent ;
|
||||
- les validations workspace finales passent ;
|
||||
- le graphe de dépendances est audité ;
|
||||
- `README.md` et `USAGE.md` sont complets ;
|
||||
- TODO/hors scope sont fermés ou reportés explicitement ;
|
||||
- le prompt final `0.2.2` est prêt ;
|
||||
- la release entière a été clôturée dans la session qui l'a ouverte.
|
||||
|
||||
## 20. Release suivante
|
||||
|
||||
La release suivante prévue est :
|
||||
|
||||
```text
|
||||
0.2.2 — ksp-wallet-lib / .kspwallet foundation
|
||||
```
|
||||
|
||||
Elle devra utiliser les fondations N1 mais **ne pas dépendre du transport** pour son cœur cryptographique/format.
|
||||
|
||||
Le transport `0.2.1` sera ensuite composé avec Wallet dans `0.2.3 — ksp-app-wallet-desk` pour afficher notamment le solde réseau du wallet.
|
||||
|
||||
## Instruction d'ouverture
|
||||
|
||||
Commencer `0.2.1-pre.001` par la relecture des sources internes, l'audit exact du transport bot3 et la consultation de la documentation officielle Solana HTTP actuelle.
|
||||
|
||||
Construire ensuite la matrice exhaustive des méthodes et le plan `008` **avant toute grosse migration/implémentation**.
|
||||
|
||||
Ne pas copier `ks-onchain-transport` tel quel, ne pas introduire WebSocket/Yellowstone par anticipation, ne pas coupler Transport à Config, et ne pas commencer une release dont le sizing ne garantit pas raisonnablement la clôture dans cette même session.
|
||||
Reference in New Issue
Block a user