183 lines
7.8 KiB
Markdown
183 lines
7.8 KiB
Markdown
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
|
|
<!-- version: 4 -->
|
|
|
|
# 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.
|
|
|
|
## 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é :
|
|
|
|
```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.
|
|
|
|
## 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.
|