0.1.4-alpha.1
This commit is contained in:
@@ -1,5 +1,5 @@
|
|||||||
<!-- file: README.md -->
|
<!-- file: README.md -->
|
||||||
<!-- version: 25 -->
|
<!-- version: 26 -->
|
||||||
|
|
||||||
# Project Governance Rules
|
# Project Governance Rules
|
||||||
|
|
||||||
@@ -11,7 +11,7 @@ Le dépôt officiel est `https://git.sasedev.com/Sasedev/pgr`.
|
|||||||
|
|
||||||
## Statut
|
## Statut
|
||||||
|
|
||||||
PGR a clôturé sa phase de fondation `0.0.x`, dispose avec `0.1.0` de sa première baseline réutilisable stable, avec `0.1.1` d’une fondation frontend Web stable, avec `0.1.2` d’owners Java, Maven et Gradle séparés et composables, et avec `0.1.3` d’un profil Android réévalué contre Games sans généraliser ses choix locaux. Les contrats SDK, identité, natif/ABI, Lint, tests, packaging et 16 KB sont désormais bornés par leur applicabilité réelle. Tauri reste réservé à `0.1.4` et l’adoption Games à `0.1.5`.
|
PGR a clôturé sa phase de fondation `0.0.x`, dispose avec `0.1.0` de sa première baseline réutilisable stable, avec `0.1.1` d’une fondation frontend Web stable, avec `0.1.2` d’owners Java, Maven et Gradle séparés et composables, et avec `0.1.3` d’un profil Android réévalué contre Games sans généraliser ses choix locaux. `0.1.4-alpha.1` ouvre désormais le réexamen Tauri : les conditions Web du report historique sont confirmées couvertes, sept hosts actuels Games/KSP sont inventoriés et le candidat de skeleton organisationnel est retenu pour instruction sans matérialisation anticipée. L’adoption Games reste réservée à `0.1.5` et l’adoption KSP à `0.1.6`.
|
||||||
|
|
||||||
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. La release `0.1.0` stabilise la première baseline réutilisable : adoption `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, skeletons/templates Rust/Cargo exercés par dry-run, clôture `rel.N`, handoff opérateur automatique et trajectoire `0.1.1` à `0.1.7` issue d'une revue d'horizon explicite. La release `0.1.1` stabilise la fondation frontend Web : owners indépendants TypeScript/package/Vite/CSS-Sass, déclarations de types externes conditionnelles, package manager neutre, validation frontend indépendante du host et skeleton Web composable, tout en conservant le skeleton Tauri en `DEFER` jusqu’à son réexamen `0.1.4`. La release `0.1.2` stabilise trois owners indépendants `520-JAVA`, `521-MAVEN` et `522-GRADLE`, clarifie JDK/source/bytecode et l'ownership Gradle, conserve Maven cohérent sans corpus artificiel et maintient les responsabilités Android dans `610-ANDROID.md` pour leur réévaluation distincte en `0.1.3`. La release `0.1.3` stabilise le profil Android générique : séparation des responsabilités SDK et identité applicative, contraintes natives conditionnelles, Android Lint explicite, niveaux de tests distincts, frontières APK/AAB et compatibilité 16 KB liée au code natif et au canal de distribution, sans imposer les versions ou ABI propres à Games.
|
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. La release `0.1.0` stabilise la première baseline réutilisable : adoption `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, skeletons/templates Rust/Cargo exercés par dry-run, clôture `rel.N`, handoff opérateur automatique et trajectoire `0.1.1` à `0.1.7` issue d'une revue d'horizon explicite. La release `0.1.1` stabilise la fondation frontend Web : owners indépendants TypeScript/package/Vite/CSS-Sass, déclarations de types externes conditionnelles, package manager neutre, validation frontend indépendante du host et skeleton Web composable, tout en conservant le skeleton Tauri en `DEFER` jusqu’à son réexamen `0.1.4`. La release `0.1.2` stabilise trois owners indépendants `520-JAVA`, `521-MAVEN` et `522-GRADLE`, clarifie JDK/source/bytecode et l'ownership Gradle, conserve Maven cohérent sans corpus artificiel et maintient les responsabilités Android dans `610-ANDROID.md` pour leur réévaluation distincte en `0.1.3`. La release `0.1.3` stabilise le profil Android générique : séparation des responsabilités SDK et identité applicative, contraintes natives conditionnelles, Android Lint explicite, niveaux de tests distincts, frontières APK/AAB et compatibilité 16 KB liée au code natif et au canal de distribution, sans imposer les versions ou ABI propres à Games.
|
||||||
|
|
||||||
@@ -33,6 +33,7 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é
|
|||||||
- [`docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md`](docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md) — plan historique de la fondation frontend Web stable `0.1.1` ;
|
- [`docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md`](docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md) — plan historique de la fondation frontend Web stable `0.1.1` ;
|
||||||
- [`docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md`](docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md) — plan historique de la stable `0.1.2` : réévaluation Games, scission Java/Maven/Gradle et maintien d'Android hors scope ;
|
- [`docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md`](docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md) — plan historique de la stable `0.1.2` : réévaluation Games, scission Java/Maven/Gradle et maintien d'Android hors scope ;
|
||||||
- [`docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`](docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md) — plan historique de la stable Android `0.1.3`, fondée sur Games avec classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
|
- [`docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`](docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md) — plan historique de la stable Android `0.1.3`, fondée sur Games avec classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
|
||||||
|
- [`docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md`](docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md) — plan actif du réexamen Tauri `0.1.4`, fondé sur les hosts actuels Games/KSP, les owners Web stabilisés et la documentation Tauri 2 courante ;
|
||||||
- [`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/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/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 ;
|
- [`docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) — fondation composable de gouvernance locale pour un projet adoptant PGR ;
|
||||||
|
|||||||
207
deltas/0.1.4/alpha.1.md
Normal file
207
deltas/0.1.4/alpha.1.md
Normal file
@@ -0,0 +1,207 @@
|
|||||||
|
<!-- file: deltas/0.1.4/alpha.1.md -->
|
||||||
|
<!-- version: 1 -->
|
||||||
|
|
||||||
|
# Delta 0.1.4-alpha.1 — intake et cadrage du réexamen Tauri
|
||||||
|
|
||||||
|
## Objet
|
||||||
|
|
||||||
|
Ouvrir `0.1.4` conformément à `prompts/010-V0_1_4_START_PROMPT.md`, conserver une preuve locale de l'audit des baselines réellement fournies et matérialiser le plan avant toute modification normative ou création d'un skeleton Tauri.
|
||||||
|
|
||||||
|
La tranche ne crée pas `docs/skeletons/004-TAURI.md`, ne modifie pas `710-TAURI.md` et ne commence aucune adoption Games/KSP.
|
||||||
|
|
||||||
|
## Sources vérifiées avant préparation
|
||||||
|
|
||||||
|
```text
|
||||||
|
pgr-v0.1.3(1).zip
|
||||||
|
SHA-256 f3a7dffd5fe0fd3542e6b5207fda0b94bca2bd05bd5a54542d0a08d635a5d6ee
|
||||||
|
CRC PASS
|
||||||
|
|
||||||
|
pgr-0.1.3-publish.001-report.md
|
||||||
|
SHA-256 5405a1d6c216a5882c4638c07d573d50d440ce9e4e892d97f425e99054245544
|
||||||
|
status PASS
|
||||||
|
|
||||||
|
games-v0.3.6(3).zip
|
||||||
|
SHA-256 ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
|
||||||
|
CRC PASS
|
||||||
|
|
||||||
|
khadhroony-solana-project-v0.3.19(1).zip
|
||||||
|
SHA-256 64a3813620925fa4f8914cdf74113399cfdd78ad51d60bbeff9bafbddcf4b253
|
||||||
|
CRC PASS
|
||||||
|
```
|
||||||
|
|
||||||
|
La baseline PGR correspond exactement au SHA canonique publié. La baseline Games correspond exactement à la référence `0.3.6` du prompt. KSP `0.3.19` est le corpus courant explicitement fourni et remplace, pour cette étude, la référence historique `0.3.17` sans prétendre posséder une preuve post-tag non fournie.
|
||||||
|
|
||||||
|
## Résultats d'intake
|
||||||
|
|
||||||
|
La stable PGR rejoue `48/48` tests Python et ses trois audits Markdown propres.
|
||||||
|
|
||||||
|
Games `0.3.6` rejoue ses audits Rust/workspace, Markdown tables et distribution layout propres. KSP `0.3.19` rejoue ses audits Rust/workspace et Markdown tables propres.
|
||||||
|
|
||||||
|
L'inventaire Tauri courant comporte `7` hosts : un sous Games et six sous KSP. Les sept convergent sur un host Cargo direct, `build.rs`, `tauri.conf.json`, `capabilities/`, `src/tauri.rs`, `frontend/`, TypeScript et Vite, sans `src-tauri/`.
|
||||||
|
|
||||||
|
Les choix Bootstrap/Sass/TS-RS, plugins, windows, ACL, ports, identifiers, bundle/resources et WASM ne convergent pas suffisamment pour devenir des obligations générales.
|
||||||
|
|
||||||
|
La relecture des owners Web confirme les cinq conditions historiques de sortie du `DEFER`. La vérification Tauri 2 officielle confirme que le layout standard et les commandes de commodité restent des possibilités supportées, tandis que capabilities/permissions doivent être traitées comme une surface de sécurité explicite.
|
||||||
|
|
||||||
|
## Modifications de la tranche
|
||||||
|
|
||||||
|
- `VERSION` passe à `0.1.4-alpha.1` ;
|
||||||
|
- `README.md` annonce l'ouverture du réexamen Tauri et référence son plan actif ;
|
||||||
|
- `docs/000-README.md` ajoute les points d'entrée actifs de `0.1.4` ;
|
||||||
|
- `docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md` consigne audits, inventaire, classification et trajectoire ;
|
||||||
|
- le présent delta conserve le contrat de gate opérateur.
|
||||||
|
|
||||||
|
`ROADMAP.md` et `CHANGELOG.md` restent inchangés pendant cette tranche d'ouverture. Leur mise à jour est volontairement réservée aux phases de fermeture lorsque l'état réellement atteint est connu.
|
||||||
|
|
||||||
|
## Décision de tranche
|
||||||
|
|
||||||
|
```text
|
||||||
|
conditions Web historiques SATISFIED
|
||||||
|
ancien motif Web du DEFER LIFT
|
||||||
|
skeleton Tauri organisationnel ADOPT FOR MATERIALIZATION
|
||||||
|
création pendant alpha.1 NO
|
||||||
|
prochaine tranche alpha.2 — réconciliation normative 710 + étude 002
|
||||||
|
```
|
||||||
|
|
||||||
|
Cette décision autorise la matérialisation future du candidat ; elle ne présume pas que sa forme historique est correcte en bloc.
|
||||||
|
|
||||||
|
## Gate opérateur
|
||||||
|
|
||||||
|
Appliquer le delta puis exécuter depuis la racine du dépôt :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
cat VERSION
|
||||||
|
|
||||||
|
test -f docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
|
||||||
|
test -f deltas/0.1.4/alpha.1.md
|
||||||
|
test ! -e history/0.1.4/alpha.1.md
|
||||||
|
test ! -e docs/skeletons/004-TAURI.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
|
||||||
|
|
||||||
|
assert Path('VERSION').read_text(encoding='utf-8').strip() == '0.1.4-alpha.1'
|
||||||
|
|
||||||
|
expected = {
|
||||||
|
'0.0.1': 12,
|
||||||
|
'0.0.2': 12,
|
||||||
|
'0.0.3': 10,
|
||||||
|
'0.0.4': 9,
|
||||||
|
'0.0.5': 19,
|
||||||
|
'0.1.0': 10,
|
||||||
|
'0.1.1': 11,
|
||||||
|
'0.1.2': 7,
|
||||||
|
'0.1.3': 6,
|
||||||
|
}
|
||||||
|
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.1.3').glob('*.md'):
|
||||||
|
text = path.read_text(encoding='utf-8')
|
||||||
|
match = re.search(r'## Statut\s+(?:`?)(PASS|FAIL|PARTIAL|BLOCKED)', text)
|
||||||
|
assert match is not None, path
|
||||||
|
statuses[path.name] = match.group(1)
|
||||||
|
assert len(statuses) == 6, statuses
|
||||||
|
assert set(statuses.values()) == {'PASS'}, statuses
|
||||||
|
assert statuses['rel.1.md'] == 'PASS'
|
||||||
|
|
||||||
|
roadmap = Path('ROADMAP.md').read_text(encoding='utf-8')
|
||||||
|
assert '- `(x) 0.1.3`' in roadmap
|
||||||
|
for release in range(4, 8):
|
||||||
|
assert f'- `( ) 0.1.{release}`' in roadmap, release
|
||||||
|
assert '0.1.8' not in roadmap
|
||||||
|
|
||||||
|
prompt = Path('prompts/010-V0_1_4_START_PROMPT.md').read_text(encoding='utf-8')
|
||||||
|
for phrase in (
|
||||||
|
'Version cible : `0.1.4`',
|
||||||
|
'Première tranche attendue : `0.1.4-alpha.1`',
|
||||||
|
'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER',
|
||||||
|
'conditions de sortie du report historique',
|
||||||
|
'skeleton Tauri',
|
||||||
|
'adoption Games `0.1.5`',
|
||||||
|
'adoption KSP `0.1.6`',
|
||||||
|
):
|
||||||
|
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 (
|
||||||
|
'7` hosts',
|
||||||
|
'conditions historiques de sortie SATISFIED',
|
||||||
|
'Classification initiale `alpha.1`',
|
||||||
|
'### `ADOPT`',
|
||||||
|
'### `KEEP-LOCAL`',
|
||||||
|
'### `OVERRIDE`',
|
||||||
|
'### `DEFER`',
|
||||||
|
'ADOPT FOR MATERIALIZATION',
|
||||||
|
'`alpha.2` — réconciliation normative Tauri',
|
||||||
|
'`alpha.3` — skeleton Tauri contrôlé',
|
||||||
|
'`beta.1` — réconciliation et décision d\'artefacts',
|
||||||
|
'`rc.1` — freeze et handoff',
|
||||||
|
'`rel.1` — stable',
|
||||||
|
'0.1.5',
|
||||||
|
'0.1.6',
|
||||||
|
):
|
||||||
|
assert phrase in plan, phrase
|
||||||
|
|
||||||
|
assert Path('docs/rules/710-TAURI.md').read_text(encoding='utf-8').startswith(
|
||||||
|
'<!-- file: docs/rules/710-TAURI.md -->\n<!-- version: 6 -->'
|
||||||
|
)
|
||||||
|
assert Path('docs/studies/002-TAURI_SKELETON_DECISION.md').read_text(encoding='utf-8').startswith(
|
||||||
|
'<!-- file: docs/studies/002-TAURI_SKELETON_DECISION.md -->\n<!-- version: 2 -->'
|
||||||
|
)
|
||||||
|
assert Path('docs/skeletons/003-WEB_FRONTEND.md').exists()
|
||||||
|
assert not Path('docs/skeletons/004-TAURI.md').exists()
|
||||||
|
assert not Path('history/0.1.4/alpha.1.md').exists()
|
||||||
|
|
||||||
|
print('0.1.4 alpha.1 structural audit: clean (96 prior pairs, 7 current Tauri hosts classified, no premature skeleton/adoption)')
|
||||||
|
PY
|
||||||
|
|
||||||
|
git diff --check
|
||||||
|
git add VERSION README.md docs/000-README.md \
|
||||||
|
docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md \
|
||||||
|
deltas/0.1.4/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.4/alpha.1.md
|
||||||
|
M docs/000-README.md
|
||||||
|
A docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
|
||||||
|
```
|
||||||
|
|
||||||
|
## Revue opérateur attendue
|
||||||
|
|
||||||
|
La revue doit confirmer que `alpha.1` ne modifie ni `710-TAURI.md` ni l'étude historique avant validation du cadrage ; que les sept hosts réellement fournis sont utilisés comme preuves et non comme modèles à recopier ; que Bootstrap/Sass/TS-RS/WASM/plugins/windows/ports/identifiers restent correctement classifiés ; et que ni Games ni KSP ne sont adoptés pendant `0.1.4`.
|
||||||
|
|
||||||
|
Elle doit aussi confirmer que le candidat de skeleton est **autorisé à être matérialisé plus tard**, et non déjà créé par cette tranche.
|
||||||
|
|
||||||
|
## Transition
|
||||||
|
|
||||||
|
### PASS
|
||||||
|
|
||||||
|
Produire `history/0.1.4/alpha.1.md` à partir des résultats réellement observés. Dans la même réponse, préparer séparément le delta `0.1.4-alpha.2` consacré à la réconciliation normative de `710-TAURI.md` et de `002-TAURI_SKELETON_DECISION.md`, sans créer encore `004-TAURI.md`.
|
||||||
|
|
||||||
|
Après remise du history, fournir automatiquement le bloc opérateur exact pour appliquer le history, committer/pusher `0.1.4-alpha.1`, puis seulement appliquer le delta suivant conformément à `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`.
|
||||||
|
|
||||||
|
### FAIL
|
||||||
|
|
||||||
|
Consigner le résultat réel dans le history, puis ouvrir `0.1.4-alpha.1.fix.1` ou un REPLAN selon la cause. Aucun changement prévu pour `alpha.2` ne doit être absorbé silencieusement dans le fix.
|
||||||
@@ -1,5 +1,5 @@
|
|||||||
<!-- file: docs/000-README.md -->
|
<!-- file: docs/000-README.md -->
|
||||||
<!-- version: 40 -->
|
<!-- version: 41 -->
|
||||||
|
|
||||||
# Documentation PGR
|
# Documentation PGR
|
||||||
|
|
||||||
@@ -20,6 +20,14 @@ 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.
|
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.4
|
||||||
|
|
||||||
|
- [`plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md`](plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md) — plan actif du réexamen Tauri : audit des hosts Games/KSP actuels, classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, décision contrôlée sur le skeleton et séquencement jusqu'à la stable.
|
||||||
|
- [`rules/710-TAURI.md`](rules/710-TAURI.md) — owner Tauri 2 à réconcilier avec le corpus courant et la documentation officielle avant toute modification normative.
|
||||||
|
- [`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.
|
||||||
|
- [`studies/002-TAURI_SKELETON_DECISION.md`](studies/002-TAURI_SKELETON_DECISION.md) — décision historique `DEFER`, conditions de sortie et préparation `0.1.1-beta.1` réexaminées par la présente release.
|
||||||
|
- [`../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
|
## 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 historique de la stable `0.1.3`, de l'audit Games à la stabilisation du profil Android générique et au handoff Tauri `0.1.4`.
|
- [`plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`](plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md) — plan historique de la stable `0.1.3`, de l'audit Games à la stabilisation du profil Android générique et au handoff Tauri `0.1.4`.
|
||||||
|
|||||||
318
docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
Normal file
318
docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
Normal file
@@ -0,0 +1,318 @@
|
|||||||
|
<!-- file: docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md -->
|
||||||
|
<!-- version: 1 -->
|
||||||
|
|
||||||
|
# Plan 0.1.4 — réexamen Tauri et skeleton contrôlé
|
||||||
|
|
||||||
|
## Statut et sources
|
||||||
|
|
||||||
|
Plan actif de `0.1.4`, créé pendant `0.1.4-alpha.1` conformément à `prompts/010-V0_1_4_START_PROMPT.md`, après audit indépendant de la stable taggée `v0.1.3`, de son rapport post-tag `PASS` et des corpus Games/KSP réellement fournis.
|
||||||
|
|
||||||
|
Sources autoritaires de reprise PGR réellement fournies :
|
||||||
|
|
||||||
|
```text
|
||||||
|
pgr-v0.1.3(1).zip f3a7dffd5fe0fd3542e6b5207fda0b94bca2bd05bd5a54542d0a08d635a5d6ee
|
||||||
|
pgr-0.1.3-publish.001-report.md 5405a1d6c216a5882c4638c07d573d50d440ce9e4e892d97f425e99054245544
|
||||||
|
```
|
||||||
|
|
||||||
|
Le nom local de l'archive PGR comporte `(1)`, mais son SHA-256 correspond exactement à l'archive canonique `pgr-v0.1.3.zip` enregistrée par le rapport `publish.001`. Le rapport est `PASS`, porte sur cette même archive et confirme le commit stable `fe80dbbb737390a7ea99df27d979bd59ccfb86e3`. Le tag annoté `v0.1.3` possède l'objet tag `9b3667f622ab6ef86c1301f8cfa2301b561a0124` et se déréférence vers ce commit stable.
|
||||||
|
|
||||||
|
Corpus externes réellement fournis pour instruire Tauri :
|
||||||
|
|
||||||
|
```text
|
||||||
|
games-v0.3.6(3).zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
|
||||||
|
khadhroony-solana-project-v0.3.19(1).zip 64a3813620925fa4f8914cdf74113399cfdd78ad51d60bbeff9bafbddcf4b253
|
||||||
|
```
|
||||||
|
|
||||||
|
Le SHA-256 Games correspond exactement à la baseline canonique `games-v0.3.6.zip` déjà enregistrée par le prompt de reprise. KSP `0.3.19` est plus récent que la référence historique `0.3.17` citée par le prompt ; il est donc le corpus KSP courant de cette session. L'archive KSP fournie ne possède pas de rapport post-tag associé dans les sources de cette reprise : elle est utilisée comme corpus autoritaire fourni, sans lui attribuer de preuve Git absente.
|
||||||
|
|
||||||
|
## Audit de la stable `v0.1.3`
|
||||||
|
|
||||||
|
### Intégrité et publication
|
||||||
|
|
||||||
|
L'archive PGR contient `332` entrées sous une racine unique `pgr/`, soit `290` fichiers et `42` 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.
|
||||||
|
|
||||||
|
`VERSION` vaut exactement `0.1.3`. Le rapport post-tag confirme la cohérence de la stable, la présence du prompt `010`, la clôture de `0.1.3` par `rel.1` et le maintien de `0.1.4` à `0.1.7` sans réservation supplémentaire.
|
||||||
|
|
||||||
|
### Gates rejouées
|
||||||
|
|
||||||
|
La suite Python et les audits documentaires ont été rejoués directement depuis l'archive extraite :
|
||||||
|
|
||||||
|
```text
|
||||||
|
48 / 48 tests PASS
|
||||||
|
Markdown header audit: clean (264 file(s))
|
||||||
|
Markdown table audit: clean (11 table(s), 264 file(s))
|
||||||
|
Markdown link audit: clean (337 local link(s), 264 file(s))
|
||||||
|
```
|
||||||
|
|
||||||
|
La stable fournie est donc une base saine pour ouvrir `0.1.4-alpha.1`.
|
||||||
|
|
||||||
|
## Préconditions PGR du réexamen
|
||||||
|
|
||||||
|
Le report historique de `docs/studies/002-TAURI_SKELETON_DECISION.md` demandait cinq familles de responsabilités avant tout nouveau jugement sur un skeleton Tauri :
|
||||||
|
|
||||||
|
1. TypeScript et conventions Web contrôlées ;
|
||||||
|
2. Vite et ownership des commandes, du dev server et des outputs ;
|
||||||
|
3. Sass/CSS et statut des artefacts générés ;
|
||||||
|
4. validation frontend indépendante de la validation Tauri ;
|
||||||
|
5. framework CSS classé comme décision de skeleton/projet et non comme règle Tauri.
|
||||||
|
|
||||||
|
La préparation effectuée en `0.1.1-beta.1` avait déjà constaté ces cinq conditions couvertes. La relecture de la stable `0.1.3` confirme qu'elles le restent au travers des owners `530/540/550/560`, de `005-WEB_FRONTEND_VALIDATION.md` et de `003-WEB_FRONTEND.md`.
|
||||||
|
|
||||||
|
Conclusion `alpha.1` :
|
||||||
|
|
||||||
|
```text
|
||||||
|
conditions historiques de sortie SATISFIED
|
||||||
|
réexamen du candidat autorisé
|
||||||
|
création automatique interdite
|
||||||
|
ancien motif Web du DEFER levé
|
||||||
|
jugement sur le skeleton à instruire par le corpus courant
|
||||||
|
```
|
||||||
|
|
||||||
|
Le `DEFER` historique n'est donc pas reconduit par inertie. Son motif bloquant Web est levé, mais cette levée ne suffit pas à elle seule à créer le skeleton.
|
||||||
|
|
||||||
|
## Audit du corpus Tauri courant
|
||||||
|
|
||||||
|
### Intégrité des archives
|
||||||
|
|
||||||
|
Les trois archives PGR, Games et KSP sont CRC-propres et ne contiennent aucun lien symbolique.
|
||||||
|
|
||||||
|
Games `0.3.6` contient `652` entrées sous `games/`, soit `502` fichiers et `150` répertoires. Ses audits statiques rejoués sont propres :
|
||||||
|
|
||||||
|
```text
|
||||||
|
General Rust rule audit: clean
|
||||||
|
Rust export completeness audit: 0 candidate(s)
|
||||||
|
games.sasedev workspace audit: clean
|
||||||
|
Markdown table audit: clean (6 table(s), 317 file(s))
|
||||||
|
Distribution layout audit: clean (55 required path(s), 11 forbidden path(s) absent)
|
||||||
|
```
|
||||||
|
|
||||||
|
KSP `0.3.19` contient `2369` entrées sous `khadhroony-solana-project/`, soit `2146` fichiers et `223` répertoires. Ses audits statiques rejoués sont propres :
|
||||||
|
|
||||||
|
```text
|
||||||
|
General Rust rule audit: clean
|
||||||
|
Rust export completeness audit: 0 candidate(s)
|
||||||
|
KSP workspace Rust rule audit: clean
|
||||||
|
Markdown table audit: clean (353 table(s), 1029 file(s))
|
||||||
|
```
|
||||||
|
|
||||||
|
Ces audits attestent la cohérence structurelle des corpus fournis. Ils ne constituent pas une adoption PGR de Games ou KSP.
|
||||||
|
|
||||||
|
### Inventaire des hosts actuels
|
||||||
|
|
||||||
|
Games `0.3.6` possède désormais un seul host Tauri courant :
|
||||||
|
|
||||||
|
```text
|
||||||
|
crates/apps/game-snake-poc-tauri
|
||||||
|
```
|
||||||
|
|
||||||
|
KSP `0.3.19` possède six hosts Tauri courants :
|
||||||
|
|
||||||
|
```text
|
||||||
|
crates/ksp-app-backfill-desk
|
||||||
|
crates/ksp-app-config-desk
|
||||||
|
crates/ksp-app-raw-transaction-ingest-desk
|
||||||
|
crates/ksp-app-solprices-desk
|
||||||
|
crates/ksp-app-store-desk
|
||||||
|
crates/ksp-app-wallet-desk
|
||||||
|
```
|
||||||
|
|
||||||
|
Le corpus courant contient donc `7` hosts, contre `8` dans l'étude historique `0.0.5` : Games est passé de deux hosts observés à un seul. Le réexamen ne doit donc pas recopier mécaniquement l'inventaire historique.
|
||||||
|
|
||||||
|
### Convergences structurelles observées
|
||||||
|
|
||||||
|
Les sept hosts actuels convergent sur une ossature directe à la racine de la crate :
|
||||||
|
|
||||||
|
```text
|
||||||
|
Cargo.toml
|
||||||
|
build.rs
|
||||||
|
package.json
|
||||||
|
tsconfig.json
|
||||||
|
tauri.conf.json
|
||||||
|
vite.config.ts
|
||||||
|
capabilities/
|
||||||
|
src/lib.rs
|
||||||
|
src/main.rs
|
||||||
|
src/tauri.rs
|
||||||
|
frontend/
|
||||||
|
```
|
||||||
|
|
||||||
|
Aucun de ces sept hosts n'utilise `src-tauri/`. Tous sont des crates Cargo mixtes `lib + bin`, utilisent un frontend privé TypeScript/Vite et raccordent le dev/build frontend au host Tauri.
|
||||||
|
|
||||||
|
Cette convergence justifie une convention organisationnelle PGR pour les nouveaux projets contrôlés. Elle ne démontre pas que `src-tauri/` serait invalide ou non supporté par Tauri, ni que toute application Tauri existante devrait migrer.
|
||||||
|
|
||||||
|
### Divergences significatives
|
||||||
|
|
||||||
|
KSP exerce communément Bootstrap, Sass et TS-RS dans ses desks actuels. Games ne les exerce pas comme bloc équivalent dans son host courant et possède en plus une chaîne WASM spécifique au jeu.
|
||||||
|
|
||||||
|
Les corpus divergent également sur les plugins, fenêtres, identifiers, ports de dev server, ressources/bundles et détails de capabilities. Le Store Desk KSP possède notamment un contrat de commandes/permissions plus riche que les autres hosts.
|
||||||
|
|
||||||
|
Ces divergences empêchent de transformer le bloc historique `frontend/ + Vite + TypeScript + Sass + Bootstrap + TS-RS` en baseline Tauri universelle.
|
||||||
|
|
||||||
|
## Vérification officielle Tauri 2 courante
|
||||||
|
|
||||||
|
La documentation Tauri 2 officielle a été réexaminée pendant `alpha.1` sur les points susceptibles d'avoir évolué.
|
||||||
|
|
||||||
|
Constats retenus :
|
||||||
|
|
||||||
|
- la structure documentée par Tauri présente `src-tauri/` comme layout typique/scaffold, tandis que la configuration Tauri et le projet Rust restent les éléments fonctionnels déterminants ; PGR peut donc conserver une convention différente pour ses projets contrôlés sans déclarer le layout standard invalide ;
|
||||||
|
- les capabilities et permissions sont une frontière de sécurité active ; l'enregistrement d'une commande native et l'autorisation de son appel depuis le frontend ne doivent pas être confondus ;
|
||||||
|
- lorsque la sélection explicite des capabilities n'est pas configurée, les fichiers de capability du répertoire de capabilities peuvent être activés automatiquement selon la configuration Tauri courante ; un skeleton contrôlé doit donc rendre cette surface visible et revue ;
|
||||||
|
- le CLI Tauri supporte plusieurs launchers/package managers et possède toujours des commandes de commodité, dont l'ajout de plugins et les workflows mobiles ; PGR n'a aucune raison d'imposer npm ni `cargo tauri add` ;
|
||||||
|
- les templates mobiles Tauri évoluent avec l'écosystème plateforme ; les versions Gradle/Kotlin/SDK observées dans une release Tauri ne doivent pas devenir des constantes PGR universelles.
|
||||||
|
|
||||||
|
Références officielles vérifiées le `2026-09-29` :
|
||||||
|
|
||||||
|
- <https://v2.tauri.app/start/project-structure/>
|
||||||
|
- <https://v2.tauri.app/security/capabilities/>
|
||||||
|
- <https://v2.tauri.app/security/permissions/>
|
||||||
|
- <https://v2.tauri.app/reference/cli/>
|
||||||
|
- <https://v2.tauri.app/blog/tauri-2-12-0/>
|
||||||
|
|
||||||
|
## Classification initiale `alpha.1`
|
||||||
|
|
||||||
|
### `ADOPT`
|
||||||
|
|
||||||
|
Sont retenus pour le candidat organisationnel PGR :
|
||||||
|
|
||||||
|
- composition explicite avec `001-PROJECT_GOVERNANCE_FOUNDATION`, `002-RUST_CARGO_WORKSPACE`, `003-WEB_FRONTEND` et `710-TAURI` au lieu de dupliquer leurs règles ;
|
||||||
|
- host Cargo direct `lib + bin` sans couche `src-tauri/` ajoutée uniquement pour reproduire un scaffold, pour les nouveaux projets que PGR contrôle entièrement ;
|
||||||
|
- `build.rs`, `tauri.conf.json`, `capabilities/` et `src/tauri.rs` comme surface Tauri visible de cette convention ;
|
||||||
|
- `frontend/` comme layout recommandé du skeleton contrôlé, sans en faire une obligation Tauri universelle ;
|
||||||
|
- TypeScript + Vite comme baseline Web recommandée du skeleton lorsque le projet ne possède pas déjà un autre choix frontend motivé ;
|
||||||
|
- validation frontend indépendante avant preuve d'intégration Tauri lorsque la modification touche les deux surfaces ;
|
||||||
|
- revue explicite des capabilities, permissions, commandes natives et plugins comme surface de sécurité ;
|
||||||
|
- ajout manuel/revu des plugins comme voie canonique du skeleton contrôlé, tout en autorisant les commandes de commodité lorsqu'elles apportent une valeur réelle et que leurs modifications sont relues ;
|
||||||
|
- WASM séparé du host Tauri par défaut ;
|
||||||
|
- composition des owners Android/iOS applicables pour les cibles mobiles au lieu de transférer ces responsabilités à `710`.
|
||||||
|
|
||||||
|
### `KEEP-LOCAL`
|
||||||
|
|
||||||
|
Restent des décisions de projet ou de produit :
|
||||||
|
|
||||||
|
- ports `devUrl`, identifiers, titres et dimensions de fenêtres ;
|
||||||
|
- CSP, icônes, bundle targets, resources et chemins spécifiques imposés par un produit ;
|
||||||
|
- Bootstrap et Sass lorsque réellement utiles ;
|
||||||
|
- TS-RS uniquement lorsqu'une frontière DTO Rust/TypeScript possédée par le host existe, conformément au profil strict ;
|
||||||
|
- plugins concrets tels que tracing, filesystem ou autres ;
|
||||||
|
- chaîne WASM Games et ses scripts ;
|
||||||
|
- fenêtres auxiliaires, splash screens et ACL spécifiques comme celles exercées par certains desks KSP ;
|
||||||
|
- versions concrètes Tauri, Vite, TypeScript, Bootstrap, Sass, plugins et toolchains plateforme.
|
||||||
|
|
||||||
|
### `OVERRIDE`
|
||||||
|
|
||||||
|
Le candidat historique est corrigé sur les points suivants :
|
||||||
|
|
||||||
|
- le bloc `frontend/ + Vite + TypeScript + Sass + Bootstrap + TS-RS` n'est plus traité comme une seule baseline indivisible ; seuls les éléments justifiés par le skeleton et les owners applicables sont sélectionnés ;
|
||||||
|
- l'absence de champ `version` dans des `tauri.conf.json` observés n'annule pas la politique PGR `CANONICAL / MIRROR-EXACT / MIRROR-STABLE` ; la stratégie de version reste explicite ;
|
||||||
|
- une capability présente dans le dépôt n'est pas considérée comme suffisamment sûre par sa seule existence : sélection, fenêtres/webviews, permissions et commandes doivent être revues comme un contrat de sécurité ;
|
||||||
|
- l'absence de `src-tauri/` devient une convention organisationnelle des nouvelles baselines PGR contrôlées, pas une règle prétendant que Tauri exige cette absence.
|
||||||
|
|
||||||
|
### `DEFER`
|
||||||
|
|
||||||
|
Restent différés faute de besoin démontré :
|
||||||
|
|
||||||
|
- template technique Tauri copiable contenant `tauri.conf.json`, `build.rs` ou des capabilities génériques ;
|
||||||
|
- contrat de validation Tauri séparé de `400-VALIDATION.md`, `005-WEB_FRONTEND_VALIDATION.md` et `710-TAURI.md` ;
|
||||||
|
- framework CSS universel ;
|
||||||
|
- catalogue de plugins, fenêtres ou permissions par défaut ;
|
||||||
|
- owner serveur Rust, deployment/operations ou iOS créé par proximité ;
|
||||||
|
- valeurs Android/Gradle/Kotlin/SDK/ABI dérivées des templates Tauri courants ;
|
||||||
|
- migration ou adoption de Games/KSP, réservées respectivement à `0.1.5` et `0.1.6`.
|
||||||
|
|
||||||
|
## Décision de cadrage `alpha.1`
|
||||||
|
|
||||||
|
Le corpus courant démontre une convergence suffisante pour retenir **un skeleton Tauri organisationnel comme candidat à matérialiser pendant `0.1.4`**, sous réserve de la réconciliation normative préalable de `710-TAURI.md` et de l'étude historique.
|
||||||
|
|
||||||
|
La décision est donc :
|
||||||
|
|
||||||
|
```text
|
||||||
|
ancien DEFER pour absence d'owners Web LIFT
|
||||||
|
candidat de skeleton organisationnel ADOPT FOR MATERIALIZATION
|
||||||
|
création dans alpha.1 NO
|
||||||
|
normalisation des choix locaux NO
|
||||||
|
```
|
||||||
|
|
||||||
|
`alpha.1` ne crée volontairement pas `docs/skeletons/004-TAURI.md`. La tranche suivante doit d'abord consolider le contrat Tauri actuel, notamment la frontière commandes/capabilities/permissions et la formulation des conventions organisationnelles face aux possibilités officiellement supportées.
|
||||||
|
|
||||||
|
## Trajectoire de `0.1.4`
|
||||||
|
|
||||||
|
### `alpha.1` — intake, audit et décision de cadrage
|
||||||
|
|
||||||
|
Objectifs :
|
||||||
|
|
||||||
|
- auditer la stable `v0.1.3` et le rapport post-tag `PASS` ;
|
||||||
|
- auditer les corpus Games/KSP fournis et inventorier leurs hosts Tauri actuels ;
|
||||||
|
- rejouer les audits statiques disponibles ;
|
||||||
|
- vérifier les préconditions historiques du report ;
|
||||||
|
- confronter le corpus à la documentation Tauri 2 courante ;
|
||||||
|
- classifier `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
|
||||||
|
- décider si le skeleton reste un candidat justifié, sans le créer.
|
||||||
|
|
||||||
|
Sortie attendue : présent plan et cadrage validé par la gate opérateur.
|
||||||
|
|
||||||
|
### `alpha.2` — réconciliation normative Tauri
|
||||||
|
|
||||||
|
Réexaminer `docs/rules/710-TAURI.md` et `docs/studies/002-TAURI_SKELETON_DECISION.md` à partir du cadrage validé.
|
||||||
|
|
||||||
|
La tranche doit notamment :
|
||||||
|
|
||||||
|
- distinguer clairement commande enregistrée, permission et capability ;
|
||||||
|
- rendre explicite la politique de sélection/revue des capability files ;
|
||||||
|
- conserver `src-tauri/` comme possibilité supportée et l'absence de `src-tauri/` comme convention organisationnelle PGR contrôlée ;
|
||||||
|
- maintenir TypeScript/Vite/frontend/Sass/Bootstrap/TS-RS dans leurs owners appropriés ;
|
||||||
|
- conserver une validation proportionnée plutôt qu'un `tauri build` systématique ;
|
||||||
|
- ne créer encore aucun template ou owner par symétrie.
|
||||||
|
|
||||||
|
### `alpha.3` — skeleton Tauri contrôlé
|
||||||
|
|
||||||
|
Si `alpha.2` confirme l'absence de défaut bloquant, créer `docs/skeletons/004-TAURI.md` comme specification organisationnelle composable.
|
||||||
|
|
||||||
|
Le skeleton devra :
|
||||||
|
|
||||||
|
- composer la fondation, Rust/Cargo, Web et Tauri sans recopier les règles ;
|
||||||
|
- séparer décisions obligatoires, recommandations de baseline et options ;
|
||||||
|
- rendre visibles versions, package manager, frontend, capabilities, plugins, fenêtres/bundle et cibles plateforme ;
|
||||||
|
- définir un ordre d'initialisation et une gate initiale proportionnée ;
|
||||||
|
- ne créer de template technique supplémentaire que si un besoin non couvert est démontré pendant l'instanciation de la specification.
|
||||||
|
|
||||||
|
### `beta.1` — réconciliation et décision d'artefacts
|
||||||
|
|
||||||
|
Rejouer le plan contre l'ensemble des artefacts `0.1.4`, rechercher doublons et ownership caché, puis décider explicitement :
|
||||||
|
|
||||||
|
- si un template technique Tauri apporte une valeur nette ;
|
||||||
|
- si un contrat de validation Tauri séparé est nécessaire ;
|
||||||
|
- si la documentation Tauri et les skeletons existants suffisent ;
|
||||||
|
- si un dry-run local de la specification est nécessaire et réalisable avec les toolchains présentes.
|
||||||
|
|
||||||
|
Par défaut, l'absence de lacune démontrée signifie **ne pas créer** d'artefact supplémentaire.
|
||||||
|
|
||||||
|
### `rc.1` — freeze et handoff
|
||||||
|
|
||||||
|
Effectuer la gate RC, geler le scope de `0.1.4`, préparer le `CHANGELOG.md` candidate et le prompt ouvrant `0.1.5` consacré à l'adoption Games. Une revue d'horizon est effectuée avant toute réservation au-delà de `0.1.7`.
|
||||||
|
|
||||||
|
### `rel.1` — stable
|
||||||
|
|
||||||
|
Promouvoir `0.1.4`, finaliser `README.md`, `ROADMAP.md`, `CHANGELOG.md` et les index concernés, puis suivre le workflow commit stable, tag annoté et rapport post-tag externe.
|
||||||
|
|
||||||
|
## Frontières de release
|
||||||
|
|
||||||
|
`0.1.4` ne migre ni Games ni KSP et ne modifie pas leurs archives. Les observations de ces corpus servent uniquement à éprouver les abstractions PGR.
|
||||||
|
|
||||||
|
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`. Le `CHANGELOG.md` et le `ROADMAP.md` ne sont pas réécrits à l'ouverture `alpha.1` ; ils sont mis à jour dans les phases de fermeture lorsqu'ils décrivent l'état effectivement atteint et la trajectoire confirmée.
|
||||||
|
|
||||||
|
## Gate de sortie du plan
|
||||||
|
|
||||||
|
Le passage de `alpha.1` à `alpha.2` exige :
|
||||||
|
|
||||||
|
- intégrité de la baseline PGR et correspondance avec `publish.001 PASS` confirmées ;
|
||||||
|
- corpus Games/KSP identifiés par leurs SHA-256 réels ;
|
||||||
|
- inventaire des sept hosts courants vérifié ;
|
||||||
|
- conditions historiques de sortie explicitement confirmées couvertes ;
|
||||||
|
- classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` relue ;
|
||||||
|
- aucune matérialisation prématurée de `004-TAURI.md` ;
|
||||||
|
- aucune adoption Games/KSP commencée ;
|
||||||
|
- audits PGR de la tranche propres.
|
||||||
|
|
||||||
|
Un `FAIL` sur une de ces propriétés ouvre un `alpha.1.fix.N` ou un REPLAN ; il ne doit pas être absorbé silencieusement par `alpha.2`.
|
||||||
86
history/0.1.4/alpha.1.md
Normal file
86
history/0.1.4/alpha.1.md
Normal file
@@ -0,0 +1,86 @@
|
|||||||
|
<!-- file: history/0.1.4/alpha.1.md -->
|
||||||
|
<!-- version: 1 -->
|
||||||
|
|
||||||
|
# History 0.1.4-alpha.1 — intake, audit et cadrage Tauri
|
||||||
|
|
||||||
|
## Statut
|
||||||
|
|
||||||
|
PASS
|
||||||
|
|
||||||
|
La gate opérateur de `0.1.4-alpha.1` exécutée le `2026-09-29` est propre. L'intake de la stable `v0.1.3`, des corpus Games/KSP fournis et du candidat de skeleton Tauri est validé sans fix ; `alpha.2` peut réconcilier le profil Tauri et l'étude historique avant toute matérialisation de `004-TAURI.md`.
|
||||||
|
|
||||||
|
## Contrôles d'identité
|
||||||
|
|
||||||
|
Les contrôles opérateur ont confirmé :
|
||||||
|
|
||||||
|
```text
|
||||||
|
VERSION 0.1.4-alpha.1
|
||||||
|
docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md présent
|
||||||
|
deltas/0.1.4/alpha.1.md présent
|
||||||
|
history/0.1.4/alpha.1.md absent pendant la gate
|
||||||
|
docs/skeletons/004-TAURI.md absent pendant la gate
|
||||||
|
```
|
||||||
|
|
||||||
|
## Tests Python
|
||||||
|
|
||||||
|
La suite complète a affiché :
|
||||||
|
|
||||||
|
```text
|
||||||
|
Ran 48 tests in 0.744s
|
||||||
|
|
||||||
|
OK
|
||||||
|
```
|
||||||
|
|
||||||
|
Soit `48/48` tests `PASS`.
|
||||||
|
|
||||||
|
## Audits Markdown
|
||||||
|
|
||||||
|
Les trois audits documentaires sont propres :
|
||||||
|
|
||||||
|
```text
|
||||||
|
Markdown header audit: clean (266 file(s))
|
||||||
|
Markdown table audit: clean (11 table(s), 266 file(s))
|
||||||
|
Markdown link audit: clean (343 local link(s), 266 file(s))
|
||||||
|
```
|
||||||
|
|
||||||
|
## Audit structurel `alpha.1`
|
||||||
|
|
||||||
|
Le contrôle structurel de la tranche a affiché :
|
||||||
|
|
||||||
|
```text
|
||||||
|
0.1.4 alpha.1 structural audit: clean (96 prior pairs, 7 current Tauri hosts classified, no premature skeleton/adoption)
|
||||||
|
```
|
||||||
|
|
||||||
|
Il a notamment confirmé :
|
||||||
|
|
||||||
|
- les `96` couples delta/history antérieurs attendus, avec les six histories `0.1.3` tous `PASS` et `rel.1` validé ;
|
||||||
|
- `0.1.3` terminé, `0.1.4` à `0.1.7` toujours engagés et aucune réservation `0.1.8` ;
|
||||||
|
- le prompt `010` conforme au scope `0.1.4`, à la classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` et aux frontières d'adoption Games/KSP ;
|
||||||
|
- le plan `010` fondé sur les `7` hosts Tauri réellement observés dans Games `0.3.6` et KSP `0.3.19` ;
|
||||||
|
- les cinq conditions historiques de sortie du report classées `SATISFIED` ;
|
||||||
|
- `710-TAURI.md` encore en révision interne `6` et l'étude `002-TAURI_SKELETON_DECISION.md` encore en révision `2` pendant la tranche d'intake ;
|
||||||
|
- l'absence de `docs/skeletons/004-TAURI.md` et du history `alpha.1` anticipé pendant la gate.
|
||||||
|
|
||||||
|
## 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 README.md
|
||||||
|
M VERSION
|
||||||
|
A deltas/0.1.4/alpha.1.md
|
||||||
|
M docs/000-README.md
|
||||||
|
A docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
|
||||||
|
```
|
||||||
|
|
||||||
|
Aucun fichier normatif Tauri ni skeleton Tauri n'a été modifié ou créé prématurément dans `alpha.1`.
|
||||||
|
|
||||||
|
## Décision
|
||||||
|
|
||||||
|
`0.1.4-alpha.1` est validée `PASS`.
|
||||||
|
|
||||||
|
L'ancien motif Web du `DEFER` historique est levé et le candidat de skeleton organisationnel est conservé pour matérialisation, mais seulement après la réconciliation normative de `alpha.2`.
|
||||||
|
|
||||||
|
La tranche suivante reste `0.1.4-alpha.2`, bornée à `docs/rules/710-TAURI.md`, `docs/studies/002-TAURI_SKELETON_DECISION.md`, au plan actif et à leur indexation. Elle doit clarifier la frontière commande / permission / capability, la politique de sélection des capabilities, la convention de layout contrôlé et la composition avec les owners Web existants, sans créer encore `docs/skeletons/004-TAURI.md`, template Tauri ou contrat de validation Tauri séparé.
|
||||||
Reference in New Issue
Block a user