Files
khadhroony-bot3/ks-store/TODO.md
2026-08-11 22:22:40 +02:00

2.2 KiB

TODO — ks-store

Série 0.5.x

  • 0.5.3 — reconstruire kb_sol_* -> k_sol_*, ajouter block_time aux ancres raw/Core, conserver top-level/CPI dans deux tables Core avec lifecycle/replay équivalents, stack_height/parent CPI audités et renommer le journal N3 en k_sol_mat_outputs.
  • 0.5.3 — déplacer les ressources sous migrations/postgres/, imposer une instruction SQL par fichier avec exécution privée via include_str!, séparer tables/keys/index/drop/truncate et supprimer le DDL dupliqué en Rust.
  • 0.5.3 — corriger l'invalidation descendante, formaliser les replays N1 -> N2 / N2 -> N3 / frontière N3 -> N4, les paginations/limites, les conversions BIGINT et les index justifiés par les requêtes réelles.
  • 0.5.3 — finaliser en pre.005 la présentation fonctionnelle des surfaces demo_store_*, demo_config et le splash autour des modèles/compteurs du nouveau baseline sans noms d'objets physiques ; le renommage technique demo_sql_* -> demo_store_* est réalisé en pre.002.
  • 0.5.3 — exécuter avant gel le canari future-decoder/Anchor-readiness sur N1/N2/N3 : bytes d'instruction, comptes ordonnés/flags, hiérarchie CPI, logs, returnData, observations/états de comptes et provenance decoder/schema ; ajouter seulement les contrats Solana génériques manquants, sans table anchor_*.
  • 0.5.3 — produire le snapshot machine-readable des tables N1/N2/N3 réellement stabilisées après ce canari (13 tables existantes de baseline, plus éventuels contrats génériques nécessaires), documenter la politique N4 plus souple et les futures projections metadata asset/token + program metadata, puis ajouter les canaris anti-kb_sol_*, anti-backend leak, anti-secret et logging sous le target canonique ks-store avec domaine structuré ks-store.pg.
  • PostgreSQL - auditer le dimensionnement du pool selon les charges réelles.
  • Résilience - décider et implémenter, si justifié, un retry borné pour les timeouts transitoires.
  • Administration - définir les outils supplémentaires prévus par le ROADMAP avant leur implémentation.
  • Historique - documenter et tester les futures opérations historiques ajoutées à la crate.