0.1.1
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md -->
|
||||
<!-- version: 10 -->
|
||||
<!-- version: 11 -->
|
||||
|
||||
# Plan 0.1.1 — fondation frontend Web contrôlée
|
||||
|
||||
@@ -447,19 +447,19 @@ Si une responsabilité Web nécessaire reste sans owner clair, effectuer un REPL
|
||||
|
||||
### rc.1 — release candidate
|
||||
|
||||
Statut opérateur : **à valider**.
|
||||
Statut opérateur : **PASS**.
|
||||
|
||||
Geler le scope sur les owners `530/540/550/560`, les guides `008/009/010`, la validation `005`, le skeleton `003` et la preuve de préparation Tauri obtenue en `beta.1`.
|
||||
La gate opérateur a confirmé les neuf histories antérieurs avec leurs statuts réels, le scope Web gelé, le changelog candidat, le prompt `008`, le dry-run structurel du skeleton Web, les `48/48` tests, les trois audits Markdown et l'hygiène texte/JSON. Aucun owner, template technique, skeleton, validation ou étude technique n'a été modifié pendant la RC.
|
||||
|
||||
Mettre à jour le `CHANGELOG.md` candidat, rejouer un release gate proportionnel complet, vérifier l'intégrité des histories de `0.1.1` et préparer `prompts/008-V0_1_2_START_PROMPT.md` puisque la roadmap engage toujours `0.1.2` sur la réévaluation Java/Maven/Gradle.
|
||||
|
||||
Le prompt `008` doit imposer la séparation Java/Gradle générique versus Android : le profil `520` est réévalué à partir du corpus Games, tandis qu'AGP, SDK Android, JNI/ABI et packaging APK/AAB restent hors scope et réservés à `0.1.3`. Maven reste dans l'owner `520`, mais aucun artefact Maven nouveau ne doit être créé en `0.1.2` sans corpus ou besoin réel.
|
||||
|
||||
Aucune nouvelle fonctionnalité normative ne doit apparaître en RC.
|
||||
Le prompt `008-V0_1_2_START_PROMPT.md` conserve la séparation Java/Gradle générique versus Android : le profil `520` sera réévalué à partir du corpus Games, tandis qu'AGP, SDK Android, JNI/ABI et packaging APK/AAB restent hors scope et réservés à `0.1.3`.
|
||||
|
||||
### rel.1 — promotion stable
|
||||
|
||||
Promouvoir mécaniquement la RC validée vers `0.1.1`, clôturer roadmap/plan/changelog, produire le history réel, committer la stable sous `0.1.1`, puis seulement tagger `v0.1.1` et effectuer la vérification post-tag `publish.001`.
|
||||
Première clôture stable de `0.1.1`. La promotion est strictement mécanique : `VERSION = 0.1.1`, `ROADMAP.md` marque `0.1.1` terminée, le `CHANGELOG` perd son marqueur `candidate`, README/index décrivent la fondation frontend Web comme stable et le présent plan devient historique. Aucun owner, profil, template, skeleton, validation, étude ou script technique n'est modifié.
|
||||
|
||||
Le résultat opérateur de cette tranche appartient à `history/0.1.1/rel.1.md`, créé seulement après exécution de la gate. Si `rel.1` échoue, son history est conservé et un `rel.1.fix.N` corrige uniquement la fermeture ; la première tranche qui établit réellement la stable est incluse dans le commit `0.1.1` avant le tag `v0.1.1`.
|
||||
|
||||
La vérification post-tag reste séparée : `pgr-0.1.1-publish.001-report.md` ne peut être produit qu'à partir de l'archive du tag réellement publiée et des preuves Git observées. Le prompt `008` ne devient le point de départ effectif de `0.1.2` qu'après cette preuve post-tag `PASS`.
|
||||
|
||||
## Stratégie de validation
|
||||
|
||||
|
||||
Reference in New Issue
Block a user