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

v0.1.0-pre.022

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-07-24 23:24:14 +02:00
parent 34f96582bc
commit 929c89cf9f
15 changed files with 1450 additions and 69 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/EXECUTION_MODEL.md
View File

@@ -33,7 +33,7 @@ Une opération dangereuse ne doit pas être supprimée de l'exécuteur. Elle doi
- `kb_execution_api` définit les contrats communs des exécuteurs.
- `kb_execution_safety` regroupe les validations avant simulation, signature ou envoi.
- `kb_execution_solana` assemble les plans en messages/transactions Solana et orchestre la signature sans RPC.
- `kb-lib::executor::solana::transaction` assemble les plans en messages/transactions Solana et orchestre la signature sans RPC.
- `kb_executor_solana_core` construit les instructions des programmes natifs.
- `kb_wallet` isole les secrets et fournit des signataires.
- `kb_rpc` fournit simulation, envoi et confirmation.
@@ -81,7 +81,7 @@ La simulation accepte une transaction base64 non signée lorsque `sigVerify = fa
## Assemblage et signature Solana
`0.4.2-pre.005` introduit `kb_execution_solana`, frontière commune entre les exécuteurs et les adaptateurs RPC. La crate convertit les `ExApiPlannedInstruction` en instructions SDK, compile le message avec son fee payer et sa source de blockhash, puis vérifie que les signataires réellement compilés correspondent exactement au contrat du plan.
`0.4.2-pre.005` introduit `kb-lib::executor::solana::transaction`, frontière commune entre les exécuteurs et les adaptateurs RPC. La crate convertit les `ExApiPlannedInstruction` en instructions SDK, compile le message avec son fee payer et sa source de blockhash, puis vérifie que les signataires réellement compilés correspondent exactement au contrat du plan.
La transaction non signée fournit deux sorties distinctes :
@@ -110,7 +110,7 @@ getAccountInfo complet et borné à la taille nonce officielle
-> signature du même hash de message et de la même valeur nonce
```
`kb_executor_solana_core` ajoute l’autorité nonce aux signataires requis du plan métier. `kb_execution_solana` refuse les états legacy ou non initialisés, conserve le plan source immuable, expose un plan effectif avec l’avance injectée et exige que le SDK reconnaisse la transaction comme durable nonce. La lecture RPC, l’assemblage, la simulation et la signature restent des étapes séparées.
`kb_executor_solana_core` ajoute l’autorité nonce aux signataires requis du plan métier. `kb-lib::executor::solana::transaction` refuse les états legacy ou non initialisés, conserve le plan source immuable, expose un plan effectif avec l’avance injectée et exige que le SDK reconnaisse la transaction comme durable nonce. La lecture RPC, l’assemblage, la simulation et la signature restent des étapes séparées.
### Builders Address Lookup Table — `pre.015`

14
docs/EXECUTOR_SURFACE_MATRIX.md
View File

@@ -21,13 +21,13 @@ Cette matrice suit la symétrie entre surfaces de décodage et surfaces de const
## Socle d’exécution
| Crate | Rôle |
|-----------------------|------------------------------------------------------------------------------|
| `kb_execution_api` | Contrats provider-neutral des capacités, politiques, plans et résultats. |
| `kb_execution_safety` | Garde-fous stateless avant simulation, signature ou envoi. |
| `kb_execution_solana` | Compilation Solana, blockhash/nonce, preuve de simulation et signature. |
| `kb_rpc` | Acquisition, simulation, envoi et confirmation JSON-RPC ; aucune clé privée. |
| `kb_wallet` | Résolution des signataires derrière un backend explicite. |
| Crate | Rôle |
|-----------------------------------------|------------------------------------------------------------------------------|
| `kb_execution_api` | Contrats provider-neutral des capacités, politiques, plans et résultats. |
| `kb_execution_safety` | Garde-fous stateless avant simulation, signature ou envoi. |
| `kb-lib::executor::solana::transaction` | Compilation Solana, blockhash/nonce, preuve de simulation et signature. |
| `kb_rpc` | Acquisition, simulation, envoi et confirmation JSON-RPC ; aucune clé privée. |
| `kb_wallet` | Résolution des signataires derrière un backend explicite. |
## Règle mécanique

4
docs/KB_LIB_MIGRATION_AUDIT.md
View File

@@ -18,7 +18,7 @@ L’inventaire des anciennes crates métier de `khadhroony-bot2` a été compar
Il reste une ancienne crate fonctionnelle :
- `kb_execution_solana` : assemblage de transactions legacy, durable nonce, validation des comptes nonce, signature, preuves de simulation et contrôle de taille de paquet.
- `kb-lib::executor::solana::transaction` : assemblage de transactions legacy, durable nonce, validation des comptes nonce, signature, preuves de simulation et contrôle de taille de paquet.
Cette couche n’est pas un exécuteur de programme. Elle doit être portée sous la famille `executor/solana` avant la migration du transport on-chain.
@@ -28,4 +28,4 @@ Les autres modules de décodeurs, matérialisateurs et exécuteurs présents dan
### Étape suivante
Migrer `kb_execution_solana`, vérifier ses contrats publics et ses tests, puis clôturer la parité de `kb-lib` avant de passer à la future crate de transport on-chain.
La couche `kb-lib::executor::solana::transaction` est migrée. Après validation utilisateur de cette tranche, la parité fonctionnelle de `kb-lib` avec bot2 est close avant la future crate de transport on-chain.

12
docs/RUST_WORKSPACE_RULE_AUDIT.md
View File

@@ -31,12 +31,12 @@ de migration restent internes à leur inventaire et ne font pas partie de l’AP
## Nomenclature de `kb-lib`
| Famille | Constante | Type ou trait | Fonction libre |
|---|---|---|---|
| Décodeur | `DC_` | `Dc` | `decoder_` |
| Matérialiseur | `MT_` | `Mt` | `materializer_` |
| Exécuteur | `EX_` | `Ex` | `executor_` |
| Modèle | `MD_` | `Md` | `model_` |
| Famille | Constante | Type ou trait | Fonction libre |
|---------------|-----------|---------------|-----------------|
| Décodeur | `DC_` | `Dc` | `decoder_` |
| Matérialiseur | `MT_` | `Mt` | `materializer_` |
| Exécuteur | `EX_` | `Ex` | `executor_` |
| Modèle | `MD_` | `Md` | `model_` |
Les méthodes inhérentes et les helpers strictement privés ne sont pas soumis à un préfixe
global. Les symboles `pub` et `pub(crate)` le sont, car ils peuvent entrer en collision après

6
docs/SOLANA_INTERFACE_DEPENDENCIES.md
View File

@@ -63,9 +63,9 @@ Les crates officielles Ed25519, secp256k1 et secp256r1 exposent les IDs, constan
`kb_decoder_solana_core` reproduit les layouts exacts depuis les sources runtime Agave : table Ed25519/secp256r1 de 14 octets, table secp256k1 de 11 octets, sentinelle `u16::MAX` uniquement pour Ed25519/secp256r1, index `u8` toujours explicite pour secp256k1, règles zéro signature et limite secp256r1. Les fixtures manuelles rendent chaque offset visible et les tests couvrent les références inter-instructions et les bornes. Aucune dépendance `bincode` n’est ajoutée.
## Transaction client dans `kb_execution_solana`
## Transaction client dans `kb-lib::executor::solana::transaction`
`kb_execution_solana` n’importe plus l’agrégat `solana-sdk`. Sa frontière transactionnelle utilise les crates modulaires réellement consommées : `solana-instruction`, `solana-message`, `solana-transaction`, `solana-hash`, `solana-pubkey`, `solana-keypair`, `solana-signer`, `solana-nonce` et `solana-system-interface`. Les exécuteurs spécifiques conservent la même politique et ajoutent uniquement l’interface de programme nécessaire.
`kb-lib::executor::solana::transaction` n’importe plus l’agrégat `solana-sdk`. Sa frontière transactionnelle utilise les crates modulaires réellement consommées : `solana-instruction`, `solana-message`, `solana-transaction`, `solana-hash`, `solana-pubkey`, `solana-keypair`, `solana-signer`, `solana-nonce` et `solana-system-interface`. Les exécuteurs spécifiques conservent la même politique et ajoutent uniquement l’interface de programme nécessaire.
Le message à signer provient de `solana_transaction::Transaction::message_data()`. La transaction complète utilise `wincode::serialize`, supporté officiellement par les types modulaires `Message` et `Transaction`. Cette stratégie remplace tout appel direct à `bincode` et reproduit le wire attendu par `getFeeForMessage`, `simulateTransaction` et `sendTransaction`. La taille sérialisée est refusée au-delà de 1 232 octets.
@@ -95,7 +95,7 @@ Le message à signer provient de `solana_transaction::Transaction::message_data(
`kb_decoder_spl_memo` et `kb_executor_spl_memo` consomment `spl-memo-interface ^2.1` sans feature additionnelle. La version effectivement résolue pendant les validations est 2.1.0. Elle publie les trois IDs exacts et un builder générique recevant explicitement le Program ID. Ce builder place les octets exacts du message dans `Instruction::data` et transforme chaque pubkey fournie en compte readonly signer, sans sérialisation intermédiaire.
L’exécuteur appelle ce builder pour les trois générations et compare chaque plan au résultat officiel. Les différences runtime restent explicites : v1 ignore les comptes, v3/v4 les vérifient. La bibliothèque ne lie toutefois aucune génération à un cluster ou au dry-run : la simulation obligatoire établit la disponibilité effective du Program ID ciblé, puis les politiques communes gouvernent l’autorisation d’envoi et Mainnet. La démo du jalon retient séparément v4 sur Devnet. La taille packet finale reste contrôlée par `kb_execution_solana` après compilation du message.
L’exécuteur appelle ce builder pour les trois générations et compare chaque plan au résultat officiel. Les différences runtime restent explicites : v1 ignore les comptes, v3/v4 les vérifient. La bibliothèque ne lie toutefois aucune génération à un cluster ou au dry-run : la simulation obligatoire établit la disponibilité effective du Program ID ciblé, puis les politiques communes gouvernent l’autorisation d’envoi et Mainnet. La démo du jalon retient séparément v4 sur Devnet. La taille packet finale reste contrôlée par `kb-lib::executor::solana::transaction` après compilation du message.
Le décodeur ne dépend pas du builder pour lire le wire : il analyse directement les octets base64 retenus par le core, avec une borne de 4 096 octets, puis valide l’UTF‑8. La source historique v1 prouve que les comptes sont ignorés ; les processors v3/v4 exigent au contraire que chaque compte fourni soit signer avant de valider l’UTF‑8. Ces règles restent séparées dans `docs/SPL_MEMO_MATRIX.json` et les tests comparent les trois IDs locaux aux constantes de l’interface officielle.

28
docs/SOLANA_NATIVE_RPC_CLOSURE_AUDIT.md
View File

@@ -77,20 +77,20 @@ Le navigateur SQL applique maintenant la limite maximale reçue du backend avant
Validations fournies le 13 juillet 2026 :
| Crate / contrôle | Résultat |
|------------------------------------|----------:|
| `kb_program_ids` | 5 tests |
| `kb_decoder_solana_core` | 116 tests |
| `kb_executor_solana_core` | 88 tests |
| `kb_execution_api` | 22 tests |
| `kb_execution_safety` | 15 tests |
| `kb_execution_solana` | 12 tests |
| `kb_rpc` | 113 tests |
| `kb_pipeline` | 56 tests |
| `kb_config` | 41 tests |
| `kb_app_demo` | 88 tests |
| `kb_store_pg` avec PostgreSQL réel | 45 tests |
| `cargo clippy --all-targets` | propre |
| Crate / contrôle | Résultat |
|-----------------------------------------|----------:|
| `kb_program_ids` | 5 tests |
| `kb_decoder_solana_core` | 116 tests |
| `kb_executor_solana_core` | 88 tests |
| `kb_execution_api` | 22 tests |
| `kb_execution_safety` | 15 tests |
| `kb-lib::executor::solana::transaction` | 12 tests |
| `kb_rpc` | 113 tests |
| `kb_pipeline` | 56 tests |
| `kb_config` | 41 tests |
| `kb_app_demo` | 88 tests |
| `kb_store_pg` avec PostgreSQL réel | 45 tests |
| `cargo clippy --all-targets` | propre |
Le test Devnet opt-in a exécuté un transfert de 1 000 000 lamports avec airdrop nul depuis un wallet préfinancé. Il a confirmé simulation, signature, envoi, confirmation, hydratation canonique, extraction core et decode replay. `cargo tauri dev` a démarré Vite, initialisé les treize tables attendues et exercé les sessions WebSocket.