pgr/docs/plans/001-V0_0_1_FOUNDATION_PLAN.md

Plan 0.0.1 — fondation de PGR

Statut

Plan clôturé par la promotion stable 0.0.1 après validation de 0.0.1-rc.1.fix.1.

Aucune stable PGR antérieure n'existait. Cette version rend le dépôt capable de se gouverner lui-même avant l'introduction des profils technologiques et templates prévus dans les releases suivantes.

Mission

0.0.1 doit établir la fondation normative, documentaire et opératoire de Project Governance Rules.

La release doit notamment fixer :

• la finalité et les non-objectifs de PGR ;
• la hiérarchie MUST / SHOULD / MAY et les règles de scope/override/exception ;
• le modèle SemVer et le rôle de VERSION ;
• le lifecycle alpha → beta → rc → stable et les .fix.N ;
• le cadrage obligatoire de alpha.1, le replan et l'abandon/supersession ;
• les rôles de README, RULES, ROADMAP, CHANGELOG et des collections documentaires ;
• les contrats des plans, deltas, historiques, prompts, handoffs et manifests ;
• la séparation TEST / AUDIT / DIAGNOSTIC ;
• la validation proportionnée et l'autorité du gate opérateur ;
• les règles de reprise de session et de baseline ZIP taggée ;
• la préparation du prompt de démarrage de 0.0.2.

Hors périmètre

0.0.1 ne doit pas encore :

• formaliser en détail tous les profils Rust, Java, Android, Tauri, Web, PHP, Python, C/C++ ;
• produire le catalogue final des templates techniques ;
• fournir des skeleton specifications complets par type de projet ;
• créer un générateur PGR ;
• anticiper des audits spécialisés sans besoin concret ;
• réappliquer PGR à KSP ou games, travail réservé à une release ultérieure.

Principes de dimensionnement

Une tranche doit rester cohérente et validable indépendamment. La cible de 15 à 30 minutes de travail effectif reste une heuristique de dimensionnement, pas une deadline.

Si le plan devient manifestement faux, un alpha.N peut jouer le rôle de REPLAN. Une version n'est jamais forcée vers stable uniquement pour respecter une session de conversation.

Prévision

alpha.1 — Bootstrap and framing

Créer la baseline minimale : identité, .gitignore, VERSION, documents racine, objectifs, profil du dépôt, architecture de gouvernance, index des règles, matrice de validation, plan actif, delta et prompt initial.

Aucune implémentation massive des règles détaillées n'est réalisée dans cette tranche.

alpha.2 — Core governance rules

Formaliser les règles communes de versioning et lifecycle : SemVer, VERSION, maturité, fixes, cadrage alpha.1, replan, abandon/supersession, stable promotion et publication.

alpha.3 — Workflow artifacts

Formaliser plans, deltas, history, prompts, handoffs, manifests de suppression, workflow PASS/FAIL et reprise après interruption.

alpha.4 — Documentation governance

Formaliser les rôles des documents, taxonomie documentaire, headers, révisions internes, déplacement/split/fusion, conservation historique, objectifs, ideas/studies/architecture/reference et politique de langue.

alpha.5 — Validation governance

Formaliser la matrice de validation, sélection proportionnelle, TEST/AUDIT/DIAGNOSTIC, opérateur autoritaire, tests utiles/non redondants, mocks lorsque pertinents et transitions de gate.

beta.1 — Foundation reconciliation

Réconcilier les documents de fondation, éliminer duplications et contradictions, vérifier navigation, rôles, scopes et complétude de 0.0.1.

rc.1 — Foundation release candidate

Geler le scope, préparer l'entrée candidate de changelog et le prompt 0.0.2, puis exécuter la gate documentaire complète applicable.

stable — 0.0.1

Promouvoir mécaniquement la RC validée, finaliser les métadonnées de release, enregistrer rel.001, commit/tag v0.0.1, puis utiliser l'archive ZIP taggée comme baseline autoritaire de 0.0.2.

Clôture

La release candidate a nécessité rc.1.fix.1 pour corriger exclusivement une commande de gate incompatible avec l'expansion d'historique d'un Bash interactif. La gate RC complète a ensuite été validée PASS sans modification du scope normatif.

La promotion stable rel.001 clôt le plan en mettant à jour uniquement les métadonnées vivantes de release et en préparant le tag v0.0.1.

Critères de fermeture

0.0.1 est fermée lorsque :

• PGR peut expliquer et appliquer son propre cycle de version ;
• les responsabilités des principaux artefacts de gouvernance sont non ambiguës ;
• la validation d'une tranche peut être sélectionnée proportionnellement ;
• une interruption ou reprise de session est gouvernée ;
• le passage RC → stable → tag → archive suivante est défini ;
• aucune règle technologique détaillée hors fondation n'est nécessaire pour comprendre le workflow PGR.