pgr/prompts/004-V0_0_4_START_PROMPT.md

Prompt de démarrage 0.0.4 — spécifications de skeletons

Baseline et cible

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

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

Si un rapport séparé pgr-0.0.3-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 ci-dessus sont confirmés et le rapport est PASS, le texte est :

Partir de l'archive pgr-v0.0.3.zip téléchargée depuis le tag Gitea v0.0.3 et du rapport post-tag pgr-0.0.3-publish.001-report.md. Lire et exécuter prompts/004-V0_0_4_START_PROMPT.md. Vérifier l'archive, les règles, la gouvernance, la structure documentaire, les deltas/histories et la cohérence globale avant de préparer 0.0.4-alpha.1.

Si le rapport manque ou n'est pas PASS, supprimer sa mention de la phrase et transmettre son état réel séparément. Adapter les noms à ceux des fichiers effectivement téléchargés. Ce texte ne doit être remis qu'après clôture stable et vérification post-tag, jamais comme attestation anticipée au stade RC.

Mission

Définir les premières skeleton specifications Markdown réutilisables et les règles pratiques de composition des profils, templates et choix propres au projet. Un skeleton décrit une procédure de sélection, les fichiers et profils applicables, les décisions à prendre et une validation proportionnée ; il ne génère pas automatiquement un projet et ne fixe pas son architecture pour toujours.

alpha.1 MUST vérifier entièrement la stable v0.0.3, en particulier les règles 200 à 610, les cinq modèles Rust/Cargo, les trois audits Markdown, les deux audits de style Rust facultatifs, la chaîne de deltas/histories et les limites annoncées. Elle doit établir quels skeletons répondent déjà à un besoin concret et lesquels exigent encore des templates ou des décisions préalables. Planifier ensuite les tranches proportionnées de 0.0.4 avant toute matérialisation importante.

Principes de conception

• Conserver un propriétaire normatif unique par règle et une copie autonome des règles/configurations pertinentes dans chaque projet instancié.
• Respecter la séparation : règles applicables sous docs/rules/, fichiers techniques copiables sous templates/, mode d'adaptation sous docs/templates/, spécifications de skeletons Markdown et audits read-only pour les propriétés réellement contrôlables.
• Sélectionner seulement les profils et templates justifiés par le type de projet ; documenter explicitement le nom, la version, les cibles, les dépendances et les exceptions qui dépendent du destinataire.
• Ne pas déclarer universelles les valeurs 0.1.0, 2024, les seuils Clippy ou les chemins d'exemple des templates Rust/Cargo.
• Préserver les décisions d'ordre sémantique des constantes : l'audit correspondant n'est pas une gate globale de tout workspace Rust.
• Différer les skeletons Java/Android, Web, JNI, Tauri et autres familles dont les pièces nécessaires ou les propriétaires manquent encore ; un nouveau domaine demande un cadrage justifié.
• Garder les audits ciblés et non redondants avec les outils officiels ; les tests prouvent des comportements utiles, sans quota arbitraire de couverture.

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. Un changement de session ne crée pas une version nouvelle. Un rapport de publication post-tag est séparé de la validation pré-tag.