v0.1.0-pre.064-065
This commit is contained in:
70
docs/decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md
Normal file
70
docs/decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md
Normal file
@@ -0,0 +1,70 @@
|
||||
<!-- file: docs/decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Politique de sélection des archives documentaires
|
||||
|
||||
## 1. Objet
|
||||
|
||||
Cette politique définit les fichiers historiques qui peuvent être copiés depuis l’archive complète de `khadhroony-bot2` vers `olddocs/archivekbot2/`.
|
||||
|
||||
La sélection repose sur la fonction documentaire du fichier, et non sur son extension ni uniquement sur son emplacement.
|
||||
|
||||
## 2. Principe général
|
||||
|
||||
`olddocs/archivekbot2/` est une archive documentaire historique et non une copie partielle du workspace exécutable.
|
||||
|
||||
L’archive complète de bot2 reste la référence pour le code source, les fixtures, les configurations d’exécution et les artefacts nécessaires à la compilation ou aux tests.
|
||||
|
||||
## 3. Fichiers à conserver
|
||||
|
||||
Les catégories suivantes peuvent être conservées lorsqu’elles présentent une valeur historique, normative, architecturale ou décisionnelle :
|
||||
|
||||
- documents Markdown racine, sous `docs/`, sous `prompts/` et dans les anciennes crates ;
|
||||
- changelogs, roadmaps, règles, audits, plans, rapports, guides et décisions ;
|
||||
- matrices JSON décrivant une couverture, un contrat, une validation ou un inventaire ;
|
||||
- IDL archivées servant de références pour la conception manuelle des futurs décodeurs, exécuteurs, matérialisateurs, matrices et tests ;
|
||||
- schémas publics décrivant formellement un contrat de configuration ;
|
||||
- exemples de configuration destinés aux utilisateurs ou aux opérateurs ;
|
||||
- autres fichiers non exécutables dont la valeur documentaire est explicitement démontrée.
|
||||
|
||||
## 4. Fichiers à exclure
|
||||
|
||||
Les catégories suivantes ne doivent pas être copiées dans l’archive documentaire :
|
||||
|
||||
- code source et fichiers internes placés sous `src/`, même lorsqu’ils utilisent une extension documentaire, sauf décision explicite motivée ;
|
||||
- fixtures de tests, snapshots et réponses RPC enregistrées ;
|
||||
- manifests et configurations nécessaires au build ou au lancement de l’ancienne application ;
|
||||
- fichiers Tauri, npm, TypeScript et capabilities servant à l’exécution ;
|
||||
- bases de données, clés, preuves, données privées et fichiers temporaires ;
|
||||
- artefacts générés ou reconstructibles sans valeur documentaire autonome.
|
||||
|
||||
## 5. Cas explicitement conservés
|
||||
|
||||
Les fichiers suivants sont conservés car leur fonction est documentaire :
|
||||
|
||||
```text
|
||||
config/example.config.json
|
||||
config/schema.config.json
|
||||
docs/*_MATRIX.json
|
||||
idls/*.json
|
||||
```
|
||||
|
||||
`example.config.json` illustre la configuration utilisateur historique complète. `schema.config.json` formalise le contrat de cette configuration. Les matrices documentent les périmètres techniques et les validations. Les IDL sont des références archivées et ne sont pas chargées dynamiquement par le code de production.
|
||||
|
||||
## 6. Cas explicitement exclus
|
||||
|
||||
Les fichiers suivants sont exclus car ils relèvent de l’exécution ou des tests :
|
||||
|
||||
```text
|
||||
kb_app_demo/capabilities/default.json
|
||||
kb_app_demo/package.json
|
||||
kb_app_demo/tauri.conf.json
|
||||
kb_app_demo/tsconfig.json
|
||||
kb_rpc/tests/fixtures/*.json
|
||||
kb_store_core/src/**
|
||||
kb_store_pg/src/**
|
||||
```
|
||||
|
||||
## 7. Évolution de l’archive
|
||||
|
||||
Tout ajout futur à `olddocs/archivekbot2/` doit être évalué avec cette politique. En cas d’ambiguïté, le fichier n’est pas copié tant que sa valeur documentaire autonome n’est pas démontrée.
|
||||
62
docs/decisions/WINCODE_COMPATIBILITY_POLICY.md
Normal file
62
docs/decisions/WINCODE_COMPATIBILITY_POLICY.md
Normal file
@@ -0,0 +1,62 @@
|
||||
<!-- file: docs/decisions/WINCODE_COMPATIBILITY_POLICY.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Politique de compatibilité `wincode`
|
||||
|
||||
## 1. Objet
|
||||
|
||||
Ce document explique pourquoi le workspace `khadhroony-bot3` contraint actuellement `wincode` à la famille `0.5.x` et pourquoi le contrôle du `Cargo.lock` local existe.
|
||||
|
||||
Cette contrainte est un garde-fou de compatibilité de dépendances. Elle ne constitue pas un écart fonctionnel à réexaminer dans chaque prompt ou chaque livraison documentaire.
|
||||
|
||||
## 2. Incident à l’origine de la règle
|
||||
|
||||
Pendant la migration vers bot3, l’apparition de `wincode 0.6.0` dans la résolution de dépendances a créé une incompatibilité avec des crates Solana ou interfaces encore fondées sur les traits de `wincode 0.5.x`.
|
||||
|
||||
Les familles `wincode 0.5` et `wincode 0.6` ne sont pas interchangeables au niveau de leurs traits et types. Une résolution transitive non maîtrisée peut donc produire des erreurs de compilation même lorsque les noms des APIs paraissent identiques.
|
||||
|
||||
## 3. Décision actuelle
|
||||
|
||||
Tant que les interfaces Solana consommées par le workspace utilisent la famille `0.5.x` :
|
||||
|
||||
```text
|
||||
wincode = "^0.5"
|
||||
```
|
||||
|
||||
La résolution locale attendue est :
|
||||
|
||||
```text
|
||||
wincode 0.5.5
|
||||
solana-wincode-varint 1.0.0
|
||||
```
|
||||
|
||||
Le script `scripts/audit_khadhroony_workspace_rules.py` vérifie :
|
||||
|
||||
1. la contrainte `^0.5` dans le catalogue de dépendances workspace ;
|
||||
2. la présence du `Cargo.lock` local ;
|
||||
3. l’absence d’une seconde famille `wincode` incompatible ;
|
||||
4. les versions résolues attendues.
|
||||
|
||||
## 4. Rôle du `Cargo.lock`
|
||||
|
||||
Le `Cargo.lock` est nécessaire à ce contrôle parce que `Cargo.toml` décrit une plage de versions, tandis que le lockfile démontre la résolution réellement utilisée par le workspace.
|
||||
|
||||
Les archives de livraison peuvent ne pas contenir ce fichier selon leur convention d’empaquetage. Dans ce cas :
|
||||
|
||||
- l’absence du lockfile dans l’archive n’est pas un défaut fonctionnel du projet ;
|
||||
- le contrôle complet doit être exécuté dans le workspace local réel avec son `Cargo.lock` ;
|
||||
- la livraison ne doit pas répéter cette limite comme un nouvel écart documentaire à chaque session ;
|
||||
- le lockfile peut être fourni ponctuellement à la session lorsqu’une exécution de l’audit est nécessaire.
|
||||
|
||||
## 5. Évolution future
|
||||
|
||||
Le passage à `wincode 0.6+` ne doit pas être effectué par simple mise à jour de version. Il exige :
|
||||
|
||||
- l’inventaire des crates directes et transitives utilisant `wincode` ;
|
||||
- la vérification des versions d’interfaces Solana compatibles ;
|
||||
- l’absence de familles de traits concurrentes ;
|
||||
- la compilation de l’ensemble du workspace ;
|
||||
- les tests des décodeurs et parseurs concernés ;
|
||||
- la mise à jour de la règle et du script d’audit dans le même changement.
|
||||
|
||||
Jusqu’à cette migration explicitement validée, `wincode 0.5.5` reste la résolution normative du workspace.
|
||||
Reference in New Issue
Block a user