pgr/docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md

Plan 0.1.1 — fondation frontend Web contrôlée

Statut et sources

Plan actif créé pendant 0.1.1-alpha.1 conformément à prompts/007-V0_1_1_START_PROMPT.md, après audit indépendant de la stable taggée v0.1.0, de son rapport post-tag et du corpus Games réellement fourni.

Sources autoritaires de reprise PGR :

pgr-v0.1.0.zip                       bc8f3a8117d04afc1280344eceaaac8c6a4724ca94c285a6234fe42c1023b2be
pgr-0.1.0-publish.001-report.md      a64dc4a5a81e1776b641894d8493eec3ef315932fffb2881e52ff4147eb8b6a5

Le rapport publish.001 est PASS, porte sur cette même archive et confirme le commit stable 2ed8742f3b26695bcd2d1efc07eebf0cb88ff51d. Le tag annoté v0.1.0 possède l'objet tag 372650ea9fe313e7d5389ed43cacb6faa5f18f74 et se déréférence vers ce commit stable. L'absence de .git dans l'archive du tag est normale.

Corpus principal réellement fourni pour instruire le domaine Web :

games-v0.3.6(1).zip                  ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8

Le nom local comporte (1), mais son SHA-256 correspond exactement à la baseline canonique games-v0.3.6.zip enregistrée dans le prompt 007. L'archive Games est donc le corpus autoritaire attendu pour cette étude.

Un corpus secondaire récent a également été fourni :

khadhroony-solana-project-v0.3.17.zip 2a9cabcb9f147a348dcf8d24df8bc6c5029089b6d49feb17bd4a42b4293c329a

KSP 0.3.17 ne devient ni une baseline requise de 0.1.1, ni une cible de migration. Il sert uniquement à corroborer, lorsque cela évite de généraliser un choix Games accidentel, les responsabilités frontend déjà observées derrière Tauri. Toute adoption KSP reste réservée à 0.1.6.

Audit de la stable v0.1.0

Intégrité de l'archive et preuve post-tag

L'archive stable contient 254 entrées sous une racine unique pgr/, soit 221 fichiers et 33 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.0. CHANGELOG.md contient l'entrée stable 0.1.0, ROADMAP.md marque 0.1.0 terminé et engage 0.1.1 à 0.1.7 sans réserver 0.1.8.

La convention de clôture introduite par 0.1.0 est cohérente :

tranche de clôture  rel.1
history             rel.1 PASS
commit stable       0.1.0
tag                  v0.1.0
publish.001          preuve externe post-tag PASS

Aucun ancien artefact rel.001* n'est renommé rétroactivement.

Tests, audits et hygiène

Les quatre suites Python présentes donnent :

48 / 48 tests PASS

Les audits documentaires donnent :

Markdown header audit: clean (198 file(s))
Markdown table audit:  clean (8 table(s), 198 file(s))
Markdown link audit:   clean (193 local link(s), 198 file(s))

Les cinq templates Rust/Cargo TOML sont parsables. Aucun répertoire de sortie courant tel que target/, build/, builds/, dist/, node_modules/ ou __pycache__/ n'est embarqué dans la stable.

Les scripts d'audit restent des contrôles read-only. Aucun audit PGR ne devient un générateur, un formateur ou un wrapper de build.

Chaîne delta/history et vérité opérateur

Les 72 deltas publiés disposent tous d'un history correspondant :

0.0.1  12 / 12
0.0.2  12 / 12
0.0.3  10 / 10
0.0.4   9 / 9
0.0.5  19 / 19
0.1.0  10 / 10

Pour 0.1.0, la vérité opérateur reste explicitement conservée :

alpha.1          PASS
alpha.2          FAIL
alpha.2.fix.1    PASS
alpha.3          FAIL
alpha.3.fix.1    PASS
alpha.4          PASS
alpha.5          PASS
beta.1           PASS
rc.1             PASS
rel.1            PASS

Les FAIL ne sont donc ni écrasés ni requalifiés après coup.

Règles, profils, templates et skeletons

La hiérarchie normative courante reste cohérente : gouvernance, workflow, skeletons, adoption, documentation, validation, langages/écosystèmes, plateformes et frameworks possèdent des owners explicites.

Profils techniques déjà matérialisés :

510  Rust / Cargo
520  Java / Maven / Gradle
610  Android
710  Tauri 2

La stable possède :

• cinq templates techniques Rust/Cargo sous templates/rust-cargo/ ;
• deux skeleton specifications concrètes, gouvernance locale et workspace Rust/Cargo ;
• les templates documentaires de reprise, handoff opérateur et adoption d'un projet existant ;
• les contrats de validation Rust/Cargo et les audits Markdown/Rust monotâches.

Aucun owner Web générique n'existe encore. Il serait incorrect de faire porter TypeScript, Vite ou Sass/CSS par 710-TAURI.md uniquement parce qu'un host Tauri utilise une WebView.

Décisions différées vérifiées

docs/studies/002-TAURI_SKELETON_DECISION.md conserve correctement le skeleton Tauri en DEFER. Ses conditions de sortie exigent notamment :

TypeScript et conventions Web contrôlées
Vite et ownership du dev server / build outputs
Sass/CSS et statut des artefacts générés
validation frontend indépendante de Tauri
choix d'un framework CSS classé comme décision de skeleton, pas comme règle Tauri

docs/studies/003-V0_1_0_HORIZON_REVIEW.md et ROADMAP.md engagent 0.1.1 pour cette fondation frontend, puis 0.1.2 Java/Gradle, 0.1.3 Android, 0.1.4 réexamen Tauri, 0.1.5 adoption Games, 0.1.6 adoption KSP et 0.1.7 audits Rust/Clippy statiques Python.

Les sujets suivants restent volontairement hors de cette release :

• WASM, sans numéro réservé ;
• serveur Web Rust / Actix Web ou alternative, sans numéro réservé et sans corpus d'implémentation suffisant ;
• deployment & operations, horizon futur sans numéro précis réservé ;
• création du skeleton Tauri contrôlé, réservée à un réexamen objectif en 0.1.4.

La réussite de 0.1.1 devra produire les owners nécessaires à ce réexamen, mais ne lèvera pas automatiquement le DEFER.

Audit du corpus Games 0.3.6

Intégrité et portée

L'archive fournie contient 652 entrées sous une racine unique games/, soit 502 fichiers et 150 répertoires. Son CRC est propre et aucun lien symbolique n'est présent.

Games n'est pas supposé conforme à PGR à ce stade. Les observations suivantes décrivent un corpus d'implémentation réel servant à décider ce qui mérite d'être généralisé ; elles ne transforment pas ses choix locaux en norme.

Frontends exercés

Trois packages frontend sont présents :

Web/game-snake-poc/
Web/game-realtime-webtransport-browser-smoke/
crates/apps/game-snake-poc-tauri/

Ils exercent tous :

• un package.json privé ;
• TypeScript ;
• Vite ;
• un frontend/ distinct des configurations/outils du host ;
• un build de production combinant tsc et vite build lorsque la chaîne frontend elle-même est validée ;
• cacheDir et outDir placés sous ../builds/sasedev-games/..., donc hors de l'arborescence source ;
• une séparation entre sources versionnées et sorties générées.

Les deux hosts navigateur directs utilisent en plus un mode preview. Le host Tauri ajoute des paramètres propres à son environnement de développement ; ces paramètres ne sont pas des règles Vite universelles.

Styles et assets

Web/game-snake-poc exerce réellement Sass via sass-embedded, Bootstrap et une politique explicite de sorties CSS/assets. Le smoke WebTransport n'a besoin ni de Sass ni de Bootstrap. Le host Tauri Snake utilise Vite et la copie d'assets, mais son manifest actuel n'impose pas Sass.

La preuve Games indique donc :

CSS                          responsabilité frontend générale
Sass                         capacité optionnelle, pas obligation universelle
framework CSS (Bootstrap)    choix de présentation/skeleton ou projet, pas règle Web universelle
copie d'assets               besoin Vite réel, mais configuration dépendante du projet

Un owner Sass/CSS doit expliquer les sources et artefacts générés sans exiger un préprocesseur sur les frontends qui n'en ont pas besoin.

Package manager, manifest et lockfiles

Les packages exercés utilisent des commandes npm, mais le corpus ne justifie pas de rendre npm obligatoire dans PGR.

La racine Games ignore explicitement :

**/node_modules/
**/dist/
package-lock.json
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é.

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.

Le corpus Games exerce également déjà des dépendances de déclarations TypeScript :

Web/game-snake-poc                         @types/bootstrap + @types/node
Web/game-realtime-webtransport-browser-smoke  @types/node
crates/apps/game-snake-poc-tauri          @types/node

KSP 0.3.17 corrobore la même pratique sur ses applications Tauri, qui utilisent @types/bootstrap et @types/node en devDependencies. Cette répétition justifie une règle générique de découverte des déclarations nécessaires, mais ne justifie pas d'imposer ces deux packages à tous les frontends.

La règle retenue est donc : vérifier d'abord les types embarqués par le package, puis rechercher un @types/... seulement lorsqu'il est réellement nécessaire. Pour une application privée, ces déclarations de développement appartiennent normalement à devDependencies; une bibliothèque publiée doit en revanche conserver disponibles aux consommateurs les types requis par ses déclarations publiques.

Relation avec WASM et host

Deux packages Games chaînent actuellement des commandes WASM avant Vite. Cela prouve une intégration locale, mais ne justifie pas de faire du WASM une responsabilité du futur owner Vite ou TypeScript.

La frontière à conserver est :

validation frontend propre   TypeScript / Vite / CSS / assets / outputs
validation du host           Tauri, navigateur spécialisé ou autre host
validation WASM              owner futur séparé si sa valeur est démontrée

Un frontend doit pouvoir être validé autant que possible indépendamment du host qui l'embarque. Les commandes de génération WASM observées restent donc hors scope normatif de 0.1.1.

Corroboration secondaire KSP 0.3.17

KSP contient six applications Tauri possédant chacune un frontend Vite/TypeScript. Les six manifests exercent également sass-embedded et Bootstrap.

Cette répétition confirme que les owners TypeScript/Vite/Sass/CSS sont bien transversaux à plusieurs hosts et ne doivent pas être absorbés par le profil Tauri. Elle ne suffit toujours pas à rendre Sass ou Bootstrap obligatoires pour tous les frontends : le corpus Games contient déjà des contre-exemples utiles.

Aucune autre règle KSP n'est importée dans 0.1.1-alpha.1.

Décisions de revue après alpha.1

La gate opérateur de alpha.1 est PASS : 48/48 tests, audits Markdown propres et scope Git conforme. Aucun fix de cadrage n'est nécessaire.

La revue ajoute trois préférences explicites à traduire avec la force normative SHOULD :

• TypeScript : fortement recommandé pour les frontends contrôlés, mais non obligatoire. Sa valeur attendue est le type-check statique avant exécution/génération du JavaScript et la possibilité de partager des contrats typés avec d'autres écosystèmes ; lorsqu'une frontière Rust existe, des générateurs comme TS-RS peuvent éviter la duplication manuelle des DTO.
• Vite : fortement recommandé comme build tool/dev server des frontends contrôlés lorsque ses capacités correspondent au besoin, mais non obligatoire. Une alternative justifiée reste valide.
• Sass : fortement recommandé pour les chaînes de styles non triviales, en particulier lorsqu'une dépendance installée via l'écosystème de packages expose un entrypoint Sass/SCSS, des variables, maps, mixins ou autres points de configuration permettant d'adapter la bibliothèque sans modifier ses sources. Sass reste optionnel pour un frontend simple.

Bootstrap constitue un exemple réel de dépendance offrant une chaîne Sass personnalisable ; il ne devient pas pour autant une dépendance PGR universelle. Pour du nouveau code Sass, @use / @forward est préféré lorsque compatible ; @import reste toléré pour les bibliothèques existantes qui l'exigent encore.

alpha.2 matérialise donc quatre owners séparés dans la famille 500 :

530  TypeScript
540  JavaScript package ecosystem
550  Vite
560  CSS / Sass

Cette granularité conserve l'indépendance d'applicabilité : un projet peut utiliser TypeScript sans Vite, Vite avec JavaScript, CSS sans Sass, ou un package manager sans aucune des trois autres briques.

Classification initiale des choix Games

Choix Games	Classification pour l'adoption future	Motif
TypeScript pour les frontends durables	ADOPT	déjà exercé et conforme à la préférence PGR SHOULD
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	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
ports, aliases et plugins Vite	KEEP-LOCAL	valeurs propres au host/projet
commandes/génération WASM dans les scripts	DEFER	futur owner WASM séparé

Aucun OVERRIDE n'est nécessaire à ce stade : Games n'est pas encore gouverné par ces nouveaux profils et sera réellement mappé pendant 0.1.5.

Mission de 0.1.1

0.1.1 doit produire la première fondation frontend Web contrôlée de PGR à partir des responsabilités réellement exercées, sans créer un catalogue théorique de technologies Web.

La release doit pouvoir répondre de manière générique à ces questions :

1. qui possède la configuration TypeScript et quelles options relèvent du langage/outillage plutôt que du host ;
2. qui possède Vite, son dev server, son build, son cache et ses sorties ;
3. comment distinguer CSS, Sass optionnel et framework CSS optionnel ;
4. comment choisir et documenter un package manager sans imposer npm ;
5. comment traiter le manifest et le lockfile selon leur rôle ;
6. quelles sorties sont sources, générées, ignorées ou publiables ;
7. comment valider le frontend indépendamment de Tauri, WASM ou d'un backend ;
8. quels templates, skeletons ou audits read-only apportent une preuve réellement réutilisable.

Frontières d'ownership à décider

alpha.1 ne fixe volontairement ni numéros de profils ni découpage définitif. Les faits indiquent plusieurs responsabilités possibles, mais alpha.2 doit choisir la frontière la plus générale où chaque règle est vraie.

Les axes à distinguer sont au minimum :

TypeScript                 langage / toolchain frontend
manifest + package manager écosystème de package et scripts
Vite                       bundler / dev server / build outputs
CSS                        source frontend standard
Sass                       préprocesseur optionnel
framework CSS              choix de skeleton/projet si applicable
frontend host              navigateur direct, Tauri ou autre, hors owner générique

Le découpage final MUST éviter :

• un profil monolithique « Web moderne » qui rendrait toutes les briques obligatoires ;
• un owner Tauri qui posséderait des règles TypeScript/Vite génériques ;
• un owner TypeScript qui posséderait des règles de bundler ;
• une politique npm codée en dur alors que le contrat doit rester compatible avec un autre package manager choisi explicitement ;
• une règle universelle de lockfile dérivée du seul choix historique de Games ;
• l'import implicite de WASM ou d'un serveur Rust.

Artefacts candidats

Les artefacts suivants sont candidats, pas des livrables déjà décidés :

• un ou plusieurs profils normatifs dans les familles existantes lorsque leur owner est démontré ;
• guides/templates minimaux pour package.json, tsconfig.json et vite.config.ts seulement si les valeurs génériques peuvent être séparées des décisions locales ;
• contrat CSS/Sass expliquant source, génération et outputs sans imposer Sass ;
• skeleton frontend Web seulement si la composition devient suffisamment générique et indépendante de Tauri/WASM ;
• validations frontend sélectionnées selon les capacités réelles : parsing du manifest, TypeScript, build Vite, Sass/CSS, smoke navigateur si la promesse de la tranche l'exige ;
• audits Python uniquement pour des propriétés statiques génériques et certaines, en restant monotâches et read-only.

Aucun de ces artefacts n'est créé par alpha.1.

Trajectoire prévisionnelle de 0.1.1

alpha.1 — audit de stable, corpus et plan

Auditer v0.1.0, publish.001, Games 0.3.6, les décisions Tauri/horizon, puis créer le présent plan. Aucun changement normatif Web n'appartient à cette tranche.

alpha.2 — frontières d'ownership Web

Statut opérateur : FAIL.

La tranche a matérialisé les quatre owners 530 / 540 / 550 / 560, leurs frontières indépendantes et les recommandations SHOULD TypeScript/Vite/Sass. Les 48 tests et les trois audits Markdown sont restés propres et le scope Git observé correspond au delta.

La gate spécifique n'a toutefois pas pu atteindre son message final : le littéral Python 'Le profil s'applique uniquement lorsqu'un projet utilise réellement Vite.' utilise des quotes simples autour d'un texte contenant l'apostrophe de s'applique, provoquant un SyntaxError. Aucun défaut normatif des profils livrés n'est établi.

alpha.2.fix.1 — correction de la gate d'ownership Web

Statut opérateur : PASS.

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

Statut opérateur : PASS.

La tranche a matérialisé 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.

La gate spécifique atteint son message final, les 48/48 tests et les trois audits Markdown sont propres, et le scope Git correspond exactement au delta. Vite est resté réservé à alpha.4 et CSS/Sass à alpha.5.

La revue opérateur après PASS relève toutefois une précision appartenant exactement au scope de la tranche : le manifest réel doit rechercher et déclarer les types externes nécessaires (@types/node, @types/bootstrap ou équivalent) lorsque les dépendances utilisées ne fournissent pas déjà leurs propres déclarations. Le delta livré reste immuable ; cette précision est portée par un fix local.

alpha.3.fix.1 — déclarations de types externes

Statut opérateur : FAIL.

Le correctif a livré la règle types embarqués → @types si nécessaire, la classification conditionnelle de @types/node / @types/bootstrap, la distinction application privée / bibliothèque publiée et l'intégration IDE attendue. Les 48/48 tests et les trois audits Markdown sont propres, et le scope Git correspond au delta.

La gate spécifique n'a toutefois pas atteint son message final : le littéral Python 'qualité TypeScript et à l'expérience IDE' utilise des quotes simples autour d'un texte contenant l'apostrophe de l'expérience, provoquant un SyntaxError. Aucun défaut normatif du correctif n'est établi.

alpha.3.fix.2 — correction de la gate des déclarations de types

Corriger uniquement la syntaxe de validation de alpha.3.fix.1, sans modifier les règles TypeScript/package, le guide 008-WEB_TYPESCRIPT_PACKAGE.md ni les templates JSON.

La gate corrigée doit reconfirmer le FAIL historique de alpha.3.fix.1, les règles de découverte des types externes et la séparation application/bibliothèque, puis rejouer les tests et audits documentaires. Toutes les assertions contenant des apostrophes doivent utiliser des littéraux Python syntaxiquement sûrs.

alpha.4 — Vite, dev server et outputs

Matérialiser l'owner Vite et le contrat de séparation entre sources, cache, outputs de production et assets copiés. Les sorties de build doivent avoir un statut explicite de versionnement/ignorance et éviter de polluer l'arborescence source lorsque le projet peut raisonnablement les externaliser.

Les paramètres de port, host, aliases et intégrations particulières restent locaux sauf preuve générique contraire.

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.

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.

beta.1 — réconciliation et preuve de préparation Tauri

Rejouer les validations larges applicables, réconcilier documentation, owners, templates/skeletons éventuels et matrice de validation. Comparer les résultats aux conditions de sortie de 002-TAURI_SKELETON_DECISION.md.

beta.1 doit produire une conclusion factuelle sur la préparation de 0.1.4, mais MUST NOT lever lui-même le DEFER ni créer le skeleton Tauri.

Si une responsabilité Web nécessaire reste sans owner clair, effectuer un REPLAN avant RC plutôt que masquer la lacune.

rc.1 — release candidate

Geler le scope, mettre à jour le CHANGELOG.md candidat, exécuter le release gate proportionnel complet et préparer/vérifier le prompt de reprise 0.1.2 si la roadmap reste valide.

Aucune nouvelle fonctionnalité normative ne doit apparaître en RC.

rel.1 — promotion stable

Promouvoir mécaniquement la RC validée vers 0.1.1, clôturer roadmap/plan/changelog, produire le history réel, committer la stable sous 0.1.1, puis seulement tagger v0.1.1 et effectuer la vérification post-tag publish.001.

Stratégie de validation

Chaque tranche conserve les gates PGR de base applicables :

python3 -B -m unittest discover -s tests -v
python3 -B scripts/audit_markdown_headers.py ...
python3 -B scripts/audit_markdown_tables.py ...
python3 -B scripts/audit_markdown_links.py ...

Lorsqu'un artefact frontend réel est ajouté, la gate doit utiliser l'outil propriétaire lorsque disponible et pertinent au scope. Un audit Python peut prévalider une propriété statique précise, mais ne doit pas prétendre remplacer TypeScript, Vite, Sass ou le package manager.

Le choix des commandes Node/package manager doit être rendu explicite par le projet ou le fixture de validation. PGR ne doit pas utiliser npm install comme commande universelle simplement parce que Games l'utilise actuellement.

Les smokes navigateur ne sont requis que lorsqu'une tranche ou la release prétend supporter un comportement observable que le build statique ne suffit pas à prouver. Ils doivent être placés avant RC lorsque nécessaires, puis rejoués au release gate selon la matrice finale.

Déclencheurs de REPLAN

Le plan MUST être révisé avant de continuer si :

• le découpage TypeScript/package/Vite/styles ne peut pas conserver un owner unique par règle ;
• 0.1.1 devrait absorber WASM, Tauri ou un serveur Rust pour être cohérent ;
• la politique de package manager/lockfile nécessite plusieurs catégories de projet non prévues ;
• un skeleton frontend ne peut être générique sans décisions propres à Games/KSP ;
• une tranche prévue dépasse nettement l'unité cohérente et indépendamment validable visée par PGR ;
• les validations réelles montrent qu'un outil ou une target supplémentaire est nécessaire pour soutenir une règle normative ;
• le périmètre total ne peut plus raisonnablement être clôturé dans la session/release prévue.

Un REPLAN peut scinder une tranche ou, si nécessaire, réexaminer la trajectoire conformément à la règle de revue d'horizon. Il ne doit pas artificiellement remplir la release avec des owners non prouvés.

Clôture et transition

La release est prête pour RC lorsque :

• les owners Web retenus ont des frontières explicites et non redondantes ;
• TypeScript, package manager/manifest, Vite, CSS/Sass et outputs ont une politique contrôlée proportionnée ;
• la validation frontend est distinguée de la validation du host ;
• WASM, serveur Rust et Tauri n'ont pas été absorbés par proximité ;
• les choix Games non génériques restent classifiés comme locaux ou différés ;
• les conditions Tauri peuvent être réévaluées objectivement en 0.1.4 sans que 0.1.1 décide leur issue à l'avance.

Après publication 0.1.1 et publish.001 PASS, la reprise normale est 0.1.2 — réévaluation Java/Maven/Gradle — sauf REPLAN explicite de l'horizon fondé sur les résultats réels de la release.