<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
<!-- version: 2 -->

# 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.

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.

## Commandes initiales

| 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 |

## 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 de bootstrap

Pour une tranche documentaire de bootstrap, le delta doit sélectionner uniquement 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 --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.

L'opérateur vérifie également, selon le scope du delta, 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 ;
- aucun secret, chemin machine absolu ou artefact local non autorisé n'est introduit ;
- les exceptions Git intentionnellement versionnées restent effectivement traçables.

## 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.

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é.