0.1.2-alpha.2

docs/validation/001-VALIDATION_MATRIX.md

@@ -1,104 +1,216 @@
 <!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
-<!-- version: 14 -->
+<!-- version: 6 -->
 
-# Matrice de validation PGR
+# Matrice de validation Knowledge
 
-## Rôle
+## Principe
 
-Cette matrice décrit les validations canoniques du dépôt PGR. Elle évolue avec le projet et ne doit pas inventer des scripts uniquement pour remplir une case.
+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 matrice définit les contrôles disponibles ; chaque delta sélectionne uniquement ceux qui sont nécessaires pour son scope et les preuves qu'il peut avoir invalidées.
+La prévalidation de génération ne vaut pas preuve opérateur.
 
-Les catégories et règles de sélection sont définies dans [`../rules/400-VALIDATION.md`](../rules/400-VALIDATION.md).
+## Fondation documentaire
 
-## Contrôles actifs
+Pour une tranche limitée à gouvernance/documentation :
 
-| ID                  | Catégorie | Commande / contrôle                                                                  | Prérequis              | Trigger                         | Phase                | Coût   | Acteur          |
-|---------------------|-----------|--------------------------------------------------------------------------------------|------------------------|---------------------------------|----------------------|--------|-----------------|
-| `PGR-GIT-001`       | `CHECK`   | `git diff --check` ou `git diff --cached --check` selon l'état de l'index            | Git                    | toute modification suivie       | alpha/beta/RC/stable | faible | opérateur       |
-| `PGR-VERSION-001`   | `CHECK`   | comparer `VERSION` à la version attendue par le delta courant                        | fichier `VERSION`      | changement de tranche/version   | alpha/beta/RC/stable | faible | opérateur       |
-| `PGR-LAYOUT-001`    | `AUDIT`   | comparer les fichiers ajoutés/remplacés/supprimés au scope déclaré du delta          | scope du delta         | changement de structure         | alpha/beta/RC/stable | faible | opérateur/revue |
-| `PGR-DOC-001`       | `AUDIT`   | vérifier chemins, rôles et responsabilités des documents touchés                     | fichiers documentaires | modification documentaire       | alpha/beta/RC/stable | faible | opérateur/revue |
-| `PGR-MD-HEADER-001` | `AUDIT`   | `python3 -B scripts/audit_markdown_headers.py <paths...>`                            | Python 3               | Markdown gouverné modifié       | alpha/beta/RC/stable | faible | opérateur/CI    |
-| `PGR-MD-TABLE-001`  | `AUDIT`   | `python3 -B scripts/audit_markdown_tables.py <paths...>`                             | Python 3               | table Markdown ajoutée/modifiée | alpha/beta/RC/stable | faible | opérateur/CI    |
-| `PGR-NAV-001`       | `AUDIT`   | `python3 -B scripts/audit_markdown_links.py <paths...>`                              | Python 3               | navigation ou réconciliation    | alpha/beta/RC/stable | faible | opérateur/CI    |
-| `PGR-SCOPE-001`     | `AUDIT`   | vérifier que les documents vivants pointent vers les propriétaires normatifs actuels | documents vivants      | réconciliation de phase         | beta/RC/stable       | faible | revue           |
-| `PGR-STATUS-001`    | `CHECK`   | `git status --short`                                                                 | Git                    | avant fermeture d'une tranche   | alpha/beta/RC/stable | faible | opérateur       |
+```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
+```
 
-Un contrôle manuel peut rester dans la matrice lorsqu'aucun audit automatisé fiable n'existe encore. PGR SHOULD automatiser uniquement les propriétés stables et objectivement contrôlables.
+## Politique Eclipse
 
-`PGR-MD-TABLE-001` reste volontairement monotâche : il contrôle uniquement la structure et l'alignement source des tableaux Markdown. Il couvre les tableaux Markdown ordinaires ainsi que les exemples placés dans des fences explicitement `markdown` ou `md`. Les autres blocs fenced restent ignorés afin de ne pas interpréter comme Markdown des sorties terminal, extraits de code ou tableaux ASCII d'un autre langage.
+Les métadonnées Eclipse spécifiques à la machine restent ignorées, notamment `.project`, `.classpath` et les préférences non partagées.
 
-`PGR-MD-HEADER-001` contrôle seulement les deux premières lignes des fichiers Markdown sélectionnés : chemin relatif depuis la racine et révision interne positive. La revue `PGR-DOC-001` reste responsable du rôle documentaire et de la pertinence réelle d'un incrément de révision.
-
-`PGR-NAV-001` est automatisé séparément par `audit_markdown_links.py`. Il vérifie uniquement l'existence des cibles de liens Markdown locaux inline, sans contrôler les anchors, les headers, les responsabilités documentaires ou la forme des tableaux.
-
-PGR préfère plusieurs audits simples avec une responsabilité identifiable à un script unique qui agrège des règles indépendantes.
-
-## Contrôles Rust réutilisables, hors gate du dépôt PGR
-
-[`002-RUST_STYLE_AUDITS.md`](002-RUST_STYLE_AUDITS.md) décrit les audits monotâches de structure Rust : lignes vides, blocs `const`, séparation des items, ordre des modules, disposition des imports de traits et blocs de réexports. Ils acceptent des chemins Rust sélectionnés et partagent un petit support lexical ; leur validation ciblée dans PGR est `python3 -B -m unittest discover -s tests -p test_rust_audits.py -v`.
-
-Pour une nouvelle baseline contrôlée, les propriétés sans ordre métier peuvent faire partie du profil strict. L'audit `const_blocks` reste explicitement sélectionné, car une table de protocole, un schéma ou une séquence normative ne doit jamais être réordonné pour satisfaire un tri mécanique. Leur disponibilité ne transforme pas PGR en workspace Rust ; le projet propriétaire exécute ces audits après `cargo fmt`, et Rustfmt/Clippy/rustc conservent les contrôles qu'ils possèdent.
-
-[`003-RUST_EXPORT_COMPLETENESS.md`](003-RUST_EXPORT_COMPLETENESS.md) décrit séparément `audit_rust_export_completeness.py`, audit facultatif de façade crate-root. Sa validation ciblée dans PGR est `python3 -B -m unittest discover -s tests -p test_rust_export_completeness.py -v`. L'audit est destiné aux projets Rust qui choisissent explicitement ce contrat ; PGR n'exécute pas ce script sur son propre dépôt comme gate, car il ne constitue pas lui-même un workspace Rust.
-
-[`004-RUST_CARGO_BASELINE_DRY_RUN.md`](004-RUST_CARGO_BASELINE_DRY_RUN.md) décrit une preuve temporaire de réutilisabilité des skeletons/templates Rust/Cargo. Le mode « nouveau projet » utilise la toolchain officielle dans un répertoire temporaire ; le mode « projet existant » vérifie qu’un mapping d’adoption n’écrase pas les décisions locales classées `KEEP-LOCAL` ou `DEFER`. Cette preuve est sélectionnée lorsque les artefacts Rust/Cargo eux-mêmes changent ou lorsqu’une phase de release doit reconfirmer leur composabilité ; elle n’est pas une cérémonie de chaque delta documentaire.
-
-## Validation frontend Web réutilisable, hors gate du dépôt PGR
-
-[`005-WEB_FRONTEND_VALIDATION.md`](005-WEB_FRONTEND_VALIDATION.md) décrit la validation indépendante du host pour un frontend réel : restauration reproductible selon le package manager choisi, type-check TypeScript, styles, build de production et smoke navigateur seulement lorsqu'il apporte une preuve supplémentaire.
-
-Cette validation appartient aux projets qui possèdent réellement un frontend ou aux dry-runs de skeletons correspondants. Le dépôt PGR n'installe pas TypeScript, Vite ou Sass uniquement pour simuler une gate qu'il ne possède pas. Les outils officiels restent propriétaires de leurs preuves ; un audit Python PGR ne les réimplémente pas.
-
-## Politique Eclipse actuelle
-
-Les métadonnées Eclipse spécifiques à une machine restent ignorées, notamment `.project`, `.classpath` et les préférences non partagées.
-
-Le fichier suivant constitue une exception versionnée, car il porte l'encodage UTF-8 du projet et n'est pas nécessairement régénéré lors d'un import Git :
+Le fichier suivant constitue l'exception versionnée :
 
 ```text
 .settings/org.eclipse.core.resources.prefs
 ```
 
-Le `.gitignore` doit donc contenir :
+Il doit contenir :
+
+```text
+eclipse.preferences.version=1
+encoding/<project>=UTF-8
+```
+
+Le `.gitignore` doit contenir :
 
 ```text
 .settings/*
 !.settings/org.eclipse.core.resources.prefs
 ```
 
-## Gate documentaire courante
+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.
 
-Pour une tranche documentaire, le delta sélectionne les contrôles nécessaires à son scope. Une gate typique peut inclure :
+## Rust/Cargo
 
-```bash
-test "$(cat VERSION)" = "<version attendue>"
+Dès qu'un workspace Rust est matérialisé, sélectionner selon le scope :
 
-git diff --check
-
-git add <fichiers du delta>
-
-git diff --cached --check
-
-git status --short
+```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 placeholder `<version attendue>` appartient à la documentation de la matrice ; chaque delta fournit la commande concrète avec sa propre version.
+Le profil strict et les éventuelles exceptions doivent être visibles dans les manifests/règles locales.
 
-Selon le scope, la gate peut également vérifier que :
+## Administration et authentification
 
-- les fichiers ajoutés/remplacés/supprimés correspondent au delta ;
-- les headers `file/version` correspondent aux chemins réels ;
-- les liens Markdown principaux sont cohérents ;
-- aucun secret, chemin machine absolu ou artefact local non autorisé n'est introduit ;
-- les exceptions Git intentionnellement versionnées restent effectivement traçables ;
-- aucun répertoire ou contrôle n'est ajouté uniquement pour satisfaire une structure théorique.
+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 :
 
-## Autorité de validation
+- 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.
 
-Une validation n'est `PASS` qu'après exécution réelle de la gate opérateur applicable. La génération du delta ou une prévalidation par l'IA ne constitue pas le résultat opérateur.
+Les corpus historiques ne constituent pas des preuves de sécurité pour Knowledge.
 
-Les résultats `FAIL`, `PARTIAL` et `BLOCKED` doivent être enregistrés comme tels et ne doivent pas être transformés implicitement en PASS.
+## 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. 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 :
+
+```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.
+
+## 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.
 
-Après un `PASS`, l'history de la tranche validée est fourni séparément du delta suivant. Un `FAIL` reste normalement dans le scope de la tranche courante via `.fix.N`, sauf REPLAN, abandon ou supersession explicitement justifié.