0.1.1-alpha.5

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: 7 -->
+<!-- version: 8 -->
 
 # Plan 0.1.1 — fondation frontend Web contrôlée
 
@@ -393,27 +393,31 @@ Aucune règle TypeScript/package ni aucun template n'a été modifié par le fix
 
 ### alpha.4 — Vite, dev server et outputs
 
-Matérialiser le contrat Vite sans créer un `vite.config.ts` universel artificiel : les chemins `root`, `cacheDir`, `build.outDir`, la valeur `base`, les ports, aliases, plugins et intégrations de host dépendent du layout réel du projet.
+Statut opérateur : **PASS**.
 
-Le profil doit en revanche fixer les responsabilités génériques suivantes :
+La tranche a matérialisé le contrat Vite sans créer de `vite.config.ts` universel artificiel. Les sources, cache, outputs et assets ont des statuts explicites ; le dev server reste borné ; les paramètres `root`, `base`, ports, aliases et plugins restent des décisions locales.
 
-- distinguer sources versionnées, cache reproductible et outputs de build générés ;
-- garder cache et outputs hors Git, en les externalisant hors de l'arborescence source lorsque cela reste raisonnable ;
-- considérer `publicDir` comme une source statique optionnelle et les copies présentes dans `outDir` comme générées ;
-- n'utiliser `build.emptyOutDir = true` que lorsque `outDir` est un répertoire dédié et possédé sans ambiguïté par le build ;
-- garder le dev server local/loopback par défaut et n'élargir l'écoute réseau que pour un besoin explicite ;
-- rendre port + `strictPort` déterministes lorsqu'un host ou un smoke dépend d'une URL fixe ;
-- éviter les ouvertures globales de `allowedHosts` ou CORS sans justification ;
-- réserver `vite preview` à la prévisualisation locale d'un build et non à un serveur de production ;
-- ajouter Vite au manifest réel comme outil de développement et exposer `dev` / `build` / `preview` seulement lorsqu'ils correspondent au workflow réel.
-
-Les paramètres de port, host, `base`, aliases, plugins, découpage d'assets et intégrations particulières restent locaux sauf preuve générique contraire. TypeScript reste validé séparément ; CSS/Sass reste réservé à `alpha.5`.
+La gate spécifique a atteint son message final, les `48/48` tests et les trois audits Markdown sont propres, et le scope Git correspond exactement aux six chemins annoncés. TypeScript/package n'a pas été rouvert et CSS/Sass est resté réservé à `alpha.5`.
 
 ### alpha.5 — CSS/Sass et validation frontend
 
-Matérialiser la frontière CSS/Sass, puis rendre explicite la validation frontend indépendante du host. Sass reste une capacité optionnelle. Bootstrap ou toute alternative reste un choix de skeleton/projet sauf règle générique distinctement démontrée.
+Matérialiser la frontière CSS/Sass et la validation frontend indépendante du host.
 
-Cette tranche peut créer un skeleton frontend uniquement si les owners précédents rendent sa composition suffisamment stable ; sinon le skeleton reste différé sans bloquer la release.
+La tranche retient les décisions suivantes :
+
+- CSS reste une baseline valide sans préprocesseur ;
+- Sass reste optionnel mais **SHOULD** être préféré lorsque la chaîne de styles est non triviale ou lorsqu'un package expose une API Sass utile ;
+- le nouveau code Sass contrôlé privilégie `@use` / `@forward`, tandis que `@import` reste uniquement une voie de compatibilité pour les dépendances qui l'exigent encore ;
+- les sources `.css` / `.scss` / `.sass` intentionnelles sont versionnées, mais les CSS compilées, minifiées, sourcemaps et copies présentes dans un output de build sont générées et ne doivent pas devenir un second source ;
+- un package de styles doit être consommé via son entrypoint public/documenté plutôt que par des chemins internes arbitraires ;
+- Bootstrap, Tailwind CSS ou une autre bibliothèque restent des choix de projet/skeleton, jamais une obligation de `560` ;
+- lorsqu'un frontend utilise Vite + Sass, `sass-embedded` est un choix de développement recommandé lorsque compatible, mais le profil Sass ne dépend pas de Vite ;
+- la validation frontend distingue restore reproductible, type-check, build/compilation des styles et smoke navigateur seulement lorsque celui-ci apporte une preuve supplémentaire ;
+- un PASS frontend ne vaut pas PASS du host, et un host Tauri ne doit pas posséder les validations TypeScript/Vite/Sass génériques.
+
+Les owners `530/540/550/560` sont désormais assez complets pour composer un skeleton Web sans ownership caché. La tranche crée donc `003-WEB_FRONTEND.md` comme specialization contrôlée : TypeScript et Vite y restent des `SHOULD`, Sass reste conditionnel, le package manager et le framework CSS restent des décisions explicites, et aucun layout `frontend/`, `vite.config.ts`, `main.scss`, port ou package concret n'est imposé.
+
+Le skeleton ne lève pas le `DEFER` Tauri. `beta.1` devra encore réconcilier les cinq conditions de sortie de l'étude `002` et conclure factuellement si `0.1.4` peut réexaminer le candidat Tauri.
 
 ### beta.1 — réconciliation et preuve de préparation Tauri