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

0.0.5-beta.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-25 18:07:50 +02:00
parent 5a83968813
commit c97ca5f21a
9 changed files with 420 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
prompts/006-V0_1_0_START_PROMPT.md Normal file
View File

@@ -0,0 +1,69 @@
<!-- file: prompts/006-V0_1_0_START_PROMPT.md -->
<!-- version: 1 -->
# Prompt de démarrage 0.1.0 — première baseline réutilisable
## Baseline et cible
Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`.
La baseline attendue au démarrage effectif de `0.1.0` est l'archive source téléchargée depuis le tag Gitea `v0.0.5`, dont le nom attendu est `pgr-v0.0.5.zip`. Une archive source peut légitimement ne pas contenir `.git` ; vérifier son contenu et ses artefacts de gouvernance sans lui attribuer une preuve Git qu'elle ne peut contenir.
Version cible : `0.1.0`. Première tranche attendue : `0.1.0-alpha.1`.
Si un rapport séparé `pgr-0.0.5-publish.001-report.md` a effectivement été produit et conclut `PASS`, le fournir avec l'archive. S'il est absent ou non validé, le signaler explicitement ; ne jamais présumer la publication ou un résultat PASS. Ce rapport ne fait pas partie du tag et ne remplace pas l'audit de la nouvelle session.
## Reprise manuelle après publication
Après vérification réelle de l'archive du tag et du rapport post-tag PASS, remettre spontanément à l'opérateur un message de reprise adapté selon [`../docs/templates/003-NEW_SESSION_PROMPT.md`](../docs/templates/003-NEW_SESSION_PROMPT.md). Si les noms attendus sont confirmés et le rapport est PASS, la base du texte est :
```text
Partir de l'archive pgr-v0.0.5.zip téléchargée depuis le tag Gitea v0.0.5 et du rapport post-tag pgr-0.0.5-publish.001-report.md. Lire et exécuter prompts/006-V0_1_0_START_PROMPT.md. Vérifier intégralement la stable PGR, ses règles, profils, templates, skeletons, audits, décisions différées et chaîne de gouvernance avant de préparer 0.1.0-alpha.1.
```
Si le rapport manque ou n'est pas PASS, retirer sa mention et transmettre son état réel séparément. Ce texte ne doit être remis qu'après clôture stable et vérification post-tag de `0.0.5`, jamais comme attestation anticipée au stade RC.
## Mission
Transformer les fondations `0.0.x` en première baseline PGR réellement réutilisable pour initialiser de nouveaux projets sans importer des choix locaux non applicables.
`alpha.1` MUST commencer par auditer indépendamment la stable `v0.0.5` : gouvernance, owners normatifs, templates, skeleton specifications, audits, documentation, roadmap, histories/deltas et rapport post-tag lorsqu'il est fourni. Elle doit ensuite produire ou consolider le plan `0.1.0` avant toute extension importante.
Le plan doit notamment déterminer :
- quelles règles, profils, templates et skeletons sont suffisamment cohérents pour constituer la baseline réutilisable ;
- quelles validations doivent être considérées comme gates minimales ou conditionnelles d'une nouvelle instanciation ;
- quelles décisions différées doivent seulement être conservées, réétudiées ou réellement engagées ;
- où aura lieu la revue d'horizon obligatoire avant fermeture de `0.1.0`.
## Décisions héritées à respecter
- Le skeleton Tauri contrôlé reste `DEFER` tant que les owners Web suffisants ne sont pas matérialisés. `0.1.0` MAY réexaminer cette trajectoire si son plan crée effectivement ces owners, mais MUST NOT créer le skeleton seulement pour fermer le report.
- Les profils Web/TypeScript/Vite/Sass, observability et autres domaines techniques ne sont pas présumés nécessaires : ils exigent un besoin réutilisable, un corpus réel et un owner clair avant normalisation.
- Les projets documentaires/spécifications, notamment `saselang-bible` comme corpus pilote possible, et l'usage de PGR hors logiciel restent des candidats d'horizon tant qu'une décision macro ne les engage pas.
- Aucune release postérieure à `0.1.0` ne doit être inventée pour remplir la roadmap.
## Principes de baseline
- Un owner normatif unique par responsabilité ; les skeletons sélectionnent/composent les owners et ne remplacent pas ceux qui manquent.
- Une règle n'existe que si elle apporte une valeur réelle de sûreté, cohérence, lisibilité, reprise ou automatisation.
- Compiler, outil officiel, manifeste/build system et audits read-only sont préférés aux tests textuels redondants.
- Les audits restent monotâches et leurs limites explicites ; un contrôle lexical ne prétend pas remplacer un parser ou le compilateur.
- Les profils stricts peuvent être le défaut des nouveaux projets contrôlés tout en permettant des overrides explicites lorsqu'un projet externe ou une contrainte technique impose autre chose.
- Les versions, décisions et documents restent classifiés par responsabilité ; `VERSION` ne force pas la réécriture de tous les miroirs techniques ou produit.
## Revue d'horizon obligatoire
Le plan `0.1.0` MUST programmer une revue d'horizon avant la clôture stable. Cette revue doit décider, à partir de la baseline réellement obtenue, s'il faut :
- étendre `ROADMAP.md` avec des objectifs suffisamment décidés ;
- conserver explicitement l'horizon ouvert avec un prochain déclencheur ;
- requalifier une trajectoire différée telle que le skeleton Tauri ;
- différer/mettre en pause d'autres axes ;
- ou constater qu'un objectif macro est accompli.
Elle ne doit pas réserver des numéros de version uniquement pour donner l'impression d'une trajectoire longue.
## Workflow
Suivre `RULES.md`, [`../docs/rules/210-WORKFLOW.md`](../docs/rules/210-WORKFLOW.md) et [`../docs/rules/400-VALIDATION.md`](../docs/rules/400-VALIDATION.md). La séquence reste delta → gate opérateur → history constaté → application du history → commit → delta suivant. Les corrections utilisent `.fix.N`; une session ou une discussion stratégique ne crée pas de version à elle seule.