3.2 KiB
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 liste des fichiers ajoutés/remplacés/supprimés conforme au delta
AUDIT headers file/version des Markdown gouvernés
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
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.
Serveur et intégration
Actix Web/Maud reçoivent une gate backend Rust ciblée. Un smoke HTTP 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.
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 ;
- éventuels smokes externes ;
- reconstruction d'une projection dérivée à partir d'une révision Git connue.
Gate de 0.0.1-alpha.1
La première tranche est documentaire. Sa gate doit prouver :
VERSION = 0.0.1-alpha.1;- les fichiers exacts du delta ;
- l'absence de code fonctionnel ;
- les headers et liens locaux ;
- la présence de la baseline PGR vérifiée et de la matrice de décisions ;
- l'absence d'override PGR non documenté ;
- la cohérence du plan et de la transition PASS/FAIL.