sasedev-knowledge/docs/validation/001-VALIDATION_MATRIX.md

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 :

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 :

.settings/org.eclipse.core.resources.prefs

Il doit contenir :

eclipse.preferences.version=1
encoding/<project>=UTF-8

Le .gitignore doit contenir :

.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 :

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é :

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 :

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.