khadhroony-solana-project/prompts/008-V0_2_3_START_PROMPT.md

Prompt de démarrage 0.2.3 — HTTP Transactions

1. Contexte de reprise

La base attendue est la release stable :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-onchain-transport-lib

À la clôture :

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.