0.1.5-alpha.1
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 27 -->
|
||||
<!-- version: 28 -->
|
||||
|
||||
# Project Governance Rules
|
||||
|
||||
@@ -11,7 +11,7 @@ Le dépôt officiel est `https://git.sasedev.com/Sasedev/pgr`.
|
||||
|
||||
## Statut
|
||||
|
||||
PGR a clôturé sa phase de fondation `0.0.x` et dispose désormais d’une suite de baselines stables `0.1.x`. La stable `0.1.4` réexamine le domaine Tauri contre les corpus Games/KSP, consolide l’owner `710`, matérialise le skeleton organisationnel `004-TAURI.md`, confirme qu’aucun template technique ni contrat de validation Tauri séparé n’est justifié et ajoute un audit réutilisable d’hygiène texte. La revue d’horizon de fermeture réserve `0.1.5` à la sémantique normative, à l’autonomie des projets après adoption et à la frontière PGR / SaseDev Knowledge avant les adoptions Games `0.1.6` et KSP `0.1.7`.
|
||||
La stable autoritaire courante reste `0.1.4`. Le travail `0.1.5-alpha.1` ouvre maintenant l’audit transversal décidé par sa revue d’horizon : clarification de la force de `MUST / SHOULD / MAY`, autonomie des projets après instanciation/adoption et frontière PGR / SaseDev Knowledge. Cette tranche d’ouverture inventorie les ambiguïtés et fixe les owners à réconcilier sans modifier encore les règles normatives ; les adoptions Games `0.1.6`, KSP `0.1.7` et les audits Rust/Clippy `0.1.8` restent hors scope.
|
||||
|
||||
La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` établit la gouvernance normative et documentaire de PGR lui-même. La release `0.0.2` ajoute les premiers profils réutilisables Rust/Cargo, Java/Maven/Gradle et Android, ainsi que deux audits Markdown. La release `0.0.3` fournit les premiers modèles Rust/Cargo, deux audits de style Rust facultatifs, l'audit des headers Markdown et la spécification du message manuel de reprise. La release `0.0.4` définit le contrat transversal des skeleton specifications, ajoute une fondation composable de gouvernance locale et une première spécialisation Rust/Cargo workspace fondée sur les profils `500 + 510` et les cinq templates existants. La release `0.0.5` réconcilie PGR avec les baselines réelles de `khadhroony-solana-project` et `sasedev-games` : prompts versionnés, contrats documentaires locaux, lifecycle inter-release, profil Rust strict et audits monotâches, premier profil Tauri 2 et décision explicite de différer son skeleton complet jusqu'à matérialisation d'owners Web suffisants. La release `0.1.0` stabilise la première baseline réutilisable : adoption `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, skeletons/templates Rust/Cargo exercés par dry-run, clôture `rel.N`, handoff opérateur automatique et trajectoire `0.1.1` à `0.1.7` issue d'une revue d'horizon explicite. La release `0.1.1` stabilise la fondation frontend Web : owners indépendants TypeScript/package/Vite/CSS-Sass, déclarations de types externes conditionnelles, package manager neutre, validation frontend indépendante du host et skeleton Web composable, tout en conservant le skeleton Tauri en `DEFER` jusqu’à son réexamen `0.1.4`. La release `0.1.2` stabilise trois owners indépendants `520-JAVA`, `521-MAVEN` et `522-GRADLE`, clarifie JDK/source/bytecode et l'ownership Gradle, conserve Maven cohérent sans corpus artificiel et maintient les responsabilités Android dans `610-ANDROID.md` pour leur réévaluation distincte en `0.1.3`. La release `0.1.3` stabilise le profil Android générique : séparation des responsabilités SDK et identité applicative, contraintes natives conditionnelles, Android Lint explicite, niveaux de tests distincts, frontières APK/AAB et compatibilité 16 KB liée au code natif et au canal de distribution, sans imposer les versions ou ABI propres à Games. La release `0.1.4` stabilise le domaine Tauri : owner `710` recentré sur host/orchestration/ACL/plugins, skeleton `004` composable avec Rust/Cargo et Web, absence assumée de template technique générique ou de validation Tauri redondante, audit d’hygiène texte réutilisable et handoff vers `0.1.5` pour clarifier la sémantique normative et l’autonomie des projets.
|
||||
|
||||
@@ -34,6 +34,7 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é
|
||||
- [`docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md`](docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md) — plan historique de la stable `0.1.2` : réévaluation Games, scission Java/Maven/Gradle et maintien d'Android hors scope ;
|
||||
- [`docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`](docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md) — plan historique de la stable Android `0.1.3`, fondée sur Games avec classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
|
||||
- [`docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md`](docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md) — plan historique de la stable Tauri `0.1.4`, du réexamen Games/KSP au skeleton `004`, à la décision d’artefacts et à la revue d’horizon ;
|
||||
- [`docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan actif `0.1.5` : sémantique normative, autonomie locale, frontière PGR / Knowledge et réconciliation transversale avant les adoptions Games/KSP ;
|
||||
- [`docs/skeletons/004-TAURI.md`](docs/skeletons/004-TAURI.md) — specialization Tauri 2 composable, sans template technique universel ni defaults de capabilities/plugins/fenêtres/bundles ;
|
||||
- [`docs/studies/001-KSP_GAMES_RECONCILIATION.md`](docs/studies/001-KSP_GAMES_RECONCILIATION.md) — étude de réconciliation et classification des écarts entre PGR, KSP et Games ;
|
||||
- [`docs/skeletons/000-README.md`](docs/skeletons/000-README.md) — index des skeleton specifications et de leur contrat de composition ;
|
||||
|
||||
222
deltas/0.1.5/alpha.1.md
Normal file
222
deltas/0.1.5/alpha.1.md
Normal file
@@ -0,0 +1,222 @@
|
||||
<!-- file: deltas/0.1.5/alpha.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.1.5-alpha.1 — intake, audit transversal et plan d’autonomie
|
||||
|
||||
## Objet
|
||||
|
||||
Ouvrir `0.1.5` conformément à `prompts/011-V0_1_5_START_PROMPT.md`, rejouer la stable `0.1.4`, conserver son histoire réelle et matérialiser l’inventaire des ambiguïtés avant toute modification normative.
|
||||
|
||||
La tranche ne modifie aucune règle, aucun skeleton ni template normatif. Elle ne commence ni l’adoption Games `0.1.6`, ni l’adoption KSP `0.1.7`, ni les audits Rust/Clippy `0.1.8`.
|
||||
|
||||
## Sources vérifiées avant préparation
|
||||
|
||||
```text
|
||||
pgr-v0.1.4(1).zip
|
||||
SHA-256 9f85ac16a5ad9fd788df51883b6ebf592602c5189d94e338a86edab2288b8f77
|
||||
CRC PASS
|
||||
contenu 310 fichiers + 44 répertoires sous pgr/
|
||||
|
||||
pgr-0.1.4-publish.001-report.md
|
||||
SHA-256 bb0c27a69e78037328d13c7be8df255d17f55e1392f1bc1b6121dd32b6fb07da
|
||||
status PASS
|
||||
stable c41b69badfd10ef9500d4cc4061fc6f66644352c
|
||||
```
|
||||
|
||||
Le SHA de l’archive reçue correspond au SHA canonique vérifié lors de la publication post-tag. L’absence de `.git` dans l’archive est normale pour l’export du tag et n’est pas interprétée comme un défaut.
|
||||
|
||||
## Replay de la stable
|
||||
|
||||
La baseline extraite a été vérifiée avant toute préparation de delta :
|
||||
|
||||
```text
|
||||
VERSION 0.1.4
|
||||
tests Python 55/55 PASS
|
||||
hygiène texte 309 fichiers PASS
|
||||
headers Markdown 282 fichiers PASS
|
||||
tables Markdown 11 tables / 282 fichiers PASS
|
||||
liens Markdown 357 liens locaux / 282 fichiers PASS
|
||||
JSON 2 fichiers parsés
|
||||
TOML 5 fichiers parsés
|
||||
deltas 103
|
||||
histories 103
|
||||
appariement historique exact
|
||||
```
|
||||
|
||||
La séquence `0.1.4` publiée est explicitement conservée :
|
||||
|
||||
```text
|
||||
alpha.1 PASS
|
||||
alpha.2 FAIL
|
||||
alpha.2.fix.1 PASS
|
||||
alpha.3 PASS
|
||||
beta.1 PASS
|
||||
rc.1 PASS
|
||||
rel.1 PASS
|
||||
```
|
||||
|
||||
Aucun history n’est réécrit pour rendre la chronologie artificiellement linéaire.
|
||||
|
||||
## Résultats de l’audit transversal
|
||||
|
||||
Le corpus courant contient `29` fichiers avec au moins un `SHOULD` ou `SHOULD NOT`, pour `242` occurrences brutes. Cette volumétrie confirme qu’une conversion mécanique serait incorrecte : la majorité des recommandations restent valides et doivent hériter d’un contrat global clarifié.
|
||||
|
||||
Les ambiguïtés confirmées sont consignées dans `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`.
|
||||
|
||||
### Force normative
|
||||
|
||||
- `RULES.md` peut faire comprendre qu’un écart à `SHOULD` doit être systématiquement justifié ;
|
||||
- `230-ADOPTION.md` peut faire comprendre qu’un choix différent d’un `SHOULD` nécessite automatiquement `OVERRIDE` ;
|
||||
- `400-VALIDATION.md` ne protège pas encore explicitement une gate contre l’échec fondé sur le seul écart à une recommandation ;
|
||||
- plusieurs owners Web matérialisent cette ambiguïté par une justification ou un `OVERRIDE` rendu obligatoire autour d’une recommandation.
|
||||
|
||||
### Autonomie
|
||||
|
||||
Les objectifs, l’architecture, les skeletons et les patterns d’adoption contiennent déjà le principe d’autonomie, mais le contrat « baseline locale = autorité des sessions/releases suivantes » n’est pas encore propagé explicitement partout. PGR doit aussi cesser d’être interprétable comme upstream documentaire vivant après l’adoption.
|
||||
|
||||
`210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` sont classés `KEEP / REVIEW` à ce stade : ils utilisent déjà la baseline autoritaire du projet courant plutôt qu’une version PGR externe.
|
||||
|
||||
### Frontière PGR / Knowledge
|
||||
|
||||
`001-PROJECT_OBJECTIVES.md` et `002-GOVERNANCE_ARCHITECTURE.md` parlent encore de skeletons comme de « recettes Markdown ». Cette terminologie brouille la frontière décidée en `0.1.4`, où les recettes pratiques deviennent des candidats à Knowledge tandis qu’un skeleton PGR reste une spécification de composition.
|
||||
|
||||
`300-DOCUMENTATION.md` est proposé comme owner de la taxonomie ; aucun nouvel owner Knowledge n’est créé pendant `alpha.1`.
|
||||
|
||||
### Cohérence d’horizon
|
||||
|
||||
`docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` contient encore une référence vivante à l’adoption Games `0.1.5`. La trajectoire autoritaire issue de la revue `0.1.4` réserve maintenant Games à `0.1.6`, KSP à `0.1.7` et les audits Rust/Clippy à `0.1.8`.
|
||||
|
||||
La correction appartient à la réconciliation normative suivante. Les références historiques qui décrivent correctement un horizon antérieur ne doivent pas être réécrites.
|
||||
|
||||
## Modifications de la tranche
|
||||
|
||||
- `VERSION` passe à `0.1.5-alpha.1` ;
|
||||
- `README.md` annonce l’ouverture de l’audit transversal et référence le plan actif ;
|
||||
- `docs/000-README.md` ajoute les points d’entrée actifs de `0.1.5` ;
|
||||
- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` consigne preuves, ambiguïtés, owners et trajectoire ;
|
||||
- le présent delta décrit la gate opérateur.
|
||||
|
||||
`ROADMAP.md`, `CHANGELOG.md`, `RULES.md`, `docs/rules/`, `docs/skeletons/` et `docs/templates/` restent normativement inchangés pendant cette tranche d’ouverture.
|
||||
|
||||
## Décision de tranche
|
||||
|
||||
```text
|
||||
baseline 0.1.4 VERIFIED
|
||||
history 0.1.4 alpha.2 FAIL PRESERVED
|
||||
inventaire transversal COMPLETE
|
||||
conversion mécanique des SHOULD REJECTED
|
||||
owners ciblés IDENTIFIED
|
||||
règles modifiées en alpha.1 NO
|
||||
Games / KSP / audits Rust commencés NO
|
||||
prochaine tranche alpha.2 — sémantique normative et gates/adoption
|
||||
```
|
||||
|
||||
## Trajectoire retenue
|
||||
|
||||
```text
|
||||
alpha.1 intake + audit transversal + plan
|
||||
alpha.2 sémantique MUST/SHOULD/MAY + gates/adoption + cas concrets
|
||||
alpha.3 autonomie locale + réalignement PGR volontaire
|
||||
alpha.4 frontière PGR / SaseDev Knowledge
|
||||
beta.1 réconciliation transversale
|
||||
rc.1 freeze + handoff
|
||||
rel.1 promotion stable
|
||||
```
|
||||
|
||||
Le découpage peut être ajusté uniquement si une gate révèle un défaut réel ou si deux owners ne peuvent pas être corrigés proprement dans la même tranche.
|
||||
|
||||
## Gate opérateur
|
||||
|
||||
Appliquer le delta puis exécuter depuis la racine du dépôt :
|
||||
|
||||
```bash
|
||||
cat VERSION
|
||||
|
||||
test -f docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
test -f deltas/0.1.5/alpha.1.md
|
||||
test ! -e history/0.1.5/alpha.1.md
|
||||
|
||||
grep -Fx '0.1.5-alpha.1' VERSION
|
||||
grep -A2 '^## Statut$' history/0.1.4/alpha.2.md | grep -Fx 'FAIL'
|
||||
grep -A2 '^## Statut$' history/0.1.4/alpha.2.fix.1.md | grep -Fx 'PASS'
|
||||
grep -A2 '^## Statut$' history/0.1.4/rel.1.md | grep -Fx 'PASS'
|
||||
|
||||
grep -F -- '- `(x) 0.1.4`' ROADMAP.md
|
||||
grep -F -- '- `( ) 0.1.5`' ROADMAP.md
|
||||
grep -F -- '- `( ) 0.1.6`' ROADMAP.md
|
||||
grep -F -- '- `( ) 0.1.7`' ROADMAP.md
|
||||
grep -F -- '- `( ) 0.1.8`' ROADMAP.md
|
||||
! grep -F -- '- `( ) 0.1.9`' ROADMAP.md
|
||||
|
||||
python3 -B -m unittest discover -s tests -v
|
||||
|
||||
python3 -B scripts/audit_text_hygiene.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md VERSION \
|
||||
docs deltas history prompts scripts tests templates .gitignore .settings
|
||||
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 -c "from pathlib import Path; expected={'0.0.1':12,'0.0.2':12,'0.0.3':10,'0.0.4':9,'0.0.5':19,'0.1.0':10,'0.1.1':11,'0.1.2':7,'0.1.3':6,'0.1.4':7}; assert all({p.name for p in Path('deltas',r).glob('*.md')} == {p.name for p in Path('history',r).glob('*.md')} and len(list(Path('deltas',r).glob('*.md'))) == n for r,n in expected.items()); assert Path('deltas/0.1.5/alpha.1.md').is_file(); assert not Path('history/0.1.5/alpha.1.md').exists(); print('0.1.5 alpha.1 history boundary: clean (103 prior pairs, current delta pending)')"
|
||||
|
||||
grep -F 'forte recommandation non obligatoire' prompts/011-V0_1_5_START_PROMPT.md
|
||||
grep -F 'ne doivent ni rechercher automatiquement « la dernière version de PGR »' prompts/011-V0_1_5_START_PROMPT.md
|
||||
grep -F 'réservée à `0.1.6`' prompts/011-V0_1_5_START_PROMPT.md
|
||||
grep -F 'réservée à `0.1.7`' prompts/011-V0_1_5_START_PROMPT.md
|
||||
grep -F 'réservés à `0.1.8`' prompts/011-V0_1_5_START_PROMPT.md
|
||||
|
||||
grep -F '29` fichiers' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F '242` occurrences' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'alpha.2` — sémantique normative' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'alpha.3` — autonomie locale' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'alpha.4` — frontière PGR / SaseDev Knowledge' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
|
||||
git diff --check
|
||||
git status --short
|
||||
|
||||
git add VERSION README.md docs/000-README.md \
|
||||
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md \
|
||||
deltas/0.1.5/alpha.1.md
|
||||
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
Le scope indexé attendu avant ajout du history est :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/alpha.1.md
|
||||
M docs/000-README.md
|
||||
A docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
```
|
||||
|
||||
Aucun fichier sous `docs/rules/`, `docs/skeletons/` ou `docs/templates/` ne doit être indexé pour `alpha.1`.
|
||||
|
||||
## Revue opérateur attendue
|
||||
|
||||
La revue doit confirmer que l’inventaire distingue bien :
|
||||
|
||||
- un `SHOULD` réellement recommandatoire d’une obligation `MUST` ;
|
||||
- un choix local face à une recommandation d’un véritable `OVERRIDE` ;
|
||||
- l’autonomie documentaire du projet d’une simple absence de dépendance runtime/build ;
|
||||
- une skeleton specification normative d’une recette pratique candidate à Knowledge ;
|
||||
- les références vivantes à corriger des références historiques à préserver.
|
||||
|
||||
Elle doit également confirmer qu’aucune adoption Games/KSP, aucun audit Rust futur et aucune réouverture Tauri ne sont introduits par la tranche.
|
||||
|
||||
## Transition
|
||||
|
||||
### PASS
|
||||
|
||||
Produire `history/0.1.5/alpha.1.md` à partir des résultats réellement observés. Dans la même réponse, préparer séparément le delta `0.1.5-alpha.2` consacré à la sémantique normative, aux conséquences de gate/adoption et aux cas concrets déjà identifiés, sans absorber l’autonomie `alpha.3` ni la frontière Knowledge `alpha.4`.
|
||||
|
||||
Après remise du history, fournir automatiquement le bloc opérateur exact pour appliquer le history, committer/pusher `0.1.5-alpha.1`, puis seulement appliquer le delta suivant conformément à `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`.
|
||||
|
||||
### FAIL
|
||||
|
||||
Consigner le résultat réel dans le history, puis ouvrir `0.1.5-alpha.1.fix.1` ou un REPLAN selon la cause. Aucun changement prévu pour `alpha.2` ne doit être absorbé silencieusement dans le fix.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/000-README.md -->
|
||||
<!-- version: 46 -->
|
||||
<!-- version: 47 -->
|
||||
|
||||
# Documentation PGR
|
||||
|
||||
@@ -20,6 +20,15 @@ D'autres collections telles que `ideas/`, `studies/`, `reference/` ou `formats/`
|
||||
|
||||
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.1.5
|
||||
|
||||
- [`plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan actif de `0.1.5` : inventaire `alpha.1`, sémantique normative, autonomie locale, frontière PGR / Knowledge, réconciliation puis freeze.
|
||||
- [`studies/004-V0_1_4_HORIZON_REVIEW.md`](studies/004-V0_1_4_HORIZON_REVIEW.md) — décision autoritaire de fermeture `0.1.4` qui place la release de gouvernance/autonomie avant les adoptions Games/KSP.
|
||||
- [`../RULES.md`](../RULES.md), [`rules/230-ADOPTION.md`](rules/230-ADOPTION.md) et [`rules/400-VALIDATION.md`](rules/400-VALIDATION.md) — owners primaires à réconcilier pour la force de `SHOULD`, les conséquences de gate et la distinction entre recommandation, choix local et `OVERRIDE`.
|
||||
- [`rules/220-SKELETONS.md`](rules/220-SKELETONS.md), [`skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) et [`templates/007-EXISTING_PROJECT_ADOPTION.md`](templates/007-EXISTING_PROJECT_ADOPTION.md) — propagation du contrat d'autonomie après instanciation/adoption.
|
||||
- [`objectives/001-PROJECT_OBJECTIVES.md`](objectives/001-PROJECT_OBJECTIVES.md), [`architecture/002-GOVERNANCE_ARCHITECTURE.md`](architecture/002-GOVERNANCE_ARCHITECTURE.md) et [`rules/300-DOCUMENTATION.md`](rules/300-DOCUMENTATION.md) — owners proposés pour formaliser la frontière PGR / SaseDev Knowledge sans dépendance externe.
|
||||
- [`../prompts/011-V0_1_5_START_PROMPT.md`](../prompts/011-V0_1_5_START_PROMPT.md) — contrat de reprise exécuté pour ouvrir `0.1.5-alpha.1` à partir de la stable `v0.1.4` vérifiée.
|
||||
|
||||
## Points d'entrée de 0.1.4
|
||||
|
||||
- [`plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md`](plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md) — plan historique de la stable `0.1.4` : réexamen Tauri, skeleton `004`, décision d’artefacts, freeze RC et revue d’horizon.
|
||||
|
||||
290
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
Normal file
290
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
Normal file
@@ -0,0 +1,290 @@
|
||||
<!-- file: docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Plan 0.1.5 — sémantique normative, autonomie et frontière PGR / Knowledge
|
||||
|
||||
## Objet
|
||||
|
||||
`0.1.5` stabilise trois contrats transversaux décidés par la revue d’horizon `0.1.4` avant toute nouvelle adoption réelle : la force de `MUST / SHOULD / MAY`, l’autonomie d’un projet après instanciation ou adoption, et la frontière entre le référentiel normatif PGR et les contenus pratiques candidats à SaseDev Knowledge.
|
||||
|
||||
La release ne doit ni réécrire mécaniquement toutes les recommandations existantes, ni traiter PGR comme un upstream vivant des projets déjà adoptés, ni déplacer du contenu vers Knowledge sans corpus de destination autoritaire.
|
||||
|
||||
## Baseline et preuves d’ouverture
|
||||
|
||||
La baseline autoritaire est l’archive du tag Gitea `v0.1.4`.
|
||||
|
||||
```text
|
||||
archive canonique pgr-v0.1.4.zip
|
||||
archive reçue pgr-v0.1.4(1).zip
|
||||
SHA-256 9f85ac16a5ad9fd788df51883b6ebf592602c5189d94e338a86edab2288b8f77
|
||||
CRC PASS
|
||||
VERSION 0.1.4
|
||||
racine ZIP pgr/
|
||||
fichiers 310
|
||||
répertoires 44
|
||||
symlink 0
|
||||
.git dans l'archive absent — attendu pour une archive de tag
|
||||
```
|
||||
|
||||
La publication post-tag associée a été clôturée `PASS` sous `pgr-0.1.4-publish.001-report.md`. Sa preuve établit le SHA canonique ci-dessus, la publication de la stable `0.1.4` et l’autorisation du handoff vers `prompts/011-V0_1_5_START_PROMPT.md`.
|
||||
|
||||
Le replay indépendant de la baseline avant préparation de `alpha.1` confirme :
|
||||
|
||||
```text
|
||||
tests Python 55/55 PASS
|
||||
audit hygiène texte 309 fichiers PASS
|
||||
audit headers Markdown 282 fichiers PASS
|
||||
audit tables Markdown 11 tables / 282 fichiers PASS
|
||||
audit liens Markdown 357 liens locaux / 282 fichiers PASS
|
||||
JSON 2 fichiers parsés
|
||||
TOML 5 fichiers parsés
|
||||
deltas historiques 103
|
||||
histories historiques 103
|
||||
appariement delta/history exact pour 0.0.1 à 0.1.4
|
||||
```
|
||||
|
||||
La séquence `0.1.4` est conservée telle que publiée :
|
||||
|
||||
```text
|
||||
alpha.1 PASS
|
||||
alpha.2 FAIL
|
||||
alpha.2.fix.1 PASS
|
||||
alpha.3 PASS
|
||||
beta.1 PASS
|
||||
rc.1 PASS
|
||||
rel.1 PASS
|
||||
```
|
||||
|
||||
Le `FAIL` de `alpha.2` et son correctif restent des faits historiques ; `0.1.5` ne les réécrit pas.
|
||||
|
||||
## Sources de cadrage
|
||||
|
||||
La release part au minimum de :
|
||||
|
||||
- `RULES.md` ;
|
||||
- `docs/rules/200-GOVERNANCE.md` ;
|
||||
- `docs/rules/210-WORKFLOW.md` ;
|
||||
- `docs/rules/220-SKELETONS.md` ;
|
||||
- `docs/rules/230-ADOPTION.md` ;
|
||||
- `docs/rules/400-VALIDATION.md` ;
|
||||
- `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md` ;
|
||||
- `docs/templates/003-NEW_SESSION_PROMPT.md` ;
|
||||
- `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` ;
|
||||
- `docs/studies/004-V0_1_4_HORIZON_REVIEW.md` ;
|
||||
- `prompts/011-V0_1_5_START_PROMPT.md`.
|
||||
|
||||
Les owners et artefacts adjacents ne sont modifiés que lorsqu’une ambiguïté transversale réelle les concerne.
|
||||
|
||||
## Contrats cibles
|
||||
|
||||
### Force normative
|
||||
|
||||
La release doit rendre non ambigu le contrat suivant :
|
||||
|
||||
```text
|
||||
MUST / MUST NOT obligation ou interdiction normative
|
||||
SHOULD / SHOULD NOT forte recommandation non obligatoire
|
||||
MAY possibilité neutre
|
||||
```
|
||||
|
||||
Un écart à un `SHOULD` ou `SHOULD NOT` :
|
||||
|
||||
- ne constitue pas à lui seul une non-conformité ;
|
||||
- ne fait pas échouer à lui seul une gate ;
|
||||
- n’exige pas automatiquement un `OVERRIDE` ;
|
||||
- peut être documenté lorsque la raison apporte une valeur durable de maintenance, architecture ou reprise.
|
||||
|
||||
Une contradiction avec un `MUST` réellement applicable reste distincte et continue d’exiger le traitement prévu par l’owner concerné, l’exception ou l’override autorisé.
|
||||
|
||||
### Autonomie après instanciation ou adoption
|
||||
|
||||
Le cycle cible est :
|
||||
|
||||
```text
|
||||
snapshot PGR explicitement choisi
|
||||
↓
|
||||
instanciation / adoption / adaptation
|
||||
↓
|
||||
baseline locale du projet
|
||||
↓
|
||||
autorité locale pour les sessions et releases suivantes
|
||||
```
|
||||
|
||||
Après établissement de la baseline locale, le projet destinataire ne recherche pas automatiquement une version PGR plus récente et ne traite pas PGR comme une dépendance documentaire implicite. Un réalignement futur reste possible uniquement comme opération explicite et bornée, à partir d’un nouveau snapshot PGR choisi et d’une nouvelle comparaison des écarts.
|
||||
|
||||
### Frontière PGR / SaseDev Knowledge
|
||||
|
||||
PGR reste auto-suffisant pour comprendre et appliquer ses exigences.
|
||||
|
||||
PGR conserve notamment les contrats normatifs et de gouvernance, les owners, les skeleton specifications minimales, les templates nécessaires à un contrat réutilisable et les validations directement liées aux règles.
|
||||
|
||||
Les howtos détaillés, recettes pratiques, snippets, exemples d’intégration, dépannage, comparatifs et variantes d’implémentation sont des candidats à Knowledge. Cette classification n’autorise aucun déplacement automatique pendant `0.1.5` et ne crée aucune dépendance de PGR vers Knowledge.
|
||||
|
||||
## Inventaire transversal `alpha.1`
|
||||
|
||||
L’inventaire a recherché les formulations `SHOULD / SHOULD NOT`, les contrats d’override, l’autonomie post-adoption et les termes qui confondent spécification normative et recette pratique.
|
||||
|
||||
Sur le corpus normatif/documentaire courant analysé, `29` fichiers contiennent au moins un `SHOULD` ou `SHOULD NOT`, pour `242` occurrences textuelles brutes. Ce volume interdit une conversion mécanique : la majorité de ces recommandations sont légitimes et doivent seulement hériter d’une sémantique globale claire.
|
||||
|
||||
### Ambiguïtés normatives confirmées
|
||||
|
||||
`RULES.md` décrit actuellement `SHOULD / SHOULD NOT` comme un comportement attendu avec dérogation lorsque l’alternative est « mieux adaptée et justifiée ». Cette formulation peut rendre la justification obligatoire et doit devenir l’owner primaire de la clarification.
|
||||
|
||||
`RULES.md` exige aussi un override pour une contradiction intentionnelle. Le texte doit distinguer explicitement une contradiction à une obligation d’un simple choix différent d’une recommandation.
|
||||
|
||||
`docs/rules/400-VALIDATION.md` ne précise pas encore qu’un écart à un `SHOULD` ne peut pas, à lui seul, faire échouer une gate.
|
||||
|
||||
`docs/rules/230-ADOPTION.md` définit `OVERRIDE` comme le remplacement ou raffinement d’une règle PGR applicable. Sans clarification de la force normative, cette définition peut pousser à créer un override pour une simple recommandation non suivie.
|
||||
|
||||
`docs/rules/500-LANGUAGES.md` et `docs/rules/700-FRAMEWORKS.md` utilisent des formulations d’exception/override qui doivent être relues après stabilisation de la sémantique globale afin de ne pas renforcer accidentellement un `SHOULD`.
|
||||
|
||||
Des cas concrets confirment que l’ambiguïté n’est pas théorique :
|
||||
|
||||
- `docs/rules/530-TYPESCRIPT.md` associe une recommandation à une incompatibilité documentée ;
|
||||
- `docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` demande actuellement, pour la politique de lockfile, soit l’adoption de la recommandation soit un `OVERRIDE` ;
|
||||
- `docs/skeletons/003-WEB_FRONTEND.md` exige une justification lorsqu’une nouvelle baseline durable n’adopte pas la recommandation TypeScript ;
|
||||
- `docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md` impose une décision locale ou un `OVERRIDE` avec justification pour une politique de lockfile différente.
|
||||
|
||||
Ces cas doivent être corrigés de façon ciblée après la définition centrale, sans affaiblir les `MUST` réellement applicables.
|
||||
|
||||
### Ambiguïté de trajectoire confirmée
|
||||
|
||||
`docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` conserve une référence vivante à « l’adoption `0.1.5` de Games ». La revue d’horizon `0.1.4` a déplacé cette adoption en `0.1.6`. Cette référence est donc obsolète et doit être corrigée comme cohérence documentaire vivante, sans modifier les plans, études, prompts ou histories qui décrivent correctement l’ancien horizon dans leur contexte historique.
|
||||
|
||||
### Autonomie — acquis à conserver
|
||||
|
||||
Plusieurs contrats sont déjà compatibles avec la cible :
|
||||
|
||||
- `docs/objectives/001-PROJECT_OBJECTIVES.md` interdit de créer une dépendance vers PGR après instanciation et exclut la maintenance automatique des projets créés ;
|
||||
- `docs/architecture/002-GOVERNANCE_ARCHITECTURE.md` dit déjà que le projet possède sa copie et qu’une évolution ultérieure de PGR ne le modifie pas automatiquement ;
|
||||
- `docs/rules/220-SKELETONS.md` attribue les fichiers, décisions et règles locales au projet après instanciation ;
|
||||
- `docs/templates/003-NEW_SESSION_PROMPT.md` repart de la baseline stable du projet lui-même et ne reconstruit pas une source absente ;
|
||||
- `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` conclut déjà sur un projet autonome.
|
||||
|
||||
Ces acquis doivent être consolidés plutôt que réécrits en bloc.
|
||||
|
||||
### Autonomie — gaps à fermer
|
||||
|
||||
`RULES.md` interdit seulement la dépendance runtime/build et doit expliciter l’absence d’upstream documentaire PGR implicite.
|
||||
|
||||
`docs/rules/230-ADOPTION.md` doit établir clairement que la baseline locale devient l’autorité des sessions/releases suivantes et qu’un réalignement PGR ultérieur est une opération explicite.
|
||||
|
||||
`docs/rules/220-SKELETONS.md`, `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md` et `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` doivent propager ce contrat au point d’instanciation/adoption. Une éventuelle dépendance documentaire externe explicitement choisie par un projet reste sa décision locale ; elle ne transforme pas PGR en upstream implicite.
|
||||
|
||||
`docs/rules/210-WORKFLOW.md` et `docs/templates/003-NEW_SESSION_PROMPT.md` sont, à ce stade, classés `KEEP` sauf contradiction découverte pendant la réconciliation : leur notion de baseline autoritaire est déjà celle du projet courant.
|
||||
|
||||
### Frontière Knowledge — ambiguïtés confirmées
|
||||
|
||||
`docs/objectives/001-PROJECT_OBJECTIVES.md` et `docs/architecture/002-GOVERNANCE_ARCHITECTURE.md` qualifient encore un skeleton de « recette Markdown ». Or `0.1.5` réserve précisément les recettes pratiques à la famille de contenus candidats à Knowledge. Le terme doit être remplacé par une formulation de type « spécification Markdown composable » afin de préserver la nature normative/structurelle du skeleton.
|
||||
|
||||
`docs/rules/300-DOCUMENTATION.md` est l’owner naturel pour formaliser la frontière documentaire sans créer un owner Knowledge artificiel. PGR ne doit pas créer une règle ou une collection dédiée uniquement parce que Knowledge existe comme produit séparé.
|
||||
|
||||
## Owners proposés
|
||||
|
||||
Les modifications ne sont engagées qu’après validation de cet inventaire.
|
||||
|
||||
```text
|
||||
sémantique primaire
|
||||
RULES.md MODIFY
|
||||
docs/rules/230-ADOPTION.md MODIFY
|
||||
docs/rules/400-VALIDATION.md MODIFY
|
||||
|
||||
réconciliation ciblée des effets SHOULD
|
||||
docs/rules/500-LANGUAGES.md REVIEW / MODIFY IF NEEDED
|
||||
docs/rules/530-TYPESCRIPT.md MODIFY
|
||||
docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md MODIFY
|
||||
docs/rules/700-FRAMEWORKS.md REVIEW / MODIFY IF NEEDED
|
||||
docs/skeletons/003-WEB_FRONTEND.md MODIFY
|
||||
docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md MODIFY
|
||||
|
||||
autonomie
|
||||
RULES.md MODIFY
|
||||
docs/rules/220-SKELETONS.md MODIFY
|
||||
docs/rules/230-ADOPTION.md MODIFY
|
||||
docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md MODIFY
|
||||
docs/templates/007-EXISTING_PROJECT_ADOPTION.md MODIFY
|
||||
docs/rules/210-WORKFLOW.md KEEP / REVIEW
|
||||
docs/templates/003-NEW_SESSION_PROMPT.md KEEP / REVIEW
|
||||
|
||||
frontière PGR / Knowledge
|
||||
docs/objectives/001-PROJECT_OBJECTIVES.md MODIFY
|
||||
docs/architecture/002-GOVERNANCE_ARCHITECTURE.md MODIFY
|
||||
docs/rules/300-DOCUMENTATION.md MODIFY
|
||||
```
|
||||
|
||||
Aucun nouveau owner Knowledge n’est prévu par défaut.
|
||||
|
||||
## Trajectoire de release
|
||||
|
||||
### `alpha.1` — intake, audit transversal et plan
|
||||
|
||||
- vérifier la baseline stable `0.1.4` et sa chaîne delta/history ;
|
||||
- relire le handoff `011` et la revue d’horizon `004` ;
|
||||
- inventorier les ambiguïtés normatives, d’autonomie et de frontière Knowledge ;
|
||||
- proposer les owners exacts ;
|
||||
- ne modifier aucune règle normative.
|
||||
|
||||
### `alpha.2` — sémantique normative et conséquences de gate/adoption
|
||||
|
||||
- stabiliser `MUST / SHOULD / MAY` dans l’owner primaire ;
|
||||
- aligner `230-ADOPTION.md` et `400-VALIDATION.md` ;
|
||||
- corriger les cas concrets où une recommandation est transformée en justification/override obligatoire ;
|
||||
- corriger la référence vivante obsolète à l’adoption Games `0.1.5` ;
|
||||
- conserver les obligations réelles et les histories inchangées.
|
||||
|
||||
### `alpha.3` — autonomie locale et réalignement volontaire
|
||||
|
||||
- expliciter la baseline locale comme autorité après instanciation/adoption ;
|
||||
- interdire la recherche automatique de « la dernière PGR » dans le contrat d’adoption ;
|
||||
- définir le réalignement futur comme scope explicite fondé sur un snapshot choisi ;
|
||||
- propager le contrat aux skeleton/patterns concernés sans réécriture des documents déjà corrects.
|
||||
|
||||
### `alpha.4` — frontière PGR / SaseDev Knowledge
|
||||
|
||||
- clarifier la taxonomie normative/pratique ;
|
||||
- remplacer les formulations « recette Markdown » qui brouillent la nature des skeleton specifications ;
|
||||
- maintenir PGR auto-suffisant ;
|
||||
- ne déplacer aucun contenu vers Knowledge sans destination autoritaire fournie.
|
||||
|
||||
### `beta.1` — réconciliation transversale
|
||||
|
||||
- rescanner toutes les formulations `SHOULD / SHOULD NOT` pour détecter les renforcements accidentels restants ;
|
||||
- vérifier les références à l’autonomie, aux snapshots et aux overrides ;
|
||||
- rechercher les références vivantes devenues obsolètes après la revue d’horizon ;
|
||||
- vérifier que Games `0.1.6`, KSP `0.1.7` et les audits Rust `0.1.8` n’ont pas été commencés ;
|
||||
- exécuter les validations PGR complètes et proportionnées.
|
||||
|
||||
### `rc.1` — freeze et handoff
|
||||
|
||||
- figer les contrats stabilisés ;
|
||||
- mettre à jour la présentation stable/candidate et la roadmap selon l’état réellement atteint ;
|
||||
- préparer le prompt de reprise suivant uniquement si la trajectoire vers `0.1.6` reste valide ;
|
||||
- effectuer une revue d’horizon limitée aux dépendances réellement révélées par `0.1.5`.
|
||||
|
||||
### `rel.1` — promotion stable
|
||||
|
||||
- promouvoir la RC validée sans nouveau scope fonctionnel ;
|
||||
- produire le history réel de clôture ;
|
||||
- préparer la publication/tag stable puis sa vérification post-tag selon le workflow PGR.
|
||||
|
||||
## Hors scope maintenu
|
||||
|
||||
`0.1.5` ne commence pas :
|
||||
|
||||
- l’adoption réelle de `sasedev-games`, réservée à `0.1.6` ;
|
||||
- l’adoption réelle de `khadhroony-solana-project`, réservée à `0.1.7` ;
|
||||
- les audits Rust/Clippy read-only, réservés à `0.1.8` ;
|
||||
- une réouverture du domaine Tauri sans défaut transversal démontré ;
|
||||
- une migration physique vers SaseDev Knowledge ;
|
||||
- une conversion globale de tous les `SHOULD` en `MUST` ou `MAY`.
|
||||
|
||||
## Gate de planification
|
||||
|
||||
`alpha.1` est prête à validation opérateur lorsque :
|
||||
|
||||
- la baseline `0.1.4` a été rejouée proprement ;
|
||||
- l’historique `0.1.4` reste intact, y compris `alpha.2 FAIL` puis `alpha.2.fix.1 PASS` ;
|
||||
- les ambiguïtés ci-dessus sont traçables à des owners existants ;
|
||||
- aucune règle normative n’est modifiée par la tranche ;
|
||||
- le plan conserve une séparation explicite entre sémantique, autonomie et frontière Knowledge ;
|
||||
- les scopes `0.1.6`, `0.1.7` et `0.1.8` restent réservés.
|
||||
115
history/0.1.5/alpha.1.md
Normal file
115
history/0.1.5/alpha.1.md
Normal file
@@ -0,0 +1,115 @@
|
||||
<!-- file: history/0.1.5/alpha.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.1.5-alpha.1 — cadrage normatif, autonomie et frontière Knowledge
|
||||
|
||||
## Statut
|
||||
|
||||
PARTIAL
|
||||
|
||||
La gate opérateur de `0.1.5-alpha.1` exécutée le `2026-09-30` a acquis toutes les preuves mécaniques effectivement lancées, sans échec observé. Elle reste toutefois `PARTIAL` car plusieurs contrôles explicitement requis par `deltas/0.1.5/alpha.1.md` ne figurent pas dans le transcript opérateur et ne peuvent pas être remplacés par une prévalidation IA.
|
||||
|
||||
Aucun défaut du contenu livré par `alpha.1` n'est établi par les preuves disponibles. La tranche corrective `alpha.1.fix.1` est limitée à l'acquisition des contrôles manquants ; elle ne modifie aucune règle normative et n'absorbe aucun scope de `alpha.2`.
|
||||
|
||||
## Baseline et version observées
|
||||
|
||||
La version observée par l'opérateur est :
|
||||
|
||||
```text
|
||||
0.1.5-alpha.1
|
||||
```
|
||||
|
||||
Les contrôles de présence ont confirmé :
|
||||
|
||||
```text
|
||||
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md présent
|
||||
deltas/0.1.5/alpha.1.md présent
|
||||
history/0.1.5/alpha.1.md absent pendant la gate
|
||||
```
|
||||
|
||||
La chronologie stable précédente a également été relue avec les statuts attendus :
|
||||
|
||||
```text
|
||||
history/0.1.4/alpha.2.md FAIL
|
||||
history/0.1.4/alpha.2.fix.1.md PASS
|
||||
history/0.1.4/rel.1.md PASS
|
||||
```
|
||||
|
||||
## Tests Python observés
|
||||
|
||||
La suite complète a terminé avec succès :
|
||||
|
||||
```text
|
||||
Ran 55 tests in 1.678s
|
||||
|
||||
OK
|
||||
```
|
||||
|
||||
Soit `55/55` tests `PASS` pour les commandes réellement exécutées.
|
||||
|
||||
## Audits observés
|
||||
|
||||
Les audits documentaires et d'hygiène lancés par l'opérateur sont propres :
|
||||
|
||||
```text
|
||||
Text hygiene audit: clean (311 file(s))
|
||||
Markdown header audit: clean (284 file(s))
|
||||
Markdown table audit: clean (11 table(s), 284 file(s))
|
||||
Markdown link audit: clean (370 local link(s), 284 file(s))
|
||||
```
|
||||
|
||||
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
|
||||
|
||||
## Scope Git observé
|
||||
|
||||
Avant indexation, `git status --short` a affiché :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
M docs/000-README.md
|
||||
?? deltas/0.1.5/
|
||||
?? docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
```
|
||||
|
||||
Après l'ajout explicite des cinq chemins de `alpha.1`, le scope indexé est exactement :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/alpha.1.md
|
||||
M docs/000-README.md
|
||||
A docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
```
|
||||
|
||||
Aucun chemin sous `docs/rules/`, `docs/skeletons/` ou `docs/templates/` n'apparaît dans ce scope.
|
||||
|
||||
## Preuves requises non observées
|
||||
|
||||
Le transcript ne contient pas l'exécution des contrôles suivants pourtant présents dans la gate canonique du delta `alpha.1` :
|
||||
|
||||
- assertions `ROADMAP.md` confirmant `0.1.4` terminé, `0.1.5` à `0.1.8` réservés et l'absence de réservation `0.1.9` ;
|
||||
- contrôle d'appariement des `103` couples delta/history historiques et de la frontière du history courant ;
|
||||
- assertions ciblées du prompt `011` sur la sémantique `SHOULD`, l'autonomie et les réservations `0.1.6` à `0.1.8` ;
|
||||
- assertions ciblées du plan `011` sur les `29` fichiers, `242` occurrences et la séparation `alpha.2` / `alpha.3` / `alpha.4`.
|
||||
|
||||
Ces assertions avaient été prévalidées avant livraison, mais cette prévalidation ne constitue pas la preuve opérateur exigée par `docs/rules/400-VALIDATION.md`.
|
||||
|
||||
## Diagnostic
|
||||
|
||||
Le résultat est `PARTIAL`, et non `FAIL` : aucune commande réellement exécutée n'a échoué et aucun défaut de contenu n'est démontré. La limitation vient d'une gate opérateur incomplètement rejouée.
|
||||
|
||||
Le bloc de commandes remis dans le handoff précédent ne reproduisait que les commandes principales alors que le delta contenait une gate plus complète. Le correctif doit donc rester strictement opérationnel et réacquérir les preuves omises sans réécrire le contenu de `alpha.1`.
|
||||
|
||||
## Transition
|
||||
|
||||
Appliquer le présent history puis committer/pusher `0.1.5-alpha.1` avec son statut `PARTIAL` avant d'appliquer `0.1.5-alpha.1.fix.1`.
|
||||
|
||||
Le fix suivant :
|
||||
|
||||
- passe `VERSION` à `0.1.5-alpha.1.fix.1` ;
|
||||
- n'altère aucun owner normatif, skeleton, template, plan ou contenu de cadrage ;
|
||||
- rejoue les preuves manquantes et les audits documentaires nécessaires à son propre artefact ;
|
||||
- autorise `alpha.2` uniquement si sa gate obtient réellement `PASS`.
|
||||
|
||||
Aucun commit, push ni résultat de `alpha.1.fix.1` n'est déclaré observé dans le présent history.
|
||||
Reference in New Issue
Block a user