134 lines
5.1 KiB
Markdown
134 lines
5.1 KiB
Markdown
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
|
|
<!-- version: 2 -->
|
|
|
|
# Matrice de validation Knowledge
|
|
|
|
## Principe
|
|
|
|
La gate opérateur sélectionne les preuves nécessaires au scope réellement modifié. Une commande n'est pas exécutée uniquement pour augmenter le nombre de checks.
|
|
|
|
La prévalidation de génération ne vaut pas preuve opérateur.
|
|
|
|
## Fondation documentaire
|
|
|
|
Pour une tranche limitée à gouvernance/documentation :
|
|
|
|
```text
|
|
CHECK VERSION attendue
|
|
CHECK git diff --check
|
|
AUDIT fichiers Git suivis/non ignorés conformes au delta, sans confondre fichiers locaux ignorés et distribution
|
|
AUDIT headers file/version des Markdown gouvernés
|
|
AUDIT headers file/version des formats texte qui adoptent explicitement cette convention
|
|
AUDIT liens Markdown locaux principaux
|
|
REVIEW owners PGR / décisions locales / DEFER explicites
|
|
REVIEW absence de secret, chemin machine absolu et placeholder non résolu
|
|
```
|
|
|
|
## Politique Eclipse
|
|
|
|
Les métadonnées Eclipse spécifiques à la machine restent ignorées, notamment `.project`, `.classpath` et les préférences non partagées.
|
|
|
|
Le fichier suivant constitue l'exception versionnée :
|
|
|
|
```text
|
|
.settings/org.eclipse.core.resources.prefs
|
|
```
|
|
|
|
Il doit contenir :
|
|
|
|
```text
|
|
eclipse.preferences.version=1
|
|
encoding/<project>=UTF-8
|
|
```
|
|
|
|
Le `.gitignore` doit contenir :
|
|
|
|
```text
|
|
.settings/*
|
|
!.settings/org.eclipse.core.resources.prefs
|
|
```
|
|
|
|
Une gate de distribution ne doit donc pas échouer parce qu'un `.project` ignoré existe dans le workspace local. Elle doit en revanche échouer si `org.eclipse.core.resources.prefs` est ignoré ou absent du contenu suivi.
|
|
|
|
## Rust/Cargo
|
|
|
|
Dès qu'un workspace Rust est matérialisé, sélectionner selon le scope :
|
|
|
|
```text
|
|
CHECK cargo metadata --no-deps
|
|
FORMAT cargo fmt --all -- --check
|
|
CHECK cargo check --workspace
|
|
LINT cargo clippy --workspace --all-targets --all-features -- -D warnings
|
|
TEST cargo test ciblé ou workspace selon le changement
|
|
AUDIT règles structurelles PGR seulement si la preuve n'est pas déjà possédée par Cargo/Rustfmt/Clippy
|
|
```
|
|
|
|
Le profil strict et les éventuelles exceptions doivent être visibles dans les manifests/règles locales.
|
|
|
|
## Frontend Web
|
|
|
|
Dès que le frontend est matérialisé :
|
|
|
|
```text
|
|
RESTORE mode reproductible du package manager sélectionné
|
|
TYPECHECK script typecheck TypeScript
|
|
BUILD production Vite lorsque ses entrées/configuration/outputs changent
|
|
STYLES preuve séparée uniquement si le build ne prouve pas déjà la compilation requise
|
|
SMOKE navigateur seulement lorsqu'une propriété runtime le justifie
|
|
```
|
|
|
|
La gate frontend reste exécutable indépendamment du backend autant que la topologie réelle le permet.
|
|
|
|
Si plusieurs entrées/frontend existent pour PGR, HOWTOs et snippets, la gate doit couvrir chacune des entrées modifiées sans forcer trois builds identiques lorsqu'un package commun possède réellement les assets partagés.
|
|
|
|
## Serveurs et intégration
|
|
|
|
Les trois launchers Actix Web/Maud sont validés comme packages exécutables distincts lorsqu'ils sont matérialisés :
|
|
|
|
```text
|
|
knowledge-pgr-server
|
|
knowledge-howtos-server
|
|
knowledge-snippets-server
|
|
```
|
|
|
|
Leur compilation peut être prouvée par les gates workspace. Un smoke HTTP ciblé est ajouté uniquement lorsqu'une route/runtime réelle est introduite et que compilation/tests ne prouvent pas la propriété visée.
|
|
|
|
Une gate d'intégration ne remplace pas silencieusement les preuves frontend indépendantes.
|
|
|
|
## Git et forge
|
|
|
|
Les contrats Git génériques sont testés sans dépendance à une forge lorsque cela suffit.
|
|
|
|
Les tests doivent permettre plusieurs `source_id` et ne pas confondre famille de contenu avec provider de forge.
|
|
|
|
Un test live de remote ou de forge doit être explicitement classé comme externe, séparé des tests unitaires et ne doit pas devenir une condition cachée pour les opérations locales.
|
|
|
|
## PostgreSQL
|
|
|
|
Aucune gate PostgreSQL n'est créée avant matérialisation d'une dépendance ou d'un schéma réel.
|
|
|
|
Lorsqu'elle devient nécessaire, la validation doit distinguer :
|
|
|
|
- parsing/compilation des migrations ou schémas ;
|
|
- tests avec base éphémère/localement contrôlée ;
|
|
- accès cohérent depuis les trois applications lorsque le stockage partagé est concerné ;
|
|
- éventuels smokes externes ;
|
|
- reconstruction d'une projection dérivée à partir d'une révision Git connue ;
|
|
- isolation correcte par famille/source sans dupliquer trois bases par simple symétrie.
|
|
|
|
## Gate de `0.0.1-alpha.1.fix.1`
|
|
|
|
Le fix reste documentaire. Sa gate doit prouver :
|
|
|
|
- `VERSION = 0.0.1-alpha.1.fix.1` ;
|
|
- le history `alpha.1` `FAIL` déjà committé avant application du fix ;
|
|
- les fichiers Git suivis/non ignorés exacts de la fondation, sans compter `.project` ;
|
|
- `.gitignore` avec headers `file/version` et exception Eclipse correcte ;
|
|
- `.settings/org.eclipse.core.resources.prefs` présent, UTF-8 et non ignoré ;
|
|
- l'absence de code fonctionnel ;
|
|
- les headers et liens locaux ;
|
|
- la topologie documentée à trois serveurs Actix distincts ;
|
|
- au moins trois sources Git initiales et une base PostgreSQL logique partagée ;
|
|
- l'absence d'override PGR non documenté ;
|
|
- la cohérence du plan et de la transition PASS/FAIL.
|