269 lines
8.0 KiB
Markdown
269 lines
8.0 KiB
Markdown
<!-- 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 15–20 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.
|