# Prompt de démarrage 0.1.1 — fondation frontend Web ## Baseline et cible Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`. La baseline attendue au démarrage effectif de `0.1.1` est l'archive source téléchargée depuis le tag Gitea `v0.1.0`, accompagnée du rapport post-tag `pgr-0.1.0-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`. Version cible : `0.1.1`. Première tranche attendue : `0.1.1-alpha.1`. Le corpus principal attendu pour instruire le besoin Web est une archive autoritaire récente de `sasedev-games`. Si aucune baseline plus récente n'est explicitement fournie, la baseline de référence déjà auditée reste : ```text games-v0.3.6.zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8 ``` Une archive source peut légitimement ne pas contenir `.git`. Ne pas lui attribuer une preuve Git qu'elle ne peut contenir. ## Mission Créer la première fondation frontend Web contrôlée de PGR à partir de besoins réellement exercés, principalement dans Games, sans importer automatiquement les choix locaux du corpus. `alpha.1` MUST commencer par : 1. auditer indépendamment la stable `v0.1.0` et son rapport post-tag lorsqu'il est fourni ; 2. auditer le corpus Games réellement fourni et identifier les responsabilités Web exercées ; 3. relire `docs/studies/003-V0_1_0_HORIZON_REVIEW.md` et `docs/studies/002-TAURI_SKELETON_DECISION.md` ; 4. créer le plan `0.1.1` avant toute normalisation importante. ## Scope de domaine attendu La release doit instruire ensemble les responsabilités nécessaires à un frontend Web contrôlé : - TypeScript et configuration applicable ; - Vite, dev server et contrat de build outputs ; - Sass/CSS, sources et artefacts générés ; - package manager, manifest et lockfile sans imposer arbitrairement npm ; - séparation entre validation frontend et validation du host ; - templates, skeletons et audits read-only seulement lorsqu'ils apportent une preuve générique réelle. La release peut créer plusieurs owners si les responsabilités l'exigent, mais reste une seule release de domaine Web frontend. ## Hors scope `0.1.1` MUST NOT : - créer le skeleton Tauri contrôlé ; - intégrer WASM au host ou créer un profil WASM par simple proximité ; - normaliser Actix Web ou un autre serveur Rust sans corpus d'implémentation suffisant ; - migrer Games vers PGR ; - migrer KSP vers PGR ; - réécrire le profil Java/Gradle ou Android, qui possèdent leurs releases dédiées `0.1.2` et `0.1.3` ; - traiter les sujets deployment/operations de l'horizon futur. ## Relation avec Tauri Le skeleton Tauri reste `DEFER` pendant cette release. `0.1.1` doit néanmoins produire les owners Web suffisamment explicites pour que `0.1.4` puisse réexaminer objectivement les conditions de sortie de `002-TAURI_SKELETON_DECISION.md`. La réussite de `0.1.1` ne vaut pas automatiquement levée du `DEFER` Tauri. ## Principes - Partir des faits observés dans le corpus, pas d'un catalogue théorique du Web moderne. - Un outil ou package manager n'est pas rendu obligatoire parce qu'il est présent dans Games. - Les sorties générées doivent avoir un owner clair et une politique explicite de versionnement/ignorance. - Les audits Python restent monotâches et read-only ; ils ne remplacent ni TypeScript, ni Vite, ni Sass, ni le package manager. - Conserver la distinction `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` pour préparer l'adoption Games ultérieure. - Ne pas réserver de nouvelles releases au-delà de la roadmap engagée sans nouvelle revue d'horizon justifiée. ## Workflow Suivre `RULES.md`, `docs/rules/210-WORKFLOW.md`, `docs/rules/230-ADOPTION.md` et `docs/rules/400-VALIDATION.md`. La séquence reste : delta → gate opérateur → history constaté → application du history → commit/push → delta suivant. Les commandes de handoff sont remises automatiquement conformément à `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`.