pgr/prompts/005-V0_0_5_START_PROMPT.md

Prompt de démarrage 0.0.5 — réconciliation réelle avec KSP et sasedev-games

Baseline PGR et cible

Dépôt canonique PGR : https://git.sasedev.com/Sasedev/pgr.

La baseline PGR attendue au démarrage effectif de 0.0.5 est l'archive source téléchargée depuis le tag Gitea v0.0.4, dont le nom attendu est pgr-v0.0.4.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.0.5. Première tranche attendue : 0.0.5-alpha.1.

Si un rapport séparé pgr-0.0.4-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.

Sources de réconciliation externes

0.0.5 doit confronter PGR à des états réels de khadhroony-solana-project et sasedev-games. Les baselines exactes de ces deux projets doivent donc être fournies explicitement à la session sous forme d'archives, tags ou autres snapshots autoritaires clairement identifiés.

Ne pas déduire leur version, leur commit ou leur contenu d'une conversation précédente, d'un workspace local non fourni ou d'un souvenir de projet. Si l'une des deux sources manque, l'indiquer et borner l'audit à ce qui est effectivement disponible au lieu de fabriquer une comparaison complète.

Ces projets sont des corpus de réconciliation. Leurs conventions locales ne deviennent pas automatiquement des règles PGR, et PGR ne doit pas leur imposer rétroactivement une règle sans avoir distingué le besoin commun du besoin spécifique au projet.

Reprise manuelle après publication

Après vérification réelle de l'archive du tag PGR 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 PGR attendus ci-dessus sont confirmés et le rapport est PASS, la base de la phrase est :

Partir de l'archive pgr-v0.0.4.zip téléchargée depuis le tag Gitea v0.0.4 et du rapport post-tag pgr-0.0.4-publish.001-report.md. Lire et exécuter prompts/005-V0_0_5_START_PROMPT.md. Vérifier l'archive PGR et les baselines autoritaires fournies de khadhroony-solana-project et sasedev-games avant de préparer 0.0.5-alpha.1.

Si le rapport manque ou n'est pas PASS, retirer sa mention et transmettre son état réel séparément. Adapter également les références KSP/Games aux fichiers ou tags réellement fournis. Ce texte ne doit être remis qu'après clôture stable et vérification post-tag de 0.0.4, jamais comme attestation anticipée au stade RC.

Mission

Réaliser la première réconciliation explicite de PGR avec deux projets réels qui ont servi de corpus de conception : khadhroony-solana-project et sasedev-games.

alpha.1 MUST commencer par auditer indépendamment la stable v0.0.4, ses règles, profils, templates, skeleton specifications, audits et chaîne delta/history. Elle doit ensuite inventorier les règles, conventions, structures et audits réellement présents dans les deux baselines externes fournies, puis classer chaque écart avant toute modification importante.

La réconciliation doit distinguer au minimum :

• ce qui est déjà correctement possédé par PGR et seulement appliqué localement ;
• ce qui révèle un besoin commun manquant ou insuffisamment spécifié dans PGR ;
• ce qui doit rester spécifique à KSP ou à Games ;
• ce qui est devenu obsolète, redondant ou contradictoire dans un projet par rapport au modèle PGR actuel ;
• ce qui nécessite un nouveau profil, template, skeleton ou audit uniquement si un besoin réel et réutilisable le justifie.

Fixer ensuite un plan 0.0.5 proportionné. Ne pas transformer la phase d'inventaire en migration massive des projets et ne pas supposer qu'une divergence doit forcément être résolue du côté PGR.

Principes de réconciliation

• Comparer des responsabilités et propriétés concrètes, pas seulement des noms de fichiers ou des structures visuellement similaires.
• Conserver un propriétaire normatif unique et éviter de recopier dans PGR une règle déjà possédée ailleurs sous une forme plus générale.
• Ne généraliser une convention locale KSP/Games que lorsqu'au moins son besoin et son contrat sont réellement réutilisables.
• Préserver les exceptions locales motivées et les contraintes propres à une plateforme, un protocole, une application ou une phase de développement.
• Réutiliser les audits PGR existants lorsqu'ils contrôlent déjà la propriété recherchée ; ne pas recréer des scripts composites uniquement parce qu'ils existent dans un projet source.
• Vérifier les skeletons 001 et 002 contre des usages réels sans considérer leur adoption intégrale comme obligatoire.
• Documenter explicitement les éléments différés si les preuves disponibles ne suffisent pas à créer un owner ou un artefact PGR durable.

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 baselines externes servent à l'analyse et à la preuve. Une modification effective de KSP ou de sasedev-games, si elle devient nécessaire, doit être explicitement planifiée et validée dans le scope approprié ; elle ne doit pas être cachée dans un delta PGR.