From 4fc3cd5e7ecf8f189502dbbe800f0b0ceb23f36d Mon Sep 17 00:00:00 2001 From: SinuS Von SifriduS Date: Tue, 29 Sep 2026 18:01:37 +0200 Subject: [PATCH] 0.1.4-rc.1 --- CHANGELOG.md | 11 +- ROADMAP.md | 14 +- VERSION | 2 +- deltas/0.1.4/rc.1.md | 203 ++++++++++++++++++ docs/000-README.md | 4 +- .../010-V0_1_4_TAURI_REEVALUATION_PLAN.md | 23 +- docs/studies/000-README.md | 3 +- docs/studies/004-V0_1_4_HORIZON_REVIEW.md | 139 ++++++++++++ history/0.1.4/rc.1.md | 113 ++++++++++ prompts/011-V0_1_5_START_PROMPT.md | 81 +++++++ 10 files changed, 580 insertions(+), 13 deletions(-) create mode 100644 deltas/0.1.4/rc.1.md create mode 100644 docs/studies/004-V0_1_4_HORIZON_REVIEW.md create mode 100644 history/0.1.4/rc.1.md create mode 100644 prompts/011-V0_1_5_START_PROMPT.md diff --git a/CHANGELOG.md b/CHANGELOG.md index ce561d2..40056b3 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,5 @@ - + # Changelog Project Governance Rules @@ -7,6 +7,15 @@ Ce fichier décrit les changements utiles aux utilisateurs ou intégrateurs des Les tranches `alpha`, `beta`, `rc`, fixes, validations, audits et détails de développement appartiennent aux plans, deltas et historiques. Ils ne sont pas recopiés ici par défaut. +## 0.1.4 (candidate) + +- réexamine le `DEFER` historique du skeleton Tauri contre les corpus Games/KSP fournis, confirme les prérequis Web désormais couverts et lève le blocage sans généraliser les choix locaux de ces projets ; +- recentre l’owner `710-TAURI` sur le host, l’orchestration, la configuration, les commandes, permissions et capabilities, les plugins et la frontière d’intégration, tandis que TypeScript, Vite, CSS/Sass, package manager et bindings restent possédés par leurs owners dédiés ; +- matérialise `docs/skeletons/004-TAURI.md` comme specification organisationnelle composable avec la fondation, Rust/Cargo et Web, en laissant identifiants, capabilities, plugins, fenêtres, bundles et plateformes au projet destinataire ; +- confirme qu’aucun template technique Tauri générique, contrat `006-TAURI_VALIDATION.md` ni dry-run de faux projet n’est justifié tant qu’aucune responsabilité réutilisable non couverte n’est démontrée ; +- ajoute un audit réutilisable d’hygiène texte imposant LF, absence de whitespace terminal et exactement une newline finale, et durcit le contrat des archives delta/history pour interdire un répertoire englobant autour des chemins du dépôt ; +- effectue une revue d’horizon de fermeture : la clarification de `SHOULD`, l’autonomie des projets après adoption et la frontière future avec SaseDev Knowledge deviennent la cible `0.1.5`, avant les adoptions Games `0.1.6`, KSP `0.1.7` et les audits Rust `0.1.8`. + ## 0.1.3 - réévalue le profil Android contre le corpus Games réel tout en conservant Android neutre vis-à-vis du langage applicatif et en composant Java/Gradle uniquement lorsqu'ils sont réellement présents ; diff --git a/ROADMAP.md b/ROADMAP.md index 4c0d79b..6d0be70 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,5 +1,5 @@ - + # Roadmap Project Governance Rules @@ -26,21 +26,21 @@ La revue d'horizon de `0.1.0-beta.1` engage les releases suivantes, chacune avec - `(x) 0.1.1` — fondation frontend Web : TypeScript, Vite, Sass/CSS, package/build outputs et validation frontend indépendante ; - `(x) 0.1.2` — réévaluation pratique de Java/Maven/Gradle, séparation des owners lorsque leurs applicabilités divergent et matérialisation uniquement des artefacts génériques réellement nécessaires ; - `(x) 0.1.3` — réévaluation pratique du profil Android existant à partir de Games, sans absorber les décisions propres aux jeux ou à SDL ; -- `( ) 0.1.4` — domaine Tauri : réexamen du `DEFER` et matérialisation du skeleton contrôlé seulement si les owners Web issus de `0.1.1` satisfont réellement les conditions de sortie ; -- `( ) 0.1.5` — adoption réelle de PGR par `sasedev-games` avec mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ; -- `( ) 0.1.6` — adoption réelle de PGR par `khadhroony-solana-project`, principalement sur Rust/Cargo + Tauri et sans dépendance aux profils non applicables ; -- `( ) 0.1.7` — audits Python read-only d'un sous-ensemble statique des conventions Rust/Clippy, après les deux adoptions, sans prétendre remplacer `cargo clippy`. +- `( ) 0.1.4` — domaine Tauri : réexamen du `DEFER`, consolidation de l’owner `710`, matérialisation du skeleton contrôlé `004` et décision explicite de ne pas créer d’artefacts techniques redondants ; +- `( ) 0.1.5` — sémantique normative et autonomie : clarifier `MUST / SHOULD / MAY`, rendre explicite l’autorité locale d’un projet après instanciation/adoption et fixer la frontière durable entre PGR et SaseDev Knowledge ; +- `( ) 0.1.6` — adoption réelle de PGR par `sasedev-games` avec mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, après stabilisation du contrat d’autonomie ; +- `( ) 0.1.7` — adoption réelle de PGR par `khadhroony-solana-project`, principalement sur Rust/Cargo + Tauri et sans dépendance aux profils non applicables ; +- `( ) 0.1.8` — audits Python read-only d’un sous-ensemble statique des conventions Rust/Clippy, après les deux adoptions, sans prétendre remplacer `cargo clippy`. Le détail et les conditions de cette séquence sont conservés dans [`docs/studies/003-V0_1_0_HORIZON_REVIEW.md`](docs/studies/003-V0_1_0_HORIZON_REVIEW.md). ## Trajectoires différées ou non numérotées -- `(d) skeleton Tauri jusqu'au réexamen 0.1.4` — le `DEFER` de `0.0.5-alpha.9` a été maintenu pendant `0.1.1`; `0.1.1-beta.1` confirme que ses cinq prérequis Web disposent désormais d'owners PGR, mais seul `0.1.4` peut réexaminer le candidat à partir du corpus alors courant ; - `WASM` — candidat séparé à réévaluer pendant l'adoption Games si un owner PGR apporte une valeur immédiate ; - `serveur Web Rust / Actix Web ou alternative` — candidat à partir d'un corpus d'implémentation réel, pas sur la seule base d'une trajectoire roadmap ; - `saselang-bible`, projets documentaires/spécifications et généricité hors logiciel — candidats d'une trajectoire ultérieure `0.2.x` / `0.3.x` à décider ; - `deployment & operations` — famille future pour reverse proxies, bases de données, Docker/Compose, services Linux, secrets, migrations/backups, health et observabilité ; un horizon `0.4.x` ou `0.5.x` est plausible mais aucun numéro précis n'est réservé. -Une nouvelle revue d'horizon doit intervenir si un prérequis réel invalide l'ordre engagé, notamment si `0.1.1` doit être scindée, si `0.1.4` ne peut pas lever le `DEFER` Tauri ou si Games exige un owner WASM/serveur avant une adoption proportionnée. +La revue d’horizon `0.1.4-rc.1` remplace l’ordre initial `0.1.5` Games / `0.1.6` KSP / `0.1.7` audits par le contrat ci-dessus. Une nouvelle revue d’horizon doit intervenir si `0.1.5` démontre que l’autonomie ne peut pas être stabilisée sans scope supplémentaire, ou si Games/KSP exigent un owner réellement préalable à une adoption proportionnée. Le contenu détaillé et le nombre de tranches de chaque release sont définis par son plan actif, créé ou consolidé pendant `alpha.1`. diff --git a/VERSION b/VERSION index 999d2a5..c49b806 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.1.4-beta.1 +0.1.4-rc.1 diff --git a/deltas/0.1.4/rc.1.md b/deltas/0.1.4/rc.1.md new file mode 100644 index 0000000..d32551f --- /dev/null +++ b/deltas/0.1.4/rc.1.md @@ -0,0 +1,203 @@ + + + +# Delta 0.1.4-rc.1 — freeze Tauri et revue d’horizon + +## Objet + +Geler le scope Tauri validé par `beta.1`, préparer le changelog candidat et exécuter la revue d’horizon transversale exigée par le plan avant de générer le prochain start prompt. + +La RC ne corrige pas encore la sémantique `SHOULD`, le contrat d’autonomie ou la frontière PGR / Knowledge : elle décide explicitement qu’ils forment la prochaine release `0.1.5` et décale les adoptions Games/KSP afin qu’elles utilisent ensuite ce contrat stabilisé. + +## Préconditions + +- `0.1.4-beta.1` est validée `PASS` et son history est présent ; +- `710-TAURI.md` reste en révision `7` et `004-TAURI.md` en révision `1` ; +- aucun template technique Tauri ni `006-TAURI_VALIDATION.md` n’est requis ; +- les trois questions transversales enregistrées dans le plan doivent être décidées avant création du prompt suivant ; +- les archives delta/history restent relatives directement à la racine du dépôt. + +## Modifications + +- `VERSION` passe à `0.1.4-rc.1` ; +- `CHANGELOG.md` reçoit l’entrée `0.1.4 (candidate)` sans chronologie de tranches ; +- `ROADMAP.md` enregistre la revue d’horizon : `0.1.5` gouvernance/autonomie, `0.1.6` Games, `0.1.7` KSP, `0.1.8` audits Rust ; +- `docs/studies/004-V0_1_4_HORIZON_REVIEW.md` matérialise la décision et ses limites ; +- `prompts/011-V0_1_5_START_PROMPT.md` prépare la prochaine release à partir d’une future stable `v0.1.4` réellement publiée ; +- le plan et les index sont mis à jour pour refléter le freeze et le handoff ; +- aucun owner normatif transversal n’est encore modifié en RC. + +## Gate opérateur + +```bash +cat VERSION + +test -f history/0.1.4/beta.1.md +grep -A2 '^## Statut$' history/0.1.4/beta.1.md | grep -Fx 'PASS' + +test -f docs/studies/004-V0_1_4_HORIZON_REVIEW.md +test -f prompts/011-V0_1_5_START_PROMPT.md +test ! -e history/0.1.4/rc.1.md + +grep -Fx '' CHANGELOG.md +grep -Fx '' ROADMAP.md +grep -Fx '' docs/000-README.md +grep -Fx '' docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md +grep -Fx '' docs/studies/000-README.md +grep -Fx '' docs/studies/004-V0_1_4_HORIZON_REVIEW.md +grep -Fx '' prompts/011-V0_1_5_START_PROMPT.md + +python3 -B - <<'PYGATE' +from pathlib import Path +import re + +assert Path('VERSION').read_text(encoding='utf-8').strip() == '0.1.4-rc.1' + +expected_statuses = { + 'alpha.1.md': 'PASS', + 'alpha.2.md': 'FAIL', + 'alpha.2.fix.1.md': 'PASS', + 'alpha.3.md': 'PASS', + 'beta.1.md': 'PASS', +} +for name, status in expected_statuses.items(): + delta = Path('deltas/0.1.4', name) + history = Path('history/0.1.4', name) + assert delta.is_file(), name + assert history.is_file(), name + text = history.read_text(encoding='utf-8') + assert re.search(rf'## Statut\s+{status}\s', text), (name, status) + +pending = {p.name for p in Path('deltas/0.1.4').glob('*.md')} - { + p.name for p in Path('history/0.1.4').glob('*.md') +} +assert pending == {'rc.1.md'}, pending + +for path, version in ( + ('docs/rules/710-TAURI.md', 7), + ('docs/skeletons/004-TAURI.md', 1), + ('docs/studies/002-TAURI_SKELETON_DECISION.md', 4), + ('RULES.md', 14), + ('docs/rules/230-ADOPTION.md', 1), + ('docs/rules/400-VALIDATION.md', 1), +): + lines = Path(path).read_text(encoding='utf-8').splitlines() + assert lines[1] == f'', (path, lines[1]) + +changelog = Path('CHANGELOG.md').read_text(encoding='utf-8') +assert '## 0.1.4 (candidate)' in changelog +section = changelog.split('## 0.1.4 (candidate)', 1)[1].split('## 0.1.3', 1)[0] +for phrase in ( + 'skeleton Tauri', + 'commandes, permissions et capabilities', + '004-TAURI.md', + 'audit réutilisable d’hygiène texte', + '0.1.5', + '0.1.8', +): + assert phrase in section, phrase +for forbidden in ('alpha.1', 'alpha.2', 'alpha.3', 'beta.1', 'rc.1', 'rel.1'): + assert forbidden not in section, forbidden + +roadmap = Path('ROADMAP.md').read_text(encoding='utf-8') +for phrase in ( + '`( ) 0.1.4` — domaine Tauri', + '`( ) 0.1.5` — sémantique normative et autonomie', + '`( ) 0.1.6` — adoption réelle de PGR par `sasedev-games`', + '`( ) 0.1.7` — adoption réelle de PGR par `khadhroony-solana-project`', + '`( ) 0.1.8` — audits Python read-only', +): + assert phrase in roadmap, phrase +assert '`( ) 0.1.9`' not in roadmap +assert "skeleton Tauri jusqu'au réexamen 0.1.4" not in roadmap + +study = Path('docs/studies/004-V0_1_4_HORIZON_REVIEW.md').read_text(encoding='utf-8') +for phrase in ( + 'forte recommandation', + 'MUST NOT faire échouer à lui seul une gate', + 'baseline locale du projet', + 'règles locales = autorité des sessions/releases suivantes', + 'PGR MUST rester auto-suffisant', + 'une release de gouvernance/autonomie doit précéder les adoptions Games/KSP', + '0.1.8 audits Rust/Clippy read-only', +): + assert phrase in study, phrase + +prompt = Path('prompts/011-V0_1_5_START_PROMPT.md').read_text(encoding='utf-8') +for phrase in ( + 'tag Gitea `v0.1.4`', + 'pgr-0.1.4-publish.001-report.md', + '0.1.5-alpha.1', + '004-V0_1_4_HORIZON_REVIEW.md', + 'forte recommandation non obligatoire', + 'ne doivent ni rechercher automatiquement « la dernière version de PGR »', + 'SaseDev Knowledge', + 'réservée à `0.1.6`', + 'réservée à `0.1.7`', + 'réservés à `0.1.8`', +): + assert phrase in prompt, phrase + +plan = Path('docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md').read_text(encoding='utf-8') +for phrase in ( + '## Gate `beta.1` acquise', + '## Revue d’horizon préparée en `rc.1`', + '0.1.5 sémantique normative + autonomie + frontière PGR/Knowledge', + 'Le prompt `011` transmet explicitement leur réexamen à `0.1.5-alpha.1`.', +): + assert phrase in plan, phrase + +assert not Path('docs/templates/011-TAURI.md').exists() +assert not Path('docs/validation/006-TAURI_VALIDATION.md').exists() +assert not Path('history/0.1.4/rc.1.md').exists() + +print( + '0.1.4 rc.1 integration audit: clean ' + '(beta PASS, Tauri frozen, horizon reordered to governance 0.1.5 before Games/KSP, prompt 011 verified)' +) +PYGATE + +python3 -B -m unittest discover -s tests -v + +python3 -B scripts/audit_text_hygiene.py \ + VERSION README.md RULES.md ROADMAP.md CHANGELOG.md \ + docs deltas history prompts scripts tests templates .gitignore .settings + +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 + +git diff --check + +git add VERSION CHANGELOG.md ROADMAP.md \ + deltas/0.1.4/rc.1.md \ + docs/000-README.md \ + docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md \ + docs/studies/000-README.md \ + docs/studies/004-V0_1_4_HORIZON_REVIEW.md \ + prompts/011-V0_1_5_START_PROMPT.md + +git diff --cached --check +git status --short +``` + +## Scope Git attendu + +```text +M CHANGELOG.md +M ROADMAP.md +M VERSION +A deltas/0.1.4/rc.1.md +M docs/000-README.md +M docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md +M docs/studies/000-README.md +A docs/studies/004-V0_1_4_HORIZON_REVIEW.md +A prompts/011-V0_1_5_START_PROMPT.md +``` + +## Transition + +Si la gate est `PASS`, produire `history/0.1.4/rc.1.md`, committer/pousser `0.1.4-rc.1`, puis préparer la promotion mécanique `rel.1` sans rouvrir le scope Tauri ni commencer `0.1.5`. diff --git a/docs/000-README.md b/docs/000-README.md index 16f7456..e090e75 100644 --- a/docs/000-README.md +++ b/docs/000-README.md @@ -1,5 +1,5 @@ - + # Documentation PGR @@ -27,6 +27,8 @@ Les templates techniques copiables sous `templates/` restent séparés des instr - [`skeletons/003-WEB_FRONTEND.md`](skeletons/003-WEB_FRONTEND.md) — specialization Web composable dont l'existence satisfait les prérequis historiques sans rendre Vite, TypeScript, Sass, Bootstrap ou `frontend/` universels à Tauri. - [`skeletons/004-TAURI.md`](skeletons/004-TAURI.md) — skeleton Tauri 2 matérialisé en `alpha.3`, composant fondation, Rust/Cargo, Web et owner `710` sans template technique universel ni copie des choix Games/KSP. - [`studies/002-TAURI_SKELETON_DECISION.md`](studies/002-TAURI_SKELETON_DECISION.md) — décision historique `DEFER`, levée du motif Web puis décision `beta.1` : `004-TAURI.md` suffit ; aucun template technique ni contrat de validation Tauri séparé n'est justifié. +- [`studies/004-V0_1_4_HORIZON_REVIEW.md`](studies/004-V0_1_4_HORIZON_REVIEW.md) — revue de fermeture `rc.1` décidant de stabiliser en `0.1.5` la sémantique `SHOULD`, l’autonomie après adoption et la frontière PGR / SaseDev Knowledge avant Games/KSP. +- [`../prompts/011-V0_1_5_START_PROMPT.md`](../prompts/011-V0_1_5_START_PROMPT.md) — handoff préparé par la RC vers `0.1.5-alpha.1`, à utiliser uniquement après publication et vérification post-tag de `v0.1.4`. - [`../prompts/010-V0_1_4_START_PROMPT.md`](../prompts/010-V0_1_4_START_PROMPT.md) — contrat de reprise exécuté pour ouvrir `0.1.4-alpha.1` après publication vérifiée de `v0.1.3`. ## Points d'entrée de 0.1.3 diff --git a/docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md b/docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md index 612aa51..43c23b5 100644 --- a/docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md +++ b/docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md @@ -1,5 +1,5 @@ - + # Plan 0.1.4 — réexamen Tauri et skeleton contrôlé @@ -310,6 +310,25 @@ Un contrat de validation Tauri séparé dupliquerait `710`, `004`, `005` et les Le dry-run exécutable d'un projet factice n'est pas requis pour valider une specification qui ne fournit volontairement aucun scaffold technique. La preuve pertinente en `beta.1` est une vérification statique de composition : références existantes, ownership non dupliqué, décisions visibles, absence de placeholders et absence d'artefacts créés par symétrie. +## Gate `beta.1` acquise + +La gate opérateur de `beta.1` est `PASS` : `55/55` tests, audit d’hygiène texte propre sur `302` fichiers, audits Markdown propres, audit structurel d’artefacts propre et scope Git conforme. `004-TAURI.md` est confirmé suffisant ; aucun template technique Tauri, contrat `006-TAURI_VALIDATION.md` ou dry-run factice n’est ajouté. + +## Revue d’horizon préparée en `rc.1` + +La revue exigée par le point transversal est matérialisée dans `docs/studies/004-V0_1_4_HORIZON_REVIEW.md`. Elle conclut qu’une release de gouvernance/autonomie doit précéder les adoptions Games/KSP afin de ne pas propager une sémantique `SHOULD` ambiguë ni une relation implicite d’upstream avec PGR. + +Trajectoire décidée : + +```text +0.1.5 sémantique normative + autonomie + frontière PGR/Knowledge +0.1.6 adoption Games +0.1.7 adoption KSP +0.1.8 audits Rust/Clippy read-only +``` + +La RC ne modifie pas encore les owners normatifs concernés : `RULES.md`, `230-ADOPTION.md`, `400-VALIDATION.md`, le skeleton de fondation et les templates de reprise restent gelés pour `0.1.4`. Le prompt `011` transmet explicitement leur réexamen à `0.1.5-alpha.1`. + ## Point transversal découvert pendant la gate `alpha.1` L'utilisation de PGR pour initialiser SaseDev Knowledge a fait apparaître trois questions de gouvernance qui dépassent le domaine Tauri : @@ -388,7 +407,7 @@ Promouvoir `0.1.4`, finaliser `README.md`, `ROADMAP.md`, `CHANGELOG.md` et les i La release ne rouvre pas Android `0.1.3` en l'absence de défaut transversal démontré. Les détails générés des projets Android/iOS Tauri restent composés avec leurs owners de plateforme lorsqu'ils sont applicables. -La release ne réserve aucun numéro au-delà de `0.1.7`. La trajectoire actuellement publiée conserve `0.1.5` Games, `0.1.6` KSP et `0.1.7` audits Rust jusqu'à la revue d'horizon de fermeture ; cette revue peut la réordonner explicitement si le besoin transversal identifié est confirmé prioritaire. Le `CHANGELOG.md` et le `ROADMAP.md` ne sont pas réécrits prématurément ; ils sont mis à jour dans les phases de fermeture lorsqu'ils décrivent l'état effectivement atteint et la trajectoire confirmée. +La revue d’horizon de fermeture confirme que le besoin transversal est prioritaire et réordonne explicitement la trajectoire : `0.1.5` gouvernance/autonomie, `0.1.6` Games, `0.1.7` KSP et `0.1.8` audits Rust. Aucun numéro au-delà de `0.1.8` n’est réservé. Le `CHANGELOG.md` candidat et le `ROADMAP.md` sont mis à jour en RC parce qu’ils décrivent désormais une décision de fermeture acquise, pas une hypothèse prématurée. ## Gate de sortie du plan diff --git a/docs/studies/000-README.md b/docs/studies/000-README.md index 36f1d96..3fd688a 100644 --- a/docs/studies/000-README.md +++ b/docs/studies/000-README.md @@ -1,5 +1,5 @@ - + # Index des études PGR @@ -12,3 +12,4 @@ Une étude peut comparer des projets sources, des technologies ou plusieurs opti - [`001-KSP_GAMES_RECONCILIATION.md`](001-KSP_GAMES_RECONCILIATION.md) — première réconciliation explicite de PGR avec les baselines autoritaires fournies de `khadhroony-solana-project` et `sasedev-games`. - [`002-TAURI_SKELETON_DECISION.md`](002-TAURI_SKELETON_DECISION.md) — décision historique `DEFER` du skeleton Tauri, complétée en `0.1.1-beta.1` par la preuve que ses cinq prérequis Web disposent désormais d'owners PGR, sans lever le report avant `0.1.4`. - [`003-V0_1_0_HORIZON_REVIEW.md`](003-V0_1_0_HORIZON_REVIEW.md) — revue d'horizon `0.1.0-beta.1` engageant les prochaines releases `0.1.x` suffisamment décidées et conservant les autres axes sans numéro. +- [`004-V0_1_4_HORIZON_REVIEW.md`](004-V0_1_4_HORIZON_REVIEW.md) — revue de fermeture `0.1.4` clarifiant le besoin d’une release `0.1.5` dédiée à la sémantique normative, à l’autonomie des projets et à la frontière PGR / SaseDev Knowledge avant les adoptions Games/KSP. diff --git a/docs/studies/004-V0_1_4_HORIZON_REVIEW.md b/docs/studies/004-V0_1_4_HORIZON_REVIEW.md new file mode 100644 index 0000000..d361cc3 --- /dev/null +++ b/docs/studies/004-V0_1_4_HORIZON_REVIEW.md @@ -0,0 +1,139 @@ + + + +# Revue d’horizon 0.1.4 — sémantique normative, autonomie et frontière Knowledge + +## Objet + +Cette étude clôt la revue d’horizon explicitement requise par le plan `0.1.4`. Elle décide si les adoptions Games/KSP peuvent suivre immédiatement la release Tauri ou si un contrat transversal doit être stabilisé auparavant. + +Le déclencheur provient d’un usage réel de PGR pour initialiser SaseDev Knowledge. Trois ambiguïtés ont été observées sans remettre en cause le travail Tauri de `0.1.4` : force réelle de `SHOULD`, relation d’un projet avec PGR après adoption, et emplacement futur des howtos/recettes/snippets lorsque Knowledge devient suffisamment fonctionnel. + +## Sources PGR examinées + +Les owners actuels pertinents sont : + +```text +RULES.md +rules/200-GOVERNANCE.md +rules/210-WORKFLOW.md +rules/220-SKELETONS.md +rules/230-ADOPTION.md +rules/400-VALIDATION.md +skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md +templates/003-NEW_SESSION_PROMPT.md +templates/007-EXISTING_PROJECT_ADOPTION.md +``` + +Ces documents contiennent déjà des éléments compatibles avec l’intention recherchée, notamment l’autonomie du projet et la copie locale des règles applicables. Le défaut est une insuffisance de précision et de propagation du contrat, pas l’absence totale du principe. + +## 1. Force normative de `SHOULD` + +La formulation actuelle décrit `SHOULD / SHOULD NOT` comme un comportement attendu par défaut avec dérogation possible si une autre solution est mieux adaptée et justifiée. Cette rédaction peut être interprétée comme une obligation conditionnelle. + +La prochaine clarification doit établir sans ambiguïté : + +```text +MUST / MUST NOT exigence normative ; écart = non-conformité sauf exception/override autorisé +SHOULD / SHOULD NOT forte recommandation ; préférence par défaut mais non obligatoire +MAY possibilité neutre ; aucune préférence implicite +``` + +Un écart à un `SHOULD` : + +- MUST NOT devenir à lui seul une non-conformité ; +- MUST NOT faire échouer à lui seul une gate ; +- MUST NOT exiger automatiquement un `OVERRIDE` ; +- MAY être documenté lorsqu’il est significatif pour la maintenance, l’architecture ou la reprise future. + +La distinction est suffisamment structurante pour être stabilisée avant toute nouvelle adoption réelle. + +## 2. Autonomie après instanciation ou adoption + +PGR doit être un référentiel d’initialisation, de comparaison et de réalignement volontaire, pas un upstream vivant implicitement suivi par chaque projet. + +Le contrat cible est : + +```text +snapshot PGR choisi + ↓ +instanciation / adoption / adaptation + ↓ +baseline locale du projet + ↓ +règles locales = autorité des sessions/releases suivantes +``` + +Après établissement de la baseline locale : + +- le projet MUST fonctionner sans rechercher une version PGR plus récente ; +- le projet MUST NOT considérer PGR comme une dépendance documentaire implicite à mettre à jour à chaque session ; +- ses règles, architecture, plans, templates et validations locales deviennent l’autorité de son évolution ; +- la version PGR utilisée MAY être conservée comme provenance historique ; +- un réalignement futur avec PGR est une opération explicite, bornée et volontaire, utilisant un snapshot PGR choisi et une nouvelle comparaison des écarts. + +Ce point doit être propagé dans les contrats de reprise et d’adoption, sinon l’autonomie déjà annoncée dans les règles reste trop facile à contourner involontairement. + +## 3. Frontière PGR / SaseDev Knowledge + +PGR et Knowledge doivent rester utilisables indépendamment. + +La frontière cible est : + +```text +PGR + contrats normatifs et de gouvernance + owners et règles applicables + skeleton specifications minimales + templates nécessaires à un contrat réutilisable + contrats de validation/audit directement liés à ces règles + +SaseDev Knowledge + howtos détaillés + recettes et procédures pratiques + snippets + exemples d’intégration + dépannage et variantes d’implémentation + explications pédagogiques et comparatifs pratiques +``` + +PGR MUST rester auto-suffisant pour comprendre et appliquer une règle. Une règle PGR ne doit pas dépendre d’un howto Knowledge pour déterminer ce qu’elle exige. + +La future disponibilité de Knowledge MAY justifier l’épuration de contenus pratiques devenus redondants dans PGR, mais aucune extraction ne doit être effectuée uniquement pour anticiper cette disponibilité. Le déplacement physique exige un corpus Knowledge suffisamment fonctionnel et explicitement fourni comme source autoritaire de destination. + +## Décision d’horizon + +Les trois sujets sont transversaux à toutes les adoptions futures. Les reporter après Games/KSP ferait courir le risque de propager une sémantique ambiguë ou une liaison implicite à PGR dans les projets précisément utilisés pour éprouver le modèle d’adoption. + +Décision : **une release de gouvernance/autonomie doit précéder les adoptions Games/KSP**. + +La trajectoire devient : + +```text +0.1.4 Tauri et skeleton contrôlé +0.1.5 sémantique normative + autonomie + frontière PGR/Knowledge +0.1.6 adoption sasedev-games +0.1.7 adoption khadhroony-solana-project +0.1.8 audits Rust/Clippy read-only +``` + +Aucun numéro au-delà de `0.1.8` n’est réservé par cette étude. + +## Scope attendu de 0.1.5 + +`0.1.5` devra au minimum : + +1. clarifier la force de `MUST / SHOULD / MAY` et les conséquences de gate ; +2. rendre explicite l’autorité locale après instanciation/adoption dans `230-ADOPTION`, les skeletons et les patterns de reprise concernés ; +3. définir un mécanisme de réalignement PGR volontaire sans mise à jour automatique ; +4. formaliser la frontière PGR / SaseDev Knowledge et classifier les contenus qui doivent rester normatifs ou devenir candidats à un futur transfert ; +5. vérifier que PGR reste autonome sans dépendance à Knowledge ; +6. ne pas commencer les adoptions Games/KSP ni les audits Rust réservés aux releases suivantes. + +Une archive SaseDev Knowledge MAY être utilisée comme corpus d’observation si elle est explicitement fournie, mais `0.1.5` ne doit pas dépendre de son existence pour corriger les contrats PGR. + +## Hors scope de la présente RC + +La présente étude ne modifie pas encore `RULES.md`, `230-ADOPTION.md`, `400-VALIDATION.md`, les skeletons de fondation ou les templates de reprise. Ces modifications appartiennent à `0.1.5` afin que `0.1.4-rc.1` reste une phase de freeze Tauri et de handoff. + +Elle ne migre ni Games ni KSP et ne déplace aucun contenu vers SaseDev Knowledge. diff --git a/history/0.1.4/rc.1.md b/history/0.1.4/rc.1.md new file mode 100644 index 0000000..e6084d0 --- /dev/null +++ b/history/0.1.4/rc.1.md @@ -0,0 +1,113 @@ + + + +# History 0.1.4-rc.1 — freeze Tauri et revue d’horizon + +## Statut + +PASS + +La gate opérateur de `0.1.4-rc.1` exécutée le `2026-09-29` est propre. Elle confirme le freeze du domaine Tauri, la cohérence du changelog candidat, la revue d’horizon qui place la sémantique normative et l’autonomie en `0.1.5`, ainsi que le handoff `011` vers cette prochaine release sans commencer son implémentation. + +## Baseline opérateur + +La tranche précédente a été clôturée, committée puis publiée avant application de `rc.1` : + +```text +commit beta.1 091685a +push e4f405e..091685a master -> master +``` + +La version observée pendant la gate est : + +```text +0.1.4-rc.1 +``` + +Les contrôles préalables ont confirmé `history/0.1.4/beta.1.md` présent avec statut `PASS`, l’étude `004-V0_1_4_HORIZON_REVIEW.md` présente, le prompt `011-V0_1_5_START_PROMPT.md` présent et l’absence du présent history pendant la gate. + +## Révisions documentaires contrôlées + +Les révisions attendues ont été confirmées : + +```text +CHANGELOG.md version 18 +ROADMAP.md version 16 +docs/000-README.md version 45 +docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md version 5 +docs/studies/000-README.md version 5 +docs/studies/004-V0_1_4_HORIZON_REVIEW.md version 1 +prompts/011-V0_1_5_START_PROMPT.md version 1 +``` + +## Tests Python + +La suite complète a affiché à deux reprises une exécution propre ; la gate finale a notamment affiché : + +```text +Ran 55 tests in 0.913s + +OK +``` + +Soit `55/55` tests `PASS`. + +## Audit d’hygiène texte + +L’audit réutilisable a affiché : + +```text +Text hygiene audit: clean (306 file(s)) +``` + +## Audits Markdown + +Les audits documentaires sont propres : + +```text +Markdown header audit: clean (279 file(s)) +Markdown table audit: clean (11 table(s), 279 file(s)) +Markdown link audit: clean (356 local link(s), 279 file(s)) +``` + +## Audit d’intégration `rc.1` + +Le contrôle structurel a affiché : + +```text +0.1.4 rc.1 integration audit: clean (beta PASS, Tauri frozen, horizon reordered to governance 0.1.5 before Games/KSP, prompt 011 verified) +``` + +Il confirme notamment : + +- `alpha.1`, `alpha.2`, `alpha.2.fix.1`, `alpha.3` et `beta.1` possèdent leurs histories avec les statuts attendus ; +- `rc.1.md` est le seul delta `0.1.4` encore sans history pendant la gate ; +- `710-TAURI.md`, `004-TAURI.md` et l’étude `002` restent gelés ; +- le changelog candidat ne contient aucune chronologie de tranches ; +- la roadmap engage désormais `0.1.5` gouvernance/autonomie, `0.1.6` Games, `0.1.7` KSP et `0.1.8` audits Rust ; +- le prompt `011` reprend explicitement les trois questions transversales sans démarrer `0.1.5` ; +- aucun template Tauri générique ni contrat `006-TAURI_VALIDATION.md` n’est introduit. + +## Hygiène Git et scope observé + +`git diff --check` et `git diff --cached --check` n’ont produit aucun diagnostic. + +Le scope indexé observé est exactement : + +```text +M CHANGELOG.md +M ROADMAP.md +M VERSION +A deltas/0.1.4/rc.1.md +M docs/000-README.md +M docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md +M docs/studies/000-README.md +A docs/studies/004-V0_1_4_HORIZON_REVIEW.md +A prompts/011-V0_1_5_START_PROMPT.md +``` + +## Décision + +`0.1.4-rc.1` est validée `PASS`. + +`rel.1` peut promouvoir mécaniquement cette RC vers la stable `0.1.4`. Cette promotion ne doit ni rouvrir le scope Tauri ni appliquer les changements normatifs réservés à `0.1.5`. diff --git a/prompts/011-V0_1_5_START_PROMPT.md b/prompts/011-V0_1_5_START_PROMPT.md new file mode 100644 index 0000000..cb88e52 --- /dev/null +++ b/prompts/011-V0_1_5_START_PROMPT.md @@ -0,0 +1,81 @@ + + + +# Prompt de démarrage 0.1.5 — sémantique normative et autonomie des projets + +## Baseline et cible + +Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`. + +La baseline attendue au démarrage effectif de `0.1.5` est l’archive source téléchargée depuis le tag Gitea `v0.1.4`, accompagnée du rapport post-tag `pgr-0.1.4-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`. + +Version cible : `0.1.5`. Première tranche attendue : `0.1.5-alpha.1`. + +Une archive source de tag peut légitimement ne pas contenir `.git`. Ne pas lui attribuer une preuve Git qu’elle ne peut contenir. + +## Mission + +Stabiliser avant les adoptions Games/KSP trois contrats transversaux révélés par l’utilisation réelle de PGR : + +1. `SHOULD / SHOULD NOT` exprime une forte recommandation non obligatoire et ne doit pas être traité comme un `MUST` affaibli ; +2. après instanciation/adoption, le projet destinataire devient autonome et ses règles locales sont l’autorité de ses sessions/releases suivantes ; +3. PGR reste centré sur les contrats de gouvernance/règles réutilisables tandis que howtos, recettes et snippets pratiques pourront vivre dans SaseDev Knowledge lorsque celui-ci est suffisamment fonctionnel, sans créer de dépendance normative de PGR vers Knowledge. + +La décision de trajectoire autoritaire est enregistrée dans [`../docs/studies/004-V0_1_4_HORIZON_REVIEW.md`](../docs/studies/004-V0_1_4_HORIZON_REVIEW.md). + +## Intake obligatoire + +Avant toute modification : + +- vérifier intégralement l’archive stable `v0.1.4` et le rapport post-tag réellement fourni ; +- relire `RULES.md`, `docs/rules/200-GOVERNANCE.md`, `210-WORKFLOW.md`, `220-SKELETONS.md`, `230-ADOPTION.md` et `400-VALIDATION.md` ; +- relire `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`, `docs/templates/003-NEW_SESSION_PROMPT.md` et `007-EXISTING_PROJECT_ADOPTION.md` ; +- relire la revue d’horizon `004-V0_1_4_HORIZON_REVIEW.md` et le plan historique `010-V0_1_4_TAURI_REEVALUATION_PLAN.md` ; +- vérifier les deltas/histories `0.1.4`, notamment le `FAIL` explicite de `alpha.2` et son `alpha.2.fix.1 PASS`, sans réécrire cette histoire ; +- vérifier que la première tranche préparée est bien `0.1.5-alpha.1`. + +## Contrat normatif à établir + +Le travail doit converger vers les propriétés suivantes sans supposer leur rédaction finale : + +```text +MUST / MUST NOT obligation ou interdiction normative +SHOULD / SHOULD NOT forte recommandation non obligatoire +MAY possibilité neutre +``` + +Un écart à un `SHOULD` ne doit pas, à lui seul, provoquer un échec de gate ni exiger un `OVERRIDE`. Une justification locale peut rester utile lorsqu’elle apporte une valeur durable, mais elle ne transforme pas la recommandation en obligation. + +## Contrat d’autonomie à établir + +L’utilisation de PGR est ponctuelle : sélection d’un snapshot, instanciation/adoption, adaptation, puis établissement d’une baseline locale autonome. + +Les sessions/releases ultérieures d’un projet destinataire doivent partir de ses propres règles, plans, architecture et historiques. Elles ne doivent ni rechercher automatiquement « la dernière version de PGR », ni traiter PGR comme un upstream à suivre. + +Un réalignement futur avec PGR reste possible uniquement comme scope explicite utilisant un snapshot PGR choisi et une nouvelle comparaison des écarts. + +## Frontière avec SaseDev Knowledge + +PGR doit rester auto-suffisant pour comprendre ses exigences. `0.1.5` doit formaliser une frontière entre : + +- contrats normatifs, owners, skeleton specifications minimales et validations directement liées aux règles, qui restent dans PGR ; +- howtos, recettes, snippets, exemples pratiques, dépannage et variantes d’implémentation, qui deviennent candidats à Knowledge. + +Ne pas déplacer automatiquement du contenu vers SaseDev Knowledge. Si un corpus Knowledge autoritaire est explicitement fourni pendant la session, il MAY servir à vérifier la frontière ou préparer une migration future ; son absence ne bloque pas `0.1.5`. + +## Hors scope + +`0.1.5` ne doit pas : + +- commencer l’adoption de `sasedev-games`, désormais réservée à `0.1.6` ; +- commencer l’adoption de `khadhroony-solana-project`, désormais réservée à `0.1.7` ; +- commencer les audits Rust/Clippy read-only, désormais réservés à `0.1.8` ; +- rouvrir le domaine Tauri `0.1.4` sans défaut transversal réellement démontré ; +- convertir tous les `SHOULD` existants en `MUST` ou `MAY` mécaniquement ; +- rendre PGR dépendant de SaseDev Knowledge pour interpréter une règle. + +## Première tranche attendue + +`0.1.5-alpha.1` doit commencer par un audit transversal des formulations et artefacts concernés, classifier les ambiguïtés réelles, créer/consolider le plan de release et proposer les owners exacts à modifier. Elle ne doit pas réécrire massivement les règles avant cet inventaire. + +La validation doit rester proportionnée et inclure au minimum les tests/audits PGR applicables, l’audit d’hygiène texte et des contrôles structurels prouvant que les adoptions Games/KSP n’ont pas été commencées prématurément.