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

v0.2.0-pre.003

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-17 16:05:58 +02:00
parent 259bff6707
commit e721464a7c
23 changed files with 609 additions and 96 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
prompts/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: prompts/000-README.md -->
<!-- version: 9 -->
<!-- version: 10 -->
# Prompts KSP
@@ -27,4 +27,4 @@ Le prompt générique `0.1.x` a été affiné pendant `0.0.3` puis remplacé par
- [`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 ».
- [`006-V0_2_1_START_PROMPT.md`](006-V0_2_1_START_PROMPT.md) — prompt finalisé par `0.2.0-pre.003`, 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 des surfaces HTTP courantes et deprecated/unstable officiellement documentées, la séparation Config/Transport, les pools/rôles et le gate de sizing « une release = une session ».

50
prompts/006-V0_2_1_START_PROMPT.md
View File

@@ -1,8 +1,10 @@
<!-- file: prompts/006-V0_2_1_START_PROMPT.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Prompt de démarrage `0.2.1` — `ksp-onchain-transport-lib` HTTP Solana foundation
> **Statut : finalisé par `0.2.0-pre.003`.** Utiliser ce prompt uniquement après publication stable/tag `v0.2.0`; toute information externe temporelle doit être revérifiée à l'ouverture de `0.2.1-pre.001`.
## 1. Contexte de reprise
La base attendue est la release stable `v0.2.0` de `khadhroony-solana-project`.
@@ -148,6 +150,15 @@ Reprendre les besoins/invariants utiles ; ne pas reproduire :
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.
L'inventaire doit couvrir explicitement :
- l'index HTTP courant ;
- la section officielle `Deprecated Methods` même lorsqu'elle est séparée de l'index courant ;
- toute surface HTTP `unstable` / `experimental` officiellement documentée ;
- la disponibilité runtime réelle d'une méthode deprecated/obsolete avant de décider qu'elle reste supportable.
Le spot-check documentaire de clôture de `0.2.0` a observé 52 méthodes dans l'index HTTP courant du 2026-08-17 et 14 noms dans la section officielle Deprecated Methods. **Ces nombres ne sont pas un contrat** : `0.2.1-pre.001` doit refaire l'inventaire depuis les sources officielles du jour.
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 :
@@ -503,24 +514,25 @@ 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**.
3. inventaire **exhaustif** des méthodes HTTP Solana documentées actuellement, y compris les index current/deprecated/unstable séparés ;
4. comparaison nom par nom avec l'inventaire bot3 afin d'identifier ajouts, suppressions, méthodes historiques non reprises et niveau de contrat réel (`typed` vs raw/generic) ;
5. statut `stable/deprecated/unstable` de chaque méthode ;
6. matrice méthode -> module/API KSP -> request -> response -> tests -> prerelease candidate ;
7. inventaire des contrats bot3 utiles à reprendre/adapter/refondre/abandonner ;
8. décision exacte sur les settings publics Transport ;
9. décision exacte pools/rôles/capabilities/priority/rate-limit/concurrence ;
10. stratégie retry/backoff/timeout ;
11. stratégie d'erreurs ;
12. ownership des modèles de réponse difficiles ;
13. dépendances externes retenues après vérification de versions/features ;
14. design du document `std.transport` et de l'adapter Config -> Transport ;
15. nouvelles variables `.env.example` réellement nécessaires, sans secret concret ;
16. architecture de tests/fixtures/smoke tests ;
17. canaries de dépendances/ownership ;
18. hors-périmètre confirmés ;
19. critères de clôture ;
20. prévision souple des prereleases ;
21. **gate de sizing de la release entière**.
### Gate de sizing obligatoire