# 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.