pgr/prompts/007-V0_1_1_START_PROMPT.md

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 :

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.