Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.1.3-rc.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-28 13:00:04 +02:00
parent 3f3de726c2
commit a9fba6c5c3
7 changed files with 562 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
CHANGELOG.md
View File

@@ -1,5 +1,5 @@
<!-- file: CHANGELOG.md --> <!-- file: CHANGELOG.md -->
<!-- version: 15 --> <!-- version: 16 -->
# Changelog Project Governance Rules # Changelog Project Governance Rules
@@ -7,6 +7,16 @@ 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. 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.3 (candidate)
- 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 ;
- clarifie les responsabilités `compileSdk` / `targetSdk` / `minSdk`, l'identité `namespace` / `applicationId`, la configuration locale, le signing et les manifests/resources sans promouvoir les valeurs particulières de Games ;
- borne NDK, ABI et code natif aux projets réellement concernés, distingue compilation native, packaging et preuve runtime, et conserve les choix Rust/JNI/SDL de Games hors du profil Android générique ;
- rend Android Lint explicite, sépare tests JVM, tests instrumentés et smokes device/AVD, et distingue APK/AAB des preuves d'installation ou d'exécution ;
- normalise la compatibilité pages mémoire 16 KB uniquement comme contrainte conditionnelle au code natif, au package et au canal de distribution applicables, sans imposer une version AGP/NDK, un `targetSdk` ou une liste d'ABI universels ;
- confirme que les owners existants `400 + 600 + 610`, complétés par `520` et `522` lorsqu'ils s'appliquent, suffisent sans créer de skeleton Android, template, audit Python, owner JNI/Rust/SDL ou contrat de validation redondant ;
- prépare le réexamen Tauri distinct de `0.1.4` sans lever son `DEFER` par anticipation et conserve l'adoption Games comme cible séparée `0.1.5`.
## 0.1.2 ## 0.1.2
- sépare l'ancien profil combiné Java/Maven/Gradle en trois owners indépendants et composables : `520-JAVA`, `521-MAVEN` et `522-GRADLE`, afin qu'un build tool ne devienne pas implicitement applicable à tout projet Java ; - sépare l'ancien profil combiné Java/Maven/Gradle en trois owners indépendants et composables : `520-JAVA`, `521-MAVEN` et `522-GRADLE`, afin qu'un build tool ne devienne pas implicitement applicable à tout projet Java ;

2
VERSION
View File

@@ -1 +1 @@
0.1.3-beta.1 0.1.3-rc.1

312
deltas/0.1.3/rc.1.md Normal file
View File

@@ -0,0 +1,312 @@
<!-- file: deltas/0.1.3/rc.1.md -->
<!-- version: 1 -->
# Delta 0.1.3-rc.1 — gel du scope Android et gate de release candidate
## Baseline et version
Baseline attendue : commit opérateur de `0.1.3-beta.1`, réalisé après application de `history/0.1.3/beta.1.md` avec statut `PASS`.
Le hash de ce commit n'est pas anticipé.
Version avant application :
```text
0.1.3-beta.1
```
Version après application :
```text
0.1.3-rc.1
```
## Objet et gel
La RC gèle le scope fonctionnel de `0.1.3` sur :
- Android comme spécialisation de `600-PLATFORMS.md`, neutre vis-à-vis du langage applicatif et composant Java/Gradle uniquement lorsqu'ils sont réellement applicables ;
- les responsabilités distinctes de `compileSdk`, `targetSdk` et `minSdk`, avec `minSdk` justifié par le contrat produit plutôt que minimisé cérémoniellement ;
- `namespace`, `applicationId`, manifests/resources, configuration locale et signing comme responsabilités Android clairement bornées ;
- NDK, ABI et bibliothèques natives uniquement pour les projets réellement concernés, sans version NDK ni liste d'ABI universelles ;
- la séparation entre compilation native, packaging et preuve runtime ;
- Android Lint comme gate explicite, avec tests JVM, tests instrumentés et smokes device/AVD sélectionnés proportionnellement au changement ;
- la distinction APK/AAB versus preuve d'installation/exécution ;
- la compatibilité pages mémoire 16 KB comme contrat conditionnel au code natif, au package et au canal de distribution concernés, sans minimum AGP/NDK/SDK universel ;
- les choix spécifiques Games — versions d'outils, niveaux SDK, quatre ABI, Rust/JNI/SDL, modules et assets — conservés comme décisions locales ;
- la décision beta qu'aucun skeleton Android, template de build, audit Python, owner JNI/Rust/SDL ni contrat de validation Android séparé n'est justifié ;
- la frontière suivante : réexamen Tauri `0.1.4`, adoption Games `0.1.5`, adoption KSP `0.1.6`.
Le changelog reçoit une entrée candidate `0.1.3` orientée utilisateurs. Le prompt `010-V0_1_4_START_PROMPT.md` est préparé pour le réexamen Tauri après publication vérifiée de `v0.1.3`.
Aucune nouvelle règle fonctionnelle Android n'entre dans cette RC. Les owners, skeletons, templates, validations et scripts sont vérifiés mais non modifiés.
## Scope
REPLACE :
```text
VERSION
CHANGELOG.md
docs/000-README.md
docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
```
ADD :
```text
deltas/0.1.3/rc.1.md
prompts/010-V0_1_4_START_PROMPT.md
```
DELETE : aucun.
Le history `beta.1` est livré séparément et MUST être appliqué/committé avant ce delta.
## Gate opérateur de release candidate
Après application du history `PASS` de `beta.1`, commit/push de `beta.1`, puis application du présent delta :
```bash
test "$(cat VERSION)" = '0.1.3-rc.1'
git cat-file -e HEAD:history/0.1.3/beta.1.md
test -f history/0.1.3/beta.1.md
test -f deltas/0.1.3/rc.1.md
test -f prompts/010-V0_1_4_START_PROMPT.md
test ! -e history/0.1.3/rc.1.md
grep -A2 '^## Statut$' history/0.1.3/beta.1.md | grep -Fx 'PASS'
grep -Fx '<!-- version: 16 -->' CHANGELOG.md
grep -Fx '## 0.1.3 (candidate)' CHANGELOG.md
grep -Fx '<!-- version: 39 -->' docs/000-README.md
grep -Fx '<!-- version: 5 -->' docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
grep -Fx '<!-- version: 14 -->' ROADMAP.md
grep -Fx '<!-- version: 1 -->' prompts/010-V0_1_4_START_PROMPT.md
grep -Fx '<!-- version: 5 -->' docs/rules/610-ANDROID.md
grep -Fx '<!-- version: 6 -->' docs/rules/710-TAURI.md
grep -Fx '<!-- version: 2 -->' docs/studies/002-TAURI_SKELETON_DECISION.md
grep -Fx '<!-- version: 1 -->' docs/skeletons/003-WEB_FRONTEND.md
grep -Fx '<!-- version: 1 -->' docs/validation/005-WEB_FRONTEND_VALIDATION.md
```
Contrôle d'intégration de la RC :
```bash
python3 -B - <<'PYGATE'
from pathlib import Path
import re
expected = {
"alpha.1.md": "PASS",
"alpha.2.md": "PASS",
"alpha.3.md": "PASS",
"beta.1.md": "PASS",
}
histories = {path.name for path in Path("history/0.1.3").glob("*.md")}
assert histories == set(expected), histories
for name, status in expected.items():
text = Path("history/0.1.3", name).read_text(encoding="utf-8")
assert re.search(rf"## Statut\s+{status}\s", text), (name, status)
deltas = {path.name for path in Path("deltas/0.1.3").glob("*.md")}
assert deltas == set(expected) | {"rc.1.md"}, deltas
changelog = Path("CHANGELOG.md").read_text(encoding="utf-8")
assert "## 0.1.3 (candidate)" in changelog
section = changelog.split("## 0.1.3 (candidate)", 1)[1].split("## 0.1.2", 1)[0]
for phrase in (
"profil Android",
"compileSdk",
"targetSdk",
"minSdk",
"namespace",
"applicationId",
"NDK",
"Android Lint",
"tests instrumentés",
"APK/AAB",
"16 KB",
"0.1.4",
"0.1.5",
):
assert phrase in section, phrase
for forbidden in (
"alpha.1",
"alpha.2",
"alpha.3",
"beta.1",
"rc.1",
):
assert forbidden not in section, forbidden
android = Path("docs/rules/610-ANDROID.md").read_text(encoding="utf-8")
for phrase in (
"Android ne sélectionne pas à lui seul le langage applicatif du projet.",
"Le choix de `minSdk` MUST être justifié par le contrat produit",
"PGR ne fixe ni version NDK ni liste universelle d'ABI.",
"PGR MUST NOT supposer qu'un build Gradle ordinaire exécute Lint automatiquement.",
"Un AAB n'est pas directement une preuve d'installation ou d'exécution sur device.",
"## Pages mémoire 16 KB et packaging natif",
"PGR MUST NOT imposer une version AGP/NDK globale uniquement pour cette raison.",
):
assert phrase in android, phrase
for forbidden in (
"targetSdk MUST être 36",
"minSdk MUST être 21",
"NDK MUST être r28",
"MUST supporter arm64-v8a, armeabi-v7a, x86_64 et x86",
"Gradle MUST être 9.7.1",
"AGP MUST être 9.4.0",
"JDK MUST être 25",
):
assert forbidden not in android, forbidden
plan = Path("docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md").read_text(encoding="utf-8")
for phrase in (
"### beta.1 — réconciliation et décision d'artefacts\n\nRelire",
"Statut opérateur : **PASS**.",
"### rc.1 — release candidate\n\nStatut opérateur : **à valider**.",
"prompts/010-V0_1_4_START_PROMPT.md",
"Aucune nouvelle fonctionnalité normative Android ne doit apparaître en RC.",
):
assert phrase in plan, phrase
prompt = Path("prompts/010-V0_1_4_START_PROMPT.md").read_text(encoding="utf-8")
for phrase in (
"archive source téléchargée depuis le tag Gitea `v0.1.3`",
"pgr-0.1.3-publish.001-report.md",
"0.1.4-alpha.1",
"2a9cabcb9f147a348dcf8d24df8bc6c5029089b6d49feb17bd4a42b4293c329a",
"ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8",
"002-TAURI_SKELETON_DECISION.md",
"710-TAURI.md",
"003-WEB_FRONTEND",
"ADOPT / KEEP-LOCAL / OVERRIDE / DEFER",
"conditions de sortie",
"créer le skeleton Tauri parce que la roadmap le mentionne",
"adoption Games `0.1.5`",
"adoption KSP `0.1.6`",
):
assert phrase in prompt, phrase
study = Path("docs/studies/002-TAURI_SKELETON_DECISION.md").read_text(encoding="utf-8")
for phrase in (
"DEFER",
"Condition 1 — TypeScript et conventions Web contrôlées",
"Condition 2 — Vite et ownership des commandes/dev server/build outputs",
"Condition 3 — Sass/CSS et statut des artefacts générés",
"Condition 4 — validation frontend indépendante de la validation Tauri",
"Condition 5 — framework CSS classé comme décision de skeleton/projet",
"réexamen autorisé 0.1.4",
"création automatique interdite",
):
assert phrase in study, phrase
roadmap = Path("ROADMAP.md").read_text(encoding="utf-8")
for version in ("0.1.3", "0.1.4", "0.1.5", "0.1.6", "0.1.7"):
assert f"- `( ) {version}`" in roadmap, version
assert "- `( ) 0.1.8`" not in roadmap
assert "skeleton Tauri jusqu'au réexamen 0.1.4" in roadmap
for forbidden_path in (
"docs/validation/006-ANDROID_VALIDATION.md",
"docs/skeletons/004-ANDROID.md",
"docs/rules/620-JNI.md",
"docs/skeletons/004-TAURI.md",
):
assert not Path(forbidden_path).exists(), forbidden_path
index = Path("docs/000-README.md").read_text(encoding="utf-8")
assert "../prompts/010-V0_1_4_START_PROMPT.md" in index
print("0.1.3 rc.1 integration audit: clean (4 prior histories, frozen Android profile, candidate changelog and prompt 010 verified)")
PYGATE
```
Rejouer ensuite les preuves PGR :
```bash
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
```
Vérifier également l'hygiène texte/templates sans simuler une toolchain Android ou Tauri absente du dépôt PGR :
```bash
python3 -B - <<'PYHYGIENE'
from pathlib import Path
import json
import tomllib
for path in sorted(Path("templates/rust-cargo").rglob("*.toml")):
tomllib.loads(path.read_text(encoding="utf-8"))
json.loads(Path("templates/web-typescript/package.json").read_text(encoding="utf-8"))
json.loads(Path("templates/web-typescript/tsconfig.json").read_text(encoding="utf-8"))
roots = (
Path("VERSION"), Path("README.md"), Path("RULES.md"), Path("ROADMAP.md"), Path("CHANGELOG.md"),
Path("docs"), Path("deltas"), Path("history"), Path("prompts"), Path("templates"),
)
files = []
for root in roots:
if root.is_file():
files.append(root)
elif root.is_dir():
files.extend(path for path in root.rglob("*") if path.is_file())
for path in files:
try:
data = path.read_bytes()
text = data.decode("utf-8")
except UnicodeDecodeError:
continue
assert b"\r" not in data, path
assert text.endswith("\n"), path
for number, line in enumerate(text.splitlines(), 1):
assert line == line.rstrip(" \t"), (path, number)
print("0.1.3 rc.1 text/template hygiene: clean")
PYHYGIENE
git diff --check
git add VERSION CHANGELOG.md docs/000-README.md \
docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md \
deltas/0.1.3/rc.1.md prompts/010-V0_1_4_START_PROMPT.md
git diff --cached --check
git status --short
```
Le scope indexé attendu avant ajout du history est exactement :
```text
M CHANGELOG.md
M VERSION
A deltas/0.1.3/rc.1.md
M docs/000-README.md
M docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
A prompts/010-V0_1_4_START_PROMPT.md
```
La revue qualitative doit confirmer que :
- aucune règle fonctionnelle Android nouvelle n'entre en RC ;
- `610-ANDROID.md` reste en révision `5` et aucun choix Games n'est généralisé ;
- aucun artefact Android supplémentaire n'est créé ;
- le changelog candidat décrit la valeur utilisateur de `0.1.3` sans recopier la chronologie alpha/beta/RC ;
- le prompt `010` exige une future stable `v0.1.3` réellement publiée et son rapport post-tag `PASS` ;
- le `DEFER` Tauri n'est pas levé par le prompt : `0.1.4` doit le réexaminer objectivement contre les corpus courants ;
- l'adoption Games `0.1.5` et l'adoption KSP `0.1.6` ne sont pas commencées ;
- aucune preuve Android/Tauri exécutable n'est simulée dans PGR.
## Transition
### PASS
Produire séparément `history/0.1.3/rc.1.md`, puis préparer la promotion mécanique `0.1.3-rel.1` sans rouvrir le scope fonctionnel.

5
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md --> <!-- file: docs/000-README.md -->
<!-- version: 38 --> <!-- version: 39 -->
# Documentation PGR # Documentation PGR
@@ -22,12 +22,13 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
## Points d'entrée de 0.1.3 ## Points d'entrée de 0.1.3
- [`plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`](plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md) — plan actif de la réévaluation Android ; `alpha.2` et `alpha.3` ont révisé le profil et `beta.1` réconcilie les décisions avant gel RC. - [`plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`](plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md) — plan actif de la réévaluation Android ; `beta.1` est `PASS` et `rc.1` gèle le scope avant promotion stable.
- [`rules/610-ANDROID.md`](rules/610-ANDROID.md) — owner Android révisé : contrats SDK/identité/signing, natif/ABI, Lint, niveaux de tests, packaging/distribution et 16 KB conditionnel, sans absorber les choix propres à Games. - [`rules/610-ANDROID.md`](rules/610-ANDROID.md) — owner Android révisé : contrats SDK/identité/signing, natif/ABI, Lint, niveaux de tests, packaging/distribution et 16 KB conditionnel, sans absorber les choix propres à Games.
- [`rules/520-JAVA.md`](rules/520-JAVA.md) et [`rules/522-GRADLE.md`](rules/522-GRADLE.md) — owners composés uniquement lorsqu'un projet Android contient réellement du Java ou utilise Gradle. - [`rules/520-JAVA.md`](rules/520-JAVA.md) et [`rules/522-GRADLE.md`](rules/522-GRADLE.md) — owners composés uniquement lorsqu'un projet Android contient réellement du Java ou utilise Gradle.
- [`rules/600-PLATFORMS.md`](rules/600-PLATFORMS.md) et [`rules/400-VALIDATION.md`](rules/400-VALIDATION.md) — contrats généraux de plateforme et de preuve auxquels la spécialisation Android doit rester conforme. - [`rules/600-PLATFORMS.md`](rules/600-PLATFORMS.md) et [`rules/400-VALIDATION.md`](rules/400-VALIDATION.md) — contrats généraux de plateforme et de preuve auxquels la spécialisation Android doit rester conforme.
- [`studies/003-V0_1_0_HORIZON_REVIEW.md`](studies/003-V0_1_0_HORIZON_REVIEW.md) — revue ayant engagé Android `0.1.3`, Tauri `0.1.4` puis l'adoption Games `0.1.5` comme scopes distincts. - [`studies/003-V0_1_0_HORIZON_REVIEW.md`](studies/003-V0_1_0_HORIZON_REVIEW.md) — revue ayant engagé Android `0.1.3`, Tauri `0.1.4` puis l'adoption Games `0.1.5` comme scopes distincts.
- [`../prompts/009-V0_1_3_START_PROMPT.md`](../prompts/009-V0_1_3_START_PROMPT.md) — contrat de reprise exécuté pour ouvrir `0.1.3-alpha.1` après publication vérifiée de `v0.1.2`. - [`../prompts/009-V0_1_3_START_PROMPT.md`](../prompts/009-V0_1_3_START_PROMPT.md) — contrat de reprise exécuté pour ouvrir `0.1.3-alpha.1` après publication vérifiée de `v0.1.2`.
- [`../prompts/010-V0_1_4_START_PROMPT.md`](../prompts/010-V0_1_4_START_PROMPT.md) — prompt préparé par la RC pour le réexamen Tauri `0.1.4`, à exécuter uniquement après publication et vérification post-tag de `v0.1.3`.
## Points d'entrée de 0.1.2 ## Points d'entrée de 0.1.2

12
docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md --> <!-- file: docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md -->
<!-- version: 4 --> <!-- version: 5 -->
# Plan 0.1.3 — réévaluation pratique Android # Plan 0.1.3 — réévaluation pratique Android
@@ -557,9 +557,17 @@ Vérifier qu'aucun choix Games n'est devenu un `MUST` général, que les contrai
Décider explicitement qu'aucun artefact supplémentaire n'est nécessaire si `610` et les owners existants suffisent. Un artefact nouveau qui exigerait du contenu fonctionnel supplémentaire entraîne un REPLAN vers une tranche alpha dédiée. Décider explicitement qu'aucun artefact supplémentaire n'est nécessaire si `610` et les owners existants suffisent. Un artefact nouveau qui exigerait du contenu fonctionnel supplémentaire entraîne un REPLAN vers une tranche alpha dédiée.
Statut opérateur : **PASS**.
La gate beta confirme `48/48` tests Python, les trois audits Markdown, la réconciliation des owners et l'absence d'artefact Android supplémentaire justifié. Aucun fix ni REPLAN n'est requis.
### rc.1 — release candidate ### rc.1 — release candidate
Geler le scope Android, préparer le changelog candidat et le prompt de reprise `0.1.4` sans commencer Tauri. Rejouer les validations PGR de release et vérifier les frontières `0.1.4` / `0.1.5`. Statut opérateur : **à valider**.
Geler le scope Android, préparer le changelog candidat et `prompts/010-V0_1_4_START_PROMPT.md` sans commencer Tauri. Rejouer les validations PGR de release et vérifier les frontières `0.1.4` / `0.1.5`.
Aucune nouvelle fonctionnalité normative Android ne doit apparaître en RC. Le profil `610-ANDROID.md` reste en révision `5`; la RC ne fait qu'établir la présentation candidate, le handoff vers `0.1.4` et les preuves de cohérence de release.
### rel.1 — promotion stable ### rel.1 — promotion stable

127
history/0.1.3/rc.1.md Normal file
View File

@@ -0,0 +1,127 @@
<!-- file: history/0.1.3/rc.1.md -->
<!-- version: 1 -->
# History 0.1.3-rc.1 — release candidate Android
## Statut
PASS
La gate opérateur de `0.1.3-rc.1` exécutée le `2026-09-28` a réussi. Elle confirme le gel du profil Android révisé, l'intégrité des histories antérieurs, le changelog candidat, le prompt de reprise `010`, les tests Python, les audits Markdown et l'hygiène texte/templates avant promotion stable.
## Baseline opérateur
La tranche `0.1.3-beta.1` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `rc.1` :
```text
commit 3f3de72
message 0.1.3-beta.1
push origin/master PASS
```
Après application du delta `rc.1`, les contrôles initiaux ont confirmé :
```text
VERSION 0.1.3-rc.1
history/0.1.3/beta.1.md présent dans HEAD et le workspace
deltas/0.1.3/rc.1.md présent
prompts/010-V0_1_4_START_PROMPT.md présent
history/0.1.3/rc.1.md absent pendant la gate
CHANGELOG.md version 16
docs/000-README.md version 39
docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md version 5
ROADMAP.md version 14
prompts/010-V0_1_4_START_PROMPT.md version 1
docs/rules/610-ANDROID.md version 5
docs/rules/710-TAURI.md version 6
docs/studies/002-TAURI_SKELETON_DECISION.md version 2
docs/skeletons/003-WEB_FRONTEND.md version 1
docs/validation/005-WEB_FRONTEND_VALIDATION.md version 1
```
Le history `beta.1` a été retrouvé avec statut `PASS`.
## Gate d'intégration RC
Le contrôle structurel a affiché :
```text
0.1.3 rc.1 integration audit: clean (4 prior histories, frozen Android profile, candidate changelog and prompt 010 verified)
```
Il a vérifié les quatre histories antérieurs avec statut `PASS` :
```text
alpha.1 PASS
alpha.2 PASS
alpha.3 PASS
beta.1 PASS
```
Avant application du présent history, `rc.1.md` est la seule tranche `0.1.3` possédant un delta sans history.
La gate a également confirmé :
- le `CHANGELOG` candidat `0.1.3` sans détails de tranches ;
- le profil Android `610-ANDROID.md` gelé en révision `5` sans généralisation de `targetSdk 36`, `minSdk 21`, NDK r28, quatre ABI, Gradle 9.7.1, AGP 9.4.0 ou JDK 25 ;
- la composition Android avec les owners génériques sans créer d'owner JNI/Rust/SDL, skeleton Android ou contrat de validation redondant ;
- la distinction entre SDK, identité applicative, natif/ABI, Lint, niveaux de tests, APK/AAB et contraintes 16 KB conditionnelles ;
- la roadmap `0.1.3` à `0.1.7` sans réservation de `0.1.8` ;
- le maintien du `DEFER` Tauri jusqu'au réexamen `0.1.4` ;
- le prompt `010` ciblant `0.1.4-alpha.1` uniquement depuis une future archive du tag `v0.1.3` et son rapport post-tag réel ;
- l'absence de création anticipée du skeleton Tauri et le maintien des adoptions Games `0.1.5` et KSP `0.1.6` hors scope.
## Tests et audits PGR
La suite Python globale a exécuté `48` tests, tous réussis :
```text
Ran 48 tests in 0.745s
OK
```
Les audits documentaires sont propres :
```text
Markdown header audit: clean (261 file(s))
Markdown table audit: clean (11 table(s), 261 file(s))
Markdown link audit: clean (337 local link(s), 261 file(s))
```
L'hygiène texte/templates a également réussi :
```text
0.1.3 rc.1 text/template hygiene: clean
```
Les templates TOML Rust/Cargo et JSON Web ont été parsés ; aucun retour chariot, whitespace final ni fichier texte sans newline finale n'a été détecté dans le corpus contrôlé.
## 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 CHANGELOG.md
M VERSION
A deltas/0.1.3/rc.1.md
M docs/000-README.md
M docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
A prompts/010-V0_1_4_START_PROMPT.md
```
Le scope correspond exactement à la RC annoncée. Aucun owner Android, Java, Gradle ou Tauri, template, skeleton, validation, étude technique ou script d'audit n'a été modifié pendant la RC.
## Décision
`0.1.3-rc.1` est `PASS`. Aucun fix ni REPLAN n'est requis.
La transition autorisée est la promotion mécanique pré-tag :
```text
0.1.3-rel.1
```
Cette promotion ne doit pas rouvrir le scope fonctionnel. Elle doit uniquement présenter `0.1.3` comme stable, produire sa propre gate pré-tag et préparer le handoff de publication sans anticiper le rapport post-tag.

98
prompts/010-V0_1_4_START_PROMPT.md Normal file
View File

@@ -0,0 +1,98 @@
<!-- file: prompts/010-V0_1_4_START_PROMPT.md -->
<!-- version: 1 -->
# Prompt de démarrage 0.1.4 — réexamen Tauri et skeleton contrôlé
## Baseline et cible
Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`.
La baseline attendue au démarrage effectif de `0.1.4` est l'archive source téléchargée depuis le tag Gitea `v0.1.3`, accompagnée du rapport post-tag `pgr-0.1.3-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`.
Version cible : `0.1.4`. Première tranche attendue : `0.1.4-alpha.1`.
Les corpus principaux attendus pour réexaminer Tauri sont des archives autoritaires récentes de `khadhroony-solana-project` et `sasedev-games`. Si aucune baseline plus récente n'est explicitement fournie, les dernières baselines Tauri déjà auditées par PGR restent des références de comparaison, sans être présumées représenter l'état courant des projets :
```text
khadhroony-solana-project-v0.3.17.zip 2a9cabcb9f147a348dcf8d24df8bc6c5029089b6d49feb17bd4a42b4293c329a
games-v0.3.6.zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
```
Une archive source peut légitimement ne pas contenir `.git`. Ne pas lui attribuer une preuve Git qu'elle ne peut contenir.
## Reprise manuelle après publication
Après vérification réelle de l'archive du tag `v0.1.3` et du rapport post-tag `PASS`, la consigne de nouvelle session doit suivre le pattern de [`../docs/templates/003-NEW_SESSION_PROMPT.md`](../docs/templates/003-NEW_SESSION_PROMPT.md) et citer les artefacts réellement obtenus.
La forme attendue, si les noms et le statut sont confirmés, est :
```text
Partir de l'archive pgr-v0.1.3.zip téléchargée depuis le tag Gitea v0.1.3 et du rapport post-tag pgr-0.1.3-publish.001-report.md. Lire et exécuter prompts/010-V0_1_4_START_PROMPT.md. Vérifier intégralement la stable PGR et les baselines autoritaires fournies de KSP/Games avant de réexaminer le DEFER du skeleton Tauri et de préparer 0.1.4-alpha.1, sans commencer l'adoption Games réservée à 0.1.5 ni l'adoption KSP réservée à 0.1.6.
```
Ce texte ne doit pas être remis comme preuve de publication avant le `publish.001 PASS` réel.
## Mission
Réexaminer objectivement la décision `DEFER` enregistrée dans [`../docs/studies/002-TAURI_SKELETON_DECISION.md`](../docs/studies/002-TAURI_SKELETON_DECISION.md) à partir des corpus Tauri réellement fournis, du profil [`../docs/rules/710-TAURI.md`](../docs/rules/710-TAURI.md), des owners Web stabilisés par `0.1.1`, du profil Android stabilisé par `0.1.3` et des règles de skeletons.
La release `0.1.4` ne part pas du principe qu'un skeleton Tauri doit être créé. Elle doit confirmer, modifier ou abandonner le candidat historique selon les preuves courantes. Si un skeleton contrôlé est justifié, il doit sélectionner et composer des owners existants plutôt que devenir leur propriétaire implicite.
`alpha.1` MUST commencer par :
1. auditer indépendamment la stable `v0.1.3` et son rapport post-tag lorsqu'il est fourni ;
2. auditer les corpus KSP/Games réellement fournis et inventorier leurs hosts Tauri actuels, sans supposer que les layouts, versions ou plugins historiques sont encore représentatifs ;
3. relire `710-TAURI.md`, `220-SKELETONS.md`, `510-RUST_CARGO.md`, `003-WEB_FRONTEND.md`, les owners Web `530/540/550/560`, `005-WEB_FRONTEND_VALIDATION.md`, `600-PLATFORMS.md`, `610-ANDROID.md`, l'étude `002-TAURI_SKELETON_DECISION.md` et la revue d'horizon `003` ;
4. vérifier la documentation Tauri 2 officielle courante pour les points susceptibles d'avoir évolué ;
5. créer le plan `0.1.4` avant toute matérialisation importante ;
6. classifier les choix observés avec `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` et décider explicitement si les conditions de sortie du report historique sont réellement satisfaites par le corpus courant.
## Questions à instruire
La release doit notamment réexaminer :
- pertinence réelle d'un skeleton Tauri organisationnel pour les nouveaux projets contrôlés ;
- composition avec `001-PROJECT_GOVERNANCE_FOUNDATION`, `002-RUST_CARGO_WORKSPACE` et `003-WEB_FRONTEND` sans duplication normative ;
- host Cargo direct versus layout `src-tauri/`, en distinguant convention organisationnelle et possibilité supportée par Tauri ;
- statut de `frontend/`, Vite, TypeScript, Sass et Bootstrap : choix éventuels du skeleton/projet, jamais obligations Tauri implicites ;
- TS-RS pour les DTO Rust/TypeScript lorsque cette frontière est réellement présente, sans le rendre universel ;
- ownership de `tauri.conf.json`, `build.rs`, capabilities/permissions, plugins, commandes et hooks frontend ;
- ajout manuel de plugins versus commandes de commodité telles que `cargo tauri add`, avec revue explicite des modifications générées ;
- `devUrl`, `frontendDist`, outputs/caches et séparation source/généré ;
- stratégie de version produit `CANONICAL / MIRROR-EXACT / MIRROR-STABLE` sans churn cérémoniel ;
- distinction entre preuves Rust, preuves frontend, `tauri dev`, `tauri build` et packaging plateforme ;
- projets mobiles générés/modifiés par Tauri et composition avec les profils Android/iOS applicables sans absorber leurs responsabilités dans `710` ;
- nécessité éventuelle de templates techniques ou d'un contrat de validation Tauri supplémentaire, uniquement si un besoin non couvert est démontré ;
- compatibilité du candidat avec plusieurs package managers et plusieurs choix frontend supportés.
## Frontières obligatoires
`0.1.4` MUST NOT :
- migrer KSP ou Games vers PGR ;
- créer le skeleton Tauri parce que la roadmap le mentionne ou parce que les cinq prérequis Web sont désormais couverts ;
- transformer Vite, TypeScript, Sass, Bootstrap, npm, TS-RS, `frontend/` ou l'absence de `src-tauri/` en obligations universelles du profil Tauri sans preuve correspondante ;
- rouvrir Android `0.1.3` sauf défaut transversal réellement démontré ;
- démarrer l'adoption Games `0.1.5` ou l'adoption KSP `0.1.6` ;
- intégrer WASM au host Tauri par défaut ;
- créer un owner serveur Rust, deployment/operations ou iOS par proximité ;
- réserver une nouvelle release au-delà de la roadmap engagée sans revue d'horizon justifiée.
Les personnalisations produit, plugins concrets, fenêtres, CSP, ports, targets de bundle, icônes, ABI et autres valeurs spécifiques aux corpus restent locales sauf invariant réutilisable démontré.
## Principes
- Le skeleton doit composer des owners ; il ne remplace pas un owner manquant.
- Les conditions de sortie historiques autorisent un réexamen, pas une création automatique.
- Partir des hosts Tauri réellement présents dans les corpus courants et comparer leurs convergences/divergences.
- Vérifier les capacités officielles courantes de Tauri 2 avant de figer une convention organisationnelle.
- Maintenir une séparation claire entre host Rust, frontend Web, intégration Tauri et plateformes mobiles.
- Utiliser les toolchains propriétaires des preuves : Cargo/Rust pour Rust, toolchain frontend pour le Web, CLI Tauri pour l'orchestration Tauri et outils plateforme pour les artefacts mobiles.
- Ne pas exiger un `tauri build` complet lorsqu'une modification ne touche pas l'intégration ou le packaging ; inversement, ne pas assimiler un `cargo check` ou un build frontend isolé à une preuve Tauri complète lorsque la propriété dépend des hooks/capabilities/bundling.
- Conserver `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` afin de préparer les futures adoptions `0.1.5` et `0.1.6` sans les commencer.
## Workflow
Suivre [`../RULES.md`](../RULES.md), [`../docs/rules/210-WORKFLOW.md`](../docs/rules/210-WORKFLOW.md), [`../docs/rules/220-SKELETONS.md`](../docs/rules/220-SKELETONS.md), [`../docs/rules/230-ADOPTION.md`](../docs/rules/230-ADOPTION.md) et [`../docs/rules/400-VALIDATION.md`](../docs/rules/400-VALIDATION.md).
La séquence reste : delta → gate opérateur → history constaté → application du history → commit/push → delta suivant. Les commandes de handoff sont remises automatiquement conformément à [`../docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`](../docs/templates/006-OPERATOR_COMMAND_HANDOFF.md).