v0.4.6
This commit is contained in:
41
CHANGELOG.md
41
CHANGELOG.md
@@ -1,10 +1,40 @@
|
||||
<!-- file: CHANGELOG.md -->
|
||||
<!-- version: 10 -->
|
||||
<!-- version: 11 -->
|
||||
|
||||
# CHANGELOG — khadhroony-bot3
|
||||
|
||||
Ce changelog décrit les évolutions fonctionnelles globales du projet. Il ne recense pas les prereleases, les correctifs `fix` ni le détail de chaque delta. Ces informations appartiennent aux changelogs des crates concernées.
|
||||
|
||||
## 0.4.6 — alignement fonctionnel de khadhroony-bot3
|
||||
|
||||
### Architecture
|
||||
|
||||
- clôture de la migration principale de bot2 vers l’architecture consolidée bot3 ;
|
||||
- onze crates documentées et versionnées `0.4.6` ;
|
||||
- décodeurs, exécuteurs et matérialisateurs regroupés dans `kb-lib` ;
|
||||
- stockage consolidé dans `kb-store` et transports RPC dans `kb-onchain-transport`.
|
||||
|
||||
### Capacités
|
||||
|
||||
- Solana Core, SPL Memo, SPL Token classique, Associated Token Account et Token-2022 alignés sur le périmètre historique `0.4.6` ;
|
||||
- backfill, acquisition canonique, extraction Core, replay, matérialisation et idempotence validés ;
|
||||
- System Transfer, Memo v4 et surfaces SPL prévues validés dans les campagnes applicatives ;
|
||||
- session WebSocket persistante indépendamment du cycle de vie de la fenêtre `demo_ws`.
|
||||
|
||||
### Validation
|
||||
|
||||
- `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --all-targets` et `cargo test --workspace` validés ;
|
||||
- audits Rust, exports, règles Khadhroony et contrats statiques pré-`0.4.6` validés ;
|
||||
- matrices, registres runtime et bindings TS-RS validés ;
|
||||
- campagne desktop finale déclarée conforme.
|
||||
|
||||
### Exceptions et reports
|
||||
|
||||
- registre ElGamal non déclaré validé réellement sur Devnet ou Mainnet faute de déploiement et de preuves disponibles ;
|
||||
- achèvement de Metaplex Token Metadata reporté à `0.4.7` ;
|
||||
- SPL Token Metadata et décision sur `kb-offchain-transport` reportés à `0.4.8` ;
|
||||
- améliorations structurelles de `kb-config`, `kb-logging` et `kb-store` reportées à `0.5.x`.
|
||||
|
||||
## 0.1.0-mig-from-kbot2 — transition architecturale vers khadhroony-bot3
|
||||
|
||||
Cette entrée de transition regroupe la migration structurelle et fonctionnelle commencée depuis `khadhroony-bot2`. Elle identifie la campagne `0.1.0-pre.*` de bot3 sans constituer une version fonctionnelle équivalente à bot2 `0.1.0` ni un alignement officiel sur `0.4.6`.
|
||||
@@ -48,14 +78,9 @@ Cette entrée de transition regroupe la migration structurelle et fonctionnelle
|
||||
|
||||
Les sections dont le numéro porte le suffixe `-kbot2` décrivent exclusivement les versions et travaux réalisés dans `khadhroony-bot2`. Elles constituent l’historique fonctionnel du projet d’origine et ne représentent pas des versions publiées de `khadhroony-bot3`.
|
||||
|
||||
`khadhroony-bot3` résulte de la migration et de la consolidation de cette base historique dans une nouvelle architecture. Son futur alignement de version sera décidé après la clôture de l’audit `0.4.6`.
|
||||
`khadhroony-bot3` résulte de la migration et de la consolidation de cette base historique dans une nouvelle architecture. Son alignement fonctionnel est clôturé par la version bot3 `0.4.6`.
|
||||
|
||||
La future version fonctionnelle `0.4.7` de `khadhroony-bot3` devra réunir :
|
||||
|
||||
- la clôture des écarts résiduels de migration ;
|
||||
- les capacités historiques de bot2 nécessaires à l’alignement ;
|
||||
- les travaux Metaplex Token Metadata déjà réalisés puis migrés ;
|
||||
- l’achèvement des éléments de l’objectif `0.4.7-kbot2` restés incomplets, notamment l’exécuteur, l’intégration au pipeline, les démonstrations et les validations finales.
|
||||
La version `0.4.7` de `khadhroony-bot3` achèvera Metaplex Token Metadata à partir des décodeurs et matérialisations déjà migrés, en ajoutant notamment l’exécuteur, l’intégration pipeline, les démonstrations et les validations finales.
|
||||
|
||||
Les entrées `0.0.1-kbot2` à `0.4.6-kbot2` décrivent des versions fonctionnelles clôturées de bot2. L’entrée `0.4.7-kbot2` décrit une version interrompue en cours de développement par la migration vers bot3.
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
# file: Cargo.toml
|
||||
# version: 7
|
||||
# version: 8
|
||||
|
||||
[workspace]
|
||||
resolver = "3"
|
||||
@@ -18,7 +18,7 @@ members = [
|
||||
]
|
||||
|
||||
[workspace.package]
|
||||
version = "0.1.0"
|
||||
version = "0.4.6"
|
||||
edition = "2024"
|
||||
license = "MIT"
|
||||
repository = "https://git.sasedev.com/Sasedev/khadhroony-bot3"
|
||||
|
||||
24
README.md
24
README.md
@@ -1,10 +1,20 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 14 -->
|
||||
<!-- version: 15 -->
|
||||
|
||||
# Khadhroony Bot3
|
||||
|
||||
`khadhroony-bot3` est le workspace Rust consolidé succédant à `khadhroony-bot2` pour l’acquisition, le stockage, le décodage, la matérialisation, la validation et l’exécution contrôlée d’opérations Solana.
|
||||
|
||||
## Version fonctionnelle
|
||||
|
||||
Le workspace est aligné sur le périmètre fonctionnel de `khadhroony-bot2 0.4.6` dans la nouvelle architecture bot3. Les différences de structure sont intentionnelles : les modèles, décodeurs, exécuteurs et matérialisateurs sont consolidés dans `kb-lib`, le stockage dans `kb-store` et les transports RPC dans `kb-onchain-transport`.
|
||||
|
||||
Exceptions documentées :
|
||||
|
||||
- le registre ElGamal est implémenté avec validations synthétiques et garde-fous fail-closed, mais n’est pas déclaré validé réellement sur Devnet ou Mainnet ;
|
||||
- Metaplex Token Metadata possède déjà ses décodeurs d’instructions et de comptes ainsi qu’une matérialisation substantielle, mais son exécuteur, son orchestration complète et ses démonstrations appartiennent à `0.4.7` ;
|
||||
- les améliorations structurelles de `kb-config`, `kb-logging` et `kb-store` sont reportées à `0.5.x`.
|
||||
|
||||
## Architecture
|
||||
|
||||
Le workspace contient 11 crates :
|
||||
@@ -29,21 +39,13 @@ La vue détaillée est disponible dans :
|
||||
- [`docs/architecture/STORAGE_ARCHITECTURE.md`](docs/architecture/STORAGE_ARCHITECTURE.md) ;
|
||||
- [`docs/architecture/SURFACE_CRATE_MATRIX.md`](docs/architecture/SURFACE_CRATE_MATRIX.md).
|
||||
|
||||
## État fonctionnel
|
||||
|
||||
La migration a repris un périmètre proche de `khadhroony-bot2 v0.4.6`, ainsi qu’une partie du travail `0.4.7` consacré à Metaplex Token Metadata.
|
||||
|
||||
Le workspace bot3 n’est pas encore officiellement réaligné sur `0.4.6`. Cette décision dépend de l’audit ciblé prévu dans `docs/V0_4_6_ALIGNMENT_AUDIT.md`.
|
||||
|
||||
Le registre ElGamal ne doit pas être présenté comme validé sur Devnet ou Mainnet.
|
||||
|
||||
## Documentation
|
||||
|
||||
L’index actif se trouve dans [`docs/README.md`](docs/README.md).
|
||||
|
||||
Les règles normatives commencent dans [`RULES.md`](RULES.md). Les règles spécialisées sont placées sous [`docs/rules/`](docs/rules/).
|
||||
|
||||
La documentation historique bot2 est conservée sous `olddocs/archivekbot2/`. Elle sert de source historique et n’est pas normative pour bot3.
|
||||
Les documents historiques de bot2, bobobot et de la migration bot3 sont conservés sous `olddocs/`. Ils servent de sources historiques et ne sont pas normatifs.
|
||||
|
||||
## Validation générale
|
||||
|
||||
@@ -55,8 +57,6 @@ python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test --workspace
|
||||
```
|
||||
|
||||
Les changements documentaires purs peuvent se limiter à l’audit des règles lorsque le delta ne modifie ni code ni configuration d’exécution.
|
||||
|
||||
La validation frontend desktop s’effectue uniquement avec :
|
||||
|
||||
```bash
|
||||
|
||||
91
ROADMAP.md
91
ROADMAP.md
@@ -1,5 +1,5 @@
|
||||
<!-- file: ROADMAP.md -->
|
||||
<!-- version: 22 -->
|
||||
<!-- version: 23 -->
|
||||
|
||||
# ROADMAP — khadhroony-bot3
|
||||
|
||||
@@ -7,60 +7,67 @@ Le roadmap décrit les objectifs fonctionnels par version mineure. Il ne contien
|
||||
|
||||
## 0.4.6 — alignement fonctionnel et clôture de la migration principale
|
||||
|
||||
### Objectifs
|
||||
Version clôturée.
|
||||
|
||||
- formaliser l’équivalence largement atteinte avec khadhroony-bot2 `0.4.6` ;
|
||||
- documenter précisément les écarts résiduels ;
|
||||
- valider les renommages, consolidations et nouvelles frontières de crates ;
|
||||
- fermer la migration structurelle principale ;
|
||||
- décider du réalignement officiel du versionnement et du premier numéro fonctionnel publié après la transition `0.1.0-mig-from-kbot2`.
|
||||
- alignement fonctionnel sur `khadhroony-bot2 0.4.6` ;
|
||||
- consolidation de l’architecture en onze crates ;
|
||||
- validation des matrices, registres, bindings TS-RS, tests workspace et scénarios applicatifs ;
|
||||
- conservation du registre ElGamal comme exception documentée sans validation réseau réelle ;
|
||||
- report des améliorations structurelles de configuration, logging et stockage à `0.5.x`.
|
||||
|
||||
### Lots
|
||||
## 0.4.7 — achèvement de Metaplex Token Metadata
|
||||
|
||||
- refonte de la documentation générale et des règles ;
|
||||
- reconstruction des changelogs et du roadmap ;
|
||||
- documentation complète des 11 crates ;
|
||||
- reconstruction des prompts bot3 ;
|
||||
- audit ciblé `docs/V0_4_6_ALIGNMENT_AUDIT.md` ;
|
||||
- traitement ou documentation explicite des exceptions restantes.
|
||||
### Base acquise
|
||||
|
||||
### Critères de sortie
|
||||
|
||||
- chaque crate possède `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md` ;
|
||||
- les versions, noms de crates et binaires sont cohérents ;
|
||||
- les tests et validations déjà réalisés sont synthétisés sans nouvel audit complet des protocoles ;
|
||||
- le statut de `kb-wallet`, `kb-config`, `kb-pipeline-demo-scenarios`, ElGamal et des transports est explicite ;
|
||||
- l’audit conclut `READY_FOR_0_4_6` ou `READY_WITH_DOCUMENTED_EXCEPTIONS` ;
|
||||
- le changelog général n’ajoute l’entrée de réalignement qu’au dernier prerelease ou correctif précédant le commit de la version fonctionnelle retenue.
|
||||
|
||||
## 0.4.7 — Metaplex Token Metadata complet et clôture de 0.4.x
|
||||
|
||||
### Positionnement de version
|
||||
|
||||
- le premier numéro fonctionnel après la migration pourra être `0.4.6+` ou une étape préparatoire de la famille `0.4.7`, selon la conclusion de l’audit d’alignement ;
|
||||
- l’entrée générale correspondante ne sera ajoutée au changelog qu’au moment de finaliser cette version ;
|
||||
- la version finale `0.4.7` doit inclure la surface Metaplex Token Metadata complète, et non le seul décodeur déjà migré.
|
||||
- décodeur d’instructions Metaplex Token Metadata ;
|
||||
- décodeur des comptes et validation des PDA/owners ;
|
||||
- matrice contractuelle bornée ;
|
||||
- matérialisation metadata déjà substantielle ;
|
||||
- coexistence explicite avec les metadata incorporées de Token-2022.
|
||||
|
||||
### Objectifs
|
||||
|
||||
- terminer Metaplex Token Metadata commencé dans bot2 et dont le décodeur a déjà été migré dans bot3 ;
|
||||
- vérifier et compléter décodeurs de comptes et instructions ;
|
||||
- ajouter les matérialisateurs, exécuteurs, préflights et validations nécessaires ;
|
||||
- finaliser les éléments résiduels du noyau historique ;
|
||||
- préparer les démonstrations complètes de la série `0.5.x`.
|
||||
- auditer la matérialisation migrée et compléter uniquement les projections manquantes ;
|
||||
- implémenter les intents typés, builders, exécuteur, préflights et postconditions ;
|
||||
- intégrer l’exécution et les validations dans `kb-pipeline` ;
|
||||
- ajouter les scénarios réutilisables, le CLI et les panneaux desktop ;
|
||||
- valider le parcours réseau et PostgreSQL de bout en bout lorsque les fixtures sont disponibles.
|
||||
|
||||
### Contraintes
|
||||
|
||||
- ne pas confondre Metaplex Token Metadata avec les metadata incorporées de Token-2022 ou Metaplex Core ;
|
||||
- utiliser les IDL archivées comme références de conception, jamais comme moteur dynamique de production ;
|
||||
- conserver les matrices exécutables sous `test-fixtures/contract-matrices/`.
|
||||
- ne pas confondre Metaplex Token Metadata, metadata Token-2022, SPL Token Metadata ou Metaplex Core ;
|
||||
- utiliser les IDL archivées comme références, jamais comme moteur dynamique de production ;
|
||||
- conserver le fetch HTTP/IPFS/Arweave hors périmètre de `0.4.7`.
|
||||
|
||||
### Critères de sortie
|
||||
|
||||
- couverture fonctionnelle bornée et documentée ;
|
||||
- tests contractuels et unitaires complets ;
|
||||
- limites et validations réseau explicites ;
|
||||
- aucune surface partiellement annoncée comme terminée.
|
||||
- exécution simulation-first avec signers, coûts et confirmations exacts ;
|
||||
- intégration pipeline et démonstrations complètes ;
|
||||
- tests contractuels, unitaires et stateful ;
|
||||
- limites réseau et opérations historiques decode-only documentées.
|
||||
|
||||
## 0.4.8 — SPL Token Metadata et décision off-chain metadata
|
||||
|
||||
### Objectifs
|
||||
|
||||
- auditer `spl-token-metadata-interface` comme surface distincte ;
|
||||
- séparer explicitement SPL Token Metadata, metadata Token-2022 et Metaplex Token Metadata ;
|
||||
- implémenter les couches decoder, materializer, executor, pipeline et démonstrations réellement justifiées ;
|
||||
- décider si une nouvelle crate `kb-offchain-transport` doit être créée ;
|
||||
- si elle est retenue, commencer par un module metadata borné pour HTTP, IPFS et Arweave.
|
||||
|
||||
### Contraintes du fetch off-chain
|
||||
|
||||
- le contenu externe ne modifie jamais le statut canonique du replay on-chain ;
|
||||
- timeout, taille, content type, redirections, cache, hash et provenance sont bornés ;
|
||||
- protection SSRF et interdiction des réseaux locaux ;
|
||||
- aucune confiance implicite dans les JSON distants.
|
||||
|
||||
### Critères de sortie
|
||||
|
||||
- contrats SPL Token Metadata vérifiés et documentés ;
|
||||
- décision architecturale explicite sur `kb-offchain-transport` ;
|
||||
- absence de confusion ou fusion silencieuse entre sources metadata.
|
||||
|
||||
## 0.5.x — démonstrations, configuration et wallet
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/README.md -->
|
||||
<!-- version: 10 -->
|
||||
<!-- version: 11 -->
|
||||
|
||||
# Documentation active de Khadhroony Bot3
|
||||
|
||||
@@ -38,8 +38,6 @@ Modèles documentaires non génératifs :
|
||||
|
||||
## 4. Audits et décisions actifs
|
||||
|
||||
- [`audits/V0_4_6_ALIGNMENT_AUDIT.md`](audits/V0_4_6_ALIGNMENT_AUDIT.md) ;
|
||||
- [`audits/PRE_0_4_6_STATIC_CODE_AUDIT.md`](audits/PRE_0_4_6_STATIC_CODE_AUDIT.md) ;
|
||||
- [`decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md`](decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md) ;
|
||||
- [`decisions/WINCODE_COMPATIBILITY_POLICY.md`](decisions/WINCODE_COMPATIBILITY_POLICY.md).
|
||||
|
||||
@@ -96,3 +94,7 @@ Les onze crates possèdent désormais `README.md`, `TODO.md`, `USAGE.md` et `CHA
|
||||
- [`validation/PRE_062_DEVNET_VALIDATION_REPORT.md`](validation/PRE_062_DEVNET_VALIDATION_REPORT.md) ;
|
||||
- [`validation/WEBSOCKET_MAINNET_RESEARCH_VALIDATION_REPORT.md`](validation/WEBSOCKET_MAINNET_RESEARCH_VALIDATION_REPORT.md) ;
|
||||
- [`validation/MAINNET_RESEARCH_BACKFILL_VALIDATION_SCENARIO.md`](validation/MAINNET_RESEARCH_BACKFILL_VALIDATION_SCENARIO.md) ;
|
||||
|
||||
## Prompt de reprise
|
||||
|
||||
- [`0.4.7 — achèvement de Metaplex Token Metadata`](../prompts/027_v0_4_7_metaplex_token_metadata_completion.md).
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/ARCHITECTURE.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Architecture générale
|
||||
|
||||
@@ -104,4 +104,4 @@ L’exécution suit un flux séparé : intention typée, construction, préfligh
|
||||
|
||||
## 5. État de migration
|
||||
|
||||
L’architecture bot3 est largement alignée fonctionnellement sur le périmètre bot2 proche de `0.4.6`, avec des travaux `0.4.7` partiellement migrés. L’alignement officiel de version reste conditionné à l’audit ciblé prévu par `docs/V0_4_6_ALIGNMENT_AUDIT.md`.
|
||||
L’architecture bot3 est alignée fonctionnellement sur le périmètre bot2 `0.4.6`. Les travaux Metaplex Token Metadata partiellement migrés sont repris séparément dans `0.4.7`.
|
||||
|
||||
@@ -1,8 +1,13 @@
|
||||
<!-- file: kb-app-demo-desktop/CHANGELOG.md -->
|
||||
<!-- version: 6 -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# CHANGELOG — kb-app-demo-desktop
|
||||
|
||||
## 0.4.6
|
||||
|
||||
- alignement de la crate sur la version fonctionnelle bot3 `0.4.6` ;
|
||||
- clôture des tâches de migration applicables et report explicite des évolutions ultérieures dans le TODO.
|
||||
|
||||
## 0.1.0-pre.076
|
||||
|
||||
- correction de l’architecture Tauri : `tauri.rs` reste l’unique propriétaire des `#[tauri::command]` et délègue via la façade `crate::*` ;
|
||||
|
||||
@@ -1,16 +1,11 @@
|
||||
<!-- file: kb-app-demo-desktop/TODO.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# TODO — kb-app-demo-desktop
|
||||
|
||||
## Bloquants avant alignement `0.4.6`
|
||||
## `0.4.7`
|
||||
|
||||
- [ ] Validation - vérifier intégralement la synchronisation des adaptateurs Tauri et des payloads TS-RS avec les APIs réutilisables.
|
||||
- [ ] Validation - couvrir explicitement les cycles d’ouverture, fermeture et réouverture des fenêtres concernées.
|
||||
|
||||
## Entre `0.4.6` et `0.4.7`
|
||||
|
||||
- [ ] Metaplex Token Metadata - ajouter les panneaux nécessaires aux scénarios complétés de la future `0.4.7`.
|
||||
- [ ] Metaplex Token Metadata - ajouter les panneaux nécessaires aux scénarios complétés.
|
||||
|
||||
## Versions ultérieures
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
// file: kb_app_demo/frontend/sass/_app.scss
|
||||
// version: 5
|
||||
// file: kb-app-demo-desktop/frontend/sass/_app.scss
|
||||
// version: 6
|
||||
|
||||
$app-header-height: 48px;
|
||||
$app-footer-height: 48px;
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
// file: kb-app-demo-desktop/frontend/ts/demo_sql_diag.ts
|
||||
// version: 2
|
||||
// version: 3
|
||||
|
||||
import * as bootstrap from "bootstrap";
|
||||
import "simplebar";
|
||||
@@ -29,13 +29,13 @@ async function refreshDiagnostics(): Promise<void> {
|
||||
renderTables("#sqlDiagTable", "#sqlDiagTableBody", payload.tables);
|
||||
latestPayload = payload;
|
||||
renderJsonViewer("#sqlDiagJson", payload);
|
||||
frontendDebug("kb_app_demo.frontend.demo_sql_diag", "SQL diagnostics refreshed");
|
||||
frontendDebug("kb_app_demo_desktop.frontend.demo_sql_diag", "SQL diagnostics refreshed");
|
||||
} catch (caughtError) {
|
||||
const message = caughtError instanceof Error ? caughtError.message : String(caughtError);
|
||||
setText("#sqlDiagStatus", `Erreur : ${message}`);
|
||||
latestPayload = null;
|
||||
renderJsonViewer("#sqlDiagJson", { error: message });
|
||||
frontendError("kb_app_demo.frontend.demo_sql_diag", `SQL diagnostics loading failed: ${message}`);
|
||||
frontendError("kb_app_demo_desktop.frontend.demo_sql_diag", `SQL diagnostics loading failed: ${message}`);
|
||||
}
|
||||
}
|
||||
|
||||
@@ -46,8 +46,8 @@ async function copyDiagnostics(): Promise<void> {
|
||||
}
|
||||
|
||||
document.addEventListener("DOMContentLoaded", () => {
|
||||
installFrontendConsoleBridge("kb_app_demo.frontend.demo_sql_diag");
|
||||
frontendDebug("kb_app_demo.frontend.demo_sql_diag", "SQL diagnostics demo window loaded");
|
||||
installFrontendConsoleBridge("kb_app_demo_desktop.frontend.demo_sql_diag");
|
||||
frontendDebug("kb_app_demo_desktop.frontend.demo_sql_diag", "SQL diagnostics demo window loaded");
|
||||
const tooltipTriggerList = document.querySelectorAll('[data-bs-toggle="tooltip"]');
|
||||
Array.from(tooltipTriggerList).map(tooltipTriggerEl => new bootstrap.Tooltip(tooltipTriggerEl));
|
||||
document.querySelector<HTMLButtonElement>("#refreshSqlDiagButton")?.addEventListener("click", () => {
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
// file: kb-app-demo-desktop/frontend/ts/demo_sql_pg_core.ts
|
||||
// version: 3
|
||||
// version: 4
|
||||
|
||||
import * as bootstrap from "bootstrap";
|
||||
import "simplebar";
|
||||
@@ -21,18 +21,18 @@ async function refreshCore(): Promise<void> {
|
||||
setText("#sqlCoreStatus", "OK");
|
||||
renderTables("#sqlCoreTable", "#sqlCoreTableBody", payload.tables);
|
||||
renderJsonViewer("#sqlCoreJson", payload);
|
||||
frontendDebug("kb_app_demo.frontend.demo_sql_pg_core", "PostgreSQL core diagnostics refreshed");
|
||||
frontendDebug("kb_app_demo_desktop.frontend.demo_sql_pg_core", "PostgreSQL core diagnostics refreshed");
|
||||
} catch (caughtError) {
|
||||
const message = caughtError instanceof Error ? caughtError.message : String(caughtError);
|
||||
setText("#sqlCoreStatus", `Erreur : ${message}`);
|
||||
renderJsonViewer("#sqlCoreJson", { error: message });
|
||||
frontendError("kb_app_demo.frontend.demo_sql_pg_core", `PostgreSQL core diagnostics loading failed: ${message}`);
|
||||
frontendError("kb_app_demo_desktop.frontend.demo_sql_pg_core", `PostgreSQL core diagnostics loading failed: ${message}`);
|
||||
}
|
||||
}
|
||||
|
||||
document.addEventListener("DOMContentLoaded", () => {
|
||||
installFrontendConsoleBridge("kb_app_demo.frontend.demo_sql_pg_core");
|
||||
frontendDebug("kb_app_demo.frontend.demo_sql_pg_core", "PostgreSQL core demo window loaded");
|
||||
installFrontendConsoleBridge("kb_app_demo_desktop.frontend.demo_sql_pg_core");
|
||||
frontendDebug("kb_app_demo_desktop.frontend.demo_sql_pg_core", "PostgreSQL core demo window loaded");
|
||||
const tooltipTriggerList = document.querySelectorAll('[data-bs-toggle="tooltip"]');
|
||||
Array.from(tooltipTriggerList).map(tooltipTriggerEl => new bootstrap.Tooltip(tooltipTriggerEl));
|
||||
document.querySelector<HTMLButtonElement>("#refreshSqlCoreButton")?.addEventListener("click", () => {
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
// file: kb-app-demo-desktop/frontend/ts/demo_sql_pg_raw.ts
|
||||
// version: 3
|
||||
// version: 4
|
||||
|
||||
import * as bootstrap from "bootstrap";
|
||||
import "simplebar";
|
||||
@@ -21,18 +21,18 @@ async function refreshRaw(): Promise<void> {
|
||||
setText("#sqlRawStatus", "OK");
|
||||
renderTables("#sqlRawTable", "#sqlRawTableBody", payload.tables);
|
||||
renderJsonViewer("#sqlRawJson", payload);
|
||||
frontendDebug("kb_app_demo.frontend.demo_sql_pg_raw", "PostgreSQL raw diagnostics refreshed");
|
||||
frontendDebug("kb_app_demo_desktop.frontend.demo_sql_pg_raw", "PostgreSQL raw diagnostics refreshed");
|
||||
} catch (caughtError) {
|
||||
const message = caughtError instanceof Error ? caughtError.message : String(caughtError);
|
||||
setText("#sqlRawStatus", `Erreur : ${message}`);
|
||||
renderJsonViewer("#sqlRawJson", { error: message });
|
||||
frontendError("kb_app_demo.frontend.demo_sql_pg_raw", `PostgreSQL raw diagnostics loading failed: ${message}`);
|
||||
frontendError("kb_app_demo_desktop.frontend.demo_sql_pg_raw", `PostgreSQL raw diagnostics loading failed: ${message}`);
|
||||
}
|
||||
}
|
||||
|
||||
document.addEventListener("DOMContentLoaded", () => {
|
||||
installFrontendConsoleBridge("kb_app_demo.frontend.demo_sql_pg_raw");
|
||||
frontendDebug("kb_app_demo.frontend.demo_sql_pg_raw", "PostgreSQL raw demo window loaded");
|
||||
installFrontendConsoleBridge("kb_app_demo_desktop.frontend.demo_sql_pg_raw");
|
||||
frontendDebug("kb_app_demo_desktop.frontend.demo_sql_pg_raw", "PostgreSQL raw demo window loaded");
|
||||
const tooltipTriggerList = document.querySelectorAll('[data-bs-toggle="tooltip"]');
|
||||
Array.from(tooltipTriggerList).map(tooltipTriggerEl => new bootstrap.Tooltip(tooltipTriggerEl));
|
||||
document.querySelector<HTMLButtonElement>("#refreshSqlRawButton")?.addEventListener("click", () => {
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
// file: kb-app-demo-desktop/frontend/ts/demo_sql_replay_candidates.ts
|
||||
// version: 8
|
||||
// version: 9
|
||||
|
||||
import * as bootstrap from "bootstrap";
|
||||
import "simplebar";
|
||||
@@ -40,7 +40,7 @@ type EntityViewConfig = {
|
||||
fileName: string;
|
||||
};
|
||||
|
||||
const tracingTarget = "kb_app_demo.frontend.demo_sql_replay_candidates";
|
||||
const tracingTarget = "kb_app_demo_desktop.frontend.demo_sql_replay_candidates";
|
||||
const entityViewConfigs: EntityViewConfig[] = [
|
||||
{
|
||||
kind: "mint",
|
||||
|
||||
@@ -3,6 +3,11 @@
|
||||
|
||||
# CHANGELOG — kb-config
|
||||
|
||||
## 0.4.6
|
||||
|
||||
- alignement de la crate sur la version fonctionnelle bot3 `0.4.6` ;
|
||||
- clôture des tâches de migration applicables et report explicite des évolutions ultérieures dans le TODO.
|
||||
|
||||
## 0.1.0-pre.075
|
||||
|
||||
- validation statique que `kb-config` reste l’unique propriétaire direct de `dotenvy` ;
|
||||
|
||||
@@ -1,8 +1,13 @@
|
||||
<!-- file: kb-core/CHANGELOG.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# CHANGELOG — kb-core
|
||||
|
||||
## 0.4.6
|
||||
|
||||
- alignement de la crate sur la version fonctionnelle bot3 `0.4.6` ;
|
||||
- clôture des tâches de migration applicables et report explicite des évolutions ultérieures dans le TODO.
|
||||
|
||||
## 0.1.0-pre.072
|
||||
|
||||
- reclassement du TODO selon les blocants avant `0.4.6`, les travaux `0.4.7`, les versions ultérieures et les dépendances conditionnelles.
|
||||
|
||||
@@ -1,8 +1,13 @@
|
||||
<!-- file: kb-lib/CHANGELOG.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# CHANGELOG — kb-lib
|
||||
|
||||
## 0.4.6
|
||||
|
||||
- alignement de la crate sur la version fonctionnelle bot3 `0.4.6` ;
|
||||
- clôture des tâches de migration applicables et report explicite des évolutions ultérieures dans le TODO.
|
||||
|
||||
## 0.1.0-pre.072
|
||||
|
||||
- reclassement du TODO selon les blocants avant `0.4.6`, les travaux `0.4.7`, les versions ultérieures et les dépendances conditionnelles.
|
||||
|
||||
@@ -1,8 +1,13 @@
|
||||
<!-- file: kb-logging/CHANGELOG.md -->
|
||||
<!-- version: 9 -->
|
||||
<!-- version: 10 -->
|
||||
|
||||
# CHANGELOG — kb-logging
|
||||
|
||||
## 0.4.6
|
||||
|
||||
- alignement de la crate sur la version fonctionnelle bot3 `0.4.6` ;
|
||||
- clôture des tâches de migration applicables et report explicite des évolutions ultérieures dans le TODO.
|
||||
|
||||
## 0.1.0-pre.073
|
||||
|
||||
- ajout du guide transversal [`docs/guides/LOGGING.md`](../docs/guides/LOGGING.md) ;
|
||||
|
||||
@@ -1,8 +1,13 @@
|
||||
<!-- file: kb-onchain-transport/CHANGELOG.md -->
|
||||
<!-- version: 7 -->
|
||||
<!-- version: 8 -->
|
||||
|
||||
# CHANGELOG — kb-onchain-transport
|
||||
|
||||
## 0.4.6
|
||||
|
||||
- alignement de la crate sur la version fonctionnelle bot3 `0.4.6` ;
|
||||
- clôture des tâches de migration applicables et report explicite des évolutions ultérieures dans le TODO.
|
||||
|
||||
## 0.1.0-pre.074
|
||||
|
||||
- clôture de la tâche documentaire préalable à `0.4.6` après publication du guide transversal RPC/backfill/WebSocket ;
|
||||
|
||||
@@ -1,8 +1,13 @@
|
||||
<!-- file: kb-pipeline-demo-scenarios/CHANGELOG.md -->
|
||||
<!-- version: 7 -->
|
||||
<!-- version: 8 -->
|
||||
|
||||
# CHANGELOG — kb-pipeline-demo-scenarios
|
||||
|
||||
## 0.4.6
|
||||
|
||||
- alignement de la crate sur la version fonctionnelle bot3 `0.4.6` ;
|
||||
- clôture des tâches de migration applicables et report explicite des évolutions ultérieures dans le TODO.
|
||||
|
||||
## 0.1.0-pre.075
|
||||
|
||||
- ajout du guide opérateur Devnet `0.4.6` distinguant les scénarios de validation des composants réutilisables ;
|
||||
|
||||
@@ -1,11 +1,16 @@
|
||||
<!-- file: kb-pipeline/CHANGELOG.md -->
|
||||
<!-- version: 7 -->
|
||||
<!-- version: 8 -->
|
||||
|
||||
# CHANGELOG — kb-pipeline
|
||||
|
||||
## 0.4.6
|
||||
|
||||
- alignement de la crate sur la version fonctionnelle bot3 `0.4.6` ;
|
||||
- clôture des tâches de migration applicables et report explicite des évolutions ultérieures dans le TODO.
|
||||
|
||||
## 0.1.0-pre.074
|
||||
|
||||
- suppression du blocant d’audit générique après production de [`V0_4_6_ALIGNMENT_AUDIT.md`](../docs/audits/V0_4_6_ALIGNMENT_AUDIT.md), aucun écart pipeline concret supplémentaire n’ayant été démontré ;
|
||||
- suppression du blocant d’audit générique après production de `V0_4_6_ALIGNMENT_AUDIT.md`, désormais archivé sous `olddocs/archivekbot3/`, aucun écart pipeline concret supplémentaire n’ayant été démontré ;
|
||||
|
||||
## 0.1.0-pre.073
|
||||
|
||||
|
||||
@@ -1,16 +1,12 @@
|
||||
<!-- file: kb-pipeline/TODO.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# TODO — kb-pipeline
|
||||
|
||||
## Bloquants avant alignement `0.4.6`
|
||||
## `0.4.7`
|
||||
|
||||
- [ ] Audit - traiter les écarts pipeline réellement démontrés par `V0_4_6_ALIGNMENT_AUDIT.md`.
|
||||
|
||||
## Entre `0.4.6` et `0.4.7`
|
||||
|
||||
- [ ] Metaplex Token Metadata - intégrer la matérialisation migrée et les étapes restantes au replay bot3.
|
||||
- [ ] Metaplex Token Metadata - ajouter l’orchestration nécessaire à l’exécuteur et aux validations de `0.4.7`.
|
||||
- [ ] Metaplex Token Metadata - intégrer l’exécution et les étapes restantes au replay bot3.
|
||||
- [ ] Metaplex Token Metadata - ajouter l’orchestration nécessaire aux préflights, postconditions et validations.
|
||||
|
||||
## Versions ultérieures
|
||||
|
||||
|
||||
@@ -1,8 +1,13 @@
|
||||
<!-- file: kb-program-ids/CHANGELOG.md -->
|
||||
<!-- version: 6 -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# CHANGELOG — kb-program-ids
|
||||
|
||||
## 0.4.6
|
||||
|
||||
- alignement de la crate sur la version fonctionnelle bot3 `0.4.6` ;
|
||||
- clôture des tâches de migration applicables et report explicite des évolutions ultérieures dans le TODO.
|
||||
|
||||
## 0.1.0-pre.073
|
||||
|
||||
- ajout de l’archive documentaire bobobot, indexée par [`olddocs/archivekbobobot/001.README.md`](../olddocs/archivekbobobot/001.README.md), comme source historique future pour les Program IDs et IDL ;
|
||||
|
||||
@@ -1,8 +1,13 @@
|
||||
<!-- file: kb-store/CHANGELOG.md -->
|
||||
<!-- version: 10 -->
|
||||
<!-- version: 11 -->
|
||||
|
||||
# CHANGELOG — kb-store
|
||||
|
||||
## 0.4.6
|
||||
|
||||
- alignement de la crate sur la version fonctionnelle bot3 `0.4.6` ;
|
||||
- clôture des tâches de migration applicables et report explicite des évolutions ultérieures dans le TODO.
|
||||
|
||||
## 0.1.0-pre.074
|
||||
|
||||
- clôture de la tâche documentaire préalable à `0.4.6` après publication du guide PostgreSQL et stockage ;
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
<!-- file: kb-store/TODO.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# TODO — kb-store
|
||||
|
||||
## Avant alignement `0.4.6`
|
||||
|
||||
## Versions ultérieures
|
||||
## Série `0.5.x`
|
||||
|
||||
- [ ] 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.
|
||||
|
||||
@@ -1,8 +1,13 @@
|
||||
<!-- file: kb-wallet/CHANGELOG.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# CHANGELOG — kb-wallet
|
||||
|
||||
## 0.4.6
|
||||
|
||||
- alignement de la crate sur la version fonctionnelle bot3 `0.4.6` ;
|
||||
- clôture des tâches de migration applicables et report explicite des évolutions ultérieures dans le TODO.
|
||||
|
||||
## 0.1.0-pre.072
|
||||
|
||||
- reclassement du TODO selon les blocants avant `0.4.6`, les travaux `0.4.7`, les versions ultérieures et les dépendances conditionnelles.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: olddocs/archivekbot3/001.README.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Archive documentaire de khadhroony-bot3
|
||||
|
||||
@@ -20,3 +20,7 @@ Les documents archivés :
|
||||
- `prompts/` : prompts utilisés pendant la migration architecturale.
|
||||
|
||||
La documentation active reste sous `docs/`. Le point d’entrée normatif reste `RULES.md`.
|
||||
|
||||
## Clôture 0.4.6
|
||||
|
||||
Les audits, guides et checklist temporaires utilisés pour clôturer la migration sont conservés sous `docs/` dans cette archive. Ils ne sont plus normatifs.
|
||||
|
||||
8
prompts/001.README.md
Normal file
8
prompts/001.README.md
Normal file
@@ -0,0 +1,8 @@
|
||||
<!-- file: prompts/001.README.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Prompts actifs
|
||||
|
||||
Ce répertoire contient uniquement les prompts nécessaires aux prochaines versions fonctionnelles. Les prompts utilisés pendant la migration bot3 sont archivés sous `olddocs/archivekbot3/prompts/`.
|
||||
|
||||
- [`027_v0_4_7_metaplex_token_metadata_completion.md`](027_v0_4_7_metaplex_token_metadata_completion.md) : reprise après `0.4.6` et achèvement de Metaplex Token Metadata.
|
||||
193
prompts/027_v0_4_7_metaplex_token_metadata_completion.md
Normal file
193
prompts/027_v0_4_7_metaplex_token_metadata_completion.md
Normal file
@@ -0,0 +1,193 @@
|
||||
<!-- file: prompts/027_v0_4_7_metaplex_token_metadata_completion.md -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Prompt de session — `0.4.7` Achèvement de Metaplex Token Metadata
|
||||
|
||||
## 1. Mission
|
||||
|
||||
Reprendre `khadhroony-bot3` après la clôture validée de `0.4.6` et achever la surface Metaplex Token Metadata partiellement développée dans bot2. Tout ce qui avait été réalisé dans bot2 a été migré dans bot3 ; la reprise doit donc partir de cette base migrée complète, sans présenter la migration comme partielle.
|
||||
|
||||
Le travail ne consiste pas à recommencer le décodeur ni les matérialisations déjà présentes. Il doit partir de l’état réel du code, établir un plan de travail fermé, puis compléter l’exécuteur, les contrats stateful, le pipeline, les scénarios réutilisables, le CLI, le desktop et les validations finales.
|
||||
|
||||
Program ID canonique :
|
||||
|
||||
```text
|
||||
metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s
|
||||
```
|
||||
|
||||
## 2. Base validée `0.4.6`
|
||||
|
||||
La base comprend :
|
||||
|
||||
- architecture bot3 consolidée en onze crates ;
|
||||
- Solana Core, SPL Memo, SPL Token classique, ATA et Token-2022 ;
|
||||
- transports HTTP/WebSocket, stockage PostgreSQL, extraction Core et replay ;
|
||||
- exécution simulation-first, confirmations, signers et postvalidation ;
|
||||
- décodeur Metaplex Token Metadata d’instructions ;
|
||||
- décodeur des comptes Metaplex avec owners, PDA, seeds, bornes et variantes historiques ;
|
||||
- matrice `test-fixtures/contract-matrices/METAPLEX_TOKEN_METADATA_MATRIX.json` ;
|
||||
- matérialisation metadata déjà substantielle ;
|
||||
- coexistence explicite avec les metadata incorporées de Token-2022 ;
|
||||
- workspace, matrices, registres et bindings TS-RS validés.
|
||||
|
||||
Exception conservée : le registre ElGamal n’est pas déclaré validé réellement sur réseau. Cette exception ne doit pas être mêlée au jalon Metaplex.
|
||||
|
||||
## 3. Lectures obligatoires
|
||||
|
||||
1. `RULES.md`, `README.md`, `ROADMAP.md`, `CHANGELOG.md` et ce prompt ;
|
||||
2. `kb-lib/README.md`, `kb-lib/USAGE.md`, `kb-lib/TODO.md` ;
|
||||
3. `kb-pipeline/README.md`, `kb-pipeline-demo-scenarios/README.md` et `kb-app-demo-desktop/README.md` ;
|
||||
4. la matrice Metaplex active et les tests existants ;
|
||||
5. l’IDL archivée `idls/metadata.metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s.metaplex_token_metadata.V1_14_0.from_github_mpl-token-metadata.json` ;
|
||||
6. le prompt historique `olddocs/archivekbot2/prompts/026_v0_4_7_metaplex_token_metadata.md`, uniquement comme source historique à confronter au code bot3 actuel.
|
||||
|
||||
## 4. Première prerelease — plan de travail et brainstorming
|
||||
|
||||
La première prerelease de `0.4.7` est consacrée exclusivement à la préparation du développement. Elle ne doit pas introduire l’exécuteur, le pipeline Metaplex ou les démonstrations finales.
|
||||
|
||||
Elle doit :
|
||||
|
||||
- relire le code, les matrices, les tests, les documents actifs et les sources officielles retenues ;
|
||||
- inventorier les instructions et comptes déjà décodés ;
|
||||
- inventorier les projections metadata, admin, lifecycle et risk/compliance déjà présentes ;
|
||||
- identifier les opérations actuelles, historiques decode-only et non supportées ;
|
||||
- distinguer les travaux certains, les choix d’architecture et les questions encore ouvertes ;
|
||||
- proposer plusieurs options lorsque des choix structurants existent ;
|
||||
- produire un plan de travail ordonné par prerelease, avec dépendances, critères d’acceptation et validations prévues ;
|
||||
- établir une liste fermée des manques réels ;
|
||||
- confirmer explicitement qu’aucune capacité déjà couverte ne sera réimplémentée.
|
||||
|
||||
Cette première prerelease doit aboutir à un plan accepté avant le commencement du développement fonctionnel.
|
||||
|
||||
## 5. Frontière fonctionnelle
|
||||
|
||||
Metaplex Token Metadata reste distinct de :
|
||||
|
||||
- metadata incorporées de Token-2022 ;
|
||||
- SPL Token Metadata, prévu en `0.4.8` ;
|
||||
- Metaplex Core ;
|
||||
- JSON off-chain référencé par URI.
|
||||
|
||||
Le fetch HTTP/IPFS/Arweave et la création éventuelle de `kb-offchain-transport` sont hors périmètre de `0.4.7`. Cette décision sera étudiée en `0.4.8` avec SPL Token Metadata.
|
||||
|
||||
## 6. Matérialisation
|
||||
|
||||
Auditer les projections existantes et compléter uniquement les faits stables manquants :
|
||||
|
||||
- metadata : nom, symbole, URI, seller fee, créateurs, collection, uses, token standard, mutabilité et programmable config ;
|
||||
- admin : update authority, collection authority, delegates et changements d’autorité ;
|
||||
- lifecycle : création, mise à jour, vérification, édition, burn, lock/unlock et transitions prouvées ;
|
||||
- risk/compliance : royalties, mutabilité, créateurs non vérifiés, rule sets et délégations sensibles.
|
||||
|
||||
Chaque fait doit avoir un propriétaire unique. Ne jamais fusionner silencieusement metadata Metaplex et metadata Token-2022.
|
||||
|
||||
## 7. Exécution
|
||||
|
||||
Implémenter dans `kb-lib` :
|
||||
|
||||
- intents typés ;
|
||||
- builders validés contre les interfaces officielles ;
|
||||
- liste exacte des signers et comptes ;
|
||||
- coûts et plafonds de dépense ;
|
||||
- dry-run par défaut et simulation obligatoire ;
|
||||
- confirmation opérateur dédiée pour burn, changement d’autorité, verify/unverify, delegate/revoke, lock/unlock ;
|
||||
- classification explicite des opérations historiques decode-only.
|
||||
|
||||
## 8. Préflight et postconditions
|
||||
|
||||
Vérifier selon l’opération :
|
||||
|
||||
- owner et Program ID ;
|
||||
- PDA et seeds ;
|
||||
- mint, metadata, edition, token account, collection et authority ;
|
||||
- état de mutabilité, vérification, délégation, token standard et programmable config ;
|
||||
- cohérence des rule sets et comptes d’autorisation ;
|
||||
- postconditions stateful après soumission.
|
||||
|
||||
Tout écart doit échouer avant signature ou être classé explicitement non applicable.
|
||||
|
||||
## 9. Pipeline
|
||||
|
||||
Intégrer dans `kb-pipeline` :
|
||||
|
||||
- lectures stateful bornées ;
|
||||
- préparation et orchestration d’exécution ;
|
||||
- corrélation des comptes Metaplex ;
|
||||
- postvalidation ;
|
||||
- insertion canonique, extraction Core, replay et matérialisation idempotente ;
|
||||
- diagnostics stables et résultats exploitables par les scénarios.
|
||||
|
||||
## 10. Scénarios et démonstrations
|
||||
|
||||
Ajouter dans `kb-pipeline-demo-scenarios` :
|
||||
|
||||
- scénarios simulation-only par défaut ;
|
||||
- CLI pour les opérations retenues ;
|
||||
- fixtures synthétiques et, si possible, réseau ;
|
||||
- résultats structurés et preuves de postcondition.
|
||||
|
||||
Ajouter dans `kb-app-demo-desktop` uniquement les adaptateurs Tauri et panneaux nécessaires. La logique fonctionnelle doit rester dans les crates réutilisables.
|
||||
|
||||
## 11. Corpus et validations
|
||||
|
||||
Couvrir au minimum :
|
||||
|
||||
- NFT, SFT, token fongible, collection et programmable NFT ;
|
||||
- outer et CPI ;
|
||||
- transactions réussies et échouées ;
|
||||
- mauvais Program ID, owner, PDA, comptes, payload tronqué, suffixe et discriminant inconnu ;
|
||||
- conflits entre metadata Metaplex et metadata Token-2022 ;
|
||||
- replay PostgreSQL idempotent ;
|
||||
- simulation, confirmation, envoi et postconditions pour les opérations exécutables.
|
||||
|
||||
Ne pas déclarer une validation réseau si les fixtures ou préconditions ne sont pas disponibles.
|
||||
|
||||
## 12. Documentation pendant le développement
|
||||
|
||||
Mettre à jour au fil des prereleases uniquement les documents nécessaires pour refléter les décisions et contrats réellement introduits :
|
||||
|
||||
- les quatre documents des crates modifiées ;
|
||||
- la matrice Metaplex active ;
|
||||
- la documentation des opérations supportées, decode-only et non supportées ;
|
||||
- les rapports de validation propres aux capacités effectivement testées.
|
||||
|
||||
La mise à jour générale de clôture appartient à la dernière prerelease.
|
||||
|
||||
## 13. Dernière prerelease — clôture de `0.4.7`
|
||||
|
||||
La dernière prerelease doit être réservée à la clôture de la version. Elle ne doit pas introduire une nouvelle surface fonctionnelle majeure.
|
||||
|
||||
Elle doit obligatoirement :
|
||||
|
||||
- exécuter les tests finaux, les audits de conformité et les validations applicatives nécessaires ;
|
||||
- vérifier l’alignement entre code, matrices, registres, bindings TS-RS et documentation ;
|
||||
- mettre à jour définitivement `README.md`, `ROADMAP.md` et `CHANGELOG.md` ;
|
||||
- mettre à jour les `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md` des crates concernées ;
|
||||
- retirer des TODO les tâches terminées et transférer les travaux reportés vers la version correcte ;
|
||||
- archiver les prompts, plans, rapports ou documents de travail devenus historiques ;
|
||||
- supprimer les outils temporaires, fichiers de validation et références obsolètes qui ne doivent pas rester dans la version publiée ;
|
||||
- préparer le prompt complet de la session `0.4.8 — SPL Token Metadata et décision off-chain metadata` ;
|
||||
- vérifier que ce prompt commence lui aussi par une prerelease de planification et se termine par une prerelease de clôture ;
|
||||
- préparer la livraison finale de `0.4.7` selon les règles du workspace.
|
||||
|
||||
## 14. Validation finale
|
||||
|
||||
Exécuter :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test --workspace
|
||||
```
|
||||
|
||||
Si le desktop est modifié, valider avec :
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
## 15. Livraisons
|
||||
|
||||
Après l’archive complète de départ, livrer uniquement des ZIP delta contenant `delta.md`, sans SHA-256. Les correctifs d’une même prerelease utilisent `-delta-fix-XXX.zip`, avec une numérotation recommençant à `fix-001` pour chaque nouvelle prerelease.
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env python3
|
||||
# file: scripts/audit_khadhroony_workspace_rules.py
|
||||
# version: 12
|
||||
# version: 13
|
||||
|
||||
"""Audit mechanically verifiable rules specific to khadhroony-bot3."""
|
||||
|
||||
@@ -210,7 +210,7 @@ def audit_kb_lib_symbol_prefixes(root: pathlib.Path) -> list[Violation]:
|
||||
|
||||
|
||||
def audit_reserved_decoder_scaffolds(root: pathlib.Path) -> list[Violation]:
|
||||
"""Reject temporary decoder migration markers and incomplete reserved decoders."""
|
||||
"""Reject incomplete reserved decoder contracts."""
|
||||
|
||||
violations: list[Violation] = []
|
||||
decoder_root = root / "kb-lib/src/decoder"
|
||||
@@ -281,7 +281,7 @@ def audit_reserved_decoder_scaffolds(root: pathlib.Path) -> list[Violation]:
|
||||
|
||||
|
||||
def audit_reserved_materializer_scaffolds(root: pathlib.Path) -> list[Violation]:
|
||||
"""Reject temporary materializer markers and incomplete reserved materializers."""
|
||||
"""Reject incomplete reserved materializer contracts."""
|
||||
|
||||
violations: list[Violation] = []
|
||||
materializer_root = root / "kb-lib/src/materializer"
|
||||
@@ -362,7 +362,7 @@ def audit_reserved_materializer_scaffolds(root: pathlib.Path) -> list[Violation]
|
||||
|
||||
|
||||
def audit_reserved_executor_scaffolds(root: pathlib.Path) -> list[Violation]:
|
||||
"""Reject temporary executor markers and incomplete reserved executors."""
|
||||
"""Reject incomplete reserved executor contracts."""
|
||||
|
||||
violations: list[Violation] = []
|
||||
executor_root = root / "kb-lib/src/executor"
|
||||
|
||||
@@ -1,156 +0,0 @@
|
||||
#!/usr/bin/env python3
|
||||
# file: scripts/audit_pre_0_4_6_static_contracts.py
|
||||
# version: 4
|
||||
|
||||
"""Audit static contracts that must remain true before the 0.4.6 alignment."""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import argparse
|
||||
import pathlib
|
||||
import re
|
||||
import sys
|
||||
import tomllib
|
||||
|
||||
def fail(code: str, message: str) -> None:
|
||||
"""Print one violation."""
|
||||
|
||||
print(f"{code}: {message}")
|
||||
|
||||
def frontend_invokes(root: pathlib.Path) -> set[str]:
|
||||
"""Return literal Tauri commands invoked by the frontend."""
|
||||
|
||||
commands: set[str] = set()
|
||||
pattern = re.compile(r"invoke(?:<[^>]+>)?\(\s*[\"']([A-Za-z0-9_]+)[\"']")
|
||||
for suffix in ("*.ts", "*.html"):
|
||||
for path in (root / "kb-app-demo-desktop" / "frontend").rglob(suffix):
|
||||
commands.update(pattern.findall(path.read_text(encoding="utf-8")))
|
||||
return commands
|
||||
|
||||
def registered_commands(root: pathlib.Path) -> set[str]:
|
||||
"""Return commands registered in generate_handler."""
|
||||
|
||||
path = root / "kb-app-demo-desktop" / "src" / "tauri.rs"
|
||||
text = path.read_text(encoding="utf-8")
|
||||
match = re.search(r"generate_handler!\[(.*?)\]\);", text, re.DOTALL)
|
||||
if match is None:
|
||||
return set()
|
||||
return set(re.findall(r"([A-Za-z_][A-Za-z0-9_]*)[ \t]*,", match.group(1)))
|
||||
|
||||
def main() -> int:
|
||||
"""Run the pre-0.4.6 static audit."""
|
||||
|
||||
parser = argparse.ArgumentParser()
|
||||
parser.add_argument("--root", default=".")
|
||||
parser.add_argument("--report-only", action="store_true")
|
||||
arguments = parser.parse_args()
|
||||
root = pathlib.Path(arguments.root).resolve()
|
||||
violations = 0
|
||||
|
||||
dotenv_crates: list[str] = []
|
||||
for cargo in sorted(root.glob("*/Cargo.toml")):
|
||||
data = tomllib.loads(cargo.read_text(encoding="utf-8"))
|
||||
dependencies = data.get("dependencies", {})
|
||||
if "dotenvy" in dependencies:
|
||||
dotenv_crates.append(cargo.parent.name)
|
||||
if dotenv_crates != ["kb-config"]:
|
||||
fail("ALIGN001", f"dotenvy must be owned only by kb-config, found {dotenv_crates}")
|
||||
violations += 1
|
||||
|
||||
missing = sorted(frontend_invokes(root) - registered_commands(root))
|
||||
if missing:
|
||||
fail("ALIGN002", f"frontend commands missing from Tauri registration: {missing}")
|
||||
violations += 1
|
||||
|
||||
tauri_path = root / "kb-app-demo-desktop" / "src" / "tauri.rs"
|
||||
tauri_text = tauri_path.read_text(encoding="utf-8")
|
||||
forbidden_tauri_dependencies = (
|
||||
"kb_pipeline::",
|
||||
"kb_pipeline_demo_scenarios::",
|
||||
"kb_store::",
|
||||
)
|
||||
direct_dependencies = [
|
||||
dependency for dependency in forbidden_tauri_dependencies if dependency in tauri_text
|
||||
]
|
||||
if direct_dependencies:
|
||||
fail(
|
||||
"ALIGN009",
|
||||
f"tauri.rs must remain a thin IPC/runtime layer, direct domain dependencies: {direct_dependencies}",
|
||||
)
|
||||
violations += 1
|
||||
if 'window.label() != "main"' not in tauri_text or "disconnect_demo_ws_app_state" not in tauri_text:
|
||||
fail("ALIGN003", "global WebSocket shutdown must be tied to main-window destruction")
|
||||
violations += 1
|
||||
if re.search(r'window\.label\(\)\s*==\s*"demo_ws".*disconnect_demo_ws', tauri_text, re.DOTALL):
|
||||
fail("ALIGN004", "demo_ws window destruction must not disconnect the application session")
|
||||
violations += 1
|
||||
|
||||
app_state = (root / "kb-app-demo-desktop" / "src" / "app_state.rs").read_text(encoding="utf-8")
|
||||
if "demo_ws_session" not in app_state:
|
||||
fail("ALIGN005", "AppState must own the persistent demo WebSocket session")
|
||||
violations += 1
|
||||
|
||||
forbidden_crates = (
|
||||
"kb_decoder_",
|
||||
"kb_executor_",
|
||||
"kb_materializer_",
|
||||
"kb_store_core",
|
||||
"kb_store_pg",
|
||||
)
|
||||
for path in sorted(root.rglob("*.rs")):
|
||||
if any(part in {"olddocs", "target"} for part in path.parts):
|
||||
continue
|
||||
text = path.read_text(encoding="utf-8")
|
||||
for name in forbidden_crates:
|
||||
if name in text:
|
||||
fail("ALIGN006", f"legacy crate identity {name!r} found in {path.relative_to(root)}")
|
||||
violations += 1
|
||||
|
||||
required_docs = ("README.md", "TODO.md", "USAGE.md", "CHANGELOG.md")
|
||||
for cargo in sorted(root.glob("*/Cargo.toml")):
|
||||
for document in required_docs:
|
||||
if not (cargo.parent / document).is_file():
|
||||
fail("ALIGN007", f"missing {document} in {cargo.parent.name}")
|
||||
violations += 1
|
||||
|
||||
matrix = root / "test-fixtures" / "contract-matrices" / "OPERATION_NAMING_MATRIX.json"
|
||||
if not matrix.is_file():
|
||||
fail("ALIGN008", "operation naming matrix is missing")
|
||||
violations += 1
|
||||
|
||||
tauri_source = (root / "kb-app-demo-desktop/src/tauri.rs").read_text(encoding="utf-8")
|
||||
command_files = []
|
||||
for command_path in (root / "kb-app-demo-desktop/src").glob("*.rs"):
|
||||
command_source = command_path.read_text(encoding="utf-8")
|
||||
if "#[tauri::command]" in command_source:
|
||||
command_files.append(command_path.name)
|
||||
if command_files != ["tauri.rs"]:
|
||||
fail("ALIGN009", f"#[tauri::command] must exist only in tauri.rs, found: {command_files}")
|
||||
violations += 1
|
||||
forbidden_files = [
|
||||
"tauri_backfill.rs",
|
||||
"tauri_core_extraction.rs",
|
||||
"tauri_decode_replay.rs",
|
||||
"tauri_execution.rs",
|
||||
"tauri_general_commands.rs",
|
||||
"tauri_http.rs",
|
||||
"tauri_sql.rs",
|
||||
"tauri_support.rs",
|
||||
"tauri_ws.rs",
|
||||
]
|
||||
for forbidden in forbidden_files:
|
||||
if (root / "kb-app-demo-desktop/src" / forbidden).exists():
|
||||
fail("ALIGN010", f"obsolete Tauri adapter module still exists: {forbidden}")
|
||||
violations += 1
|
||||
if "return crate::demo_decode_replay_options(state);" not in tauri_source:
|
||||
fail("ALIGN011", "tauri.rs must delegate demo_decode_replay_options through the crate façade")
|
||||
violations += 1
|
||||
if violations == 0:
|
||||
print("Pre-0.4.6 static contract audit: clean")
|
||||
return 0
|
||||
|
||||
print(f"Pre-0.4.6 static contract audit: {violations} violation(s)")
|
||||
return 0 if arguments.report_only else 1
|
||||
|
||||
if __name__ == "__main__":
|
||||
raise SystemExit(main())
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env python3
|
||||
# file: scripts/audit_rust_export_completeness.py
|
||||
# version: 3
|
||||
# version: 4
|
||||
|
||||
"""Audit missing crate-root exports and replaceable long internal paths.
|
||||
|
||||
@@ -131,10 +131,7 @@ def audit_crate(workspace: pathlib.Path, crate: pathlib.Path) -> list[Candidate]
|
||||
for declaration in declaration_candidates(crate, path):
|
||||
key = (declaration.module, declaration.name)
|
||||
declarations[key] = declaration
|
||||
is_migration_scaffold = declaration.name.endswith(
|
||||
("_LEGACY_CRATE", "_MIGRATION_BOUNDARIES", "_MIGRATION_STATUS")
|
||||
)
|
||||
if key not in exports and not is_migration_scaffold:
|
||||
if key not in exports:
|
||||
relative = path.relative_to(workspace).as_posix()
|
||||
candidates.append(
|
||||
Candidate(
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env python3
|
||||
# file: scripts/audit_rust_general_rules.py
|
||||
# version: 8
|
||||
# version: 9
|
||||
|
||||
"""Audit mechanically verifiable Rust rules shared by all Rust projects."""
|
||||
|
||||
@@ -32,9 +32,6 @@ def rust_files(root: pathlib.Path) -> list[pathlib.Path]:
|
||||
if "target" not in path.parts
|
||||
and ".git" not in path.parts
|
||||
and "mnt" not in path.relative_to(root).parts
|
||||
and path.relative_to(root).parts[:2]
|
||||
!= ("migration", "khadhroony-bot2-reference")
|
||||
and not any(part.startswith("pre035_") for part in path.relative_to(root).parts)
|
||||
)
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env python3
|
||||
# file: scripts/audit_rust_workspace_rules.py
|
||||
# version: 4
|
||||
# version: 5
|
||||
|
||||
"""Run the general, export-completeness and khadhroony workspace audits."""
|
||||
|
||||
@@ -22,7 +22,6 @@ def main() -> int:
|
||||
["python3", str(script_dir / "audit_rust_general_rules.py"), "--root", arguments.root],
|
||||
["python3", str(script_dir / "audit_rust_export_completeness.py"), "--root", arguments.root],
|
||||
["python3", str(script_dir / "audit_khadhroony_workspace_rules.py"), "--root", arguments.root],
|
||||
["python3", str(script_dir / "audit_pre_0_4_6_static_contracts.py"), "--root", arguments.root],
|
||||
]
|
||||
if arguments.report_only:
|
||||
for command in commands:
|
||||
|
||||
Reference in New Issue
Block a user