v0.5.1-pre.008
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/RULES_SPECIFIC_KHADHROONY.md -->
|
||||
<!-- version: 18 -->
|
||||
<!-- version: 21 -->
|
||||
|
||||
# Règles spécifiques à `khadhroony-bot3`
|
||||
|
||||
@@ -12,7 +12,7 @@ Toute divergence avec une règle générale doit être explicitement documentée
|
||||
- Tous les noms de fichiers et de répertoires doivent être écrits en anglais.
|
||||
- Les noms de fichiers et de répertoires ne doivent contenir aucun accent, espace ou caractère spécial inutile.
|
||||
- Les noms internes doivent utiliser le format `snake_case` lorsque c'est applicable.
|
||||
- Les packages Rust utilisent le préfixe `kb-` ; leur identifiant Rust correspondant utilise automatiquement `kb_`.
|
||||
- Les bibliothèques généralistes Khadhroony Solana utilisent le préfixe Cargo `ks-` et l’identifiant Rust `ks_`; les applications et futures crates réellement propres au domaine Bot utilisent `kb-` / `kb_`.
|
||||
- Les décodeurs, matérialisateurs et exécuteurs sont des modules de `ks-lib`, pas des crates séparées.
|
||||
- Le crate de journalisation s'appelle `ks-logging`.
|
||||
- Les réexports sont regroupés par visibilité : le bloc `pub use` précède le bloc séparé `pub(crate) use`, sans ligne vide interne à un bloc ; leur ordre naturel doit rester compatible avec `cargo fmt`.
|
||||
@@ -26,6 +26,8 @@ Toute divergence avec une règle générale doit être explicitement documentée
|
||||
- Les types Rust exportés vers TypeScript doivent utiliser des noms stables et explicites.
|
||||
- Les bindings générés doivent être produits dans un dossier dédié, généralement `../frontend/ts/bindings` ou `#[ts(export, export_to = "../frontend/ts/bindings/MyStruct.ts")]`.
|
||||
- Les types purement internes au backend ne doivent pas être exportés vers TypeScript par défaut.
|
||||
- Dans l’état courant, les crates généralistes `ks-*` ne possèdent ni dépendance `ts-rs`, ni dérivation/export TS-RS, ni dossier de bindings générés. Une exception future exige un contrat TypeScript générique indépendant de Tauri, explicitement documenté et ajouté à l’audit workspace.
|
||||
- Les types source/runtime de `ks-config` susceptibles de contenir des secrets ou valeurs internes ne dérivent ni `serde::Serialize` ni `Debug`. Une surface publique ou diagnostic est construite champ par champ dans l’application propriétaire ; il est interdit de sérialiser un runtime complet puis de le redacter a posteriori.
|
||||
- Corriger le type Rust/TS-rs source puis régénérer les bindings ; ne pas considérer une modification manuelle isolée d’un fichier généré comme un correctif durable.
|
||||
- `kb-app-demo-desktop/src/tauri.rs` contient les attributs `#[tauri::command]`, l’enregistrement des commandes et des wrappers privés minces ; la logique complète doit vivre dans le module fonctionnel correspondant sous une fonction `pub(crate)` testable.
|
||||
- Un wrapper Tauri ne doit effectuer que l’adaptation des handles/states/arguments, l’appel de la fonction de module et le retour du résultat ; toute validation métier, orchestration ou construction de payload doit rester hors de `tauri.rs`.
|
||||
@@ -247,8 +249,8 @@ Aucun renommage massif de modules n'est autorisé sans étape de contrôle dédi
|
||||
- Les endpoints WebSocket doivent sélectionner une classe de defaults nommée ; leurs timeouts, capacités et politique `auto_reconnect` peuvent être remplacés explicitement au niveau de l'endpoint.
|
||||
- Les autorisations `*_send_enabled` appartiennent à la politique d'exécution, pas au contrat d'identité/stockage wallet.
|
||||
- Les schémas JSON actifs sont conservés exclusivement sous `config/schemas/`. Les documents source spécialisés possèdent chacun leur schéma ; `resolved.app.config.schema.json` décrit uniquement le contrat runtime transitoire reconstruit par `ks-config`.
|
||||
- Les exemples conformes restent sous `config/` avec un nom distinct des fichiers runtime. Les fixtures d'un contrat runtime résolu appartiennent à `test-fixtures/` et ne doivent pas être chargées en production.
|
||||
- Les fichiers historiques `config/app.config.json`, `config/example.app.config.json`, `config/schemas/app.config.schema.json`, `config/example.config.json`, `config/schema.config.json` et `config/ks-pipeline-demo-scenarios.default.config.json` sont interdits dans l'état courant.
|
||||
- Les exemples conformes résident exclusivement sous `config/exemples/` avec un nom distinct des fichiers runtime. Les fixtures d'un contrat runtime résolu appartiennent à `test-fixtures/` et ne doivent pas être chargées en production.
|
||||
- Les fichiers historiques `config/app.config.json`, `config/example.app.config.json`, `config/schemas/app.config.schema.json`, `config/example.config.json`, les fichiers `config/example.*.config.json` hors `config/exemples/`, `config/schema.config.json` et `config/ks-pipeline-demo-scenarios.default.config.json` sont interdits dans l'état courant.
|
||||
- Le chemin de composition desktop peut être remplacé par `KB_APP_DEMO_DESKTOP_CONFIG_PATH`. `KS_DEVNET_CONFIG_PATH` est uniquement un override facultatif vers une composition explicite pour les scénarios Devnet ; sans cet override, les scénarios utilisent les defaults partagés. `KS_LOGGING_CONFIG_PATH` reste un override explicite du document logging.
|
||||
- Les fichiers JSON de configuration ne doivent pas contenir de commentaires.
|
||||
- Les secrets ne doivent pas être écrits en clair dans le dépôt.
|
||||
@@ -256,7 +258,13 @@ Aucun renommage massif de modules n'est autorisé sans étape de contrôle dédi
|
||||
- Les variables possédées par les composants généralistes `ks-*` utilisent obligatoirement `KS_SECRET_*`, `KS_PUBLIC_*` ou `KS_*` ; les variables réellement spécifiques à `kb-app-demo-desktop` ou à de futures crates `kb-*` utilisent `KB_SECRET_*`, `KB_PUBLIC_*` ou `KB_*`.
|
||||
- Le namespace est déterminé par le propriétaire fonctionnel du contrat et non par son consommateur.
|
||||
- Les sous-préfixes `SECRET` sont toujours non exposables ; les sous-préfixes `PUBLIC` ne sont exposables que par une surface explicitement autorisée ; les autres variables du domaine sont internes.
|
||||
- Les bindings TS-RS sont prioritairement une frontière d'application Tauri. Une crate `ks-*` ne conserve une dérivation/export TypeScript que si le type constitue un contrat externe générique explicitement justifié ; sinon l'application définit un DTO/wrapper dédié.
|
||||
- La sensibilité d’une valeur composée suit `Secret > Internal > Public` : une URL, un DSN ou toute autre chaîne incorporant un placeholder `KS_SECRET_*`/`KB_SECRET_*` hérite de la sensibilité `Secret`, quel que soit le nom du champ final.
|
||||
- Une valeur `Secret` ne doit jamais apparaître en clair dans une sérialisation, un `Debug`, une erreur, un log, un diagnostic, un payload Tauri ou l’UI. Une valeur interne n’apparaît que dans un diagnostic explicitement borné et sémantiquement autorisé.
|
||||
- La section `application` d’une composition est opaque pour `ks-config`; le binaire propriétaire définit et valide son propre schéma sous `config/schemas/` avant usage.
|
||||
- Les bindings TS-RS sont une frontière d'application Tauri. Une crate `ks-*` ne conserve une dérivation/export TypeScript que si le type constitue un contrat externe générique explicitement justifié et audité ; sinon l'application définit un DTO/wrapper dédié.
|
||||
- Une commande Tauri ne retourne jamais directement un contrat `ks-*` susceptible de contenir des valeurs runtime ; elle retourne un DTO appartenant à l’application et construit explicitement la projection autorisée.
|
||||
- Les snapshots/runtime transport contenant une URL résolue restent backend-only : ils ne sont pas sérialisables directement, leur `Debug` est sanitisé, les DTO Tauri ne contiennent pas `endpoint_url`, et les erreurs/logs de transport ne recopient ni corps HTTP non-success ni message JSON-RPC distant susceptible de réinjecter un credential.
|
||||
- Les chemins dérivés du stockage wallet sont internes ; un payload fonctionnel Tauri ne transporte pas un chemin de fixture. Seule une surface de diagnostic explicitement bornée peut exposer un chemin interne autorisé.
|
||||
|
||||
## Ordre de développement cible
|
||||
|
||||
|
||||
Reference in New Issue
Block a user