0.0.3-alpha.1
This commit is contained in:
101
deltas/0.0.3/alpha.1.md
Normal file
101
deltas/0.0.3/alpha.1.md
Normal file
@@ -0,0 +1,101 @@
|
||||
<!-- file: deltas/0.0.3/alpha.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.0.3-alpha.1 — audit de baseline et cadrage
|
||||
|
||||
## Baseline
|
||||
|
||||
Archive fournie `pgr-v0.0.2.zip`, déclarée téléchargée du tag Gitea `v0.0.2`, vérifiée avec SHA-256 :
|
||||
|
||||
```text
|
||||
8dc5c979a4d722b4ef6ec84b6227c8cbfffb3f865f4ea9063c03ecb1e365cdc4
|
||||
```
|
||||
|
||||
Le rapport post-tag externe `pgr-0.0.2-publish.001-report.md` indique `PASS` et le même hash. Il n'est pas ajouté rétroactivement à la stable. Aucun `.git` n'est attendu dans l'archive source.
|
||||
|
||||
Version avant application : `0.0.2`.
|
||||
|
||||
Version après application : `0.0.3-alpha.1`.
|
||||
|
||||
## Objet
|
||||
|
||||
Exécuter le cadrage demandé par `prompts/003-V0_0_3_START_PROMPT.md` : audit complet de la stable, vérification des règles et de la chaîne historique, inventaire des sujets utiles, choix d'un scope initial et découpage proportionné dans un plan actif.
|
||||
|
||||
Le résultat détaillé de l'audit, ses limites et les décisions de scope sont consignés dans `docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md`. L'archive est cohérente dans les contrôles réalisés ; aucune correction rétroactive de `0.0.2` n'est nécessaire avant cette tranche.
|
||||
|
||||
## Scope
|
||||
|
||||
REPLACE :
|
||||
|
||||
```text
|
||||
VERSION
|
||||
```
|
||||
|
||||
ADD :
|
||||
|
||||
```text
|
||||
docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
|
||||
deltas/0.0.3/alpha.1.md
|
||||
```
|
||||
|
||||
DELETE : aucun.
|
||||
|
||||
L'archive delta contient exactement les fichiers complets ci-dessus, avec les mêmes chemins relatifs. Aucun manifest de suppression, history, nouveau template ou script d'audit n'appartient à cette tranche.
|
||||
|
||||
Les index et les documents historiques restent conformes sans mise à jour cérémonielle : la roadmap annonce déjà `0.0.3`, le changelog conserve les releases stables et les index documentaires pointent vers les collections existantes.
|
||||
|
||||
## Validation opérateur
|
||||
|
||||
Appliquer l'archive delta à la copie de travail du dépôt fondée sur `v0.0.2`. Depuis sa racine :
|
||||
|
||||
```bash
|
||||
test "$(cat VERSION)" = '0.0.3-alpha.1'
|
||||
test -f docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
|
||||
test -f deltas/0.0.3/alpha.1.md
|
||||
test ! -e history/0.0.3/alpha.1.md
|
||||
|
||||
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
|
||||
|
||||
files = [Path(name) for name in ('README.md', 'RULES.md', 'ROADMAP.md', 'CHANGELOG.md')]
|
||||
for directory in ('docs', 'deltas', 'history', 'prompts'):
|
||||
files.extend(Path(directory).rglob('*.md'))
|
||||
files = sorted(set(files))
|
||||
for path in files:
|
||||
lines = path.read_text(encoding='utf-8').splitlines()
|
||||
assert len(lines) >= 2 and lines[0] == f'<!-- file: {path.as_posix()} -->', path
|
||||
assert re.fullmatch(r'<!-- version: [1-9][0-9]* -->', lines[1]), path
|
||||
print(f'Markdown header audit: clean ({len(files)} file(s))')
|
||||
PY
|
||||
|
||||
git diff --check
|
||||
git add VERSION docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md deltas/0.0.3/alpha.1.md
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
Avant d'ajouter le history, le scope attendu des fichiers indexés est :
|
||||
|
||||
```text
|
||||
M VERSION
|
||||
A docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
|
||||
A deltas/0.0.3/alpha.1.md
|
||||
```
|
||||
|
||||
L'opérateur confirme également que la baseline provient bien du tag déclaré, que le hash concorde avec la preuve post-tag, que les `24` couples historiques antérieurs sont conservés, que les profils différés ne sont pas matérialisés, et que le plan ne fait pas passer une prévision pour une règle déjà active.
|
||||
|
||||
## Transition
|
||||
|
||||
### PASS
|
||||
|
||||
Rédiger et livrer séparément `history/0.0.3/alpha.1.md` avec les résultats réellement observés ; l'appliquer et committer la tranche. Préparer seulement ensuite `0.0.3-alpha.2`.
|
||||
|
||||
### FAIL
|
||||
|
||||
Enregistrer le résultat réellement observé dans le history de `alpha.1`, puis corriger le cadrage dans `0.0.3-alpha.1.fix.1` ou produire un REPLAN motivé. Aucune implémentation `alpha.2` ne doit être absorbée dans le fix.
|
||||
102
docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
Normal file
102
docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
Normal file
@@ -0,0 +1,102 @@
|
||||
<!-- file: docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Plan 0.0.3 — templates initiaux et audits réutilisables
|
||||
|
||||
## Statut et sources
|
||||
|
||||
Plan de cadrage proposé dans `0.0.3-alpha.1`. Les tranches suivantes sont une prévision, non un état validé. Aucun template ni audit nouveau n'est encore matérialisé.
|
||||
|
||||
La source autoritaire est l'archive Gitea fournie `pgr-v0.0.2.zip`, issue selon l'opérateur du tag `v0.0.2`. Son SHA-256 vérifié localement est :
|
||||
|
||||
```text
|
||||
8dc5c979a4d722b4ef6ec84b6227c8cbfffb3f865f4ea9063c03ecb1e365cdc4
|
||||
```
|
||||
|
||||
Le rapport séparé `pgr-0.0.2-publish.001-report.md` indique `PASS` et donne le même hash. Il atteste la publication post-tag sans appartenir au tag. L'archive sans `.git` ne peut prouver indépendamment le commit ni l'identité du tag ; ces éléments sont les déclarations et preuves de publication de l'opérateur.
|
||||
|
||||
Le contrat de démarrage est `prompts/003-V0_0_3_START_PROMPT.md`. Les règles applicables partent de `RULES.md`, puis des familles `200`, `210`, `300`, `400`, du modèle de profils `003` et des profils `500`/`510`, `520`, `600`/`610` selon leur scope. PGR reste un dépôt documentaire avec deux utilitaires Python ; les toolchains Rust, Java et Android ne deviennent pas des prérequis du dépôt.
|
||||
|
||||
## Audit indépendant de la stable `v0.0.2`
|
||||
|
||||
L'inspection de l'archive, sa lecture et la comparaison des fichiers extraits avec les membres ZIP ont établi :
|
||||
|
||||
- ZIP lisible, `94` entrées : `78` fichiers et `16` répertoires, une seule racine `pgr/` ; aucun doublon, chemin absolu, traversée `..`, chemin Windows ambigu ou lien symbolique ;
|
||||
- exactement `78` fichiers extraits ; `VERSION` contient `0.0.2` avec un seul retour final à la ligne ; `.git` absent comme attendu ;
|
||||
- octets des fichiers distribués décodables en UTF-8, sans NUL, CR, espace de fin de ligne ou retour final manquant ;
|
||||
- `73` fichiers Markdown dont les deux premières lignes correspondent exactement au chemin relatif `file` et à une révision positive `version` ;
|
||||
- contrôle local des deux scripts existants : `Markdown table audit: clean (2 table(s), 73 file(s))` et `Markdown link audit: clean (50 local link(s), 73 file(s))` ;
|
||||
- aucun répertoire de build/cache ou fichier local sensible connu dans les chemins distribués ; seule la préférence Eclipse UTF-8 intentionnellement conservée est présente sous `.settings/`.
|
||||
|
||||
La vérification de structure et de gouvernance a constaté :
|
||||
|
||||
- `12` deltas et `12` histories appariés exactement dans chacune des séries `0.0.1` et `0.0.2`, y compris `rel.001` ; chaque history possède un statut explicite ;
|
||||
- les versions `avant`/`après` déclarées dans tous les deltas `0.0.2` forment une chaîne continue de `0.0.1` à `0.0.2` ; les deltas `0.0.1` au format homogène depuis `alpha.1.fix.2` forment également une chaîne continue jusqu'à la stable ;
|
||||
- dans `0.0.1`, les `FAIL` de `alpha.1`, `alpha.1.fix.1`, `alpha.4` et `rc.1` sont suivis d'une tranche corrective `PASS` ; dans `0.0.2`, même traitement pour `alpha.1`, `alpha.4`, `beta.1` et `rc.1` ; les deux `rel.001` sont `PASS` ;
|
||||
- `README.md`, `ROADMAP.md` et `CHANGELOG.md` présentent `0.0.2` comme terminé et `0.0.3` comme prévu ; les plans `001` et `002` restent historiques ; le prompt `003` nomme l'archive et la preuve post-tag fournies ;
|
||||
- séparation cohérente entre objectifs durables, architecture, règles normatives, validation, plans, deltas prospectifs, histories rétrospectifs et changelog stable ; les index pointent vers les familles et profils réellement présents ;
|
||||
- les profils réellement matérialisés sont `510` Rust/Cargo, `520` Java/Maven/Gradle et `610` Android ; les seuls scripts d'audit PGR sont ceux des tableaux et des liens Markdown locaux. Aucun skeleton, générateur ou profil différé n'est présent.
|
||||
|
||||
Aucun écart bloquant n'a été constaté dans ces contrôles. Les scripts Markdown ont chacun une portée volontairement limitée : le contrôle des liens vérifie l'existence des cibles inline locales, pas les ancres ; celui des tableaux vérifie leur structure source. Leur PASS n'atteste donc pas des propriétés hors de leur contrat.
|
||||
|
||||
## Sélection des templates
|
||||
|
||||
### Retenu : configuration `rustfmt.toml`
|
||||
|
||||
Le profil `510-RUST_CARGO.md` possède déjà le contrat de formatage et donne les paramètres issus des corpus éprouvés. Un fichier de configuration minimal, accompagné d'instructions de copie et d'adaptation de l'édition Rust au projet, apporte une valeur immédiate. Il appartient au scope Rust/Cargo, sans imposer à PGR une toolchain Rust, un pin de version ou le layout d'un projet complet.
|
||||
|
||||
Avant de livrer le template, vérifier dans les corpus réellement disponibles que chaque option reste utile et compatible avec la toolchain cible ; expliciter comment adapter `edition` et la largeur. La validation de formatage s'effectuera sur un sujet Rust de test lorsque l'environnement le permet, sans prétendre compiler PGR.
|
||||
|
||||
### Candidat conditionnel : template de prompt manuel de nouvelle session
|
||||
|
||||
Les prompts `002` et `003` montrent un besoin récurrent de transmission de la baseline taggée, du rapport post-tag lorsqu'il existe et de la mission suivante. Une courte spécification Markdown réutilisable pourrait décrire les champs nécessaires et leur responsabilité, sans produire un générateur ni un prompt dupliquant tout le plan. La tranche dédiée n'est retenue qu'après avoir démontré que cette factorisation simplifie effectivement la prochaine clôture.
|
||||
|
||||
### Différés
|
||||
|
||||
Les fichiers Maven/Gradle complets, wrappers, Android `local.properties` ou signing, règles `.gitignore` universelles et catalogues de versions ne sont pas copiés par anticipation. Les profils `520` et `610` définissent des contraintes, mais aucun projet sujet et aucune matrice AGP/Gradle/JDK concrète n'ont été fournis à cette session pour choisir leurs valeurs. Les wrappers restent soumis aux outils officiels et à la décision du projet ; un `local.properties` entièrement régénéré ne justifie pas d'exemple.
|
||||
|
||||
Les spécifications complètes de skeleton restent réservées à `0.0.4` ; Rust/JNI, Web/WASM, Tauri et les autres profils différés n'entrent pas dans cette release par simple proximité technologique.
|
||||
|
||||
## Sélection des audits et patterns
|
||||
|
||||
Les deux audits existants (`tables`, `liens locaux`) sont les premiers patterns concrets : une propriété chacun, sélection explicite de chemins, lecture seule, messages déterministes et aucune invocation de toolchain. Ils doivent rester séparés.
|
||||
|
||||
Un contrôle supplémentaire de headers Markdown est candidat prioritaire. La propriété est précise : pour chaque fichier Markdown choisi, comparer `<!-- file: ... -->` à son chemin relatif et vérifier `<!-- version: N -->` avec `N >= 1`. Son owner est `docs/rules/300-DOCUMENTATION.md`, son sujet réel est le corpus de `73` Markdown PGR, et les gates précédents répètent ce contrôle en Python inline. Ni le compilateur ni les deux scripts existants ne le couvrent. Sa matérialisation doit garder la sélection de chemins explicite et tester au moins un header erroné, un header correct et un chemin absent.
|
||||
|
||||
Les scripts d'audit Rust historiques de KSP et `sasedev-games` ne sont pas inclus dans l'archive fournie. Ils restent des corpus de comparaison à examiner sur leurs sources réelles avant toute extraction d'une propriété spécialisée. Un audit Rust/Java/Android ne sera pas créé sans sujet concret et sans valeur distincte des outils officiels. Le contrôle manuel du pairing delta/history reste suffisant à ce stade ; aucune collection d'audits n'est ouverte pour remplir une taxonomie.
|
||||
|
||||
## Trajectoire prévisionnelle
|
||||
|
||||
### alpha.1 — intake et dimensionnement
|
||||
|
||||
Enregistrer l'audit de la stable, confronter le prompt au dépôt réel, inventorier les candidats, fixer le scope et produire le présent plan ainsi que le delta. Aucune matérialisation technique importante. Attendre la validation opérateur, le history distinct et le commit avant tout delta suivant.
|
||||
|
||||
### alpha.2 — template Rust ciblé
|
||||
|
||||
Créer uniquement la configuration `rustfmt.toml` et ses instructions de sélection/adaptation ; vérifier sa conformité au profil `510` et la portée de sa validation. Si la vérification d'un corpus ou la forme du template révèle un besoin plus large, revoir le plan.
|
||||
|
||||
### alpha.3 — audit de headers Markdown
|
||||
|
||||
Extraire le contrôle récurrent en un script read-only monotâche, documenter sa portée dans la matrice et vérifier des cas positifs et négatifs utiles. Ne pas fusionner cet audit avec les deux audits Markdown existants.
|
||||
|
||||
### alpha.4 — décision sur le template de workflow
|
||||
|
||||
Factoriser le prompt manuel seulement si la revue des prompts et du workflow confirme un bénéfice net ; sinon constater explicitement son report et passer à la stabilisation sans artefact artificiel.
|
||||
|
||||
### beta.1 — réconciliation
|
||||
|
||||
Vérifier ownership, navigation, séparation règle/template/audit, absence de versions universelles arbitraires et proportion des contrôles. Aucun nouveau domaine majeur sans REPLAN.
|
||||
|
||||
### rc.1 — gate de release candidate
|
||||
|
||||
Geler le scope, préparer le changelog et le prompt de la version suivante si la trajectoire est confirmée ; exécuter la gate documentaire et les vérifications ciblées des scripts réellement ajoutés.
|
||||
|
||||
### stable — 0.0.3
|
||||
|
||||
Promouvoir la RC validée, produire le history de clôture pré-tag, committer et tagger, puis contrôler séparément l'archive du tag publiée.
|
||||
|
||||
## Points de décision et validation
|
||||
|
||||
Le plan doit être revu si le template exige une toolchain figée, si l'audit de headers ne peut rester fiable et monotâche, si le template de workflow duplique le plan, ou si une comparaison du corpus réel révèle des contraintes nouvelles. Un REPLAN explicite indique `CONTINUE`, `SPLIT`, `CONTINUE-NEXT-SESSION` ou `ABANDON` ; la durée d'une conversation ne crée pas une nouvelle version.
|
||||
|
||||
La validation `alpha.1` est documentaire : identité de `VERSION`, portée du delta, headers et audits Markdown, revue des owners et des candidats, absence de changement historique rétroactif, contrôle Git dans le dépôt de l'opérateur. La prévalidation de l'archive source et du delta ne devient pas à elle seule un PASS opérateur ; ce résultat appartient au futur `history/0.0.3/alpha.1.md`.
|
||||
55
history/0.0.3/alpha.1.md
Normal file
55
history/0.0.3/alpha.1.md
Normal file
@@ -0,0 +1,55 @@
|
||||
<!-- file: history/0.0.3/alpha.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.0.3-alpha.1 — cadrage initial
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
Les contrôles mécaniques demandés par le delta `alpha.1` ont été exécutés par l'opérateur et ont réussi. La revue complémentaire, après ce gate, demande d'élargir le plan des templates Rust à Cargo et Clippy en examinant les archives de référence KSP et Games. Cette précision documentaire sera une tranche `.fix.1` distincte, après application du présent history et commit de `alpha.1`.
|
||||
|
||||
## Baseline et version
|
||||
|
||||
Baseline déclarée : archive issue du tag `v0.0.2`, accompagnée du rapport `pgr-0.0.2-publish.001-report.md` contrôlé pendant le cadrage. Version validée après application de `alpha.1` :
|
||||
|
||||
```text
|
||||
0.0.3-alpha.1
|
||||
```
|
||||
|
||||
## Validation opérateur observée
|
||||
|
||||
L'opérateur a fourni les sorties du `2026-09-23` à `16:41:08`–`16:41:09` depuis `~/Projects/pgr`. Les quatre contrôles de version, présence du plan et du delta, et absence du history courant ont terminé sans erreur :
|
||||
|
||||
```text
|
||||
test "$(cat VERSION)" = '0.0.3-alpha.1'
|
||||
test -f docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
|
||||
test -f deltas/0.0.3/alpha.1.md
|
||||
test ! -e history/0.0.3/alpha.1.md
|
||||
```
|
||||
|
||||
Audits documentaires observés :
|
||||
|
||||
```text
|
||||
Markdown table audit: clean (2 table(s), 75 file(s))
|
||||
Markdown link audit: clean (50 local link(s), 75 file(s))
|
||||
Markdown header audit: clean (75 file(s))
|
||||
```
|
||||
|
||||
Les commandes `git diff --check` et `git diff --cached --check` n'ont émis aucun diagnostic. Après `git add` des trois chemins du delta, `git status --short` a affiché :
|
||||
|
||||
```text
|
||||
M VERSION
|
||||
A deltas/0.0.3/alpha.1.md
|
||||
A docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
|
||||
```
|
||||
|
||||
La copie fournie du terminal contient un fragment de collage `ck` après le heredoc Python ; les commandes Git et leur sortie apparaissent ensuite séparément et sans erreur. Ce fragment ne modifie pas les trois résultats d'audit ni le scope Git observé.
|
||||
|
||||
## Revue post-gate et décision
|
||||
|
||||
La revue du plan après réussite mécanique a relevé une lacune de dimensionnement : le profil PGR `510` et les deux projets de référence justifient d'examiner `Cargo.toml` racine, `Cargo.toml` de crate membre et les deux niveaux de configuration Clippy en plus de `rustfmt.toml`.
|
||||
|
||||
Les archives de référence ont été fournies après l'exécution de la gate initiale. Leur étude et la correction du plan constituent le scope documentaire de `alpha.1.fix.1` ; elles ne sont pas présentées rétroactivement comme des preuves exécutées par l'opérateur pendant `alpha.1`.
|
||||
|
||||
Appliquer le présent history puis committer `alpha.1` avant d'appliquer le delta `alpha.1.fix.1`. Aucun commit, push ou gate de fix n'est déclaré observé ici.
|
||||
Reference in New Issue
Block a user