0.1.4-alpha.2

docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Plan 0.1.4 — réexamen Tauri et skeleton contrôlé
 
@@ -234,6 +234,44 @@ 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.
 
+## Gate `alpha.1` acquise
+
+La gate opérateur exécutée le `2026-09-29` est `PASS` : `48/48` tests Python, `266` fichiers Markdown propres, `343` liens locaux propres, audit structurel `96` couples antérieurs / `7` hosts Tauri propre et scope Git exactement conforme au delta.
+
+Le history `history/0.1.4/alpha.1.md` enregistre cette preuve. Aucun `alpha.1.fix.N` n'est requis.
+
+## Réconciliation normative préparée en `alpha.2`
+
+La tranche `alpha.2` resserre le profil `710` sur les responsabilités Tauri réellement possédées : host, orchestration, configuration, ACL/capabilities, plugins, intégration frontend et packaging. Elle retire du profil Tauri le choix direct de la stack Web déjà possédée par les owners `530/540/550/560` et par `003-WEB_FRONTEND.md`.
+
+Décisions préparées pour la gate :
+
+```text
+710-TAURI.md                              version 7
+002-TAURI_SKELETON_DECISION.md           version 3
+commande / permission / capability       séparées
+sélection des capabilities               décision de sécurité explicite
+src-tauri/                                supporté, non imposé
+host Cargo direct                         SHOULD pour nouvelle baseline contrôlée
+TypeScript / Vite / Sass / Bootstrap     owners Web / skeleton, pas owner Tauri
+TS-RS                                     conditionnel à la frontière typée réelle
+template Tauri                            DEFER
+validation Tauri séparée                  DEFER
+004-TAURI.md                              toujours absent pendant alpha.2
+```
+
+La décision historique `DEFER` de `0.0.5-alpha.9` reste conservée comme preuve historique, mais son motif Web est levé. L'étude révisée autorise donc `alpha.3` à matérialiser la specification `004-TAURI.md` si la présente gate reste propre.
+
+## Point transversal découvert pendant la gate `alpha.1`
+
+L'utilisation de PGR pour initialiser SaseDev Knowledge a fait apparaître trois questions de gouvernance qui dépassent le domaine Tauri :
+
+1. `SHOULD / SHOULD NOT` doit exprimer une forte recommandation non obligatoire, distincte d'un `MUST`, sans transformer automatiquement son écart en échec de gate ou en `OVERRIDE` ;
+2. une adoption/instanciation PGR doit produire un projet autonome dont les sessions suivantes utilisent ses propres règles comme autorité, sans rechercher automatiquement une version PGR plus récente ;
+3. lorsque SaseDev Knowledge sera suffisamment fonctionnel, PGR devra pouvoir rester concentré sur les contrats de gouvernance réutilisables tandis que howtos, recettes et snippets pratiques vivent dans Knowledge, sans rendre PGR dépendant de Knowledge pour comprendre une règle.
+
+Ces constats ne constituent pas un défaut du cadrage Tauri `alpha.1` et ne sont donc pas absorbés dans `alpha.2`. Ils MUST être repris dans la revue d'horizon de fermeture de `0.1.4` avant de générer le prompt de la release suivante, afin de décider explicitement si la trajectoire `0.1.5+` doit être réordonnée avant les adoptions Games/KSP.
+
 ## Trajectoire de `0.1.4`
 
 ### `alpha.1` — intake, audit et décision de cadrage
@@ -288,7 +326,9 @@ Par défaut, l'absence de lacune démontrée signifie **ne pas créer** d'artefa
 
 ### `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`.
+Effectuer la gate RC, geler le scope de `0.1.4` et préparer le `CHANGELOG.md` candidate. Avant de générer le prompt de la release suivante, effectuer une revue d'horizon qui traite explicitement le point transversal découvert après `alpha.1`.
+
+Si cette revue confirme la trajectoire existante, le prompt suivant ouvre `0.1.5` pour l'adoption Games. Si elle démontre qu'une release de gouvernance/autonomie doit précéder les adoptions, le roadmap et les numéros suivants sont réordonnés explicitement à ce moment-là plutôt que contournés silencieusement.
 
 ### `rel.1` — stable
 
@@ -300,7 +340,7 @@ Promouvoir `0.1.4`, finaliser `README.md`, `ROADMAP.md`, `CHANGELOG.md` et les i
 
 La release ne rouvre pas Android `0.1.3` en l'absence de défaut transversal démontré. Les détails générés des projets Android/iOS Tauri restent composés avec leurs owners de plateforme lorsqu'ils sont applicables.
 
-La release ne réserve aucun numéro au-delà de `0.1.7`. 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.
+La release ne réserve aucun numéro au-delà de `0.1.7`. La trajectoire actuellement publiée conserve `0.1.5` Games, `0.1.6` KSP et `0.1.7` audits Rust jusqu'à la revue d'horizon de fermeture ; cette revue peut la réordonner explicitement si le besoin transversal identifié est confirmé prioritaire. Le `CHANGELOG.md` et le `ROADMAP.md` ne sont pas réécrits prématurément ; ils sont mis à jour dans les phases de fermeture lorsqu'ils décrivent l'état effectivement atteint et la trajectoire confirmée.
 
 ## Gate de sortie du plan