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

v0.1.0-pre.011

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-07-24 14:23:58 +02:00
parent 62bc0ffb44
commit 42e8a203ec
460 changed files with 12005 additions and 7020 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
migration/khadhroony-bot2-reference/kb_store_core/README.md
View File

@@ -71,7 +71,7 @@ Les premiers contrats stabilisés sont volontairement minimaux :
| `CoreInnerInstructionInsert` | Instruction CPI résolue avec parent, chemin et hash de payload. |
| `CoreLogInsert` | Log ordonné avec rattachement prudent et hash de texte. |
| `CoreBalanceChangeInsert` | Delta SOL ou token exact, déterministe et lié au compte résolu. |
| `CoreInstructionReplayInput` | Instruction avec contexte extrait, dont les instructions outer ordonnées depuis le contrat `2`, pour les décodeurs. |
| `MdCoreInstructionReplayInput` | Instruction avec contexte extrait, dont les instructions outer ordonnées depuis le contrat `2`, pour les décodeurs. |
| `CoreInstructionReplayFilter` | Filtre de sélection des instructions à traiter ou rejouer. |
| `CoreInstructionLifecycleMark` | Marquage d'état pour une instruction normalisée. |
| `CoreInstructionProcessingState` | État opérationnel d'une instruction pour replay partiel. |
@@ -181,12 +181,12 @@ kb_sol_ops_processing_ledger
Le replay opérationnel doit pouvoir cibler `CoreInstructionRow`, pas seulement `CoreTransactionRow`. Cela permet à un décodeur de demander uniquement les instructions `Pending`, `Failed` ou `ReplayRequested`, filtrées par `program_id` et plage de slots.
Le décodage réel doit ensuite recevoir `CoreInstructionReplayInput`, c'est-à-dire une instruction avec son contexte extrait : comptes résolus, inner instructions, logs, balances et erreur de transaction. Cette décision prépare les futures tables `kb_sol_core_instructions`, `kb_sol_core_logs`, `kb_sol_core_balance_changes` et `kb_sol_ops_processing_ledger` sans figer encore leur SQL exact.
Le décodage réel doit ensuite recevoir `MdCoreInstructionReplayInput`, c'est-à-dire une instruction avec son contexte extrait : comptes résolus, inner instructions, logs, balances et erreur de transaction. Cette décision prépare les futures tables `kb_sol_core_instructions`, `kb_sol_core_logs`, `kb_sol_core_balance_changes` et `kb_sol_ops_processing_ledger` sans figer encore leur SQL exact.
## Extension `0.2.4`
`0.2.4` rend les contrats core effectivement utilisés par `kb_store_pg`. Le replay reste planifié depuis `CoreInstructionRow`, mais les décodeurs reçoivent `CoreInstructionReplayInput` avec account keys, inner instructions, logs et balance changes.
`0.2.4` rend les contrats core effectivement utilisés par `kb_store_pg`. Le replay reste planifié depuis `CoreInstructionRow`, mais les décodeurs reçoivent `MdCoreInstructionReplayInput` avec account keys, inner instructions, logs et balance changes.
Le champ `balance_change_index` est ajouté au contrat `CoreBalanceChangeInsert` afin de dédupliquer les balance changes par ordre d'extraction dans une transaction.
@@ -217,6 +217,6 @@ La couverture machine-readable est portée par `DecodeCoverageDeclarationInsert`
## Contrat contextualisé `2`
Depuis `0.4.1-pre.014`, `CoreInstructionReplayInput` transporte `outer_instructions_json`, obligatoirement un tableau JSON. Chaque entrée représente une instruction outer avec `instructionIndex`, `instructionPath`, `programId`, `payloadJson` et `payloadHash`. La liste inclut l’instruction cible et conserve l’ordre numérique du message. Ce champ participe à la sérialisation déterministe et donc au hash de replay.
Depuis `0.4.1-pre.014`, `MdCoreInstructionReplayInput` transporte `outer_instructions_json`, obligatoirement un tableau JSON. Chaque entrée représente une instruction outer avec `instructionIndex`, `instructionPath`, `programId`, `payloadJson` et `payloadHash`. La liste inclut l’instruction cible et conserve l’ordre numérique du message. Ce champ participe à la sérialisation déterministe et donc au hash de replay.
Ce changement est purement contractuel : il ne requiert aucune migration SQL et ne modifie pas les garanties d’idempotence ou de rollback des stores.