pgr/history/0.0.2/alpha.1.md

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 :

v0.0.1

Version observée après application du delta :

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 :

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 :

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.