82 lines
5.4 KiB
Markdown
82 lines
5.4 KiB
Markdown
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
|
|
<!-- version: 5 -->
|
|
|
|
# Matrice de validation PGR
|
|
|
|
## Rôle
|
|
|
|
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 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.
|
|
|
|
Les catégories et règles de sélection sont définies dans [`../rules/400-VALIDATION.md`](../rules/400-VALIDATION.md).
|
|
|
|
## Contrôles actifs
|
|
|
|
| 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 headers `file/version`, chemins, liens et responsabilités des documents touchés | fichiers documentaires | modification documentaire | alpha/beta/RC/stable | faible | opérateur/revue |
|
|
| `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` | vérifier que les points d'entrée et liens canoniques ciblent des fichiers existants | index et docs racine | navigation ou réconciliation | beta/RC/stable | faible | opérateur/revue |
|
|
| `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 |
|
|
|
|
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.
|
|
|
|
`PGR-MD-TABLE-001` est le premier audit matérialisé dans PGR lui-même. Il reste volontairement monotâche : il contrôle uniquement la structure et l'alignement source des tableaux Markdown, sans vérifier les blank lines, les headers, les liens ou d'autres règles documentaires.
|
|
|
|
## 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 :
|
|
|
|
```text
|
|
.settings/org.eclipse.core.resources.prefs
|
|
```
|
|
|
|
Le `.gitignore` doit donc contenir :
|
|
|
|
```text
|
|
.settings/*
|
|
!.settings/org.eclipse.core.resources.prefs
|
|
```
|
|
|
|
## Gate documentaire courante
|
|
|
|
Pour une tranche documentaire, le delta sélectionne les contrôles nécessaires à son scope. Une gate typique peut inclure :
|
|
|
|
```bash
|
|
test "$(cat VERSION)" = "<version attendue>"
|
|
|
|
git diff --check
|
|
|
|
git add <fichiers du delta>
|
|
|
|
git diff --cached --check
|
|
|
|
git status --short
|
|
```
|
|
|
|
Le placeholder `<version attendue>` appartient à la documentation de la matrice ; chaque delta fournit la commande concrète avec sa propre version.
|
|
|
|
Selon le scope, la gate peut également vérifier que :
|
|
|
|
- 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.
|
|
|
|
## Autorité de validation
|
|
|
|
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 résultats `FAIL`, `PARTIAL` et `BLOCKED` doivent être enregistrés comme tels et ne doivent pas être transformés implicitement en PASS.
|
|
|
|
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é.
|