106 lines
4.7 KiB
Markdown
106 lines
4.7 KiB
Markdown
<!-- file: history/0.0.2/alpha.1.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# History 0.0.2-alpha.1 — baseline audit and profile sizing
|
|
|
|
## Statut
|
|
|
|
FAIL
|
|
|
|
Les commandes mécaniques prévues par le delta `alpha.1` ont toutes réussi, mais la revue opérateur a identifié des défauts dans le cadrage lui-même. Comme `alpha.1` est précisément la gate d'audit, de sizing et de planification de `0.0.2`, la tranche ne doit pas être déclarée PASS tant que ces défauts ne sont pas corrigés.
|
|
|
|
## Baseline
|
|
|
|
Archive source issue du tag stable Gitea :
|
|
|
|
```text
|
|
v0.0.1
|
|
```
|
|
|
|
Version observée après application du delta :
|
|
|
|
```text
|
|
0.0.2-alpha.1
|
|
```
|
|
|
|
L'absence de `.git` dans l'archive de baseline reste normale et n'a pas été traitée comme une anomalie.
|
|
|
|
## Validation opérateur observée
|
|
|
|
Les commandes communiquées par l'opérateur ont réussi :
|
|
|
|
```bash
|
|
test "$(cat VERSION)" = "0.0.2-alpha.1"
|
|
|
|
test -f docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
|
|
test -f deltas/0.0.2/alpha.1.md
|
|
|
|
grep -F 'Plan actif créé pendant `0.0.2-alpha.1`' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
|
|
grep -F 'Aucun défaut bloquant de gouvernance' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
|
|
grep -F '### alpha.2 — Rule profile model' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
|
|
grep -F '### alpha.8 — Tauri desktop/mobile' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
|
|
|
|
grep -F -- '- `( ) 0.0.2`' ROADMAP.md
|
|
grep -F 'v0.0.1' prompts/002-V0_0_2_START_PROMPT.md
|
|
|
|
git diff --check
|
|
|
|
git add VERSION docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md deltas/0.0.2/alpha.1.md
|
|
|
|
git diff --cached --check
|
|
|
|
git status --short
|
|
```
|
|
|
|
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
|
|
|
|
La sortie finale observée avant ajout du présent history est exactement :
|
|
|
|
```text
|
|
M VERSION
|
|
A deltas/0.0.2/alpha.1.md
|
|
A docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
|
|
```
|
|
|
|
## Défauts identifiés par revue
|
|
|
|
### Tableau Markdown non aligné
|
|
|
|
Le tableau `Inventaire des profils candidats` est syntaxiquement lisible par Markdown, mais ses colonnes ne sont pas alignées dans le source. Le défaut est visible immédiatement lors d'une revue et n'a pas été détecté par la gate `alpha.1`.
|
|
|
|
Un audit réutilisé en diagnostic depuis les projets sources confirme le défaut sur les quatre colonnes du tableau.
|
|
|
|
Ce cas fournit une propriété stable et objectivement automatisable : l'alignement source des tableaux Markdown. Il justifie l'introduction d'un premier audit PGR monotâche et read-only au lieu d'ajouter un contrôle manuel supplémentaire.
|
|
|
|
### Sizing trop large
|
|
|
|
Le plan initial conservait, après `alpha.1`, sept tranches technologiques `alpha.2` à `alpha.8` avant réconciliation et RC.
|
|
|
|
Ce découpage est trop ambitieux pour l'objectif de dimensionnement « une version complète par session », surtout avant d'avoir mesuré le coût réel du premier profil. L'opérateur demande explicitement de privilégier l'exécution correcte du scope retenu plutôt que de matérialiser trop de profils dans `0.0.2`.
|
|
|
|
Le fix doit donc réduire le scope initial de la release à un ensemble minimal mais représentatif : modèle de profil, Rust/Cargo, Java/Maven/Gradle et Android. Les compositions Rust+Android/JNI, Web/WASM et Tauri restent candidates mais sont différées.
|
|
|
|
### Preuve post-tag `publish.001` déjà disponible
|
|
|
|
La revue initiale avait correctement conclu que `publish.001` ne pouvait pas faire partie du tag `v0.0.1`, mais elle n'avait pas retrouvé le rapport post-tag déjà conservé hors du tag.
|
|
|
|
Le rapport `pgr-0.0.1-publish.001-report.md` existe dans la bibliothèque de travail et indique `Status: PASS` pour l'archive `pgr-v0.0.1.zip`, avec le SHA-256 attendu.
|
|
|
|
Cette preuve ne doit pas être injectée rétroactivement dans le tag stable. Elle doit simplement être reconnue comme preuve post-publication externe à la baseline source.
|
|
|
|
La maturité future de PGR devra également permettre aux handoffs/prompts de reprise d'indiquer explicitement si un tel rapport post-publication doit être fourni à la session suivante. Cette amélioration de workflow ne doit toutefois pas élargir `0.0.2`.
|
|
|
|
## Conséquence
|
|
|
|
`0.0.2-alpha.1` est enregistré en `FAIL`.
|
|
|
|
La tranche suivante est `0.0.2-alpha.1.fix.1`, strictement limitée au cadrage de `alpha.1` :
|
|
|
|
- corriger le tableau Markdown du plan ;
|
|
- reconnaître correctement le rapport post-tag `publish.001` déjà disponible sans modifier `v0.0.1` ;
|
|
- réduire le nombre de profils matérialisés dans `0.0.2` ;
|
|
- introduire un premier audit Markdown monotâche, read-only et sans dépendance externe, parce qu'un défaut réel vient d'en démontrer la nécessité ;
|
|
- enregistrer ce nouvel audit dans la matrice de validation.
|
|
|
|
Aucune règle technologique prévue pour `alpha.2+` ne doit être absorbée dans le fix.
|