v0.2.2-pre.007

This commit is contained in:
2026-08-18 09:48:11 +02:00
parent ecfb9500eb
commit b57f796187
16 changed files with 1020 additions and 78 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: prompts/000-README.md -->
<!-- version: 11 -->
<!-- version: 12 -->
# Prompts KSP
@@ -28,3 +28,4 @@ Le prompt générique `0.1.x` a été affiné pendant `0.0.3` puis remplacé par
- [`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 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 » ;
- [`007-V0_2_2_START_PROMPT.md`](007-V0_2_2_START_PROMPT.md) — prompt préparé par la dernière prerelease de `0.2.1`, destiné à ouvrir `0.2.2 — HTTP Accounts + Tokens + Cluster` après publication stable de `0.2.1`; il cible les 22 wrappers typés restants de ces familles et impose un nouvel audit officiel/gate de sizing à `pre.001`.
- [`008-V0_2_3_START_PROMPT.md`](008-V0_2_3_START_PROMPT.md) — prompt préparé par la dernière prerelease de `0.2.2`, destiné à ouvrir `0.2.3 — HTTP Transactions` après publication stable de `0.2.2`; il cible les 11 méthodes Transactions et impose un audit actuel ainsi que la politique no-resend des write submissions.

View File

@@ -0,0 +1,268 @@
<!-- file: prompts/008-V0_2_3_START_PROMPT.md -->
<!-- version: 1 -->
# Prompt de démarrage `0.2.3` — HTTP Transactions
## 1. Contexte de reprise
La base attendue est la release stable :
```text
v0.2.2
```
`0.2.1` a stabilisé la foundation HTTP Solana et quatre canaris typed. `0.2.2` complète Accounts/Tokens/Cluster avec 22 wrappers supplémentaires, un smoke Devnet Transport pur, des DTOs wire communs et les canaries de clôture.
La surface acquise au démarrage de `0.2.3` doit donc être :
```text
52 méthodes HTTP courantes enregistrées
14 méthodes historiques Deprecated / runtime Removed
26 wrappers typed : 4 foundation + 22 Accounts/Tokens/Cluster
partition restante : 11 Transactions + 15 Blocks/Economics
Transport -X-> Config/Store/Program/tracing direct
Config -> Transport autorisé
```
La release à ouvrir est :
```text
0.2.3 — HTTP Transactions
```
La première tranche est `0.2.3-pre.001` et commence par **audit officiel actuel + brainstorming + sizing** avant toute implémentation lourde.
## 2. Mission
Compléter les 11 méthodes Transactions affectées à `HttpRpcCoverageRelease::V0_2_3` :
```text
getFeeForMessage
getLatestBlockhash
getRecentPrioritizationFees
getSignaturesForAddress
getSignatureStatuses
getTransaction
getTransactionCount
isBlockhashValid
requestAirdrop
sendTransaction
simulateTransaction
```
Cette liste est la partition KSP actuelle. `pre.001` doit la revérifier contre la documentation Solana du jour avant de confirmer le périmètre.
## 3. Classification de sécurité à préserver
La metadata KSP actuelle distingue :
```text
8 Read / RetrySafe
2 WriteSubmission / NeverAfterDispatch : requestAirdrop, sendTransaction
1 Simulation / RetrySafe : simulateTransaction
```
`pre.001` doit vérifier que cette classification reste correcte. La règle la plus importante est :
> aucune resoumission automatique d'une WriteSubmission après un dispatch ambigu.
Un timeout après dispatch, une rupture de connexion après envoi ou toute autre issue où KSP ne peut pas prouver l'absence de dispatch doit arrêter le retry automatique.
## 4. Sources internes obligatoires
Relire avant modification :
```text
ROADMAP.md
CHANGELOG.md
RULES.md
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
docs/plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md
docs/plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md
docs/validation/003-V0_2_1_ONCHAIN_HTTP.md
docs/validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.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/rules/RULES_DEPENDENCIES.md
docs/rules/RULES_RUST.md
docs/rules/RULES_KSP.md
docs/rules/FILE_CONTRACTS.md
docs/rules/VERSION_WORKFLOW.md
docs/rules/PROMPT_STRUCTURE.md
crates/ksp-onchain-transport-lib/README.md
crates/ksp-onchain-transport-lib/USAGE.md
crates/ksp-onchain-transport-lib/src/
crates/ksp-onchain-transport-lib/unit_tests/
crates/ksp-onchain-transport-lib/tests/
```
Les anciens deltas sont historiques et ne doivent pas être réécrits.
## 5. Sources externes normatives
Au début de `pre.001`, réauditer :
```text
https://solana.com/docs/rpc/http
https://solana.com/docs/rpc/json-structures
```
Et les sources primaires Agave actuelles lorsque la documentation HTTP laisse une ambiguïté sur les configs, limites ou champs wire.
Pour chaque méthode Transaction vérifier :
- paramètres et ordre exacts ;
- commitments/minContextSlot ;
- encodings actuels et formes legacy ;
- cardinalités ;
- null/optional ;
- structures de signature/status/transaction/meta ;
- `maxSupportedTransactionVersion` ;
- erreurs significatives ;
- statut stable/deprecated/unstable ;
- limites provider/runtime utiles avant I/O.
`getTransaction` doit notamment conserver explicitement sa forme moderne et la compatibilité legacy encore auditée, sans présenter la forme legacy comme recommandée.
## 6. Gate de sizing obligatoire
Répondre explicitement :
```text
Les 11 wrappers Transactions, leurs DTOs/wires, les règles write/simulation, les tests et la documentation peuvent-ils être clôturés proprement dans cette session ?
```
Si NON, scinder `0.2.3` avant implémentation lourde. Une prerelease vise environ 1520 minutes de travail effectif.
## 7. Architecture Transport
Conserver le flux unique :
```text
wrapper typed
-> descriptor central
-> execute_standard_rpc
-> pool/admission
-> executor HTTP
-> validation JSON-RPC
-> decode typed
```
Interdits : client HTTP parallèle, `reqwest` direct par wrapper, bypass retry/deadline/admission, Transport -> Config, modèle Store/Program, `tracing` direct.
Réutiliser les primitives `SolanaCommitment`, `SolanaContextConfig`, `SolanaRpcContext` et les erreurs KSP lorsque pertinentes.
## 8. Transaction wire et dépendances
Ne pas ajouter une crate Solana RPC/client haut niveau pour recopier les types du wire.
`pre.001` doit décider explicitement si la représentation/validation des messages et transactions sérialisés justifie enfin une dépendance `base64`, `bs58` ou autre. Ne pas ajouter une dépendance seulement parce que les exemples RPC l'utilisent.
Les apps/workers ne doivent pas recevoir de dépendance protocolaire Solana supplémentaire : la surface publique appartient à Transport/Core.
## 9. Read methods
Auditer particulièrement :
- fee/message et blockhash contextuels ;
- recent prioritization fees ;
- signatures pagination `before/until/limit` ;
- signature statuses et recherche historique ;
- transaction nullable, encoding et version ;
- transaction count ;
- validité d'un blockhash.
Conserver l'ordre des listes et les `null` documentés.
## 10. Write submissions
### `requestAirdrop`
Considérer l'appel comme une soumission : une signature retournée n'autorise pas un resend automatique aveugle après résultat ambigu.
### `sendTransaction`
La règle no-resend est critique. Le wrapper doit utiliser la policy centrale existante et ne jamais introduire sa propre boucle de retry.
Le contrat Transport ne devient pas un executor métier : il transporte une transaction déjà construite/signée et préserve les options RPC.
## 11. `simulateTransaction`
Simulation n'est pas une WriteSubmission et reste retry-safe selon la metadata actuelle, sous réserve du réaudit `pre.001`.
Préserver les options et résultats utiles sans introduire de décodage Program métier.
## 12. Tests
Fixtures HTTP locales obligatoires pour chaque méthode :
- request exacte ;
- success typed ;
- null/optional ;
- config/legacy pertinent ;
- erreurs RPC ;
- cardinalités ;
- write dispatch/no-resend ;
- simulation.
Conserver les canaries :
```text
current == 52 confirmées
historical == 14 confirmées
0.2.1 exact == 4
0.2.2 exact == 22
0.2.3 exact == 11
0.2.4 reste 15 sans avancement prématuré
```
Les smokes live restent opt-in et ne remplacent jamais les fixtures.
## 13. Documentation et fin de release
La dernière prerelease doit, comme `0.2.2-pre.007` :
- réauditer l'inventaire officiel ;
- figer les canaries de complétude ;
- décider/ajouter un smoke opt-in pertinent sans créer une mauvaise ownership boundary ;
- synchroniser README/USAGE, plan et matrice de validation ;
- préparer le prompt `0.2.4` ;
- laisser `CHANGELOG.md` à `rel.001` ;
- préparer une release stable strictement publicationnelle.
## 14. Validations
Pendant le développement :
```bash
cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-onchain-transport-lib
```
À la clôture :
```bash
cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-onchain-transport-lib
cargo test -p ksp-config-lib
cargo test -p ksp-core-lib
cargo test -p ksp-app-config-desk
cargo test --workspace
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
```
Ne jamais déclarer une commande réussie sans preuve opérateur ou exécution réelle.