0.0.5-alpha.3.fix.1

This commit is contained in:
2026-09-24 23:40:02 +02:00
parent 1b1a7092e5
commit a954d7f90a
7 changed files with 405 additions and 12 deletions

View File

@@ -0,0 +1,128 @@
<!-- file: history/0.0.5/alpha.3.fix.1.md -->
<!-- version: 1 -->
# History 0.0.5-alpha.3.fix.1 — couverture des tables dans les exemples Markdown fenced
## Statut
PASS
La gate opérateur de `0.0.5-alpha.3.fix.1` exécutée le `2026-09-24` valide la correction de `PGR-MD-TABLE-001`. Le faux négatif constaté pendant `alpha.3` est couvert par des tests de régression, les deux tables fenced du template `004` sont désormais gouvernées par l'audit et les contrôles documentaires/Git sont propres.
## Baseline et version
La tranche part du commit opérateur de `0.0.5-alpha.3`, enregistré après application du history `FAIL`. La sortie Git fournie identifie ce commit sous la forme abrégée :
```text
1b1a709 0.0.5-alpha.3
```
Le push vers `origin/master` a réussi avant l'application de `alpha.3.fix.1`.
La version contrôlée après application du fix est :
```text
0.0.5-alpha.3.fix.1
```
Les artefacts suivants sont présents pendant la gate :
```text
history/0.0.5/alpha.3.md
deltas/0.0.5/alpha.3.md
deltas/0.0.5/alpha.3.fix.1.md
tests/test_markdown_tables.py
```
`history/0.0.5/alpha.3.fix.1.md` est absent pendant la gate, conformément au workflow.
## Validation opérateur observée
Les contrôles de statut et de révision ont réussi :
```text
history/0.0.5/alpha.3.md FAIL
scripts/audit_markdown_tables.py version 2
docs/templates/004-FILE_FAMILY_CONTRACTS.md version 2
docs/validation/001-VALIDATION_MATRIX.md version 10
tests/test_markdown_tables.py version 1
```
La suite ciblée du nouvel audit a exécuté `4` tests, tous réussis :
```text
Ran 4 tests in 0.093s
OK
```
Les cas couverts vérifient :
- le comptage conjoint d'une table ordinaire et d'une table fenced Markdown ;
- le rejet d'une table mal alignée dans une fence `markdown` ;
- l'audit de l'alias `md` ;
- le maintien hors scope des fences non Markdown.
La suite Python globale a exécuté `19` tests, tous réussis :
```text
Ran 19 tests in 0.311s
OK
```
Les trois audits documentaires affichent :
```text
Markdown header audit: clean (134 file(s))
Markdown table audit: clean (6 table(s), 134 file(s))
Markdown link audit: clean (127 local link(s), 134 file(s))
```
Le contrôle ciblé du template affiche désormais :
```text
Markdown table audit: clean (2 table(s), 1 file(s))
```
Le contrôle structurel spécifique affiche :
```text
0.0.5 alpha.3.fix.1 fenced Markdown table audit: clean (regression covered, two template examples governed)
```
Il confirme notamment que l'audit reconnaît uniquement les fences explicites `markdown` ou `md`, que les deux exemples du template sont présents et que la matrice de validation documente l'exclusion volontaire des sorties terminal/non-Markdown.
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
Le scope Git observé avant ajout du présent history est exactement :
```text
M VERSION
A deltas/0.0.5/alpha.3.fix.1.md
M docs/templates/004-FILE_FAMILY_CONTRACTS.md
M docs/validation/001-VALIDATION_MATRIX.md
M scripts/audit_markdown_tables.py
A tests/test_markdown_tables.py
```
## Résultat
Le défaut de `alpha.3` est corrigé sans élargir l'audit à des blocs de code qui ne sont pas explicitement du Markdown. `PGR-MD-TABLE-001` couvre maintenant les tables normales ainsi que les exemples fenced Markdown, tout en continuant d'ignorer les fences d'autres langages.
Aucun nouveau fix de `alpha.3` n'est requis.
Après la gate, une revue distincte du plan et des historiques de conception PGR a révélé un besoin de gouvernance plus large : le contrat des plans n'assigne pas encore explicitement les responsabilités de clôture/transition et PGR ne définit pas encore de revue d'horizon de roadmap. Ce besoin ne remet pas en cause le présent fix ; il justifie un REPLAN dans la tranche normale suivante.
## Transition
Appliquer le présent history puis committer et pousser `0.0.5-alpha.3.fix.1`.
La tranche suivante devient :
```text
0.0.5-alpha.4
```
avec rôle `REPLAN`. Elle doit traiter uniquement le lifecycle inter-release, le contrat de clôture/transition des plans, la revue d'horizon et les optimisations workflow directement liées. Les anciens travaux prévus à partir de `alpha.4` sont décalés sans être abandonnés.