78 lines
4.0 KiB
Markdown
78 lines
4.0 KiB
Markdown
<!-- file: prompts/007-V0_1_1_START_PROMPT.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# 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`.
|