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

v0.5.3-pre.004

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-12 14:31:48 +02:00
parent 400ced4832
commit b6583bd9fb
47 changed files with 2978 additions and 291 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
ks-store/README.md
View File

@@ -1,5 +1,5 @@
<!-- file: ks-store/README.md -->
<!-- version: 7 -->
<!-- version: 8 -->
# ks-store
@@ -11,10 +11,10 @@ La crate expose :
- `Store` et `StoreOpenOptions` comme façade d'ouverture et handle persistant backend-agnostique ;
- les DTO et entités N1 raw/acquisition, N2 Core, N3 decode/materialization et ledger ;
- les traits async `StoreHealthStore`, `RawTransactionStore`, `CoreTransactionStore`, `CoreExtractionStore` et `DecodePipelineStore` ;
- les traits async `StoreHealthStore`, `RawTransactionStore`, `CoreTransactionStore`, `AccountStateStore`, `CoreExtractionStore` et `DecodePipelineStore` ;
- les filtres et résultats de replay sans préfixe backend ;
- des diagnostics et résumés runtime/init sanitisés ne révélant ni secret ni nom physique d'objet ;
- des transactions atomiques pour extraction, décodage et matérialisation.
- des transactions atomiques pour normalisation d’état de compte, extraction Core, décodage et matérialisation.
## Frontière backend
@@ -40,7 +40,20 @@ Le baseline candidat au gel comprend **16 tables N1-N3** :
Les ressources PostgreSQL sont rangées sous `migrations/postgres/` et suivent la règle **une instruction SQL par fichier**. L'orchestrateur privé applique tables, contraintes et index dans une transaction unique et refuse explicitement un schéma historique contenant encore des objets `kb_sol_*`.
Le baseline comporte actuellement **236 ressources SQL atomiques** et **75 index attendus**, comptés sans exposer leurs noms dans l'API publique.
Le baseline conserve **16 tables** et comporte désormais **240 ressources SQL atomiques** et **79 index attendus** après la revue des chemins de replay `pre.004`, comptés sans exposer leurs noms dans l'API publique.
## Repositories et replay `0.5.3-pre.004`
`pre.004` ferme la symétrie opérationnelle des repositories sans ajouter de table :
- les instructions top-level et CPI restent séparées physiquement mais sont lues par une union logique commune pour le replay ;
- le lifecycle decode/materialization est recalculé pour les deux scopes et tient compte de l’identité/version du decoder courant ;
- le remplacement d’un graphe Core invalide ses descendants N3 dans la même transaction ; un remplacement decode invalide les sorties de matérialisation de ce decoder/input ;
- `k_sol_obs_account_observations` -> `k_sol_core_account_states` devient un replay N1 -> N2 opérationnel, versionné par processing ledger ;
- les pages interactives utilisent un curseur stable et sont bornées à 500 lignes ; les batches de processing Core/decode/account-state sont séparément bornés à 1 000 ;
- les opérations PostgreSQL réécrites émettent des traces `TRACE` sous `ks-store` avec durée/résultat/nombre de lignes, sans SQL brut ni valeur bindée.
Le gel formel N1/N2/N3 n’est pas encore déclaré : il reste conditionné au snapshot et aux validations de réconciliation prévus dans la tranche dédiée.
## Readiness des futurs décodeurs