pgr/deltas/0.0.2/alpha.2.md

<!-- file: deltas/0.0.2/alpha.2.md -->
<!-- version: 1 -->

# Delta 0.0.2-alpha.2 — rule profile model

## Baseline

Version attendue avant application :

```text
0.0.2-alpha.1.fix.1
```

Le history `history/0.0.2/alpha.1.fix.1.md` MUST avoir été appliqué et committé avant ce delta.

Version après application :

```text
0.0.2-alpha.2
```

## Objet

Formaliser le modèle de profils PGR avant toute consolidation technologique détaillée.

Cette tranche définit :

- la notion de profil et son propriétaire normatif ;
- l'applicabilité d'un profil à partir de faits réels du projet ;
- la composition du général vers le spécifique ;
- la résolution des overrides et des conflits ;
- la non-duplication des règles héritées ;
- le traitement des spécialisations internes et profils composites ;
- la distinction entre règle décidée et choix encore ouvert ;
- les contrats communs des familles `500 — languages / ecosystems` et `600 — platforms` nécessaires au scope réduit de `0.0.2`.

Aucune règle Rust, Cargo, Java, Maven, Gradle ou Android détaillée n'est encore introduite.

## Modèle retenu

La composition de référence reste :

```text
GENERAL
    ↓
ecosystem / language
    ↓
platform
    ↓
framework
    ↓
project type / subsystem
    ↓
project-specific
    ↓
explicit exception
```

Chaque règle durable possède un seul owner normatif. Les profils spécifiques héritent des règles générales et ne les recopient pas.

Une contradiction volontaire doit être un override explicite, borné et justifié. Deux règles applicables de même niveau qui se contredisent sans relation explicite constituent un défaut à résoudre ; l'ordre des fichiers ne crée aucune priorité.

Les profils composites ne sont créés que si l'intersection de plusieurs profils possède un contrat propre réel. La simple coexistence de deux technologies ne suffit pas.

## Familles activées

`alpha.2` active uniquement les familles nécessaires aux prochaines tranches :

```text
500 — languages / ecosystems
600 — platforms
```

Les familles suivantes restent réservées et non matérialisées :

```text
700 — frameworks
800 — architecture
```

Les règles project-specific continuent d'appartenir au dépôt qui les possède ; PGR ne crée pas de placeholder `900` sans contenu réel.

## Scope

REPLACE :

```text
VERSION
RULES.md
docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
docs/rules/000-README.md
```

ADD :

```text
docs/architecture/003-RULE_PROFILE_MODEL.md
docs/rules/500-LANGUAGES.md
docs/rules/600-PLATFORMS.md
deltas/0.0.2/alpha.2.md
```

DELETE : aucun.

Aucun manifest de suppression n'est nécessaire.

## Validation opérateur

```bash
test "$(cat VERSION)" = "0.0.2-alpha.2"

test -f docs/architecture/003-RULE_PROFILE_MODEL.md
test -f docs/rules/500-LANGUAGES.md
test -f docs/rules/600-PLATFORMS.md
test -f deltas/0.0.2/alpha.2.md

grep -F 'Toute règle durable doit posséder un seul propriétaire normatif canonique.' docs/architecture/003-RULE_PROFILE_MODEL.md
grep -F "L'ordre des fichiers dans un répertoire ne crée jamais une priorité normative." docs/architecture/003-RULE_PROFILE_MODEL.md
grep -F 'PGR ne crée pas automatiquement un profil composite pour chaque combinaison possible.' docs/architecture/003-RULE_PROFILE_MODEL.md

grep -F 'Les profils spécifiques utilisent la plage `510` à `599`.' docs/rules/500-LANGUAGES.md
grep -F 'Une spécialisation de build tool ne devient pas une règle du langage entier.' docs/rules/500-LANGUAGES.md

grep -F 'La modernité de la toolchain de build et la version minimale du runtime ou de la target sont deux décisions distinctes.' docs/rules/600-PLATFORMS.md
grep -F 'Les profils spécifiques utilisent la plage `610` à `699`.' docs/rules/600-PLATFORMS.md

grep -F '500-LANGUAGES.md' RULES.md
grep -F '600-PLATFORMS.md' RULES.md
grep -F '003-RULE_PROFILE_MODEL.md' docs/rules/000-README.md
grep -F 'famille `500 — languages / ecosystems`' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md

python3 -B scripts/audit_markdown_tables.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts

git diff --check

git add VERSION RULES.md \
    docs/architecture/003-RULE_PROFILE_MODEL.md \
    docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md \
    docs/rules/000-README.md \
    docs/rules/500-LANGUAGES.md \
    docs/rules/600-PLATFORMS.md \
    deltas/0.0.2/alpha.2.md

git diff --cached --check

git status --short
```

La sortie attendue avant ajout du history est :

```text
M  RULES.md
M  VERSION
A  deltas/0.0.2/alpha.2.md
A  docs/architecture/003-RULE_PROFILE_MODEL.md
M  docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
M  docs/rules/000-README.md
A  docs/rules/500-LANGUAGES.md
A  docs/rules/600-PLATFORMS.md
```

Revue opérateur complémentaire :

- confirmer que le modèle permet de déterminer où une règle doit être possédée sans utiliser l'ordre des fichiers comme priorité ;
- confirmer que les spécialisations Maven/Gradle pourront rester locales à Java/build et qu'une contrainte Android ne contaminera pas Java en général ;
- confirmer que les familles `700` et `800` ne sont pas créées prématurément ;
- confirmer qu'aucune règle technologique détaillée prévue pour `alpha.3+` n'a été absorbée dans cette tranche.

## Transition

### PASS

Créer et appliquer séparément `history/0.0.2/alpha.2.md`, committer la tranche, puis préparer `0.0.2-alpha.3` consacré au premier profil réel `Rust / Cargo`.

`alpha.3` reste le point de mesure prévu par le plan : si le coût réel d'un profil complet invalide le sizing, effectuer un REPLAN avant `alpha.4`.

### FAIL

Rester dans `0.0.2-alpha.2.fix.M` tant que le modèle de profil lui-même n'est pas cohérent. Ne pas commencer le profil Rust/Cargo sur un modèle non validé.