0.1.1-alpha.3

docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Plan 0.1.1 — fondation frontend Web contrôlée
 
@@ -206,12 +206,17 @@ pnpm-lock.yaml
 yarn.lock
 ```
 
-Aucun lockfile Node n'est versionné dans l'archive. Cette politique est un choix Games actuel, pas une preuve qu'un lockfile frontend doit toujours être ignoré. `0.1.1` doit donc distinguer :
+Aucun lockfile Node n'est versionné dans l'archive. Cette politique est un choix Games actuel, pas une preuve qu'un lockfile frontend doit toujours être ignoré.
 
-- le contrat générique d'un manifest/package manager ;
-- la sélection explicite du package manager par le projet ;
-- la politique du lockfile selon le type de package/application et la reproductibilité recherchée ;
-- la politique locale Games, qui restera `KEEP-LOCAL` tant qu'une règle générique différente n'est pas décidée et justifiée.
+`alpha.3` retient une politique fondée sur le rôle :
+
+- une application privée ou déployable `SHOULD` versionner le lockfile produit par son package manager afin de figer l'arbre réellement résolu ;
+- une bibliothèque publiée `MAY` versionner un lockfile pour stabiliser l'environnement contributeur/CI, mais le manifest et ses contraintes restent le contrat de résolution des consommateurs ;
+- un exemple, template ou fixture sans résolution de dépendances réelle `MAY` ne pas posséder de lockfile ;
+- un même package `SHOULD NOT` conserver simultanément plusieurs lockfiles de package managers concurrents, sauf migration explicitement temporaire ;
+- lorsqu'un lockfile est versionné, CI `SHOULD` utiliser le mode gelé/immutable/clean-install équivalent du package manager sélectionné plutôt qu'une résolution permissive.
+
+L'absence actuelle de lockfiles dans Games devient donc une décision à réexaminer pendant l'adoption `0.1.5` : les packages applicatifs pourront `ADOPT` la recommandation en versionnant leur lockfile, ou documenter un `OVERRIDE` s'ils conservent volontairement une autre politique.
 
 ### Relation avec WASM et host
 
@@ -266,7 +271,7 @@ Cette granularité conserve l'indépendance d'applicabilité : un projet peut ut
 | Vite comme build tool/dev server           | `ADOPT`                                         | déjà exercé ; reste remplaçable par une alternative justifiée  |
 | `package.json` comme manifest frontend     | `ADOPT`                                         | owner générique nécessaire                                     |
 | npm comme package manager concret          | `KEEP-LOCAL`                                    | PGR ne rend pas npm universel                                  |
-| absence/versionnement des lockfiles Games  | `KEEP-LOCAL` en attente de `alpha.3`            | ne pas généraliser le corpus historique                        |
+| absence/versionnement des lockfiles Games  | `DEFER` jusqu'à l'adoption `0.1.5`              | choisir alors `ADOPT` ou `OVERRIDE` selon le rôle du package   |
 | Sass dans `game-snake-poc`                 | `ADOPT` lorsque la chaîne de styles le justifie | capacité recommandée, applicabilité conditionnelle             |
 | Bootstrap                                  | `KEEP-LOCAL`                                    | choix de présentation/skeleton, pas règle Web universelle      |
 | `frontend/` comme layout                   | `KEEP-LOCAL` / candidat skeleton                | ne pas transformer un layout observé en règle de langage/build |
@@ -344,15 +349,17 @@ La gate spécifique n'a toutefois pas pu atteindre son message final : le litté
 
 ### alpha.2.fix.1 — correction de la gate d'ownership Web
 
-Corriger uniquement la syntaxe de validation de `alpha.2`, sans modifier les profils `530/540/550/560`, `710-TAURI.md`, les index ou l'architecture déjà livrés.
+Statut opérateur : **PASS**.
 
-La gate corrigée doit reconfirmer le `FAIL` historique de `alpha.2`, les quatre owners indépendants, les recommandations `SHOULD`, la classification Games, le maintien du `DEFER` Tauri, puis rejouer les tests et audits documentaires.
+Le correctif a conservé le `FAIL` historique de `alpha.2`, reconfirmé les quatre owners `530/540/550/560`, les recommandations `SHOULD`, la classification Games et le `DEFER` Tauri. Les `48/48` tests et les trois audits Markdown sont propres ; le scope du fix est resté limité à `VERSION`, au plan et au delta de correction.
 
 ### alpha.3 — TypeScript et écosystème de package
 
-Matérialiser les règles et artefacts réutilisables pour TypeScript, manifest, scripts de package et sélection du package manager. Définir une politique de lockfile fondée sur le rôle de l'artefact et la reproductibilité, pas sur une préférence npm.
+Matérialiser les règles et artefacts réutilisables pour TypeScript, manifest, scripts de package et sélection du package manager.
 
-Si un template `package.json` ou `tsconfig.json` est ajouté, il doit rester minimal, parsable et adaptable sans versions arbitrairement figées lorsque PGR ne possède pas cette décision.
+La tranche retient un type-check indépendant sous le script canonique `typecheck`, un `tsconfig` strict sans émission comme baseline minimale, un `package.json` privé minimal pour les applications contrôlées et une politique de lockfile fondée sur le rôle de l'artefact et la reproductibilité, jamais sur une préférence npm.
+
+Les templates `package.json` et `tsconfig.json` restent volontairement minimaux et parsables. Ils n'imposent ni version TypeScript, ni package manager, ni target/module/runtime, ni Vite ; ces décisions sont ajoutées par le projet ou par les owners des tranches suivantes. Vite reste réservé à `alpha.4` et CSS/Sass à `alpha.5`.
 
 ### alpha.4 — Vite, dev server et outputs