Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.0.1-alpha.5

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-23 08:13:06 +02:00
parent 797230bc33
commit 1aa4c0e0b7
7 changed files with 405 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
docs/validation/001-VALIDATION_MATRIX.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Matrice de validation PGR
@@ -7,18 +7,21 @@
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.
PGR est encore dans sa phase de bootstrap documentaire. Les contrôles initiaux restent donc volontairement simples et reposent sur Git, des commandes shell ciblées et une revue opérateur explicite.
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.
## Commandes initiales
Les catégories et règles de sélection sont définies dans [`../rules/400-VALIDATION.md`](../rules/400-VALIDATION.md).
| ID | Catégorie | Commande / contrôle | Trigger | Phase |
|-------------------------|-----------|------------------------------------------------------------------------------------------|--------------------------------------------|----------------------|
| `PGR-GIT-001` | CHECK | `git diff --check` ou `git diff --cached --check` selon l'état de l'index | toute modification suivie par Git | alpha/beta/RC/stable |
| `PGR-GIT-BOOTSTRAP-001` | CHECK | `git add .` puis `git diff --cached --check` | bootstrap ou fichiers entièrement nouveaux | bootstrap |
| `PGR-VERSION-001` | CHECK | comparer `VERSION` à la version attendue par le delta courant | changement de tranche/version | alpha/beta/RC/stable |
| `PGR-LAYOUT-001` | REVIEW | `find . -type f -not -path './.git/*' -print` puis comparaison au scope du delta | ajout/suppression/déplacement de fichiers | alpha/beta/RC/stable |
| `PGR-DOC-001` | REVIEW | vérifier headers `file/version`, chemins, liens et responsabilités des documents touchés | modification documentaire | alpha/beta/RC/stable |
| `PGR-STATUS-001` | CHECK | `git status --short` | avant fermeture d'une tranche | alpha/beta/RC/stable |
## 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-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.
## Politique Eclipse actuelle
@@ -37,16 +40,16 @@ Le `.gitignore` doit donc contenir :
!.settings/org.eclipse.core.resources.prefs
```
## Gate documentaire de bootstrap
## Gate documentaire courante
Pour une tranche documentaire de bootstrap, le delta doit sélectionner uniquement les contrôles nécessaires à son scope. Une gate typique peut inclure :
Pour une tranche documentaire, le delta sélectionne les contrôles nécessaires à son scope. Une gate typique peut inclure :
```bash
git status --short
test "$(cat VERSION)" = "<version attendue>"
find . -type f -not -path './.git/*' -print
git diff --check
git add <fichiers du delta>
git diff --cached --check
@@ -55,18 +58,19 @@ git status --short
Le placeholder `<version attendue>` appartient à la documentation de la matrice ; chaque delta fournit la commande concrète avec sa propre version.
L'opérateur vérifie également, selon le scope du delta, que :
Selon le scope, la gate peut également vérifier que :
- aucun répertoire vide n'a été ajouté uniquement pour anticiper le futur ;
- les fichiers ajoutés/remplacés/supprimés correspondent au delta ;
- les headers `file/version` correspondent aux chemins réels ;
- `VERSION` contient exactement une ligne avec la version de la tranche courante ;
- les liens Markdown de navigation principaux sont cohérents ;
- 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.
- 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 du gate opérateur. La génération du delta ou une prévalidation par l'IA ne constitue pas le résultat opérateur.
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.
Après un `PASS`, l'historique de la tranche validée est fourni séparément du delta suivant. Un `FAIL` reste dans le scope de la tranche courante via `.fix.N`, sauf REPLAN ou abandon explicitement justifié.
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é.