0.0.3-beta.1
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/000-README.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Documentation PGR
|
||||
|
||||
@@ -11,9 +11,16 @@ Ce fichier est l'index d'entrée de la documentation structurée de Project Gove
|
||||
- [`architecture/`](architecture/) — état architectural courant de PGR et profils applicables ;
|
||||
- [`plans/`](plans/) — plans vivants des releases en cours, puis références historiques après fermeture ;
|
||||
- [`rules/`](rules/) — règles normatives détaillées, organisées progressivement par scope ;
|
||||
- [`templates/`](templates/) — choix et instructions d'adaptation des premiers templates techniques ;
|
||||
- [`templates/`](templates/) — instructions d'adaptation des templates techniques et spécification du message manuel de reprise ;
|
||||
- [`validation/`](validation/) — matrices de validation et contrats de preuve.
|
||||
|
||||
D'autres collections telles que `ideas/`, `studies/`, `reference/` ou `formats/` ne sont créées que lorsqu'un premier artefact réel les justifie.
|
||||
|
||||
Les templates techniques copiables sous `templates/` restent séparés des instructions documentaires sous `docs/templates/`. Les répertoires workflow de racine (`deltas/`, `history/`, `handoffs/`, `manifests/`, `prompts/`, `scripts/`) restent séparés de `docs/` parce qu'ils portent le processus de développement et de livraison lui-même.
|
||||
|
||||
## Points d'entrée de 0.0.3
|
||||
|
||||
- [`plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md`](plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md) — périmètre et trajectoire de la release active ;
|
||||
- [`templates/001-RUST_CARGO_TOOLING.md`](templates/001-RUST_CARGO_TOOLING.md) et [`templates/002-CARGO_MANIFESTS.md`](templates/002-CARGO_MANIFESTS.md) — adaptation des cinq fichiers Rust/Cargo copiables ;
|
||||
- [`templates/003-NEW_SESSION_PROMPT.md`](templates/003-NEW_SESSION_PROMPT.md) — spécification du message manuel après une stable publiée ;
|
||||
- [`validation/001-VALIDATION_MATRIX.md`](validation/001-VALIDATION_MATRIX.md) et [`validation/002-RUST_STYLE_AUDITS.md`](validation/002-RUST_STYLE_AUDITS.md) — gates PGR et limites des audits de style Rust facultatifs.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md -->
|
||||
<!-- version: 6 -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# Plan 0.0.3 — templates initiaux et audits réutilisables
|
||||
|
||||
@@ -84,7 +84,7 @@ Les spécifications complètes de skeleton restent réservées à `0.0.4` ; Rust
|
||||
|
||||
## Sélection des audits et patterns
|
||||
|
||||
Les deux audits Markdown existants (`tables`, `liens locaux`) restent séparés : une propriété chacun, sélection explicite des chemins et lecture seule. Le contrôle récurrent des headers Markdown demeure un candidat prioritaire, possédé par `docs/rules/300-DOCUMENTATION.md`, à extraire dans une tranche distincte avec cas positifs et négatifs.
|
||||
Les trois audits Markdown (`headers`, `tables`, `liens locaux`) restent séparés : une propriété chacun, sélection explicite des chemins et lecture seule. L'audit des headers, livré en `alpha.5`, applique le contrat de `docs/rules/300-DOCUMENTATION.md` avec des cas positifs et négatifs ciblés ; il ne juge ni le rôle du document ni la pertinence de l'incrément de sa révision.
|
||||
|
||||
La comparaison des scripts Python KSP `0.3.16` et Games `0.3.5` montre que `audit_rust_general_rules.py` (~580 lignes dans chaque corpus) mélange headers et versions Rust, imports, rustdoc, structure des items, blancs, constantes et modules. `audit_rust_export_completeness.py` possède le contrat particulier des façades et réexports ; KSP ajoute `audit_ksp_workspace_rules.py` pour manifests/frontières/tracing, tandis que Games regroupe plusieurs intégrations Web/Android/Gradle dans `audit_distribution_layout.py`. `audit_rust_workspace_rules.py` est un orchestrateur ; il peut rester un lanceur sans devenir propriétaire de ces contrats.
|
||||
|
||||
@@ -134,6 +134,10 @@ La comparaison des prompts `002` et `003` confirme une répétition utile à fac
|
||||
|
||||
Vérifier ownership, navigation, séparation règle/template/audit, absence de versions universelles arbitraires et proportion des contrôles. Aucun nouveau domaine majeur sans REPLAN.
|
||||
|
||||
La revue préparatoire de cette tranche constate que les sept deltas `0.0.3` de `alpha.1` à `alpha.6`, fix inclus, forment une chaîne de versions continue depuis `0.0.2` et possèdent chacun un history `PASS` fondé sur la gate opérateur ; `beta.1` n'a pas encore de history. Les propriétaires restent distincts : profil `510` pour les conventions Rust facultatives, règles `210` et `300` pour workflow et headers, documents de `docs/templates/` pour l'adaptation, scripts monotâches pour les contrôles. Leurs validations ciblées ont été acquises dans les tranches précédentes ; `beta.1` vérifie leur intégration et la navigation sans exiger de nouveau build des projets sources.
|
||||
|
||||
Trois écarts documentaires justifient le delta : l'index de `docs/` présentait tous ses templates comme techniques alors que le troisième décrit la reprise de session ; le plan désignait toujours les headers Markdown comme candidat après leur livraison ; la matrice réservait l'audit de liens à `beta/RC/stable` alors que les gates `alpha` l'emploient également sur des changements de navigation. L'index racine ne pointait pas vers le plan actif. Ces renvois sont corrigés dans les documents vivants sans modifier les snapshots ni les choix de version `0.1.0` et d'édition `2024` explicitement présentés comme exemples adaptables dans les manifests et instructions Rust/Cargo. Le résultat de la gate `beta.1` reste à constater par son history séparé.
|
||||
|
||||
### rc.1 — gate de release candidate
|
||||
|
||||
Geler le scope, préparer le changelog et le prompt de la version suivante si la trajectoire est confirmée ; exécuter la gate documentaire et les vérifications ciblées des scripts réellement ajoutés.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
|
||||
<!-- version: 8 -->
|
||||
<!-- version: 9 -->
|
||||
|
||||
# Matrice de validation PGR
|
||||
|
||||
@@ -21,7 +21,7 @@ Les catégories et règles de sélection sont définies dans [`../rules/400-VALI
|
||||
| `PGR-DOC-001` | `AUDIT` | vérifier chemins, rôles et responsabilités des documents touchés | fichiers documentaires | modification documentaire | alpha/beta/RC/stable | faible | opérateur/revue |
|
||||
| `PGR-MD-HEADER-001` | `AUDIT` | `python3 -B scripts/audit_markdown_headers.py <paths...>` | Python 3 | Markdown gouverné modifié | alpha/beta/RC/stable | faible | opérateur/CI |
|
||||
| `PGR-MD-TABLE-001` | `AUDIT` | `python3 -B scripts/audit_markdown_tables.py <paths...>` | Python 3 | table Markdown ajoutée/modifiée | alpha/beta/RC/stable | faible | opérateur/CI |
|
||||
| `PGR-NAV-001` | `AUDIT` | `python3 -B scripts/audit_markdown_links.py <paths...>` | Python 3 | navigation ou réconciliation | beta/RC/stable | faible | opérateur/CI |
|
||||
| `PGR-NAV-001` | `AUDIT` | `python3 -B scripts/audit_markdown_links.py <paths...>` | Python 3 | navigation ou réconciliation | alpha/beta/RC/stable | faible | opérateur/CI |
|
||||
| `PGR-SCOPE-001` | `AUDIT` | vérifier que les documents vivants pointent vers les propriétaires normatifs actuels | documents vivants | réconciliation de phase | beta/RC/stable | faible | revue |
|
||||
| `PGR-STATUS-001` | `CHECK` | `git status --short` | Git | avant fermeture d'une tranche | alpha/beta/RC/stable | faible | opérateur |
|
||||
|
||||
|
||||
Reference in New Issue
Block a user