Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.1.1-alpha.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-27 10:09:35 +02:00
parent 2ed8742f3b
commit 7b7565d5d4
6 changed files with 712 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 23 -->
<!-- version: 24 -->
# Documentation PGR
@@ -20,6 +20,13 @@ D'autres collections telles que `ideas/`, `studies/`, `reference/` ou `formats/`
Les templates techniques copiables sous `templates/` restent séparés des instructions documentaires sous `docs/templates/`. Les répertoires workflow de racine (`deltas/`, `history/`, `handoffs/`, `manifests/`, `prompts/`, `scripts/`) restent séparés de `docs/` parce qu'ils portent le processus de développement et de livraison lui-même.
## Points d'entrée de 0.1.1
- [`plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md`](plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md) — plan actif de la fondation frontend Web contrôlée, de l'audit des corpus à la séparation TypeScript/Vite/styles/package/validation.
- [`studies/002-TAURI_SKELETON_DECISION.md`](studies/002-TAURI_SKELETON_DECISION.md) — décision `DEFER` dont `0.1.1` doit satisfaire les prérequis Web sans créer ni autoriser automatiquement le skeleton Tauri.
- [`studies/003-V0_1_0_HORIZON_REVIEW.md`](studies/003-V0_1_0_HORIZON_REVIEW.md) — revue ayant engagé `0.1.1` à `0.1.7` et maintenu WASM, serveur Rust et deployment sans réservation prématurée.
- [`../prompts/007-V0_1_1_START_PROMPT.md`](../prompts/007-V0_1_1_START_PROMPT.md) — contrat de reprise autoritaire de la release `0.1.1`.
## Points d'entrée de 0.1.0
- [`plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md`](plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md) — plan historique de la stable `0.1.0`, depuis l’audit de `v0.0.5` jusqu’à la baseline réutilisable, la clôture/publication et la revue d’horizon.

381
docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md Normal file
View File

@@ -0,0 +1,381 @@
<!-- file: docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md -->
<!-- version: 1 -->
# 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 :
```text
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 :
```text
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 :
```text
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 :
```text
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 :
```text
48 / 48 tests PASS
```
Les audits documentaires donnent :
```text
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 :
```text
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 :
```text
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 :
```text
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 :
```text
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 :
```text
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 :
```text
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 :
```text
**/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é. `0.1.1` doit donc distinguer :
- le contrat générique d'un manifest/package manager ;
- la sélection explicite du package manager par le projet ;
- la politique du lockfile selon le type de package/application et la reproductibilité recherchée ;
- la politique locale Games, qui restera `KEEP-LOCAL` tant qu'une règle générique différente n'est pas décidée et justifiée.
### 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 :
```text
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`.
## 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 :
```text
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
Décider la composition minimale des owners nécessaires à TypeScript, package manager/manifest, Vite et styles. Matérialiser uniquement les familles/profils dont l'ownership est suffisamment prouvé.
Cette tranche doit aussi classifier explicitement les choix Games selon `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` sans migrer Games.
### alpha.3 — TypeScript et écosystème de package
Matérialiser les règles et artefacts réutilisables pour TypeScript, manifest, scripts de package et sélection du package manager. Définir une politique de lockfile fondée sur le rôle de l'artefact et la reproductibilité, pas sur une préférence npm.
Si un template `package.json` ou `tsconfig.json` est ajouté, il doit rester minimal, parsable et adaptable sans versions arbitrairement figées lorsque PGR ne possède pas cette décision.
### 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 :
```text
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.