0.0.5-alpha.3
This commit is contained in:
173
deltas/0.0.5/alpha.3.md
Normal file
173
deltas/0.0.5/alpha.3.md
Normal file
@@ -0,0 +1,173 @@
|
||||
<!-- file: deltas/0.0.5/alpha.3.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.0.5-alpha.3 — pattern facultatif de contrats de fichiers ou familles
|
||||
|
||||
## Baseline et version
|
||||
|
||||
Baseline attendue : commit opérateur de `0.0.5-alpha.2`, réalisé après application de `history/0.0.5/alpha.2.md` avec statut `PASS`.
|
||||
|
||||
Le hash de ce commit n'est pas anticipé. Le history `alpha.2` et le présent delta peuvent être livrés dans le même échange, mais restent deux archives séparées et le delta `alpha.3` MUST NOT être appliqué avant le commit de `alpha.2`.
|
||||
|
||||
Version avant application :
|
||||
|
||||
```text
|
||||
0.0.5-alpha.2
|
||||
```
|
||||
|
||||
Version après application :
|
||||
|
||||
```text
|
||||
0.0.5-alpha.3
|
||||
```
|
||||
|
||||
## Objet
|
||||
|
||||
Exécuter la troisième tranche du plan `0.0.5` en généralisant un besoin observé indépendamment dans les deux corpus externes : expliciter, lorsque la complexité le justifie, la responsabilité et la règle de modification de certaines familles de fichiers locales.
|
||||
|
||||
La tranche normalise le pattern et non les catalogues KSP/Games. Elle n'impose ni le nom `FILE_CONTRACTS.md`, ni une table exhaustive, ni la reprise de leurs chemins, règles métier ou conventions de release.
|
||||
|
||||
## Scope
|
||||
|
||||
REPLACE :
|
||||
|
||||
```text
|
||||
VERSION
|
||||
docs/000-README.md
|
||||
docs/rules/300-DOCUMENTATION.md
|
||||
docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
|
||||
```
|
||||
|
||||
ADD :
|
||||
|
||||
```text
|
||||
docs/templates/004-FILE_FAMILY_CONTRACTS.md
|
||||
deltas/0.0.5/alpha.3.md
|
||||
```
|
||||
|
||||
DELETE : aucun.
|
||||
|
||||
L'archive delta contient uniquement ces six fichiers complets avec leurs chemins relatifs. Elle ne contient pas `history/0.0.5/alpha.2.md`, livré séparément pour clôturer la tranche précédente, ni `history/0.0.5/alpha.3.md`, qui sera produit après la gate opérateur.
|
||||
|
||||
## Contrat matérialisé
|
||||
|
||||
`docs/rules/300-DOCUMENTATION.md` possède désormais le pattern générique :
|
||||
|
||||
- un registre local est facultatif et ne doit exister que pour lever une ambiguïté réelle ;
|
||||
- il décrit au minimum fichier/famille, responsabilité durable et règle de modification ;
|
||||
- source de vérité, statut généré/versionné, owner ou validation restent des champs optionnels ;
|
||||
- le registre ne doit ni recopier les owners existants ni devenir un miroir exhaustif de l'arborescence ;
|
||||
- son nom, son emplacement et sa forme appartiennent au projet destinataire ;
|
||||
- l'ajout d'un fichier déjà couvert par une famille ne force pas une entrée supplémentaire.
|
||||
|
||||
`docs/templates/004-FILE_FAMILY_CONTRACTS.md` fournit une forme d'adaptation courte avec critères d'usage, modèle minimal, règles d'instanciation et exemple abstrait.
|
||||
|
||||
La fondation `001-PROJECT_GOVERNANCE_FOUNDATION.md` référence ce pattern uniquement comme possibilité pour un projet dont plusieurs familles durables deviennent ambiguës. Elle confirme explicitement qu'un projet simple n'a rien à matérialiser.
|
||||
|
||||
## Validation opérateur
|
||||
|
||||
Après avoir appliqué `history/0.0.5/alpha.2.md`, committé `0.0.5-alpha.2`, puis appliqué le présent delta, depuis la racine du dépôt :
|
||||
|
||||
```bash
|
||||
test "$(cat VERSION)" = '0.0.5-alpha.3'
|
||||
test -f history/0.0.5/alpha.2.md
|
||||
test -f deltas/0.0.5/alpha.3.md
|
||||
test -f docs/templates/004-FILE_FAMILY_CONTRACTS.md
|
||||
test ! -e history/0.0.5/alpha.3.md
|
||||
|
||||
grep -Fx '<!-- version: 11 -->' docs/000-README.md
|
||||
grep -Fx '<!-- version: 3 -->' docs/rules/300-DOCUMENTATION.md
|
||||
grep -Fx '<!-- version: 2 -->' docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
|
||||
grep -Fx '<!-- version: 1 -->' docs/templates/004-FILE_FAMILY_CONTRACTS.md
|
||||
|
||||
python3 -B -m unittest discover -s tests -v
|
||||
|
||||
python3 -B scripts/audit_markdown_headers.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
|
||||
python3 -B scripts/audit_markdown_tables.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
|
||||
python3 -B scripts/audit_markdown_links.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
|
||||
|
||||
python3 -B - <<'PY'
|
||||
from pathlib import Path
|
||||
import re
|
||||
|
||||
history = Path('history/0.0.5/alpha.2.md').read_text(encoding='utf-8')
|
||||
assert re.search(r'## Statut\s+PASS\s', history)
|
||||
|
||||
doc = Path('docs/rules/300-DOCUMENTATION.md').read_text(encoding='utf-8')
|
||||
template = Path('docs/templates/004-FILE_FAMILY_CONTRACTS.md').read_text(encoding='utf-8')
|
||||
foundation = Path('docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md').read_text(encoding='utf-8')
|
||||
index = Path('docs/000-README.md').read_text(encoding='utf-8')
|
||||
|
||||
required_doc = (
|
||||
'## Registre local de contrats de fichiers ou familles',
|
||||
'outil de désambiguïsation, pas un inventaire exhaustif',
|
||||
'le fichier, motif de chemin ou famille concernée',
|
||||
'sa responsabilité durable',
|
||||
'la règle ou le déclencheur pertinent de modification',
|
||||
'PGR n\'impose ni `FILE_CONTRACTS.md`',
|
||||
'l\'ajout d\'un fichier conforme à une famille déjà décrite ne force pas une nouvelle entrée',
|
||||
)
|
||||
for phrase in required_doc:
|
||||
assert phrase in doc, phrase
|
||||
|
||||
required_template = (
|
||||
'# Pattern — contrats locaux de fichiers ou familles',
|
||||
'Quand l\'utiliser',
|
||||
'Forme minimale',
|
||||
'Règles d\'adaptation',
|
||||
'Critère de sortie',
|
||||
'`docs/rules/FILE_CONTRACTS.md` est un nom possible, pas une convention PGR obligatoire',
|
||||
)
|
||||
for phrase in required_template:
|
||||
assert phrase in template, phrase
|
||||
|
||||
assert '004-FILE_FAMILY_CONTRACTS.md' in foundation
|
||||
assert 'Ce registre reste facultatif' in foundation
|
||||
assert '004-FILE_FAMILY_CONTRACTS.md' in index
|
||||
|
||||
for text in (doc, template, foundation):
|
||||
for forbidden in ('tokio-postgres', 'WebTransport', 'Uroburas'):
|
||||
assert forbidden not in text, forbidden
|
||||
|
||||
print('0.0.5 alpha.3 file-family contract audit: clean (optional registry, short reusable pattern, no project-specific contract imported)')
|
||||
PY
|
||||
|
||||
git diff --check
|
||||
git add VERSION docs/000-README.md docs/rules/300-DOCUMENTATION.md \
|
||||
docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md \
|
||||
docs/templates/004-FILE_FAMILY_CONTRACTS.md deltas/0.0.5/alpha.3.md
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
Le scope indexé attendu avant ajout du history est :
|
||||
|
||||
```text
|
||||
M VERSION
|
||||
A deltas/0.0.5/alpha.3.md
|
||||
M docs/000-README.md
|
||||
M docs/rules/300-DOCUMENTATION.md
|
||||
M docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
|
||||
A docs/templates/004-FILE_FAMILY_CONTRACTS.md
|
||||
```
|
||||
|
||||
La revue opérateur doit en outre confirmer que :
|
||||
|
||||
- le pattern réduit une ambiguïté réelle au lieu d'imposer une nouvelle cérémonie ;
|
||||
- `FILE_CONTRACTS.md` reste un exemple de nom, jamais une obligation ;
|
||||
- le registre ne devient pas un catalogue exhaustif de chaque fichier du dépôt ;
|
||||
- une règle détaillée déjà possédée ailleurs est référencée plutôt que dupliquée ;
|
||||
- la fondation n'impose aucun nouveau document aux petits projets ou aux projets dont les responsabilités sont déjà claires.
|
||||
|
||||
## Transition
|
||||
|
||||
### PASS
|
||||
|
||||
Rédiger et livrer séparément `history/0.0.5/alpha.3.md` avec les résultats réellement observés ; l'appliquer et committer la tranche. Préparer seulement ensuite `0.0.5-alpha.4` pour l'audit Rust facultatif de façade/export completeness.
|
||||
|
||||
### FAIL
|
||||
|
||||
Consigner le résultat réel dans le history de `alpha.3`, puis corriger le pattern dans `0.0.5-alpha.3.fix.1` ou produire un REPLAN motivé. Aucun contenu de l'audit Rust `alpha.4` ne doit être absorbé silencieusement dans un fix.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/000-README.md -->
|
||||
<!-- version: 10 -->
|
||||
<!-- version: 11 -->
|
||||
|
||||
# Documentation PGR
|
||||
|
||||
@@ -24,6 +24,7 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
|
||||
|
||||
- [`plans/005-V0_0_5_RECONCILIATION_PLAN.md`](plans/005-V0_0_5_RECONCILIATION_PLAN.md) — cadrage, classification et trajectoire active de la réconciliation `0.0.5` ;
|
||||
- [`studies/001-KSP_GAMES_RECONCILIATION.md`](studies/001-KSP_GAMES_RECONCILIATION.md) — inventaire comparatif des baselines KSP/Games et décisions de généralisation, maintien local ou différé.
|
||||
- [`templates/004-FILE_FAMILY_CONTRACTS.md`](templates/004-FILE_FAMILY_CONTRACTS.md) — pattern facultatif pour expliciter les responsabilités et règles de modification de familles de fichiers locales lorsque la complexité le justifie.
|
||||
|
||||
## Points d'entrée de 0.0.4
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/300-DOCUMENTATION.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Documentation rules
|
||||
|
||||
@@ -76,6 +76,26 @@ Un document sous `docs/objectives/` décrit la mission durable, les objectifs, c
|
||||
|
||||
Il MUST NOT être remplacé par `ROADMAP.md` : les objectifs expliquent pourquoi le projet existe et ce qu'il cherche à garantir ; la roadmap décrit comment sa trajectoire est découpée.
|
||||
|
||||
## Registre local de contrats de fichiers ou familles
|
||||
|
||||
Un projet MAY maintenir un registre local lorsque plusieurs fichiers ou familles durables ont des responsabilités, sources de vérité ou règles de modification qui ne sont pas suffisamment évidentes depuis leur nom, leur écosystème ou leurs owners existants.
|
||||
|
||||
Ce registre est un outil de désambiguïsation, pas un inventaire exhaustif de l'arborescence. Il MUST NOT être créé uniquement pour recopier les rôles déjà définis par PGR, un manifeste, une toolchain ou une documentation locale plus appropriée. Un petit projet dont les responsabilités sont déjà claires SHOULD ne pas créer ce document.
|
||||
|
||||
Chaque entrée utile SHOULD identifier au minimum :
|
||||
|
||||
- le fichier, motif de chemin ou famille concernée ;
|
||||
- sa responsabilité durable ;
|
||||
- la règle ou le déclencheur pertinent de modification.
|
||||
|
||||
Selon le besoin, une entrée MAY aussi préciser une source de vérité, le caractère généré/versionné, un owner local ou une validation associée. Ces champs supplémentaires ne doivent être ajoutés que s'ils réduisent réellement une ambiguïté.
|
||||
|
||||
Le nom, l'emplacement et la forme du registre appartiennent au projet destinataire. PGR n'impose ni `FILE_CONTRACTS.md`, ni une table Markdown, ni un catalogue de chaque fichier. Une liste courte, une table ou une autre forme lisible sont équivalentes si le contrat reste explicite.
|
||||
|
||||
Lorsqu'un owner existant possède déjà la règle détaillée, le registre SHOULD le référencer plutôt que dupliquer son contenu. Il est mis à jour lorsque le contrat d'une famille change réellement ; l'ajout d'un fichier conforme à une famille déjà décrite ne force pas une nouvelle entrée.
|
||||
|
||||
[`../templates/004-FILE_FAMILY_CONTRACTS.md`](../templates/004-FILE_FAMILY_CONTRACTS.md) fournit un pattern documentaire court pour les projets qui choisissent d'adopter ce registre.
|
||||
|
||||
## Taxonomie documentaire
|
||||
|
||||
La taxonomie doit rester sémantique et proportionnée. Les familles communes comprennent notamment :
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Skeleton — Project governance foundation
|
||||
|
||||
@@ -92,6 +92,8 @@ Selon la réalité du projet :
|
||||
- `docs/architecture/` est utile lorsqu'un état architectural ou un profil local doit être possédé durablement ;
|
||||
- `docs/validation/` est utile lorsqu'une matrice ou un contrat de preuve mérite un document séparé.
|
||||
|
||||
Pour un projet où plusieurs fichiers ou familles durables ont des responsabilités ou règles de modification difficiles à déduire, la fondation MAY aussi instancier un registre local selon [`../templates/004-FILE_FAMILY_CONTRACTS.md`](../templates/004-FILE_FAMILY_CONTRACTS.md). Ce registre reste facultatif : un projet simple ou déjà explicite n'a rien à matérialiser.
|
||||
|
||||
Ne pas créer ces fichiers uniquement pour reproduire l'arborescence du dépôt PGR.
|
||||
|
||||
### Workflow retenu
|
||||
|
||||
80
docs/templates/004-FILE_FAMILY_CONTRACTS.md
vendored
Normal file
80
docs/templates/004-FILE_FAMILY_CONTRACTS.md
vendored
Normal file
@@ -0,0 +1,80 @@
|
||||
<!-- file: docs/templates/004-FILE_FAMILY_CONTRACTS.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Pattern — contrats locaux de fichiers ou familles
|
||||
|
||||
## Objectif
|
||||
|
||||
Ce pattern aide un projet à expliciter quelques responsabilités de fichiers ou familles durables lorsqu'elles deviennent difficiles à déduire de l'arborescence, de la toolchain ou des règles déjà existantes.
|
||||
|
||||
Il complète le contrat documentaire de [`../rules/300-DOCUMENTATION.md`](../rules/300-DOCUMENTATION.md). Il n'impose aucun fichier particulier au projet destinataire.
|
||||
|
||||
## Quand l'utiliser
|
||||
|
||||
Créer un registre local seulement lorsqu'il réduit une ambiguïté réelle, par exemple lorsque :
|
||||
|
||||
- plusieurs familles voisines ont des rôles différents qui provoquent régulièrement des erreurs de placement ;
|
||||
- un fichier est une source de vérité tandis qu'un autre est généré ou dérivé ;
|
||||
- une famille possède une règle de modification ou de synchronisation non évidente ;
|
||||
- des contributeurs doivent savoir quel owner modifier sans relire plusieurs documents spécialisés.
|
||||
|
||||
Ne pas l'utiliser pour inventorier chaque fichier d'un petit dépôt, recopier les rôles standards déjà décrits par PGR ou dupliquer un manifeste/build system qui possède déjà l'information.
|
||||
|
||||
## Forme minimale
|
||||
|
||||
Le nom et l'emplacement appartiennent au projet destinataire. `docs/rules/FILE_CONTRACTS.md` est un nom possible, pas une convention PGR obligatoire.
|
||||
|
||||
Une entrée utile contient au minimum :
|
||||
|
||||
```text
|
||||
file or family
|
||||
responsibility
|
||||
modification rule
|
||||
```
|
||||
|
||||
Lorsque ces informations sont utiles, le projet MAY ajouter :
|
||||
|
||||
```text
|
||||
source of truth / generated status
|
||||
local owner or reference
|
||||
validation or synchronization requirement
|
||||
```
|
||||
|
||||
Une table Markdown convient aux registres structurés :
|
||||
|
||||
```markdown
|
||||
| Fichier ou famille | Responsabilité | Règle de modification |
|
||||
|--------------------|----------------|------------------------|
|
||||
| `<path-or-pattern>` | `<rôle durable>` | `<quand/comment modifier>` |
|
||||
```
|
||||
|
||||
Une liste courte est préférable lorsqu'elle reste plus lisible. La forme n'est pas normative ; la clarté de la responsabilité l'est pour le projet qui choisit d'adopter ce contrat.
|
||||
|
||||
## Règles d'adaptation
|
||||
|
||||
Lors de l'instanciation :
|
||||
|
||||
1. sélectionner uniquement les fichiers ou familles dont le contrat local apporte une information non évidente ;
|
||||
2. référencer l'owner détaillé existant au lieu de recopier ses règles ;
|
||||
3. regrouper les chemins qui partagent réellement le même contrat plutôt que créer une entrée par fichier ;
|
||||
4. distinguer explicitement source de vérité et artefact généré lorsque cette distinction existe ;
|
||||
5. supprimer ou fusionner une entrée devenue redondante lorsque son rôle est désormais évident ailleurs.
|
||||
|
||||
Le registre SHOULD évoluer lorsqu'une responsabilité ou règle de modification change réellement. Il SHOULD NOT être modifié uniquement parce qu'un nouveau fichier respecte déjà une famille décrite.
|
||||
|
||||
## Exemple abstrait
|
||||
|
||||
```markdown
|
||||
| Fichier ou famille | Responsabilité | Règle de modification |
|
||||
|--------------------|----------------|------------------------|
|
||||
| `config/*.example` | Décrire les exemples versionnés de configuration locale. | Mettre à jour lorsqu'une option utilisateur versionnée est ajoutée ou retirée ; ne jamais y placer de secret réel. |
|
||||
| `generated/**` | Contenir les sorties reconstruisibles produites par la toolchain choisie. | Ne pas modifier manuellement ; régénérer depuis la source de vérité documentée. |
|
||||
```
|
||||
|
||||
Cet exemple illustre la forme uniquement. Il ne crée aucune règle universelle sur les chemins `config/` ou `generated/`.
|
||||
|
||||
## Critère de sortie
|
||||
|
||||
Le pattern est utile si un nouveau contributeur peut déterminer plus vite où une responsabilité vit et quand modifier une famille sans devoir maintenir un catalogue parallèle du dépôt.
|
||||
|
||||
S'il ajoute davantage de cérémonie que d'information, ne pas l'instancier ou le retirer.
|
||||
114
history/0.0.5/alpha.3.md
Normal file
114
history/0.0.5/alpha.3.md
Normal file
@@ -0,0 +1,114 @@
|
||||
<!-- file: history/0.0.5/alpha.3.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.0.5-alpha.3 — pattern facultatif de contrats de fichiers ou familles
|
||||
|
||||
## Statut
|
||||
|
||||
FAIL
|
||||
|
||||
La tranche `0.0.5-alpha.3` n'est pas enregistrée `PASS` telle quelle.
|
||||
|
||||
Le contenu documentaire prévu est présent et les commandes automatisées de la gate ont toutes retourné un succès, mais la revue opérateur a identifié un défaut objectif dans `docs/templates/004-FILE_FAMILY_CONTRACTS.md` : la table d'exemple commençant à la ligne 46 n'était pas alignée alors que `scripts/audit_markdown_tables.py` annonçait un état `clean`.
|
||||
|
||||
Le diagnostic montre que l'audit ignorait tous les blocs fenced. Les tables placées dans des fences explicitement `markdown` n'étaient donc ni comptées ni validées. La preuve `PGR-MD-TABLE-001` était incomplète pour cette tranche.
|
||||
|
||||
## Baseline
|
||||
|
||||
La tranche précédente `0.0.5-alpha.2` a été committée et poussée sous le commit observé :
|
||||
|
||||
```text
|
||||
d7282dc
|
||||
```
|
||||
|
||||
Version contrôlée après application de `alpha.3` :
|
||||
|
||||
```text
|
||||
0.0.5-alpha.3
|
||||
```
|
||||
|
||||
Le scope Git observé avant le présent history est exactement :
|
||||
|
||||
```text
|
||||
M VERSION
|
||||
A deltas/0.0.5/alpha.3.md
|
||||
M docs/000-README.md
|
||||
M docs/rules/300-DOCUMENTATION.md
|
||||
M docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
|
||||
A docs/templates/004-FILE_FAMILY_CONTRACTS.md
|
||||
```
|
||||
|
||||
## Contrôles automatisés observés
|
||||
|
||||
Les `15` tests Python ont tous réussi :
|
||||
|
||||
```text
|
||||
Ran 15 tests in 0.219s
|
||||
OK
|
||||
```
|
||||
|
||||
Les audits Markdown ont annoncé :
|
||||
|
||||
```text
|
||||
Markdown header audit: clean (132 file(s))
|
||||
Markdown table audit: clean (4 table(s), 132 file(s))
|
||||
Markdown link audit: clean (127 local link(s), 132 file(s))
|
||||
```
|
||||
|
||||
L'audit structurel spécifique a également réussi :
|
||||
|
||||
```text
|
||||
0.0.5 alpha.3 file-family contract audit: clean (optional registry, short reusable pattern, no project-specific contract imported)
|
||||
```
|
||||
|
||||
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
|
||||
|
||||
## Défaut exact
|
||||
|
||||
`docs/templates/004-FILE_FAMILY_CONTRACTS.md` contient des exemples de tables sous la forme :
|
||||
|
||||
````text
|
||||
```markdown
|
||||
| ... |
|
||||
| ... |
|
||||
```
|
||||
````
|
||||
|
||||
La fonction `_audit_file` de `scripts/audit_markdown_tables.py` entrait dans un état `fence` dès l'ouverture du bloc puis ignorait toutes les lignes jusqu'à sa fermeture. Une table Markdown d'exemple pouvait donc être mal alignée sans être vue par l'audit.
|
||||
|
||||
La table signalée par l'opérateur à partir de la ligne 46 présente effectivement des largeurs brutes différentes entre header, séparateur et ligne de données. Le diagnostic du fix révèle en outre qu'une seconde table fenced du même template, dans la section `Exemple abstrait`, était masquée par le même défaut.
|
||||
|
||||
Ce comportement est hérité des audits observés dans les corpus KSP/Games, mais PGR doit corriger son propre contrat au lieu de conserver ce faux négatif.
|
||||
|
||||
## Décision
|
||||
|
||||
Aucun REPLAN n'est requis.
|
||||
|
||||
Le pattern documentaire de `alpha.3` reste pertinent. Le défaut est local à la qualité de son exemple et à la couverture de `PGR-MD-TABLE-001`.
|
||||
|
||||
La correction reste dans :
|
||||
|
||||
```text
|
||||
0.0.5-alpha.3.fix.1
|
||||
```
|
||||
|
||||
Le fix doit :
|
||||
|
||||
- auditer les tables Markdown ordinaires ;
|
||||
- auditer aussi les tables présentes dans des fences explicitement `markdown` ou `md` ;
|
||||
- continuer d'ignorer les autres fences afin d'éviter de traiter comme Markdown des sorties terminal ou tableaux ASCII d'un autre langage ;
|
||||
- ajouter des tests de régression positifs et négatifs ;
|
||||
- réaligner toutes les tables fenced du template `004` révélées par ce contrôle ;
|
||||
- préciser ce contrat dans la matrice de validation.
|
||||
|
||||
Le delta `alpha.3` reste un snapshot historique et n'est pas réécrit.
|
||||
|
||||
## Résultat
|
||||
|
||||
`0.0.5-alpha.3` est enregistré `FAIL`.
|
||||
|
||||
La transition autorisée est :
|
||||
|
||||
```text
|
||||
0.0.5-alpha.3.fix.1
|
||||
```
|
||||
Reference in New Issue
Block a user