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

0.0.1-alpha.3.fix.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-27 22:36:07 +02:00
parent 46a159a3bc
commit 6e978bfed8
5 changed files with 450 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
VERSION
View File

@@ -1 +1 @@
0.1.2-alpha.1 0.1.2-alpha.2

259
deltas/0.1.2/alpha.2.md Normal file
View File

@@ -0,0 +1,259 @@
<!-- file: deltas/0.1.2/alpha.2.md -->
<!-- version: 1 -->
# Delta 0.1.2-alpha.2 — révision ciblée Java / Gradle
## Baseline et version
Baseline attendue : commit opérateur de `0.1.2-alpha.1`, réalisé après application de `history/0.1.2/alpha.1.md` avec statut `PASS`.
Le hash de ce commit n'est pas anticipé.
Version avant application :
```text
0.1.2-alpha.1
```
Version après application :
```text
0.1.2-alpha.2
```
## Objet
Appliquer la révision normative ciblée décidée après l'audit Games de `alpha.1` sans transformer les choix locaux du corpus en prescriptions générales.
La tranche précise uniquement :
- la distinction entre JDK de build, niveau source et bytecode/runtime supporté ;
- la possibilité pour un JDK plus récent de cibler explicitement un niveau Java plus ancien ;
- l'ownership naturel de `settings.gradle(.kts)`, du build root, des builds de modules et de `gradle.properties` partagé ;
- la nécessité qu'une politique « Gradle système » possède une contrainte effectivement vérifiée ;
- la séparation entre configuration Gradle partagée portable et état local/machine/secrets ;
- la frontière entre règles Java/Gradle générales et overrides Android.
Les sections Maven sont relues et conservées sans nouvel artefact : Games `0.3.6` ne contient aucun projet Maven permettant de justifier une normalisation supplémentaire.
## Scope
REPLACE :
```text
VERSION
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
docs/rules/520-JAVA_MAVEN_GRADLE.md
```
ADD :
```text
deltas/0.1.2/alpha.2.md
```
DELETE : aucun.
`docs/rules/610-ANDROID.md`, `RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, les autres profils, templates, skeletons, validations, scripts et tests restent inchangés.
Aucun `history/0.1.2/alpha.2.md` n'est anticipé.
## Décisions Java
Le contrat existant est conservé et rendu plus explicite :
```text
JDK de build
!= niveau Java du code source
!= niveau de bytecode/runtime minimal supporté
```
Un JDK de build plus récent peut être utilisé avec une cible Java plus ancienne lorsque cette cible est déclarée explicitement par le build et réellement supportée par la toolchain.
PGR ne rend obligatoire ni `--release`, ni une toolchain Java, ni `sourceCompatibility`/`targetCompatibility` pour tous les builds. Le mécanisme concret dépend de Maven, Gradle, du plugin et du projet ; le contrat important est que la compatibilité ne soit pas une conséquence implicite du JDK actif.
Les versions Games observées restent locales : ni JDK 25 LTS ni Java 17 ne deviennent un minimum PGR.
## Décisions Gradle
### Ownership
La responsabilité est explicitée sans imposer le layout Games :
```text
settings.gradle(.kts)
composition du build
politiques globales de résolution lorsqu'elles existent
contraintes de bootstrap/version devant agir avant les projets
build root
plugins, versions et conventions réellement partagés
build de module
plugins, dépendances, sources, tâches et paramètres locaux au module
gradle.properties partagé
propriétés portables, non secrètes et réellement communes
```
Une logique transverse devenue importante peut être extraite dans un script, build logic ou plugin possédé plutôt que dupliquée. Aucun de ces mécanismes n'est rendu obligatoire.
### Gradle système et Wrapper
Le Wrapper reste conditionnel : il est recommandé lorsqu'il apporte une reproductibilité utile, mais son absence dans Games reste `KEEP-LOCAL` et n'est pas généralisée.
Lorsqu'un projet choisit un Gradle système, sa contrainte de compatibilité doit être effectivement vérifiée par le build ou par une gate exécutée par le projet/CI. Une version écrite uniquement dans la documentation ne suffit pas.
PGR ne reprend ni le minimum `9.6.0` ni l'API `GradleVersion.current()` de Games comme règle universelle. Ils constituent une implémentation valide d'une politique locale, pas la forme obligatoire de la vérification.
### Propriétés et état local
Un `gradle.properties` partagé doit rester portable et non secret. Les chemins machine, credentials, secrets et overrides développeur utilisent un mécanisme local approprié et restent hors Git.
Le version catalog reste optionnel. Groovy DSL et Kotlin DSL restent tous deux reconnus ; le choix Groovy de Games reste `KEEP-LOCAL`.
## Maven
Aucun `pom.xml`, Maven Wrapper ou projet Maven n'existe dans le corpus Games autoritaire. Les sections Maven de `520` ont donc uniquement été relues pour vérifier qu'elles restent cohérentes avec la philosophie générale : centraliser ce qui est réellement commun, ne pas imposer un Wrapper par cérémonie, préférer les gates ciblées et ne pas automatiser `clean` sans besoin.
Aucun template, skeleton, audit ou autre artefact Maven n'est ajouté.
## Frontière Android
`610-ANDROID.md` n'est pas modifié.
Les éléments suivants restent hors scope de `0.1.2` :
```text
AGP et sa matrice de compatibilité
compileSdk / targetSdk / minSdk
NDK et ABI
JNI / AAR / Prefab
applicationId / namespace
manifests / resources
APK / AAB / signing
Variant API Android
devices / AVD / smokes Android
contraintes 16 KB
SDL3 et architecture Games
```
`520` documente seulement qu'une plateforme ou un framework peut imposer un override plus étroit sans transformer cet override en minimum Java/Gradle général.
## Validation opérateur
Après application du history `PASS`, commit/push de `alpha.1`, puis application du présent delta :
```bash
test "$(cat VERSION)" = '0.1.2-alpha.2'
git cat-file -e HEAD:history/0.1.2/alpha.1.md
test -f history/0.1.2/alpha.1.md
test -f deltas/0.1.2/alpha.2.md
test ! -e history/0.1.2/alpha.2.md
grep -A2 '^## Statut$' history/0.1.2/alpha.1.md | grep -Fx 'PASS'
grep -Fx '<!-- version: 2 -->' docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
grep -Fx '<!-- version: 3 -->' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -Fx '<!-- version: 2 -->' docs/rules/610-ANDROID.md
python3 -B -m unittest discover -s tests -v
python3 -B scripts/audit_markdown_headers.py \
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
python3 -B scripts/audit_markdown_tables.py \
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
python3 -B scripts/audit_markdown_links.py \
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
python3 -B - <<'PYGATE'
from pathlib import Path
import re
history = Path('history/0.1.2/alpha.1.md').read_text(encoding='utf-8')
assert re.search(r'## Statut\s+PASS\s', history)
profile = Path('docs/rules/520-JAVA_MAVEN_GRADLE.md').read_text(encoding='utf-8')
for phrase in (
'Un JDK de build plus récent MAY compiler un projet qui cible un niveau source ou bytecode plus ancien',
'Le simple fait qu\'une compilation réussisse avec le JDK actif ne constitue pas une déclaration de compatibilité.',
'composition du build et inclusion des projets',
'plugins, dépendances, sources, tâches et paramètres propres au module',
'propriétés portables, non secrètes et réellement communes au build',
'effectivement vérifiée',
'Une version seulement écrite dans la documentation sans contrôle exécutable n\'est pas une preuve suffisante',
'Son absence dans un corpus particulier ne constitue pas une règle générale.',
):
assert phrase in profile, phrase
for phrase in (
'AGP',
'`minSdk`',
'`targetSdk`',
'NDK',
'ABI/JNI',
'packaging APK/AAB',
'device/AVD',
):
assert phrase in profile, phrase
plan = Path('docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
for phrase in (
'## Décision après `alpha.1`',
'La gate opérateur de `alpha.1` est `PASS`',
'`KEEP-LOCAL` : Groovy DSL, absence de Wrapper dans Games, JDK 25 LTS et cible Java 17',
'`OVERRIDE` : matrice AGP/Gradle/JDK et autres contraintes de plateforme Android',
'`DEFER` : version catalog, skeleton Java/Gradle, audit Python Java/Gradle et nouveaux artefacts Maven',
'`alpha.2` est donc bornée à la révision du profil `520`',
):
assert phrase in plan, phrase
android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
assert android.startswith('<!-- file: docs/rules/610-ANDROID.md -->\n<!-- version: 2 -->')
for path in (
'docs/templates',
'docs/skeletons',
'scripts',
):
assert Path(path).is_dir(), path
print('0.1.2 alpha.2 Java/Gradle audit: clean (JDK/source/bytecode explicit, Gradle ownership and system-version verification clarified, Android boundary preserved)')
PYGATE
git diff --check
git add VERSION \
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md \
docs/rules/520-JAVA_MAVEN_GRADLE.md \
deltas/0.1.2/alpha.2.md
git diff --cached --check
git status --short
```
Le scope indexé attendu avant ajout du history est :
```text
M VERSION
A deltas/0.1.2/alpha.2.md
M docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
M docs/rules/520-JAVA_MAVEN_GRADLE.md
```
La revue qualitative doit confirmer que :
- aucune version JDK ou Java observée dans Games n'est devenue un minimum général ;
- un Gradle système reste permis seulement avec une contrainte réellement vérifiée ;
- le Wrapper reste conditionnel et le Groovy DSL n'est pas privilégié normativement ;
- `gradle.properties` partagé ne devient pas un emplacement pour secrets ou chemins machine ;
- les sections Maven n'ont pas acquis de règle provenant d'un corpus qui n'exerce pas Maven ;
- aucune responsabilité Android n'a été déplacée hors de `610` ou démarrée prématurément dans `0.1.2` ;
- aucun template, skeleton ou audit supplémentaire n'a été créé pour matérialiser artificiellement la release.
## Transition
### PASS
Produire `history/0.1.2/alpha.2.md`, puis préparer `0.1.2-beta.1` pour la réconciliation finale du profil contre Games, `500-LANGUAGES.md`, `610-ANDROID.md` et les règles générales de validation, ainsi que la décision explicite sur l'absence ou la nécessité d'artefacts supplémentaires.
### FAIL
Consigner le diagnostic réel dans `history/0.1.2/alpha.2.md` et rester dans `alpha.2.fix.N` sauf REPLAN justifié. Le fix MUST rester borné à la révision Java/Gradle et ne doit pas absorber `beta.1` ou le scope Android `0.1.3`.

15
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md --> <!-- file: docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md -->
<!-- version: 1 --> <!-- version: 2 -->
# Plan 0.1.2 — réévaluation Java / Maven / Gradle # Plan 0.1.2 — réévaluation Java / Maven / Gradle
@@ -267,6 +267,19 @@ La release doit donc privilégier une correction ciblée plutôt qu'une réécri
Le regroupement actuel Java/Maven/Gradle dans un seul owner est également relu au regard de `500-LANGUAGES.md`. Une scission documentaire ne sera effectuée que si elle réduit réellement les responsabilités ambiguës. En l'absence de corpus Maven, `0.1.2` ne créera pas artificiellement un nouvel owner Maven uniquement pour satisfaire une préférence de découpage. Le regroupement actuel Java/Maven/Gradle dans un seul owner est également relu au regard de `500-LANGUAGES.md`. Une scission documentaire ne sera effectuée que si elle réduit réellement les responsabilités ambiguës. En l'absence de corpus Maven, `0.1.2` ne créera pas artificiellement un nouvel owner Maven uniquement pour satisfaire une préférence de découpage.
## Décision après `alpha.1`
La gate opérateur de `alpha.1` est `PASS` : `48/48` tests Python, audits Markdown propres, audit structurel propre et scope Git conforme. Aucun `alpha.1.fix.N` ni REPLAN n'est requis.
La revue confirme la classification initiale sans l'élargir :
- `ADOPT` : distinction JDK de build / niveau source / bytecode-runtime, ownership Gradle explicite et politique Gradle système seulement si sa contrainte est effectivement vérifiée ;
- `KEEP-LOCAL` : Groovy DSL, absence de Wrapper dans Games, JDK 25 LTS et cible Java 17 ;
- `OVERRIDE` : matrice AGP/Gradle/JDK et autres contraintes de plateforme Android ;
- `DEFER` : version catalog, skeleton Java/Gradle, audit Python Java/Gradle et nouveaux artefacts Maven.
`alpha.2` est donc bornée à la révision du profil `520`. Le profil `610-ANDROID.md` reste inchangé et aucun template, skeleton, audit ou artefact Maven n'est ajouté.
## Mission de `0.1.2` ## Mission de `0.1.2`
La release doit produire un profil Java/Maven/Gradle mieux éprouvé par une implémentation réelle tout en restant générique. La release doit produire un profil Java/Maven/Gradle mieux éprouvé par une implémentation réelle tout en restant générique.

41
docs/rules/520-JAVA_MAVEN_GRADLE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/520-JAVA_MAVEN_GRADLE.md --> <!-- file: docs/rules/520-JAVA_MAVEN_GRADLE.md -->
<!-- version: 2 --> <!-- version: 3 -->
# Profil Java / Maven / Gradle # Profil Java / Maven / Gradle
@@ -9,7 +9,9 @@ Ce document possède les règles réutilisables propres au langage Java et à se
Il complète [`500-LANGUAGES.md`](500-LANGUAGES.md). Les règles de gouvernance, documentation et validation restent possédées par leurs familles générales. Il complète [`500-LANGUAGES.md`](500-LANGUAGES.md). Les règles de gouvernance, documentation et validation restent possédées par leurs familles générales.
Android n'est pas défini ici. Une contrainte AGP, SDK Android, `minSdk`, `targetSdk`, `versionCode`, signing ou packaging APK/AAB appartient au profil plateforme Android et peut surcharger localement les règles Gradle ou JDK de ce document. Android n'est pas défini ici. Une contrainte AGP, SDK Android, `minSdk`, `targetSdk`, `versionCode`, NDK, ABI/JNI, `applicationId`, `namespace`, manifest/resources, signing, packaging APK/AAB, device/AVD ou smoke Android appartient au profil plateforme Android ou à un owner spécialisé et peut raffiner localement les règles Gradle ou JDK de ce document.
Une compatibilité Gradle/JDK plus étroite imposée par une plateforme ou un framework reste un override local. Elle MUST NOT être remontée comme minimum Java/Gradle général uniquement parce qu'un projet l'exerce.
## Politique JDK et compatibilité Java ## Politique JDK et compatibilité Java
@@ -32,6 +34,10 @@ niveau de bytecode/runtime minimal supporté
Le niveau Java ciblé MUST être déclaré explicitement par le build lorsqu'il affecte la compatibilité. Il ne doit pas dépendre implicitement du JDK actif sur la machine. Le niveau Java ciblé MUST être déclaré explicitement par le build lorsqu'il affecte la compatibilité. Il ne doit pas dépendre implicitement du JDK actif sur la machine.
Un JDK de build plus récent MAY compiler un projet qui cible un niveau source ou bytecode plus ancien lorsque le build exprime explicitement cette cible et que la toolchain choisie la supporte. Le simple fait qu'une compilation réussisse avec le JDK actif ne constitue pas une déclaration de compatibilité.
Selon le build, ce contrat peut être matérialisé par une option de release, une toolchain, des niveaux source/target ou un mécanisme équivalent. PGR ne généralise pas un mécanisme particulier à tous les builds Java.
Une hausse de la version Java minimale supportée constitue un changement de compatibilité et MUST être justifiée comme telle. Une hausse de la version Java minimale supportée constitue un changement de compatibilité et MUST être justifiée comme telle.
PGR MUST NOT imposer une version exacte de JDK uniquement parce qu'un corpus historique ou un autre projet utilise cette version. PGR MUST NOT imposer une version exacte de JDK uniquement parce qu'un corpus historique ou un autre projet utilise cette version.
@@ -225,16 +231,29 @@ Les gates globales telles que le reactor complet, `verify` ou le packaging de to
## Gradle — ownership du build ## Gradle — ownership du build
Un projet Gradle SHOULD centraliser la configuration commune au niveau root lorsqu'elle est réellement partagée. Un projet Gradle SHOULD centraliser la configuration commune lorsqu'elle est réellement partagée, sans déplacer au root une responsabilité qui appartient à un module particulier.
Selon le DSL retenu, les propriétaires typiques sont : Selon le DSL retenu, les propriétaires naturels sont typiquement :
```text ```text
settings.gradle / settings.gradle.kts settings.gradle / settings.gradle.kts
build.gradle / build.gradle.kts -> composition du build et inclusion des projets
gradle.properties -> politique de résolution des plugins/dépendances lorsqu'elle est réellement globale
-> contraintes de bootstrap ou de version Gradle lorsqu'elles doivent s'appliquer avant la configuration des projets
build.gradle / build.gradle.kts root
-> plugins, versions ou conventions réellement partagés
-> configuration transverse qui ne doit pas être recopiée dans chaque sous-projet
build.gradle / build.gradle.kts de module
-> plugins, dépendances, sources, tâches et paramètres propres au module
gradle.properties partagé
-> propriétés portables, non secrètes et réellement communes au build
``` ```
Cette répartition décrit des responsabilités, pas un layout obligatoire. Un build simple MAY légitimement porter moins de fichiers, et une logique transverse devenue importante MAY être extraite dans un script, build logic ou plugin clairement possédé plutôt que dupliquée.
Les sous-projets SHOULD NOT recopier sans nécessité : Les sous-projets SHOULD NOT recopier sans nécessité :
- la compatibilité Java ; - la compatibilité Java ;
@@ -243,6 +262,8 @@ Les sous-projets SHOULD NOT recopier sans nécessité :
- les contraintes de dépendances ; - les contraintes de dépendances ;
- les configurations de tests communes. - les configurations de tests communes.
Les chemins machine, credentials, secrets et overrides propres à un développeur MUST NOT être introduits dans un `gradle.properties` partagé. Ils doivent utiliser un mécanisme local approprié, par exemple propriétés utilisateur Gradle, variables d'environnement ou fichier local explicitement ignoré lorsque la toolchain en possède un.
Un version catalog tel que `gradle/libs.versions.toml` MAY être utilisé lorsque la taille du projet le justifie. PGR MUST NOT l'imposer pour un projet qui n'en tire aucun bénéfice réel. Un version catalog tel que `gradle/libs.versions.toml` MAY être utilisé lorsque la taille du projet le justifie. PGR MUST NOT l'imposer pour un projet qui n'en tire aucun bénéfice réel.
## Gradle Wrapper et version de Gradle ## Gradle Wrapper et version de Gradle
@@ -258,7 +279,11 @@ latest compatible
Le projet MUST choisir la forme la moins restrictive qui prouve réellement sa compatibilité. Le projet MUST choisir la forme la moins restrictive qui prouve réellement sa compatibilité.
Un Gradle Wrapper SHOULD être versionné lorsqu'il apporte une reproductibilité utile pour la distribution, la CI ou l'onboarding. Un projet contrôlé MAY utiliser un Gradle système si sa contrainte de compatibilité est explicitement vérifiée. Un Gradle Wrapper SHOULD être versionné lorsqu'il apporte une reproductibilité utile pour la distribution, la CI ou l'onboarding. Son absence dans un corpus particulier ne constitue pas une règle générale.
Un projet contrôlé MAY utiliser un Gradle système si sa contrainte de compatibilité est **effectivement vérifiée** par le build ou par une gate exécutée par le projet/CI. Une version seulement écrite dans la documentation sans contrôle exécutable n'est pas une preuve suffisante de compatibilité.
La vérification peut être portée par `settings.gradle(.kts)`, par une logique de bootstrap ou par une gate dédiée adaptée au projet. PGR n'impose pas l'API Gradle exacte utilisée pour cette vérification.
Une plateforme ou un framework plus spécifique MAY imposer une contrainte plus étroite. Cette contrainte ne se propage jamais implicitement aux autres projets Gradle. Une plateforme ou un framework plus spécifique MAY imposer une contrainte plus étroite. Cette contrainte ne se propage jamais implicitement aux autres projets Gradle.
@@ -303,7 +328,7 @@ Les métadonnées IDE spécifiques à une machine restent ignorées sauf excepti
Les wrappers retenus sont une exception volontaire : ils peuvent être générés par l'outil, mais leurs fichiers nécessaires au bootstrap reproductible sont versionnés. Les wrappers retenus sont une exception volontaire : ils peuvent être générés par l'outil, mais leurs fichiers nécessaires au bootstrap reproductible sont versionnés.
Les fichiers de configuration locale contenant chemins machine, credentials ou overrides développeur restent hors Git. Un template est ajouté uniquement lorsqu'un utilisateur doit réellement préparer une valeur non régénérée automatiquement. Les fichiers de configuration locale contenant chemins machine, credentials, secrets ou overrides développeur restent hors Git. Cette règle s'applique également aux propriétés Gradle locales : une propriété partagée doit rester portable et non secrète. Un template est ajouté uniquement lorsqu'un utilisateur doit réellement préparer une valeur non régénérée automatiquement.
## Validation et futurs audits PGR ## Validation et futurs audits PGR

143
history/0.0.1/alpha.3.fix.1.md Normal file
View File

@@ -0,0 +1,143 @@
<!-- file: history/0.0.1/alpha.3.fix.1.md -->
<!-- version: 1 -->
# History 0.0.1-alpha.3.fix.1 — correction `SourceId` et précision Web/Maud
## Statut
FAIL
La gate opérateur de `0.0.1-alpha.3.fix.1` exécutée le `2026-09-27` confirme la correction de `SourceId` et le passage des tests ciblés, mais Clippy strict échoue sur la documentation manquante des variantes publiques de `ContentFamily`.
## Baseline opérateur
La tranche `alpha.3` `FAIL` a été historisée, committée et poussée avant application du fix :
```text
history/0.0.1/alpha.3.md = FAIL
commit 6b6bdcf
message 0.0.1-alpha.3
branch master
push origin/master PASS
status clean après push
```
Le push observé a avancé `origin/master` de `8cd187b` à `6b6bdcf`.
## Correction `SourceId`
La vérification ciblée confirme que le fix attendu est présent :
```text
return Ok(Self(value.to_owned()));
```
L'erreur de compilation `E0423` observée sur `alpha.3` n'est plus reproduite.
## Structure et audits
Les contrôles suivants sont propres :
```text
VERSION = 0.0.1-alpha.3.fix.1
git diff --check = clean
cargo fmt --all -- --check = PASS
Rust blank-line audit: clean (8 file(s))
Rust item-spacing audit: clean (8 file(s))
Rust module-order audit: clean (8 file(s))
Rust trait-import-block audit: clean (8 file(s))
Rust re-export-block audit: clean (8 file(s))
Rust export completeness audit: 0 candidate(s) across 3 package(s)
```
## `cargo check`
`cargo check --workspace` termine avec succès pour les trois crates.
Il émet cependant quatre warnings `missing_docs` dans :
```text
crates/knowledge-domain-lib/src/content_family.rs
```
sur les variantes publiques :
```text
Pgr
Howto
Snippet
ProjectLocal
```
La politique workspace déclare `missing_docs = "warn"`, donc ces diagnostics restent des warnings sous `cargo check`.
## Échec Clippy strict
La commande :
```text
cargo clippy --workspace --all-targets --all-features -- -D warnings
```
transforme les warnings `missing_docs` en erreurs, comme attendu par la gate stricte.
Les quatre variantes publiques non documentées empêchent donc le `PASS` de tranche.
Le défaut ne doit pas être contourné par un `allow(missing_docs)` ni par une réduction de la politique de lint ; les items publics doivent être documentés.
## Tests ciblés
Les tests passent malgré les warnings documentaires :
```text
knowledge-domain-lib : 3 passed; 0 failed
knowledge-git-api : 1 passed; 0 failed
knowledge-sync-api : 1 passed; 0 failed
```
Les preuves confirment notamment :
- construction valide de `SourceId` ;
- rejet d'un identifiant vide ;
- absence de limite codée à trois repositories ;
- indépendance du contrat Git vis-à-vis d'une forge ;
- caractère non autoritaire de `ExternalSignal`.
## Scope Git observé
`git diff --cached --check` est propre.
Le staging transmis avant ajout du présent history contient :
```text
M CHANGELOG.md
M Cargo.lock
M Cargo.toml
M README.md
M ROADMAP.md
M RULES.md
M VERSION
M crates/knowledge-domain-lib/src/source.rs
M crates/knowledge-domain-lib/src/unit_tests.rs
A deltas/0.0.1/alpha.3.fix.1.md
M docs/000-README.md
M docs/architecture/001-PROJECT_PROFILE.md
M docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md
M docs/plans/001-V0_0_1_FOUNDATION_PLAN.md
A docs/studies/002-ACTIX_MAUD_VITE_CORPUS_STUDY.md
M docs/validation/001-VALIDATION_MATRIX.md
```
Ce scope est cohérent avec le fix annoncé et le `Cargo.lock` régénéré par Cargo.
## Décision
`0.0.1-alpha.3.fix.1` est `FAIL`.
La transition autorisée est :
```text
0.0.1-alpha.3.fix.2
```
Le second fix doit rester minimal : documenter les quatre variantes publiques de `ContentFamily`, conserver la politique `missing_docs`, puis rejouer `cargo check`, Clippy strict et les trois suites ciblées. Aucun élargissement fonctionnel n'est autorisé.