Sasedev/sasedev-knowledge
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
7c0048b6a76845a9f2272e326b362dc3e514dbd9
sasedev-knowledge/docs/validation/001-VALIDATION_MATRIX.md
SinuS Von SifriduS 7c0048b6a7 0.0.1-beta.1
2026-09-28 10:37:50 +02:00

20 KiB
Raw Blame History

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.

Administration et authentification

Aucune route admin/login n'est validée tant qu'elle n'existe pas réellement. Lorsqu'elles seront matérialisées, les gates devront prouver séparément :

  • refus d'accès non authentifié aux opérations privilégiées ;
  • refus d'accès authentifié sans autorisation suffisante ;
  • autorisation vérifiée côté serveur et pas seulement par la navigation frontend ;
  • isolation correcte des opérations PGR, HOWTOs et snippets ;
  • comportement d'une éventuelle façade admin transverse sans bypass des contrôles locaux.

Les corpus historiques ne constituent pas des preuves de sécurité pour Knowledge.

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. Les templates statiques de référence appartiennent à cette gate : leur rôle est de prouver le design/markup/assets côté Web avant adaptation Maud, pas de prouver le rendu Actix.

Lorsque Vite est sélectionné pour les assets réellement servis par Maud, la gate de production doit également prouver l’émission d’un manifest parsable et la présence des clés d’entrée attendues. Une gate d’intégration Actix/Maud distincte prouve ensuite que ces clés sont résolues sans coder les noms hashés.

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.

Gate de 0.0.1-alpha.2

La tranche doit prouver :

  • VERSION = 0.0.1-alpha.2 et [workspace.package].version identique ;
  • Cargo.lock versionné et non ignoré ;
  • Cargo.toml, rustfmt.toml, clippy.toml et .cargo/config.toml sans placeholder PGR ;
  • cargo metadata --format-version 1 --no-deps ;
  • cargo fmt --all -- --check ;
  • cargo check --workspace ;
  • cargo clippy --workspace --all-targets --all-features -- -D warnings ;
  • cargo test --workspace --all-targets --all-features ;
  • artefacts Cargo hors dépôt sous ../builds/sasedev-knowledge/target/ ;
  • seule knowledge-domain-lib matérialisée comme première crate, sans création placeholder des trois serveurs ;
  • étude auth/admin présente avec distinction entre fonctionnalités câblées, préparatoires et seulement annoncées ;
  • surfaces admin locales documentées sans figer /admin, /login ou un modèle de rôles ;
  • hygiène Git et headers documentaires applicables.

Gate de 0.0.1-alpha.3

La tranche doit prouver :

  • VERSION = 0.0.1-alpha.3 et [workspace.package].version identique ;
  • trois packages seulement : knowledge-domain-lib, knowledge-git-api, knowledge-sync-api ;
  • knowledge-git-api et knowledge-sync-api comme crates passives sans dépendance Actix, Gitea, PostgreSQL ou runtime ;
  • source/famille de contenu capables de représenter plus de trois sources configurées ;
  • GitRepository indépendant d'une forge et sans format de hash Git figé ;
  • RepositoryEventSource produisant un signal non autoritaire lié à un source_id ;
  • Cargo.lock régénéré par Cargo et versionné après ajout des deux packages ;
  • cargo fmt --all -- --check, cargo check --workspace et Clippy strict ;
  • tests ciblés des trois crates ;
  • audits Rust PGR sélectionnés propres, y compris la façade crate-root ;
  • absence de knowledge-git-lib, adapter Gitea, schéma PostgreSQL, Actix Web et frontend ;
  • hygiène Git et headers documentaires/code applicables.

L'audit audit_rust_const_blocks.py n'appartient pas à la gate globale de cette tranche.

Gate de 0.0.1-alpha.3.fix.1

Le fix doit prouver :

  • VERSION = 0.0.1-alpha.3.fix.1 et version workspace identique ;
  • history alpha.3 FAIL committé avant application du fix ;
  • construction valide de SourceId depuis son module sans contourner la visibilité du tuple struct ;
  • test de régression direct SourceId::new("pgr") + tests précédents ;
  • audits Rust PGR sélectionnés propres ;
  • cargo check, Clippy strict et les trois suites ciblées PASS ;
  • aucune dépendance ou crate fonctionnelle Web/Actix/PostgreSQL/Gitea ajoutée ;
  • trajectoire Web documentée : skeleton Web PGR obligatoire en alpha.4, templates statiques de référence, rendu runtime Maud, manifest Vite produit côté frontend et intégration Actix/Maud seulement en alpha.5 ;
  • hygiène Git et documentation propres.

Gate de 0.0.1-alpha.3.fix.2

Le second fix doit prouver :

  • VERSION = 0.0.1-alpha.3.fix.2 et version workspace identique ;
  • history alpha.3.fix.1 FAIL committé avant application du fix ;
  • documentation Rust présente sur chacune des quatre variantes publiques Pgr, Howto, Snippet et ProjectLocal ;
  • aucune réduction de la politique missing_docs et aucun allow(missing_docs) introduit pour contourner la gate ;
  • audits Rust PGR sélectionnés propres ;
  • cargo check --workspace sans warning missing_docs ;
  • Clippy workspace strict -D warnings PASS ;
  • les trois suites ciblées knowledge-domain-lib, knowledge-git-api et knowledge-sync-api PASS ;
  • Cargo.lock régénéré/versionné si la version workspace le modifie ;
  • aucun changement fonctionnel des contrats domaine/Git/synchronisation ;
  • aucun frontend, serveur Actix, schéma PostgreSQL ou adapter de forge ajouté ;
  • hygiène Git et documentation propres.

Gate de 0.0.1-alpha.3.fix.3

Le troisième fix doit prouver :

  • VERSION = 0.0.1-alpha.3.fix.3 et version workspace identique ;
  • history alpha.3.fix.2 FAIL committé avant application du fix ;
  • docs/validation/001-VALIDATION_MATRIX.md se termine par exactement une fin de ligne, sans ligne vide supplémentaire ;
  • git diff --check PASS avant clôture de tranche ;
  • documentation des quatre variantes publiques ContentFamily conservée ;
  • aucun allow(missing_docs) ajouté et politique missing_docs inchangée ;
  • audits Rust PGR sélectionnés propres ;
  • cargo check --workspace PASS ;
  • Clippy workspace strict -D warnings PASS ;
  • les trois suites ciblées knowledge-domain-lib, knowledge-git-api et knowledge-sync-api PASS ;
  • aucune modification fonctionnelle des contrats domaine/Git/synchronisation ;
  • aucun frontend, serveur Actix, schéma PostgreSQL ou adapter de forge ajouté ;
  • staging Git propre à la tranche.

Gate de 0.0.1-alpha.4

La tranche Web doit prouver :

  • VERSION = 0.0.1-alpha.4 et version workspace Cargo identique ;
  • history alpha.3.fix.3 PASS committé avant application d'alpha.4 ;
  • package unique Web/knowledge-template-lab/ et absence des trois launchers Actix encore différés ;
  • npm sélectionné comme package manager ;
  • package-lock.json généré par npm, versionné et non ignoré ;
  • dépendances réelles et versions explicites pour TypeScript, Vite, Sass, Bootstrap, Popper et types nécessaires ;
  • npm ci PASS depuis le lockfile ;
  • npm run typecheck indépendant PASS ;
  • npm run build PASS ;
  • cache Vite et build.outDir hors dépôt sous ../builds/sasedev-knowledge/ ;
  • manifest Vite de production parsable ;
  • entrée stable src/main.ts présente dans le manifest et associée à un asset JavaScript ;
  • au moins un asset CSS associé à l'entrée ou à son graphe de build ;
  • page statique de référence incluse dans le build Vite sans route Actix/Maud ;
  • aucun chemin /admin, /login ou hostname de production figé dans le package de laboratoire ;
  • aucune crate serveur, dépendance Actix/Maud, migration PostgreSQL ou adapter de forge ajouté ;
  • gates Rust existantes toujours propres après le bump de version ;
  • git diff --cached --check propre et outputs générés absents du staging.

Gate de 0.0.1-alpha.4.fix.1

Le premier fix Web doit prouver :

  • VERSION = 0.0.1-alpha.4.fix.1 et version workspace Cargo identique ;
  • history alpha.4 FAIL committé avant application du fix ;
  • git diff --check propre ;
  • compilerOptions.types contient exactement vite/client dans Web/knowledge-template-lab/tsconfig.json ;
  • aucun shim *.scss local ajouté pour contourner les types Vite ;
  • npm ci PASS depuis le package-lock.json déjà versionné par alpha.4 ;
  • npm run typecheck PASS ;
  • npm run build PASS ;
  • manifest Vite parsable avec entrée src/main.ts, JavaScript et CSS ;
  • npm install-scripts ls exécuté pour exposer les scripts d'installation non approuvés sans les approuver automatiquement ;
  • warnings Sass issus de Bootstrap observables mais non traités comme défaut Knowledge tant que le build reste PASS ;
  • gates Rust existantes toujours propres après le bump de version ;
  • aucun serveur Actix/Maud, route runtime, migration PostgreSQL ou adapter de forge ajouté ;
  • staging Git propre et outputs générés absents du dépôt.

Gate de 0.0.1-alpha.4.fix.2

Le second fix Web doit prouver :

  • VERSION = 0.0.1-alpha.4.fix.2 et version workspace Cargo identique ;
  • history alpha.4.fix.1 FAIL committé avant application du fix ;
  • git diff --check propre ;
  • @types/node = 24.13.6 présent dans devDependencies ;
  • tsconfig.json contient types = ["vite/client", "node"] ;
  • tsconfig.json conserve ES2022, DOM, DOM.Iterable et ajoute ESNext.Disposable ;
  • tsconfig.vite.json contient types = ["node"] et lib = ["ES2022", "ESNext.Disposable"] ;
  • aucun shim *.scss source propre au projet n'est ajouté ;
  • l'audit de shims ne parcourt pas node_modules ;
  • npm install met à jour package-lock.json avec @types/node puis npm ci PASS ;
  • npm run typecheck PASS ;
  • npm run build PASS ;
  • manifest Vite parsable avec entrée src/main.ts, JavaScript et CSS ;
  • npm install-scripts ls garde observable la politique @parcel/watcher sans approbation automatique ;
  • gates Rust existantes toujours propres après le bump de version ;
  • aucun serveur Actix/Maud, loader Rust du manifest, route runtime, migration PostgreSQL ou adapter de forge ajouté ;
  • staging Git propre et outputs générés absents du dépôt.

Gate de 0.0.1-alpha.5

La composition serveur doit prouver :

  • VERSION = 0.0.1-alpha.5 et version workspace identique ;
  • history alpha.4.fix.2 PASS committé avant application ;
  • workspace contenant knowledge-web-lib et exactement les trois nouveaux launchers attendus ;
  • knowledge-web-lib comme unique owner Actix/Maud/Vite runtime partagé ;
  • launchers dépendant de knowledge-web-lib sans dépendance directe Actix/Maud/Serde ;
  • Actix Web 4.15.0, Actix Files 0.7.0, Maud 0.27.0, Serde 1.0.229 et Serde JSON 1.0.151 dans le manifest de knowledge-web-lib ;
  • aucun panic!, unwrap, expect ou ? ajouté ;
  • aucune origin/port Vite ou adresse de bind choisie par le code ;
  • mode dev résolvant @vite/client puis src/main.ts depuis KNOWLEDGE_VITE_DEV_ORIGIN ;
  • mode production résolvant src/main.ts depuis le manifest configuré et servant les fichiers /assets/* depuis le build réel ;
  • routes runtime limitées à / et /healthz pour cette tranche ;
  • aucune route admin/login, auth, PostgreSQL ou forge ajoutée ;
  • npm ci, typecheck et build du template lab toujours PASS ;
  • audits Rust PGR, cargo check, Clippy strict et tests ciblés PASS ;
  • smoke HTTP production PASS pour les trois launchers avec ports de test injectés par environnement ;
  • Cargo.lock mis à jour/versionné et staging propre.

Convention locale des tests Rust

Knowledge sélectionne la convention PGR optionnelle suivante comme règle locale obligatoire :

crate/
  src/
  unit_tests/
  tests/

unit_tests/ contient les tests unitaires attachés aux modules source par #[path = "..."].

tests/ contient exclusivement les tests d'intégration Cargo qui consomment l'API publique.

La gate Rust ajoute :

python3 -B scripts/audit_rust_test_layout.py crates

Cet audit doit refuser notamment :

  • un attribut #[test] dans src/ ;
  • un fichier src/unit_tests.rs ou src/tests.rs ;
  • un mod unit_tests; classique sous src/ ;
  • un fichier sous unit_tests/ qui n'est référencé par aucun #[path = "..."] d'un source de la crate.

Gate de 0.0.1-alpha.5.fix.1

Le fix de layout des tests doit prouver :

  • VERSION = 0.0.1-alpha.5.fix.1 et version workspace identique ;
  • history alpha.5 FAIL committé avant application ;
  • suppression exacte des quatre anciens src/unit_tests.rs via le manifest de suppression ;
  • tests unitaires sous unit_tests/ hors de src/ pour knowledge-domain-lib, knowledge-git-api, knowledge-sync-api et knowledge-web-lib ;
  • rattachements #[cfg(test)] + #[path = "..."] depuis les modules source propriétaires ;
  • aucun #[test] sous crates/*/src/ ;
  • tests/ réservé aux futurs tests d'intégration Cargo ;
  • audit_rust_test_layout.py PASS ;
  • audits Rust PGR existants toujours PASS, y compris export completeness qui suit les modules #[path] ;
  • cargo check, Clippy strict et cargo test --workspace --all-targets --all-features PASS ;
  • baseline Web npm ci, typecheck et build PASS ;
  • smoke HTTP production des trois serveurs PASS ;
  • aucune modification fonctionnelle Actix/Maud/Vite au-delà du rattachement des tests ;
  • git diff --cached --check propre.

Gate de 0.0.1-alpha.5.fix.2

Le second fix de clôture doit prouver :

  • VERSION = 0.0.1-alpha.5.fix.2 et version workspace identique ;
  • history alpha.5.fix.1 FAIL committé avant application ;
  • git diff --check PASS immédiatement après application, avant toute commande de formatage ;
  • cargo fmt --all -- --check PASS sans exécution préalable de cargo fmt --all, afin de prouver que le snapshot livré est déjà formaté ;
  • les quatre anciens src/unit_tests.rs restent absents ;
  • les cinq fichiers sous unit_tests/ restent présents et rattachés par #[path = "..."] ;
  • audit_rust_test_layout.py et les audits Rust PGR existants PASS ;
  • cargo check, Clippy strict et cargo test --workspace --all-targets --all-features PASS ;
  • npm ci, npm run typecheck et npm run build PASS ;
  • manifest Vite PASS ;
  • smoke HTTP de knowledge-pgr-server, knowledge-howtos-server et knowledge-snippets-server PASS ;
  • aucune modification fonctionnelle du runtime Actix/Maud/Vite ;
  • git diff --cached --check propre.

Gate de 0.0.1-beta.1

La réconciliation beta doit prouver :

  • VERSION = 0.0.1-beta.1 et version workspace identique ;
  • history alpha.5.fix.2 PASS committé avant application de beta ;
  • aucun nouveau package Cargo, package npm ou comportement runtime introduit ;
  • workspace Cargo toujours composé exactement de sept packages ;
  • knowledge-web-lib et les trois launchers documentés comme matérialisés ;
  • aucune formulation durable ne décrit encore knowledge-web-lib comme candidate ou les launchers comme non matérialisés ;
  • owners Web PGR réconciliés avec alpha.4/alpha.5 ;
  • unit_tests/ confirmé comme convention locale et audit associé toujours propre ;
  • étude 003-V0_0_1_FOUNDATION_RECONCILIATION.md présente ;
  • roadmap engage uniquement 0.0.2 et ne réserve aucun numéro supplémentaire ;
  • prompt 002-V0_0_2_START_PROMPT.md présent et explicitement bloqué jusqu'au post-tag 0.0.1 PASS ;
  • DEFER PostgreSQL/forge/auth/admin/formats finaux conservés ;
  • CHANGELOG.md ne contient plus le détail interne du fix rustfmt comme changement utilisateur ;
  • audits Markdown headers/tables/links propres ;
  • cargo fmt --check, audits Rust, cargo check, Clippy strict et tests workspace propres ;
  • baseline Web npm ci, typecheck et build propre ;
  • manifest Vite parsable ;
  • smoke HTTP des trois launchers propre ;
  • git diff --cached --check propre.
Reference in New Issue View Git Blame Copy Permalink