0.0.5-alpha.6.fix.3
This commit is contained in:
140
deltas/0.0.5/alpha.6.fix.3.md
Normal file
140
deltas/0.0.5/alpha.6.fix.3.md
Normal file
@@ -0,0 +1,140 @@
|
||||
<!-- file: deltas/0.0.5/alpha.6.fix.3.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.0.5-alpha.6.fix.3 — politique de versions Tauri/frontend
|
||||
|
||||
## Baseline et version
|
||||
|
||||
Baseline attendue : commit opérateur complet de `0.0.5-alpha.6.fix.2`, réalisé après application de `history/0.0.5/alpha.6.fix.2.md` avec statut `FAIL`.
|
||||
|
||||
Version après application :
|
||||
|
||||
```text
|
||||
0.0.5-alpha.6.fix.3
|
||||
```
|
||||
|
||||
## Motif
|
||||
|
||||
La gate mécanique de `alpha.6.fix.2` est propre, mais la revue fonctionnelle identifie une convention mal généralisée : KSP et Games ont tous deux utilisé l'omission de `tauri.conf.json > version` et une `package.json > version` rarement synchronisée comme moyen de réduire le churn des prereleases. PGR ne doit pas transformer cette solution historique en obligation.
|
||||
|
||||
L'objectif réel est de conserver `VERSION` comme identité exacte de travail tout en évitant de modifier les miroirs produit qui n'ont pas besoin de suivre chaque `alpha`, `.fix`, beta ou RC.
|
||||
|
||||
## Scope
|
||||
|
||||
REPLACE :
|
||||
|
||||
```text
|
||||
VERSION
|
||||
docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
|
||||
docs/rules/200-GOVERNANCE.md
|
||||
docs/rules/710-TAURI.md
|
||||
docs/studies/001-KSP_GAMES_RECONCILIATION.md
|
||||
```
|
||||
|
||||
ADD :
|
||||
|
||||
```text
|
||||
deltas/0.0.5/alpha.6.fix.3.md
|
||||
```
|
||||
|
||||
DELETE : aucun.
|
||||
|
||||
## Décisions
|
||||
|
||||
Le fix rétablit une classification explicite des valeurs de version :
|
||||
|
||||
- `CANONICAL` pour `VERSION` ;
|
||||
- `MIRROR-EXACT` pour les miroirs techniques qui doivent suivre chaque prerelease ;
|
||||
- `MIRROR-STABLE` pour les champs qui portent seulement la cible `X.Y.Z` ;
|
||||
- catégories indépendantes pour compteurs, schémas et révisions documentaires.
|
||||
|
||||
Pour une application Tauri contrôlée appartenant au même produit, `tauri.conf.json > version` et `package.json > version`, lorsqu'ils sont conservés, SHOULD être `MIRROR-STABLE` par défaut et porter `X.Y.Z` pendant tout le développement de cette cible. Ils ne sont pas modifiés uniquement pour passer de `alpha.N` à un autre alpha/fix/beta/RC.
|
||||
|
||||
Si des bundles prerelease sont réellement distribués et doivent être identifiables séparément, le projet MAY sélectionner `MIRROR-EXACT` ou une politique de jalons de packaging documentée. L'omission d'un champ reste possible lorsqu'il est réellement inutile, mais elle n'est plus la stratégie PGR recommandée uniquement pour éviter le churn.
|
||||
|
||||
La revue obligatoire déclenchée par `.fix.3` conclut `CONTINUE` : `alpha.6` reste bornée au profil Tauri ; `alpha.7`, `alpha.8` et `alpha.9` conservent leurs scopes distincts.
|
||||
|
||||
## Hors scope
|
||||
|
||||
Ce fix ne modifie ni les règles Rust strictes prévues en `alpha.7`, ni les audits de formatage de `alpha.8`, ni le skeleton Tauri de `alpha.9`. Il ne modifie pas non plus la politique Cargo existante de `510-RUST_CARGO.md`.
|
||||
|
||||
## Validation opérateur
|
||||
|
||||
Après application du history `FAIL` de `alpha.6.fix.2`, commit/push de cette tranche, puis application du présent fix :
|
||||
|
||||
```bash
|
||||
test "$(cat VERSION)" = '0.0.5-alpha.6.fix.3'
|
||||
test -f history/0.0.5/alpha.6.fix.2.md
|
||||
test -f deltas/0.0.5/alpha.6.fix.3.md
|
||||
test ! -e history/0.0.5/alpha.6.fix.3.md
|
||||
|
||||
grep -A2 '^## Statut$' history/0.0.5/alpha.6.fix.2.md | grep -Fx 'FAIL'
|
||||
grep -Fx '<!-- version: 4 -->' docs/rules/200-GOVERNANCE.md
|
||||
grep -Fx '<!-- version: 4 -->' docs/rules/710-TAURI.md
|
||||
grep -Fx '<!-- version: 7 -->' docs/studies/001-KSP_GAMES_RECONCILIATION.md
|
||||
grep -Fx '<!-- version: 8 -->' docs/plans/005-V0_0_5_RECONCILIATION_PLAN.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
|
||||
|
||||
history = Path("history/0.0.5/alpha.6.fix.2.md").read_text(encoding="utf-8")
|
||||
assert re.search(r"## Statut\s+FAIL\s", history)
|
||||
|
||||
governance = Path("docs/rules/200-GOVERNANCE.md").read_text(encoding="utf-8")
|
||||
for phrase in (
|
||||
"MIRROR-EXACT",
|
||||
"MIRROR-STABLE",
|
||||
"Seul un `MIRROR-EXACT` est normalement modifié à chaque changement de `VERSION`.",
|
||||
"PGR MUST NOT imposer la suppression d'un champ utile uniquement pour éviter de le modifier à chaque prerelease",
|
||||
):
|
||||
assert phrase in governance, phrase
|
||||
|
||||
tauri = Path("docs/rules/710-TAURI.md").read_text(encoding="utf-8")
|
||||
for phrase in (
|
||||
"PGR MUST NOT imposer l'une de ces deux formes uniquement pour réduire le nombre de fichiers modifiés.",
|
||||
"la politique recommandée lorsque les prereleases ne sont pas distribuées comme produits installables distincts est `MIRROR-STABLE`",
|
||||
"tauri.conf.json version = X.Y.Z",
|
||||
"package.json version = X.Y.Z",
|
||||
"remplace explicitement les conventions historiques KSP/Games",
|
||||
):
|
||||
assert phrase in tauri, phrase
|
||||
|
||||
plan = Path("docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md").read_text(encoding="utf-8")
|
||||
assert "`alpha.6.fix.3` restaure la classification générale" in plan
|
||||
assert "résultat `CONTINUE`" in plan
|
||||
|
||||
print("0.0.5 alpha.6.fix.3 version policy audit: clean (canonical/exact/stable mirrors classified, Tauri/frontend churn bounded)")
|
||||
PY
|
||||
|
||||
git diff --check
|
||||
|
||||
git add VERSION \
|
||||
docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md \
|
||||
docs/rules/200-GOVERNANCE.md docs/rules/710-TAURI.md \
|
||||
docs/studies/001-KSP_GAMES_RECONCILIATION.md \
|
||||
deltas/0.0.5/alpha.6.fix.3.md
|
||||
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
La sortie Git attendue avant ajout du history est exactement :
|
||||
|
||||
```text
|
||||
M VERSION
|
||||
A deltas/0.0.5/alpha.6.fix.3.md
|
||||
M docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
|
||||
M docs/rules/200-GOVERNANCE.md
|
||||
M docs/rules/710-TAURI.md
|
||||
M docs/studies/001-KSP_GAMES_RECONCILIATION.md
|
||||
```
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md -->
|
||||
<!-- version: 7 -->
|
||||
<!-- version: 8 -->
|
||||
|
||||
# Plan 0.0.5 — réconciliation réelle avec KSP et sasedev-games
|
||||
|
||||
@@ -104,6 +104,10 @@ La politique `gen/` n'est pas généralisée : les sorties purement reproductibl
|
||||
|
||||
La gate `alpha.6.fix.1` révèle un second défaut de quoting Python (`l'extérieur` dans une chaîne simple) et la revue opérateur demande une seconde passe sur les règles réelles KSP/Games. `alpha.6.fix.2` corrige le gate et renforce la convention des projets contrôlés avec le layout direct sans `src-tauri/`, `lib.rs`/`main.rs`/`tauri.rs`, TS-RS lorsque le frontend TypeScript partage des DTO Rust, modules de fenêtres/responsabilités et préférence pour l'intégration explicite des plugins. Les règles Rust générales et la nomenclature des crates restent volontairement dans `alpha.7/alpha.8`.
|
||||
|
||||
La gate mécanique de `alpha.6.fix.2` est propre, mais la revue fonctionnelle révèle une troisième divergence : KSP et Games avaient tous deux converti la réduction du churn de version en préférence pour l'absence de `tauri.conf.json > version` et la stagnation de `package.json`. Cette solution ne doit pas devenir une règle PGR. `alpha.6.fix.3` restaure la classification générale `CANONICAL` / `MIRROR-EXACT` / `MIRROR-STABLE` et définit pour Tauri/frontend une synchronisation de jalon `X.Y.Z` par défaut, sans bump à chaque tranche.
|
||||
|
||||
Comme `fix.3` atteint le seuil de revue obligatoire des correctifs, le plan est réexaminé : résultat `CONTINUE`. Le scope Tauri reste cohérent et borné après cette correction ; les chantiers Rust `alpha.7`/`alpha.8` et la décision de skeleton `alpha.9` restent séparés et ne sont pas absorbés par le fix.
|
||||
|
||||
### alpha.7 — profil Rust strict, chemins et nomenclature explicite
|
||||
|
||||
Réconcilier les décisions historiques avec les règles effectivement versionnées dans KSP/Games. KSP sert de référence stricte pour les `use` réservés aux traits, chemins externes publics les plus courts, réexports `self::`, alias interdits, façade crate-root et contrôle de flux explicite ; Games confirme le noyau mais montre quelles règles doivent rester sélectionnables ou adaptables.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/200-GOVERNANCE.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Governance rules
|
||||
|
||||
@@ -38,9 +38,20 @@ Lorsqu'un dépôt utilise le fichier racine `VERSION`, ce fichier :
|
||||
|
||||
Un manifeste technique MAY refléter exactement `VERSION` lorsque son propre contrat l'exige. Un autre mécanisme de versioning MAY rester indépendant lorsqu'il possède une sémantique différente, par exemple un `versionCode` Android, une révision de document ou une version de protocole.
|
||||
|
||||
PGR MUST NOT imposer une égalité globale entre tous les champs contenant un numéro de version.
|
||||
PGR MUST NOT imposer une égalité globale entre tous les champs contenant un numéro de version. Pour éviter à la fois les divergences silencieuses et le churn mécanique, chaque valeur de version durable SHOULD être classée selon son rôle réel. Les catégories réutilisables sont notamment :
|
||||
|
||||
Un champ de version qui n'est ni requis par l'écosystème ni utile au projet SHOULD être omis plutôt que maintenu comme duplication décorative.
|
||||
- `CANONICAL` — identité SemVer exacte de l'unité de release, normalement portée par `VERSION` ;
|
||||
- `MIRROR-EXACT` — miroir technique qui suit exactement `VERSION`, prereleases et fixes compris ;
|
||||
- `MIRROR-STABLE` — miroir du jalon produit `X.Y.Z` ciblé, stable pendant `X.Y.Z-alpha.*`, `beta.*`, `rc.*` et leurs fixes ;
|
||||
- `INDEPENDENT-COUNTER` — compteur technique monotone possédant sa propre sémantique ;
|
||||
- `INDEPENDENT-SCHEMA` — version de protocole, format ou schéma indépendante du produit ;
|
||||
- `DOCUMENT-REVISION` — révision interne d'un document ou artefact documentaire.
|
||||
|
||||
Seul un `MIRROR-EXACT` est normalement modifié à chaque changement de `VERSION`. Un `MIRROR-STABLE` SHOULD être fixé ou vérifié lorsque la cible `X.Y.Z` est ouverte, puis ne pas être réécrit uniquement parce qu'une tranche passe de `alpha.N` à `alpha.N+1`, à un `.fix.N`, à une beta ou à une RC. La promotion stable vérifie qu'il représente toujours la release publiée.
|
||||
|
||||
Lorsqu'une prerelease est réellement distribuée comme artefact installable distinct et que son écosystème exige une identité de package propre, le champ concerné peut devenir `MIRROR-EXACT` ou suivre des jalons explicitement définis. Cette décision appartient au plan de versioning/packaging du projet ; elle ne doit pas résulter d'une égalité globale implicite.
|
||||
|
||||
Un champ de version qui n'est ni requis par l'écosystème ni utile au projet SHOULD être omis plutôt que maintenu comme duplication décorative. Réciproquement, PGR MUST NOT imposer la suppression d'un champ utile uniquement pour éviter de le modifier à chaque prerelease : il faut d'abord lui attribuer la bonne classe de synchronisation.
|
||||
|
||||
## Schéma SemVer PGR
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/710-TAURI.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Profil Tauri 2
|
||||
|
||||
@@ -121,23 +121,28 @@ Le répertoire produit par le frontend est un artefact de build lorsqu'il est re
|
||||
|
||||
## Version produit
|
||||
|
||||
Lorsque l'application Tauri appartient au même release train que le projet, `VERSION` reste la version canonique de cette unité de release.
|
||||
Lorsque l'application Tauri appartient au même release train que le projet, `VERSION` reste la version canonique exacte de cette unité de release. Les champs de version de Tauri et du frontend ne sont toutefois pas obligés de suivre chaque prerelease ou fix : ils sont classés selon [`200-GOVERNANCE.md`](200-GOVERNANCE.md).
|
||||
|
||||
Pour Tauri 2, une configuration qui omet la propriété applicative `version` peut utiliser la version du package Cargo du host. Lorsqu'un workspace PGR hérite déjà `workspace.package.version`, cette chaîne SHOULD être préférée si elle évite une duplication sans perdre d'information :
|
||||
Tauri 2 accepte une `version` applicative explicite dans `tauri.conf.json` et l'utilise pour les métadonnées/bundles. Si ce champ est absent, Tauri peut utiliser la version du package Cargo du host. PGR MUST NOT imposer l'une de ces deux formes uniquement pour réduire le nombre de fichiers modifiés.
|
||||
|
||||
Pour un projet contrôlé qui conserve une `version` explicite dans `tauri.conf.json`, la politique recommandée lorsque les prereleases ne sont pas distribuées comme produits installables distincts est `MIRROR-STABLE` : le champ porte la cible `X.Y.Z` de la version en cours de développement, est fixé ou vérifié à l'ouverture de cette cible et reste stable pendant ses `alpha.*`, `beta.*`, `rc.*` et fixes. La promotion stable vérifie la cohérence sans provoquer de réécriture cérémonielle si la valeur est déjà correcte.
|
||||
|
||||
Si le projet distribue réellement des bundles prerelease qui doivent être identifiables séparément, `tauri.conf.json > version` MAY devenir `MIRROR-EXACT` ou suivre des jalons de packaging explicitement documentés. Le choix dépend du contrat de distribution, pas d'une préférence PGR pour l'omission du champ.
|
||||
|
||||
Pour un `package.json` frontend privé appartenant à la même application, une propriété `version` conservée SHOULD de même être classée `MIRROR-STABLE` par défaut : elle peut porter `X.Y.Z` pendant tout le développement de cette release sans suivre chaque tranche. Si le package frontend est publié ou versionné indépendamment, il possède alors sa propre unité/version et cette règle ne s'applique plus.
|
||||
|
||||
La chaîne de version d'un projet contrôlé peut donc être, par exemple :
|
||||
|
||||
```text
|
||||
VERSION
|
||||
↓
|
||||
workspace.package.version
|
||||
↓
|
||||
package Cargo du host
|
||||
↓
|
||||
version applicative Tauri
|
||||
VERSION = X.Y.Z-alpha.N.fix.M # CANONICAL
|
||||
workspace.package.version = X.Y.Z-alpha.N.fix.M # MIRROR-EXACT si le workspace l'a choisi
|
||||
tauri.conf.json version = X.Y.Z # MIRROR-STABLE
|
||||
package.json version = X.Y.Z # MIRROR-STABLE si conservée
|
||||
```
|
||||
|
||||
Si une version Tauri explicite est conservée dans la configuration, elle MUST représenter la même release ou documenter clairement pourquoi elle constitue une unité indépendante.
|
||||
Cette classification évite de réécrire `package.json` et `tauri.conf.json` à chaque delta tout en conservant des champs de version utiles et lisibles. Elle remplace explicitement les conventions historiques KSP/Games qui préféraient omettre la version Tauri comme solution générale au churn.
|
||||
|
||||
Les numéros de version propres aux plateformes, par exemple Android `versionCode`, restent possédés par le profil plateforme concerné et ne sont pas assimilés au SemVer produit.
|
||||
Les numéros propres aux plateformes, par exemple Android `versionCode`, restent possédés par le profil plateforme concerné et ne sont pas assimilés au SemVer produit.
|
||||
|
||||
## Capabilities, permissions et frontière WebView/native
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/001-KSP_GAMES_RECONCILIATION.md -->
|
||||
<!-- version: 6 -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# Étude de réconciliation PGR / KSP / sasedev-games
|
||||
|
||||
@@ -153,7 +153,7 @@ Tauri est réellement présent dans les deux corpus et n'est plus un exemple iso
|
||||
|
||||
Les différences sont tout aussi importantes que les points communs : KSP possède deux fenêtres par Desk, active le bundling et utilise des hooks npm simples ; Games utilise une fenêtre, désactive le bundling dans les POC observés et l'un de ses hooks construit d'abord un frontend WASM via un script Python. Les CSP, ports, identifiants, ressources et plugins ne sont pas uniformes.
|
||||
|
||||
Toutes les configurations observées omettent une version Tauri explicite tandis que leur package Cargo hérite de la version workspace. Cette pratique est compatible avec le mécanisme Tauri 2 qui peut utiliser la version du package Cargo lorsque `tauri.conf` n'en fournit pas ; elle donne une base commune utile pour éviter une duplication de version dans un projet à release train unique.
|
||||
Toutes les configurations observées omettent une version Tauri explicite tandis que leur package Cargo hérite de la version workspace. La relecture des règles montre que ce n'est pas un simple accident : KSP `VER-ID-015/016` et Games `VER-TAURI-001..004` ont tous deux utilisé l'omission de `tauri.conf.json > version` et la non-synchronisation systématique de `package.json` pour réduire le churn. La clarification opérateur de `alpha.6.fix.2` rejette toutefois la généralisation de cette solution : l'objectif durable est de **classifier la fréquence de synchronisation**, pas de supprimer les champs. PGR conserve donc la possibilité d'une version Tauri/frontend explicite et privilégie `MIRROR-STABLE` lorsque ces valeurs doivent seulement porter le jalon `X.Y.Z` cible.
|
||||
|
||||
Les deux corpus versionnent leurs capability files et ignorent les dépendances/sorties frontend reproductibles. Ils ignorent également `gen/`, mais ce dernier point n'est pas généralisé : les projets mobiles Tauri peuvent contenir sous leur projet généré des personnalisations de plateforme intentionnelles qui doivent être classifiées avant toute politique Git.
|
||||
|
||||
@@ -183,6 +183,21 @@ La clarification opérateur de `alpha.6.fix.1` déclenche une seconde lecture de
|
||||
|
||||
**Nomenclature des crates** : KSP encode explicitement le rôle (`ksp-<role>-lib`, `ksp-<domain>-api`, `ksp-app-<role>-<interface>`, workers/jobs), tandis que Games conserve lui aussi des noms révélant rôle et cible (`game-logging-lib`, `*-desktop`, `*-tauri`, `*-wasm`, `engine-v1-*`). PGR doit donc étudier une convention générale « préfixe projet + responsabilité + suffixe de rôle/cible » sans figer les vocabulaires propres à KSP ou Games.
|
||||
|
||||
|
||||
#### Politique de version Tauri/frontend réconciliée
|
||||
|
||||
La baseline KSP `0.3.16` illustre le défaut de l'ancienne convention : les six `tauri.conf.json` n'ont pas de champ `version`, tandis que leurs `package.json` portent des versions historiques différentes (`0.2.6`, `0.2.12-pre.9`, `0.3.7`, `0.3.8` ou `0.3.15`) sans représenter uniformément la release courante. Games `0.3.5` suit la même famille de règles. Cette situation réduit les modifications mécaniques mais affaiblit la lisibilité des manifests.
|
||||
|
||||
La décision PGR est donc :
|
||||
|
||||
- `VERSION` = `CANONICAL` exact de la tranche ;
|
||||
- version Cargo = `MIRROR-EXACT` lorsque le profil Rust du projet la synchronise ;
|
||||
- `tauri.conf.json > version` et `package.json > version`, lorsqu'ils sont conservés pour le même produit, SHOULD normalement être `MIRROR-STABLE` et porter la cible `X.Y.Z` pendant tout le développement ;
|
||||
- une distribution réelle de prereleases peut sélectionner une politique plus fine (`MIRROR-EXACT` ou jalons de packaging) ;
|
||||
- l'absence du champ reste autorisée lorsque le projet n'en tire aucune valeur, mais n'est plus la recommandation PGR destinée à éviter le churn.
|
||||
|
||||
Cette décision est cohérente avec le principe PGR historique qui distingue déjà version canonique, miroirs techniques, compteurs et versions de schéma au lieu d'exiger `tous les champs == VERSION`.
|
||||
|
||||
### Web / Vite / WASM
|
||||
|
||||
Les corpus et la clarification opérateur permettent désormais de séparer trois choses :
|
||||
|
||||
100
history/0.0.5/alpha.6.fix.3.md
Normal file
100
history/0.0.5/alpha.6.fix.3.md
Normal file
@@ -0,0 +1,100 @@
|
||||
<!-- file: history/0.0.5/alpha.6.fix.3.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.0.5-alpha.6.fix.3 — politique de versions Tauri/frontend réconciliée
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
La gate opérateur de `0.0.5-alpha.6.fix.3` exécutée le `2026-09-25` valide la correction de la politique de versions produit : `VERSION` reste l'identité exacte de la tranche, tandis que les autres valeurs sont classifiées selon leur rôle (`MIRROR-EXACT`, `MIRROR-STABLE` ou version indépendante) au lieu d'être supprimées ou synchronisées mécaniquement. Les tests, audits Markdown, contrôle structurel ciblé et contrôles Git sont propres ; le scope indexé correspond exactement au delta.
|
||||
|
||||
## Baseline et version
|
||||
|
||||
La tranche part du commit opérateur de `0.0.5-alpha.6.fix.2` :
|
||||
|
||||
```text
|
||||
b7e65d9 0.0.5-alpha.6.fix.2
|
||||
```
|
||||
|
||||
Le push vers `origin/master` a réussi avant l'application de `alpha.6.fix.3`.
|
||||
|
||||
La version contrôlée après application du correctif est :
|
||||
|
||||
```text
|
||||
0.0.5-alpha.6.fix.3
|
||||
```
|
||||
|
||||
`history/0.0.5/alpha.6.fix.2.md` est présent avec statut `FAIL`, `deltas/0.0.5/alpha.6.fix.3.md` est présent et `history/0.0.5/alpha.6.fix.3.md` était absent pendant la gate, conformément au workflow.
|
||||
|
||||
## Validation opérateur observée
|
||||
|
||||
L'opérateur a fourni les sorties du `2026-09-25` depuis `~/Projects/pgr`, à `10:35:30`–`10:37:41`.
|
||||
|
||||
Les contrôles de révision ont confirmé :
|
||||
|
||||
```text
|
||||
docs/rules/200-GOVERNANCE.md version 4
|
||||
docs/rules/710-TAURI.md version 4
|
||||
docs/studies/001-KSP_GAMES_RECONCILIATION.md version 7
|
||||
docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md version 8
|
||||
```
|
||||
|
||||
La suite Python globale a exécuté `37` tests, tous réussis :
|
||||
|
||||
```text
|
||||
Ran 37 tests in 0.487s
|
||||
|
||||
OK
|
||||
```
|
||||
|
||||
Les trois audits documentaires affichent :
|
||||
|
||||
```text
|
||||
Markdown header audit: clean (152 file(s))
|
||||
Markdown table audit: clean (7 table(s), 152 file(s))
|
||||
Markdown link audit: clean (149 local link(s), 152 file(s))
|
||||
```
|
||||
|
||||
Le contrôle structurel spécifique affiche :
|
||||
|
||||
```text
|
||||
0.0.5 alpha.6.fix.3 version policy audit: clean (canonical/exact/stable mirrors classified, Tauri/frontend churn bounded)
|
||||
```
|
||||
|
||||
Il confirme notamment que seul un `MIRROR-EXACT` suit normalement chaque changement de `VERSION`, qu'un `MIRROR-STABLE` peut rester sur la cible `X.Y.Z`, et que PGR n'impose plus la suppression d'un champ de version utile uniquement pour éviter le churn des prereleases.
|
||||
|
||||
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
|
||||
|
||||
Le scope Git observé avant ajout du présent history est exactement :
|
||||
|
||||
```text
|
||||
M VERSION
|
||||
A deltas/0.0.5/alpha.6.fix.3.md
|
||||
M docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
|
||||
M docs/rules/200-GOVERNANCE.md
|
||||
M docs/rules/710-TAURI.md
|
||||
M docs/studies/001-KSP_GAMES_RECONCILIATION.md
|
||||
```
|
||||
|
||||
La transcription du terminal intercale quelques fragments du heredoc de contrôle avec la sortie de `unittest`. Les trente-sept tests, les audits Markdown, le contrôle structurel final et le scope Git restent identifiables et ne signalent aucun échec.
|
||||
|
||||
## Résultat
|
||||
|
||||
Le troisième correctif ferme la divergence de politique de version identifiée pendant `alpha.6`. La revue obligatoire liée à `.fix.3` conserve le résultat `CONTINUE` : aucun nouveau découpage de `alpha.6` n'est nécessaire.
|
||||
|
||||
Le profil Tauri peut maintenant être considéré comme suffisamment borné pour reprendre la trajectoire normale. Les règles Rust strictes, le formatage structurel et la décision de skeleton Tauri restent volontairement séparés dans les tranches suivantes.
|
||||
|
||||
Aucun nouveau fix `alpha.6` n'est requis.
|
||||
|
||||
## Transition
|
||||
|
||||
Appliquer le présent history puis committer et pousser `0.0.5-alpha.6.fix.3`.
|
||||
|
||||
La tranche suivante est :
|
||||
|
||||
```text
|
||||
0.0.5-alpha.7
|
||||
```
|
||||
|
||||
Elle doit rester limitée au profil Rust strict, aux chemins/imports/réexports et à une nomenclature générique explicite des crates. Le formatage structurel et ses audits restent réservés à `alpha.8`; le skeleton Tauri reste réservé à `alpha.9`.
|
||||
Reference in New Issue
Block a user