pgr/prompts/006-V0_1_0_START_PROMPT.md

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. Si les noms attendus sont confirmés et le rapport est PASS, la base du texte est :

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 et ../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.