93 lines
4.4 KiB
Markdown
93 lines
4.4 KiB
Markdown
<!-- file: docs/plans/001-V0_0_1_FOUNDATION_PLAN.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# Plan 0.0.1 — fondation de PGR
|
|
|
|
## Statut
|
|
|
|
Plan actif créé pendant `0.0.1-alpha.1` à partir du bootstrap initial du dépôt PGR.
|
|
|
|
Aucune stable PGR antérieure n'existe. Cette version doit rendre le dépôt capable de se gouverner lui-même avant d'introduire les 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`.
|
|
|
|
## 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.
|