diff --git a/README.md b/README.md index 26ae82e..aed09e5 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ - + # Project Governance Rules @@ -11,7 +11,7 @@ Le dépôt officiel est `https://git.sasedev.com/Sasedev/pgr`. ## Statut -PGR est actuellement en phase de fondation `0.0.x`. +PGR a clôturé sa phase de fondation `0.0.x` et construit actuellement sa première baseline réutilisable `0.1.0`. La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` établit la gouvernance normative et documentaire de PGR lui-même. La release `0.0.2` ajoute les premiers profils réutilisables Rust/Cargo, Java/Maven/Gradle et Android, ainsi que deux audits Markdown. La release `0.0.3` fournit les premiers modèles Rust/Cargo, deux audits de style Rust facultatifs, l'audit des headers Markdown et la spécification du message manuel de reprise. La release `0.0.4` définit le contrat transversal des skeleton specifications, ajoute une fondation composable de gouvernance locale et une première spécialisation Rust/Cargo workspace fondée sur les profils `500 + 510` et les cinq templates existants. La release `0.0.5` réconcilie PGR avec les baselines réelles de `khadhroony-solana-project` et `sasedev-games` : prompts versionnés, contrats documentaires locaux, lifecycle inter-release, profil Rust strict et audits monotâches, premier profil Tauri 2 et décision explicite de différer son skeleton complet jusqu'à matérialisation d'owners Web suffisants. @@ -29,6 +29,7 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é - [`docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md`](docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md) — plan historique des templates et audits `0.0.3` ; - [`docs/plans/004-V0_0_4_SKELETONS_PLAN.md`](docs/plans/004-V0_0_4_SKELETONS_PLAN.md) — plan historique des skeleton specifications `0.0.4` ; - [`docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md`](docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md) — plan historique de réconciliation `0.0.5` ; +- [`docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md`](docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md) — plan actif de la première baseline réutilisable `0.1.0` ; - [`docs/studies/001-KSP_GAMES_RECONCILIATION.md`](docs/studies/001-KSP_GAMES_RECONCILIATION.md) — étude de réconciliation et classification des écarts entre PGR, KSP et Games ; - [`docs/skeletons/000-README.md`](docs/skeletons/000-README.md) — index des skeleton specifications et de leur contrat de composition ; - [`docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) — fondation composable de gouvernance locale pour un projet adoptant PGR ; diff --git a/VERSION b/VERSION index bbdeab6..d6711f8 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.0.5 +0.1.0-alpha.1 diff --git a/deltas/0.1.0/alpha.1.md b/deltas/0.1.0/alpha.1.md new file mode 100644 index 0000000..b721e3d --- /dev/null +++ b/deltas/0.1.0/alpha.1.md @@ -0,0 +1,202 @@ + + + +# Delta 0.1.0-alpha.1 — audit de la stable et cadrage de la baseline réutilisable + +## Baseline et sources + +Baseline PGR autoritaire : `pgr-v0.0.5.zip`, archive source téléchargée depuis le tag Gitea `v0.0.5`, accompagnée du rapport externe `pgr-0.0.5-publish.001-report.md` avec statut `PASS`. + +SHA-256 vérifiés : + +```text +pgr-v0.0.5.zip 1fb72bafb24b5a0f3406561b96caa8245142a5f099e692842d9ef1ba44f41b49 +pgr-0.0.5-publish.001-report.md a6727fd1f3122dbb19eb79d6b904ebaed2bbfc360ed4a34cc1299cb2166efd96 +games-v0.3.6.zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8 +khadhroony-solana-project-v0.3.16.zip db3cc1b3fc3fb07ee864b02e2a7346c673d4cf63b33e8e872aca6c6458856ca0 +``` + +Games et KSP sont uniquement des corpus de pression pour préparer l'adoption future ; ils ne sont ni modifiés ni incorporés à cette archive delta. + +Version avant application : + +```text +0.0.5 +``` + +Version après application : + +```text +0.1.0-alpha.1 +``` + +## Objet + +Exécuter `prompts/006-V0_1_0_START_PROMPT.md` : auditer intégralement la stable `v0.0.5`, ses règles, profils, templates, skeletons, audits, décisions différées et chaîne de gouvernance, puis créer le plan de la première baseline réellement réutilisable avant tout changement normatif important. + +La tranche consigne également les décisions de cadrage acquises pendant la reprise : + +- corriger en `0.1.0` la convention future `rel.001` vers `rel.1` sans réécrire l'historique ; +- distinguer le nom de tranche de fermeture du commit qui établit finalement la stable `X.Y.Z` ; +- formaliser le handoff automatique des commandes Git après chaque history et des commandes/preuves de publication avant/après tag ; +- traiter Web, serveur Rust/Actix, Java/Android, WASM et Tauri dans des releases `0.1.x` séparées, jamais comme un bloc unique `0.1.0` ; +- préparer l'adoption de PGR par Games dès que son sous-ensemble requis est prêt, puis par KSP dont la pression est principalement Rust/Cargo + Tauri. + +Aucune de ces corrections n'est encore matérialisée normativement dans `alpha.1`. + +## Résultat de l'audit d'intake + +La stable et son rapport post-tag sont cohérents. L'archive contient `225` entrées sous `pgr/`, `194` fichiers et `31` répertoires, CRC propre, aucun symlink et aucune métadonnée `.git` attendue. + +La suite PGR donne `48/48` tests `PASS`. Les audits Markdown sont propres : `171` fichiers pour les headers, `8` tables sur `171` fichiers et `161` liens locaux sur `171` fichiers. + +Les `62` couples delta/history de `0.0.1` à `0.0.5` sont complets. Les `19` histories de `0.0.5` conservent leurs statuts réels, notamment `rel.001` `FAIL` puis `rel.001.fix.1` `PASS`. + +Les owners actuels couvrent déjà Rust/Cargo (`510`), Java/Maven/Gradle (`520`), Android (`610`) et Tauri (`710`). Les templates techniques actuels sont Rust/Cargo ; les skeletons concrets sont la fondation de gouvernance et le workspace Rust/Cargo. Le skeleton Tauri reste correctement `DEFER` tant que les owners Web manquants ne sont pas matérialisés. + +Games `0.3.6` confirme une pression réelle Web/Vite/TypeScript/Sass, Android/Gradle, Rust/WASM et Tauri, avec `0.3.7` réservé dans son propre roadmap à l'alignement PGR. KSP `0.3.16` contient six applications Tauri et un socle essentiellement Rust/Cargo. Ces observations servent au sizing futur et ne créent aucun profil dans cette tranche. + +## Scope + +REPLACE : + +```text +VERSION +README.md +docs/000-README.md +``` + +ADD : + +```text +docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md +deltas/0.1.0/alpha.1.md +``` + +DELETE : aucun. + +`RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, les règles, profils, templates, skeletons, scripts et histories existants restent inchangés dans `alpha.1`. + +Aucun `history/0.1.0/alpha.1.md` n'est anticipé avant la gate opérateur. + +## Validation opérateur + +Après application sur la stable `0.0.5`, depuis la racine du dépôt : + +```bash +test "$(cat VERSION)" = '0.1.0-alpha.1' +test -f docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md +test -f deltas/0.1.0/alpha.1.md +test ! -e history/0.1.0/alpha.1.md + +grep -Fx '' README.md +grep -Fx '' docs/000-README.md +grep -F '006-V0_1_0_REUSABLE_BASELINE_PLAN.md' README.md docs/000-README.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 + +expected = { + '0.0.1': 12, + '0.0.2': 12, + '0.0.3': 10, + '0.0.4': 9, + '0.0.5': 19, +} +for release, count in expected.items(): + deltas = {path.name for path in Path('deltas', release).glob('*.md')} + histories = {path.name for path in Path('history', release).glob('*.md')} + assert len(deltas) == count, (release, len(deltas)) + assert deltas == histories, (release, sorted(deltas ^ histories)) + +statuses = {} +for path in Path('history/0.0.5').glob('*.md'): + text = path.read_text(encoding='utf-8') + match = re.search(r'## Statut\s+(PASS|FAIL|PARTIAL|BLOCKED)\s', text) + assert match is not None, path + statuses[path.name] = match.group(1) +assert statuses['rel.001.md'] == 'FAIL' +assert statuses['rel.001.fix.1.md'] == 'PASS' + +for path in ( + Path('docs/rules/510-RUST_CARGO.md'), + Path('docs/rules/520-JAVA_MAVEN_GRADLE.md'), + Path('docs/rules/610-ANDROID.md'), + Path('docs/rules/710-TAURI.md'), + Path('docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md'), + Path('docs/skeletons/002-RUST_CARGO_WORKSPACE.md'), + Path('docs/studies/002-TAURI_SKELETON_DECISION.md'), +): + assert path.is_file(), path + +plan = Path('docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md').read_text(encoding='utf-8') +for phrase in ( + 'rel.1', + 'première tranche qui obtient le PASS stable', + 'Commandes opérateur et publication', + 'une release/session par domaine cohérent', + 'Games', + 'KSP', + 'TypeScript', + 'Vite', + 'Android', + 'WASM', + 'Tauri', + 'Actix Web ou autre framework', + 'beta.1 — réconciliation finale et revue d\'horizon', +): + assert phrase in plan, phrase + +assert '- `( ) 0.1.0`' in Path('ROADMAP.md').read_text(encoding='utf-8') +assert '- `( ) 0.1.1`' not in Path('ROADMAP.md').read_text(encoding='utf-8') +print('0.1.0 alpha.1 structural audit: clean (62 prior pairs, stable workflow truth preserved, future 0.1.x unnumbered)') +PY + +git diff --check +git add VERSION README.md docs/000-README.md \ + docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md \ + deltas/0.1.0/alpha.1.md +git diff --cached --check +git status --short +``` + +Le scope indexé attendu avant ajout du history est : + +```text +M README.md +M VERSION +A deltas/0.1.0/alpha.1.md +M docs/000-README.md +A docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md +``` + +La revue opérateur doit également confirmer que : + +- le plan ne transforme pas les futurs axes `0.1.x` en versions numérotées prématurément ; +- Java/Android et Tauri sont reconnus comme profils existants, non recréés artificiellement ; +- le `DEFER` du skeleton Tauri reste intact dans cette tranche ; +- Games et KSP restent des corpus externes non modifiés ; +- aucune règle Web/WASM/Actix n'est introduite dans `alpha.1` ; +- les anciennes occurrences `rel.001*` restent intactes et historiques. + +## Transition + +### PASS + +Produire `history/0.1.0/alpha.1.md` à partir des résultats réellement observés. Dans la même réponse, si aucune décision nouvelle n'est ouverte, préparer séparément le delta `0.1.0-alpha.2` consacré uniquement à la clôture stable `rel.N` et à l'identité du commit final. + +Après remise du history, fournir spontanément le bloc Git exact à exécuter pour fermer `alpha.1` avant application du delta suivant, même si la règle normative des handoffs automatiques ne sera matérialisée qu'en `alpha.3`. + +### FAIL + +Consigner le résultat réel dans le history, puis ouvrir `0.1.0-alpha.1.fix.1` ou un REPLAN selon la cause. Aucun changement de `alpha.2` ne doit être absorbé silencieusement dans le fix. diff --git a/docs/000-README.md b/docs/000-README.md index 5f235c9..1a56d05 100644 --- a/docs/000-README.md +++ b/docs/000-README.md @@ -1,5 +1,5 @@ - + # Documentation PGR @@ -20,6 +20,10 @@ D'autres collections telles que `ideas/`, `studies/`, `reference/` ou `formats/` Les templates techniques copiables sous `templates/` restent séparés des instructions documentaires sous `docs/templates/`. Les répertoires workflow de racine (`deltas/`, `history/`, `handoffs/`, `manifests/`, `prompts/`, `scripts/`) restent séparés de `docs/` parce qu'ils portent le processus de développement et de livraison lui-même. +## Points d'entrée de 0.1.0 + +- [`plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md`](plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md) — audit de la stable `v0.0.5`, cadrage du workflow de clôture/publication et préparation de la première baseline PGR réellement réutilisable. + ## Points d'entrée de 0.0.5 - [`plans/005-V0_0_5_RECONCILIATION_PLAN.md`](plans/005-V0_0_5_RECONCILIATION_PLAN.md) — périmètre et décisions de la release `0.0.5` ; diff --git a/docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md b/docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md new file mode 100644 index 0000000..25f0a28 --- /dev/null +++ b/docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md @@ -0,0 +1,257 @@ + + + +# Plan 0.1.0 — première baseline PGR réutilisable + +## Statut et sources + +Plan actif créé pendant `0.1.0-alpha.1` conformément à `prompts/006-V0_1_0_START_PROMPT.md` après audit indépendant de la stable taggée `v0.0.5` et de son rapport post-tag. + +Sources autoritaires de reprise : + +```text +pgr-v0.0.5.zip 1fb72bafb24b5a0f3406561b96caa8245142a5f099e692842d9ef1ba44f41b49 +pgr-0.0.5-publish.001-report.md a6727fd1f3122dbb19eb79d6b904ebaed2bbfc360ed4a34cc1299cb2166efd96 +``` + +Le rapport `publish.001` est `PASS` et porte sur cette même archive. L'absence de `.git` dans l'archive du tag est normale et n'est pas une validation manquante. + +Deux corpus récents ont également été fournis pour préparer l'adoption future sans devenir des dépendances de la baseline `0.1.0` : + +```text +games-v0.3.6.zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8 +khadhroony-solana-project-v0.3.16.zip db3cc1b3fc3fb07ee864b02e2a7346c673d4cf63b33e8e872aca6c6458856ca0 +``` + +Games `0.3.6` conserve explicitement `0.3.7` comme future release d'alignement PGR. KSP `0.3.16` reste principalement un corpus Rust/Cargo avec six applications Tauri ; aucune migration de Games ou KSP n'appartient à `0.1.0`. + +## Audit de la stable `v0.0.5` + +### Intégrité et chaîne historique + +L'archive stable contient `225` entrées sous une racine unique `pgr/`, soit `194` fichiers et `31` répertoires. Son CRC est propre, aucun lien symbolique n'est présent et `.git` est absent comme attendu pour une archive de tag Gitea. + +Les `62` couples delta/history des releases `0.0.1` à `0.0.5` sont complets : + +```text +0.0.1 12 / 12 +0.0.2 12 / 12 +0.0.3 10 / 10 +0.0.4 9 / 9 +0.0.5 19 / 19 +``` + +La vérité opérateur de `0.0.5` est conservée, notamment les `FAIL` intermédiaires et la fermeture finale `rel.001.fix.1` en `PASS`. Aucun ancien delta/history ne sera renommé rétroactivement lorsque la nouvelle convention `rel.N` sera introduite. + +### Tests et audits + +La stable passe : + +```text +python3 -B -m unittest discover -s tests -v +48 tests PASS + +Markdown header audit: clean (171 file(s)) +Markdown table audit: clean (8 table(s), 171 file(s)) +Markdown link audit: clean (161 local link(s), 171 file(s)) +``` + +Les audits PGR restent monotâches et read-only : trois audits Markdown, six audits de style Rust, un audit Rust de façade/export completeness, plus leur helper commun. Aucun audit ne devient un wrapper de build. + +### Règles, profils, templates et skeletons + +La hiérarchie normative est cohérente et possède un owner explicite pour gouvernance, workflow, skeletons, documentation, validation, langages/écosystèmes, plateformes et frameworks. + +Profils techniques déjà matérialisés : + +```text +510 Rust / Cargo +520 Java / Maven / Gradle +610 Android +710 Tauri 2 +``` + +La baseline possède cinq templates techniques Rust/Cargo sous `templates/rust-cargo/`, deux skeleton specifications concrètes — fondation de gouvernance et workspace Rust/Cargo — et les contrats de validation associés. + +Le profil Rust/Cargo est suffisamment avancé pour servir rapidement de référence à Games et KSP. Les profils Java/Gradle et Android existent déjà normativement ; leur future release `0.1.x` devra donc d'abord réévaluer leur complétude pratique, leurs templates, skeletons et audits nécessaires au cas Games au lieu de recréer les profils depuis zéro. + +Le profil Tauri `710` existe également, mais le skeleton Tauri contrôlé reste volontairement `DEFER` : il attend des owners Web suffisants pour TypeScript, Vite, Sass/CSS, sorties frontend et validation frontend indépendante. + +## Défauts de gouvernance à corriger en 0.1.0 + +L'audit ne révèle pas de défaut bloquant de la stable, mais deux conventions doivent être corrigées avant de diffuser PGR plus largement. + +### Clôture stable `rel.N` + +L'expérience réelle de `0.0.5` montre que la convention actuelle `rel.001` mélange inutilement padding historique et identité de tranche. La convention future doit utiliser : + +```text +rel.1 +rel.1.fix.1 +rel.2 +... +``` + +Les anciens fichiers `rel.001*` restent immuables. + +Le nom de tranche et le message du commit qui matérialise finalement la stable doivent être distingués. Par défaut PGR : + +```text +rel.1 FAIL -> commit de tranche X.Y.Z-rel.1 +rel.1.fix.1 FAIL -> commit de tranche X.Y.Z-rel.1.fix.1 +première tranche qui obtient le PASS stable + -> commit final X.Y.Z +``` + +Le tag `vX.Y.Z` n'est créé qu'après ce commit final stable. + +### Commandes opérateur et publication + +Après production d'un history constaté, le générateur doit remettre spontanément les commandes exactes à exécuter entre l'application de ce history et le delta suivant. Le défaut PGR retenu est : + +```bash +git add -A +git diff --cached --check +git status --short +git commit -m "" +git push origin +``` + +Le bloc doit être adapté au projet et au statut réel de la tranche ; il ne doit pas inventer une branche ou un remote lorsqu'ils ne sont pas établis. + +Pour la dernière clôture pré-tag, le handoff opérateur doit en plus fournir le bloc de tag/vérification approprié et indiquer explicitement les preuves/artefacts à remettre pour générer la vérification post-tag, notamment l'archive issue du tag et les preuves Git réellement disponibles. Un tag annoté doit être vérifié sans confondre l'objet tag avec son commit déréférencé. + +Après `publish.* PASS`, la consigne manuelle de nouvelle session reste produite automatiquement selon `docs/templates/003-NEW_SESSION_PROMPT.md`. + +## Mission de `0.1.0` + +`0.1.0` doit transformer la fondation `0.0.x` en baseline réellement réutilisable **sans absorber les domaines technologiques futurs**. + +La release doit : + +1. corriger la sémantique de clôture `rel.N` et des commits stables ; +2. rendre obligatoire le handoff automatique des commandes opérateur après chaque history et lors de la publication ; +3. formaliser une adoption proportionnée de PGR par un projet existant, distincte de l'instanciation d'un nouveau projet ; +4. vérifier que la fondation et le skeleton Rust/Cargo peuvent servir de baseline réutilisable sans dépendre de choix KSP/Games ; +5. effectuer avant RC une revue d'horizon qui engage uniquement les prochaines releases `0.1.x` suffisamment décidées. + +`0.1.0` ne crée pas de profil Web, WASM, serveur Rust/Actix, Java, Android ou Tauri supplémentaire. Ces domaines seront traités séparément dans la série `0.1.x` lorsque leur release dédiée sera engagée. + +## Direction acquise pour la série `0.1.x` + +La série `0.1.x` doit rester composée de releases concrètes indépendantes, en pratique une release/session par domaine cohérent. Il est explicitement exclu de regrouper Web, serveur Rust, Java/Android, Tauri et WASM dans `0.1.0` ou dans une unique grosse release suivante. + +La revue d'horizon de `0.1.0` devra ordonner et, seulement lorsque le scope est suffisamment décidé, numéroter les axes suivants : + +- owners Web contrôlés : TypeScript, Vite, Sass/CSS, package manager/build outputs et validation frontend ; +- serveur Web Rust — Actix Web ou autre framework seulement à partir d'un besoin et d'un corpus réels, notamment pour les trajectoires HTTP/3 ; +- réévaluation pratique du profil Java/Gradle existant pour Games ; +- réévaluation pratique du profil Android existant pour Games ; +- WASM comme domaine séparé si l'adoption Games démontre qu'un owner PGR apporte une valeur immédiate ; +- levée du `DEFER` Tauri seulement après matérialisation des owners Web nécessaires ; +- adoption de PGR par Games dès que le sous-ensemble requis est réellement prêt ; +- adoption de PGR par KSP ensuite, avec une pression principalement Rust/Cargo + Tauri et sans attendre les profils non pertinents pour KSP. + +Les numéros exacts `0.1.1`, `0.1.2`, etc. ne sont pas réservés dans `alpha.1`. Cette attribution appartient à la revue d'horizon lorsque l'ordre réel est suffisamment décidé. + +Après cette vague d'adoption `0.1.x`, les axes plus larges — projets documentaires/spécifications tels que `saselang-bible`, généricité hors logiciel et autres familles technologiques — restent candidats pour une trajectoire `0.2.x`/`0.3.x` à décider ultérieurement, sans réservation artificielle aujourd'hui. + +## Trajectoire prévisionnelle de `0.1.0` + +### alpha.1 — audit de stable et plan + +Vérifier intégralement `v0.0.5`, son rapport post-tag, les owners normatifs, profils, templates, skeletons, audits, chaîne delta/history et décisions différées. Consigner le cadrage présent sans changement normatif ni migration externe. + +### alpha.2 — clôture stable et identité `rel.N` + +Modifier les owners de gouvernance/workflow nécessaires pour : + +- remplacer la convention future `rel.001` par `rel.1` ; +- préserver l'immutabilité des anciennes releases ; +- définir le message de commit des tranches de clôture échouées ; +- définir que le commit qui obtient finalement le `PASS` stable se nomme `X.Y.Z` par défaut avant création de `vX.Y.Z`. + +Aucun changement technologique dans cette tranche. + +### alpha.3 — handoff automatique des commandes opérateur + +Formaliser le bloc de commandes remis après chaque history, l'ordre commit/push avant application du delta suivant, les commandes supplémentaires de tag pour une stable validée et la liste des preuves à fournir pour produire le rapport post-tag. + +Créer ou adapter un template documentaire uniquement si cela évite de dupliquer ces commandes dans chaque delta. + +### alpha.4 — adoption d'un projet existant + +Formaliser une méthode courte d'adoption PGR pour un dépôt existant : audit de la baseline réelle, mapping des owners applicables, classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, migration progressive et interdiction de réécrire l'historique uniquement pour le rendre rétroactivement conforme. + +Ce contrat doit permettre de préparer Games puis KSP sans imposer tous les profils PGR à chaque projet. + +### alpha.5 — baseline réutilisable et dry-run de composition + +Réconcilier la fondation `001`, le skeleton Rust/Cargo `002`, les templates Rust/Cargo et la validation minimale. Effectuer un dry-run documentaire/structurel d'instanciation et d'adoption afin de vérifier qu'un nouveau projet Rust et un projet Rust existant peuvent sélectionner les owners utiles sans dépendre de KSP/Games. + +Les profils Java/Android/Tauri sont classifiés mais ne reçoivent pas leurs nouveaux templates/skeletons dans cette tranche. + +### beta.1 — réconciliation finale et revue d'horizon + +Stabiliser la baseline `0.1.0`, vérifier les documents durables et effectuer la revue d'horizon obligatoire. Cette revue décidera les prochaines releases `0.1.x` à réellement inscrire dans `ROADMAP.md`, une par domaine cohérent, en privilégiant la préparation rapide de Games puis KSP. + +Le prompt de la prochaine version n'est créé que lorsque cette revue a effectivement fixé la cible suivante. + +### rc.1 — release candidate + +Geler le scope, produire l'entrée candidate de `CHANGELOG.md`, exécuter le release gate complet applicable, vérifier le prompt/handoff suivant et confirmer que les changements `rel.N`/commandes opérateur sont exercés par les artefacts de la release elle-même. + +### rel.1 — promotion stable + +Première utilisation de la convention corrigée `rel.1`. La promotion reste mécanique et proportionnée. Si `rel.1` échoue, le history est conservé et un `rel.1.fix.N` corrige uniquement la fermeture ; la première tranche qui établit réellement la stable est committée sous `0.1.0` avant le tag `v0.1.0`. + +## Stratégie de validation + +Chaque tranche documentaire rejoue au minimum : + +```text +python3 -B -m unittest discover -s tests -v +python3 -B scripts/audit_markdown_headers.py ... +python3 -B scripts/audit_markdown_tables.py ... +python3 -B scripts/audit_markdown_links.py ... +``` + +Les scripts d'audit restent read-only et ne déclenchent aucun build. Les changements de workflow doivent recevoir des contrôles structurels ciblés qui vérifient la nomenclature future sans imposer de renommer les snapshots historiques. + +Le dry-run de composition `alpha.5` doit privilégier les parsers/outils officiels lorsque disponibles. Une prévalidation générateur ne remplace pas le gate opérateur. + +## Déclencheurs de REPLAN + +REPLAN est requis si : + +- `0.1.0` commence à absorber Web, Android, WASM, Actix ou le skeleton Tauri au lieu de les laisser à des releases `0.1.x` distinctes ; +- la convention de commit stable ne peut pas être définie sans ambiguïté avec les histories `FAIL`/fix ; +- le handoff automatique dépend de valeurs Git qui ne peuvent pas être établies de manière sûre ; +- l'adoption d'un projet existant exige de modifier rétroactivement son historique ; +- le dry-run révèle que la fondation ou le skeleton Rust/Cargo n'est pas réellement autonome ; +- la revue d'horizon transforme des candidats en numéros réservés sans scope suffisamment décidé. + +## Clôture et transition + +- documentation durable du workflow : `alpha.2` à `alpha.4` ; +- preuve de réutilisabilité : `alpha.5` ; +- réconciliation documentaire et revue d'horizon : `beta.1` ; +- `CHANGELOG` candidate et release gate : `rc.1` ; +- promotion stable et nouveau contrat `rel.1` : `rel.1` ; +- tag/post-tag : après le commit stable `0.1.0`, avec handoff opérateur automatique ; +- prompt suivant : créé uniquement si `beta.1` a réellement engagé la prochaine cible `0.1.x`. + +## Revue d'horizon + +État : **requise**. + +Moment : `beta.1`, après preuve de réutilisabilité et avant RC. + +Sorties autorisées : + +- engager une ou plusieurs prochaines releases `0.1.x`, chacune avec un seul domaine cohérent ; +- conserver certains axes comme `DEFER` ou candidats sans numéro ; +- ordonner Games avant KSP lorsque les owners requis le permettent ; +- lever le `DEFER` Tauri uniquement si les owners Web requis existent réellement ; +- repousser WASM ou serveur Rust si leur normalisation n'apporte pas encore assez de valeur ; +- conserver `saselang-bible` et la généricité hors logiciel pour une trajectoire ultérieure sans l'inventer prématurément. diff --git a/history/0.1.0/alpha.1.md b/history/0.1.0/alpha.1.md new file mode 100644 index 0000000..2136f40 --- /dev/null +++ b/history/0.1.0/alpha.1.md @@ -0,0 +1,103 @@ + + + +# History 0.1.0-alpha.1 — audit de la stable et cadrage de la baseline réutilisable + +## Statut + +PASS + +La gate opérateur de `0.1.0-alpha.1` exécutée le `2026-09-25` valide l'audit de reprise depuis `v0.0.5`, le plan de la première baseline PGR réutilisable et le maintien des futurs domaines `0.1.x` comme axes non numérotés. Aucun fix ni REPLAN de `alpha.1` n'est requis. + +Cette preuve ferme uniquement le cadrage `alpha.1`. Elle ne matérialise encore ni la nouvelle convention `rel.N`, ni le handoff automatique des commandes Git, ni un profil technologique supplémentaire. + +## Baseline et version + +La tranche part de la stable taggée `v0.0.5`, dont l'archive autoritaire et le rapport post-tag `publish.001` ont été audités pendant la préparation du delta. + +La version contrôlée après application du delta est : + +```text +0.1.0-alpha.1 +``` + +L'opérateur a confirmé la présence de `deltas/0.1.0/alpha.1.md` et l'absence du présent history pendant la gate. Les révisions attendues ont été retrouvées : + +```text +README.md version 15 +docs/000-README.md version 18 +docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md présent et indexé +``` + +## Validation opérateur observée + +L'opérateur a fourni les sorties du `2026-09-25` depuis `~/Projects/pgr`, à `22:08:29`–`22:08:30`. + +La suite Python globale a exécuté `48` tests, tous réussis : + +```text +Ran 48 tests in 0.720s + +OK +``` + +Les audits documentaires sont propres : + +```text +Markdown header audit: clean (173 file(s)) +Markdown table audit: clean (8 table(s), 173 file(s)) +Markdown link audit: clean (163 local link(s), 173 file(s)) +``` + +Le contrôle structurel spécifique a affiché : + +```text +0.1.0 alpha.1 structural audit: clean (62 prior pairs, stable workflow truth preserved, future 0.1.x unnumbered) +``` + +Il confirme notamment : + +- les `62` couples delta/history des releases `0.0.1` à `0.0.5` ; +- la conservation de `rel.001` en `FAIL` et `rel.001.fix.1` en `PASS` dans l'historique `0.0.5` ; +- la présence des profils Rust/Cargo, Java/Maven/Gradle, Android et Tauri ainsi que des skeletons et de l'étude Tauri attendus ; +- les décisions de cadrage `rel.1`, commit stable final, releases `0.1.x` par domaine, Games avant KSP et maintien des axes Web/Vite/Android/WASM/Tauri/serveur Rust comme horizons non numérotés ; +- l'absence de réservation prématurée de `0.1.1` dans `ROADMAP.md`. + +## Contrôles Git + +`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic. + +Le statut indexé transmis avant ajout du présent history est exactement : + +```text +M README.md +M VERSION +A deltas/0.1.0/alpha.1.md +M docs/000-README.md +A docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md +``` + +Le scope correspond donc au delta livré et aucun fichier normatif, profil, template, skeleton, script ou history antérieur n'a été modifié par `alpha.1`. + +## Revue de cadrage + +Les précisions ajoutées pendant la session ne remettent pas en cause le scope validé de `alpha.1` : + +- les domaines Web, serveur Rust, Java/Android, WASM et Tauri restent destinés à des releases `0.1.x` séparées ; +- KSP reste principalement dépendant de la baseline Rust/Cargo déjà mûre et du futur déblocage Tauri ; +- un futur audit Python simulant uniquement un sous-ensemble statiquement vérifiable des conventions Clippy est conservé comme candidat non prioritaire après les adoptions Games puis KSP ; il ne remplacera pas `cargo clippy` ; +- les profils de déploiement/exploitation — reverse proxy, bases de données, conteneurs et responsabilités associées — restent un horizon plus lointain, sans numéro de release réservé. + +Ces deux derniers horizons n'ont pas été introduits dans les fichiers de `alpha.1`. Ils peuvent être enregistrés dans le plan actif lors d'une tranche ultérieure sans transformer cette gate en échec. + +## Transition + +Appliquer le présent history puis committer et pousser `0.1.0-alpha.1`. + +La tranche suivante est : + +```text +0.1.0-alpha.2 +``` + +Elle est strictement consacrée à la convention future `rel.N`, à l'abandon du padding `rel.001` pour les nouvelles releases et à la distinction entre commits de clôture échoués et commit final stable `X.Y.Z`. Les anciennes releases restent immuables.