Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.0.2-beta.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-23 15:26:40 +02:00
parent ead2e879ef
commit 0719955875
8 changed files with 475 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
docs/architecture/003-RULE_PROFILE_MODEL.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/003-RULE_PROFILE_MODEL.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Modèle de profils de règles PGR
@@ -156,6 +156,46 @@ Les familles `700 — frameworks` et `800 — architecture` restent réservées
Le modèle architectural présent n'oblige pas à créer des fichiers placeholders pour les profils différés.
## Réconciliation des profils matérialisés en `0.0.2`
La première implémentation réelle du modèle comporte trois profils :
```text
510 — Rust / Cargo
520 — Java / Maven / Gradle
610 — Android
```
Leur composition observée confirme que la taxonomie n'a pas besoin d'un profil composite supplémentaire dans `0.0.2`.
Un projet Rust ordinaire peut appliquer :
```text
GENERAL
+ 500
+ 510
```
Un projet Java/Gradle Android peut appliquer :
```text
GENERAL
+ 500
+ 520
+ 600
+ 610
```
La forme condensée de cette composition est `GENERAL + 500 + 520 + 600 + 610`.
Le profil Android raffine localement les contraintes JDK/Gradle lorsque la matrice AGP/Gradle/JDK l'exige ; cette spécialisation ne modifie pas le profil Java/Gradle hors Android.
Aucune contradiction non résolue de même niveau n'a été identifiée entre les profils `510`, `520` et `610`.
La revue beta n'a pas justifié l'activation d'une famille `700 — frameworks` ou `800 — architecture`. Les règles réellement transversales rencontrées restent déjà possédées par `RULES.md`, les familles existantes ou le présent modèle architectural.
La réconciliation a également confirmé qu'une règle générale ne doit pas être recopiée comme si le profil spécifique en devenait propriétaire. Un profil peut rappeler une conséquence spécifique au contexte, mais doit référencer l'owner général lorsque le contrat lui-même n'est pas spécialisé.
## Instanciation future
Les futures skeleton specifications sélectionneront les profils applicables et recopieront leurs règles pertinentes dans la baseline locale du projet créé.

28
docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Plan 0.0.2 — premiers profils de règles technologiques
@@ -149,6 +149,30 @@ Réconcilier les profils créés, vérifier les scopes/overrides, éliminer les
Aucun nouveau profil technologique majeur ne doit être introduit en beta sans REPLAN.
État observé à l'entrée de beta :
```text
alpha.1 FAIL cadrage initial corrigé par fix.1
alpha.1.fix.1 PASS sizing réduit + premier audit Markdown
alpha.2 PASS modèle de profils et familles 500/600
alpha.3 PASS Rust / Cargo
alpha.4 FAIL incohérence locale entre texte et grep de gate
alpha.4.fix.1 PASS cohérence de gate rétablie
alpha.5 PASS Android
```
Cette synthèse décrit uniquement la trajectoire du plan ; les preuves détaillées restent dans les histories immuables correspondants.
La réconciliation beta confirme comme owners technologiques de `0.0.2` :
```text
510-RUST_CARGO.md
520-JAVA_MAVEN_GRADLE.md
610-ANDROID.md
```
Aucune famille `700` ou `800` n'est activée. Aucun profil différé n'est ramené dans le scope.
### rc.1 — Rule profiles release candidate
Geler le scope, préparer l'entrée candidate `0.0.2` du changelog, finaliser le prompt `0.0.3` et exécuter la gate documentaire complète applicable.
@@ -187,7 +211,7 @@ Un nouveau besoin critique, plusieurs fixes consécutifs ou une évolution qui r
- créer les skeleton specifications complètes réservées à `0.0.4` ;
- créer un générateur ;
- réécrire KSP ou `sasedev-games` ;
- multiplier les audits spécialisés ; `alpha.1.fix.1` introduit uniquement l'audit Markdown monotâche justifié par un défaut réellement observé ;
- multiplier les audits spécialisés ; `0.0.2` ne matérialise que des audits génériques monotâches justifiés par un besoin réel (`tables` puis `liens locaux`), sans audit technologique artificiel ;
- transformer les exemples de technologies en dépendances du dépôt PGR ;
- modifier rétroactivement les deltas/histories `0.0.1` pour refléter des règles apparues après leur émission.

6
docs/rules/610-ANDROID.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/610-ANDROID.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Profil Android
@@ -147,9 +147,9 @@ La même politique s'applique aux fichiers locaux analogues tels que `keystore.p
## Signing et secrets
Les secrets de signature ne sont jamais versionnés.
L'interdiction générale de versionner ou distribuer des secrets reste possédée par `RULES.md`. Le profil Android ajoute uniquement les conséquences propres au signing de cette plateforme.
Sont notamment interdits dans Git, les deltas, histories, prompts et documentation :
Dans le scope Android, les éléments suivants sont notamment des secrets ou artefacts privés soumis à cette interdiction :
```text
release keystore

28
docs/validation/001-VALIDATION_MATRIX.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
<!-- version: 5 -->
<!-- version: 6 -->
# Matrice de validation PGR
@@ -13,20 +13,24 @@ Les catégories et règles de sélection sont définies dans [`../rules/400-VALI
## Contrôles actifs
| ID | Catégorie | Commande / contrôle | Prérequis | Trigger | Phase | Coût | Acteur |
|--------------------|-----------|------------------------------------------------------------------------------------------|------------------------|---------------------------------|----------------------|--------|-----------------|
| `PGR-GIT-001` | `CHECK` | `git diff --check` ou `git diff --cached --check` selon l'état de l'index | Git | toute modification suivie | alpha/beta/RC/stable | faible | opérateur |
| `PGR-VERSION-001` | `CHECK` | comparer `VERSION` à la version attendue par le delta courant | fichier `VERSION` | changement de tranche/version | alpha/beta/RC/stable | faible | opérateur |
| `PGR-LAYOUT-001` | `AUDIT` | comparer les fichiers ajoutés/remplacés/supprimés au scope déclaré du delta | scope du delta | changement de structure | alpha/beta/RC/stable | faible | opérateur/revue |
| `PGR-DOC-001` | `AUDIT` | vérifier headers `file/version`, chemins, liens et responsabilités des documents touchés | fichiers documentaires | modification documentaire | alpha/beta/RC/stable | faible | opérateur/revue |
| `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` | vérifier que les points d'entrée et liens canoniques ciblent des fichiers existants | index et docs racine | navigation ou réconciliation | beta/RC/stable | faible | opérateur/revue |
| `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 |
| ID | Catégorie | Commande / contrôle | Prérequis | Trigger | Phase | Coût | Acteur |
|--------------------|-----------|--------------------------------------------------------------------------------------|------------------------|---------------------------------|----------------------|--------|-----------------|
| `PGR-GIT-001` | `CHECK` | `git diff --check` ou `git diff --cached --check` selon l'état de l'index | Git | toute modification suivie | alpha/beta/RC/stable | faible | opérateur |
| `PGR-VERSION-001` | `CHECK` | comparer `VERSION` à la version attendue par le delta courant | fichier `VERSION` | changement de tranche/version | alpha/beta/RC/stable | faible | opérateur |
| `PGR-LAYOUT-001` | `AUDIT` | comparer les fichiers ajoutés/remplacés/supprimés au scope déclaré du delta | scope du delta | changement de structure | alpha/beta/RC/stable | faible | opérateur/revue |
| `PGR-DOC-001` | `AUDIT` | vérifier headers `file/version`, chemins et responsabilités des documents touchés | fichiers documentaires | modification documentaire | alpha/beta/RC/stable | faible | opérateur/revue |
| `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-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 |
Un contrôle manuel peut rester dans la matrice lorsqu'aucun audit automatisé fiable n'existe encore. PGR SHOULD automatiser uniquement les propriétés stables et objectivement contrôlables.
`PGR-MD-TABLE-001` est le premier audit matérialisé dans PGR lui-même. Il reste volontairement monotâche : il contrôle uniquement la structure et l'alignement source des tableaux Markdown, sans vérifier les blank lines, les headers, les liens ou d'autres règles documentaires.
`PGR-MD-TABLE-001` reste volontairement monotâche : il contrôle uniquement la structure et l'alignement source des tableaux Markdown.
`PGR-NAV-001` est automatisé séparément par `audit_markdown_links.py`. Il vérifie uniquement l'existence des cibles de liens Markdown locaux inline, sans contrôler les anchors, les headers, les responsabilités documentaires ou la forme des tableaux.
PGR préfère plusieurs audits simples avec une responsabilité identifiable à un script unique qui agrège des règles indépendantes.
## Politique Eclipse actuelle