pgr/docs/000-README.md

Documentation PGR

Ce fichier est l'index d'entrée de la documentation structurée de Project Governance Rules.

Collections actives

• objectives/ — mission, objectifs durables, non-objectifs et contraintes globales ;
• architecture/ — état architectural courant de PGR et profils applicables ;
• plans/ — plans vivants des releases en cours, puis références historiques après fermeture ;
• studies/ — études bornées utilisées pour comparer des corpus, instruire une décision ou conserver une analyse avant normalisation ;
• rules/ — règles normatives détaillées, organisées progressivement par scope ;
• skeletons/ — spécifications Markdown de composition et d'initialisation de projets ;
• templates/ — instructions d'adaptation des templates techniques et spécification du message manuel de reprise ;
• validation/ — matrices de validation et contrats de preuve.

D'autres collections telles que ideas/, studies/, reference/ ou formats/ ne sont créées que lorsqu'un premier artefact réel les justifie.

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 — plan historique de la stable 0.1.5 : sémantique normative, autonomie locale, frontière PGR / Knowledge, réconciliation, correctif RC documentaire et handoff vers 0.1.6.
• 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/230-ADOPTION.md et rules/400-VALIDATION.md — owners primaires réconciliés en alpha.2 : SHOULD / SHOULD NOT est une forte recommandation non obligatoire, sans FAIL de gate ni OVERRIDE automatique pour un simple écart.
• rules/220-SKELETONS.md, rules/230-ADOPTION.md, skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md et templates/007-EXISTING_PROJECT_ADOPTION.md — owners réconciliés en alpha.3 : baseline locale autoritaire, absence d'upstream PGR implicite et réalignement volontaire fondé sur un snapshot choisi.
• objectives/001-PROJECT_OBJECTIVES.md, architecture/002-GOVERNANCE_ARCHITECTURE.md et rules/300-DOCUMENTATION.md — owners réconciliés en alpha.4 : PGR reste auto-suffisant pour ses contrats normatifs ; les contenus pratiques externes restent complémentaires, sans dépendance PGR vers Knowledge ni déplacement automatique.
• beta.1 réconcilie les trois contrats sans nouvel owner normatif : les renforcements SHOULD connus restent corrigés, 210-WORKFLOW.md et 003-NEW_SESSION_PROMPT.md restent compatibles avec l’autonomie locale, et les références vivantes Games/KSP/audits restent respectivement réservées à 0.1.6, 0.1.7 et 0.1.8.
• studies/005-V0_1_5_HORIZON_REVIEW.md — revue limitée rc.1 confirmant que l’adoption Games 0.1.6 reste la prochaine dépendance réelle sans nouveau prérequis transversal ni réservation de 0.1.9.
• ../prompts/012-V0_1_6_START_PROMPT.md — handoff préparé vers l’adoption réelle de sasedev-games en 0.1.6-alpha.1, à utiliser uniquement après publication et vérification post-tag de v0.1.5 avec un corpus Games autoritaire explicitement fourni.
• ../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 — plan historique de la stable 0.1.4 : réexamen Tauri, skeleton 004, décision d’artefacts, freeze RC et revue d’horizon.
• rules/710-TAURI.md — owner Tauri 2 réconcilié en alpha.2 : host/orchestration, frontière commandes-permissions-capabilities, sélection des capabilities, plugins, version produit et validation proportionnée, sans absorber les choix Web.
• skeletons/003-WEB_FRONTEND.md — specialization Web composable dont l'existence satisfait les prérequis historiques sans rendre Vite, TypeScript, Sass, Bootstrap ou frontend/ universels à Tauri.
• skeletons/004-TAURI.md — skeleton Tauri 2 matérialisé en alpha.3, composant fondation, Rust/Cargo, Web et owner 710 sans template technique universel ni copie des choix Games/KSP.
• studies/002-TAURI_SKELETON_DECISION.md — décision historique DEFER, levée du motif Web puis décision beta.1 : 004-TAURI.md suffit ; aucun template technique ni contrat de validation Tauri séparé n'est justifié.
• studies/004-V0_1_4_HORIZON_REVIEW.md — revue de fermeture rc.1 décidant de stabiliser en 0.1.5 la sémantique SHOULD, l’autonomie après adoption et la frontière PGR / SaseDev Knowledge avant Games/KSP.
• ../prompts/011-V0_1_5_START_PROMPT.md — handoff de la stable 0.1.4 vers 0.1.5-alpha.1, à exécuter uniquement après publication et vérification post-tag de v0.1.4.
• ../prompts/010-V0_1_4_START_PROMPT.md — contrat de reprise exécuté pour ouvrir 0.1.4-alpha.1 après publication vérifiée de v0.1.3.

Points d'entrée de 0.1.3

• plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md — plan historique de la stable 0.1.3, de l'audit Games à la stabilisation du profil Android générique et au handoff Tauri 0.1.4.
• rules/610-ANDROID.md — owner Android révisé : contrats SDK/identité/signing, natif/ABI, Lint, niveaux de tests, packaging/distribution et 16 KB conditionnel, sans absorber les choix propres à Games.
• rules/520-JAVA.md et rules/522-GRADLE.md — owners composés uniquement lorsqu'un projet Android contient réellement du Java ou utilise Gradle.
• rules/600-PLATFORMS.md et rules/400-VALIDATION.md — contrats généraux de plateforme et de preuve auxquels la spécialisation Android doit rester conforme.
• studies/003-V0_1_0_HORIZON_REVIEW.md — revue ayant engagé Android 0.1.3, Tauri 0.1.4 puis l'adoption Games 0.1.5 comme scopes distincts.
• ../prompts/009-V0_1_3_START_PROMPT.md — contrat de reprise exécuté pour ouvrir 0.1.3-alpha.1 après publication vérifiée de v0.1.2.
• ../prompts/010-V0_1_4_START_PROMPT.md — prompt préparé par la RC pour le réexamen Tauri 0.1.4, à exécuter uniquement après publication et vérification post-tag de v0.1.3.

Points d'entrée de 0.1.2

• plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md — plan historique de la stable 0.1.2, de la réévaluation Games à la scission 520/521/522, avec frontière Android explicite.
• rules/520-JAVA.md — owner Java issu de la réévaluation du profil historique combiné ; il possède JDK, compatibilité source/bytecode, structure, API et tests Java.
• rules/521-MAVEN.md — spécialisation Maven séparée afin que Maven ne devienne pas implicitement applicable à tout projet Java.
• rules/522-GRADLE.md — spécialisation Gradle éprouvée contre Games, avec ownership du build, politique Wrapper/système et propriétés partagées/locales.
• rules/610-ANDROID.md — owner de contrôle de frontière ; AGP, SDK/NDK, ABI/JNI, manifests, packaging/signing et smokes Android restent hors du scope 0.1.2.
• studies/003-V0_1_0_HORIZON_REVIEW.md — revue ayant engagé 0.1.2 puis la réévaluation Android 0.1.3 comme releases distinctes.
• ../prompts/008-V0_1_2_START_PROMPT.md — contrat de reprise autoritaire exécuté pour ouvrir 0.1.2-alpha.1 après publication vérifiée de v0.1.1.
• ../prompts/009-V0_1_3_START_PROMPT.md — prompt préparé par la RC pour la réévaluation Android 0.1.3, à exécuter uniquement après publication et vérification post-tag de v0.1.2.

Points d'entrée de 0.1.1

• plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md — plan historique de la stable 0.1.1, de l'audit des corpus à la fondation Web composable et à la préparation du futur réexamen Tauri.
• rules/530-TYPESCRIPT.md, rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md, rules/550-VITE.md et rules/560-CSS_SASS.md — owners frontend matérialisés par 0.1.1-alpha.2, séparant langage typé, écosystème de package, build tool et styles.
• templates/008-WEB_TYPESCRIPT_PACKAGE.md — adaptation de la baseline minimale package.json + tsconfig.json de alpha.3, sans package manager, versions ou bundler imposés.
• templates/009-WEB_VITE.md — guide d'adaptation Vite de alpha.4 : root, dev server, cache, outputs, assets et scripts sans imposer de layout ni de port universels.
• templates/010-WEB_CSS_SASS.md — guide CSS/Sass de alpha.5 : sources, modules Sass, packages de styles et artefacts générés sans imposer de framework CSS.
• validation/005-WEB_FRONTEND_VALIDATION.md — validation frontend réutilisable et indépendante du host : restore, type-check, build/styles et smoke proportionné.
• skeletons/003-WEB_FRONTEND.md — specialization Web composable fondée sur les owners 530/540/550/560, sans imposer Vite, Sass, npm, Bootstrap ou un layout unique.
• studies/002-TAURI_SKELETON_DECISION.md — décision DEFER conservée ; beta.1 vérifie que ses cinq prérequis Web sont désormais couverts et prépare leur réexamen objectif en 0.1.4 sans créer le skeleton Tauri.
• studies/003-V0_1_0_HORIZON_REVIEW.md — revue ayant engagé 0.1.1 à 0.1.7 et maintenu WASM, serveur Rust et deployment sans réservation prématurée.
• ../prompts/007-V0_1_1_START_PROMPT.md — contrat de reprise autoritaire de la release 0.1.1.
• ../prompts/008-V0_1_2_START_PROMPT.md — prompt de reprise préparé pour réévaluer Java/Maven/Gradle en 0.1.2, à utiliser seulement après publication et vérification post-tag de 0.1.1, avec frontière Android explicite.

Points d'entrée de 0.1.0

• plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md — plan historique de la stable 0.1.0, depuis l’audit de v0.0.5 jusqu’à la baseline réutilisable, la clôture/publication et la revue d’horizon.
• templates/006-OPERATOR_COMMAND_HANDOFF.md — pattern de remise automatique des commandes entre history, commit/push, delta suivant, tag et vérification post-tag.
• rules/230-ADOPTION.md — contrat d’adoption proportionnée de PGR par un projet existant sans réécriture rétroactive de son historique.
• templates/007-EXISTING_PROJECT_ADOPTION.md — pattern court de baseline, mapping ADOPT / KEEP-LOCAL / OVERRIDE / DEFER, découpage et validation d’une migration existante.
• validation/004-RUST_CARGO_BASELINE_DRY_RUN.md — contrat de dry-run temporaire pour vérifier la composition d’un nouveau workspace Rust/Cargo et l’adoption non destructive d’un workspace existant.
• studies/003-V0_1_0_HORIZON_REVIEW.md — revue d’horizon de beta.1 engageant 0.1.1 à 0.1.7 par domaines cohérents et laissant WASM, serveur Rust et deployment sans réservation prématurée.
• ../prompts/007-V0_1_1_START_PROMPT.md — prompt de reprise préparé pour la fondation frontend Web 0.1.1, à utiliser seulement après publication et vérification post-tag de 0.1.0.

Points d'entrée de 0.0.5

• plans/005-V0_0_5_RECONCILIATION_PLAN.md — périmètre et décisions de la release 0.0.5 ;
• studies/001-KSP_GAMES_RECONCILIATION.md — inventaire comparatif des baselines KSP/Games et décisions de généralisation, maintien local ou différé.
• studies/002-TAURI_SKELETON_DECISION.md — décision alpha.9 sur la maturité du skeleton Tauri contrôlé et ses prérequis Web encore manquants.
• templates/004-FILE_FAMILY_CONTRACTS.md — pattern facultatif pour expliciter les responsabilités et règles de modification de familles de fichiers locales lorsque la complexité le justifie.
• templates/005-RELEASE_PLAN.md — pattern de plan de release avec clôture/transition explicites et revue d'horizon proportionnée.
• validation/002-RUST_STYLE_AUDITS.md et validation/003-RUST_EXPORT_COMPLETENESS.md — contrats et limites des audits Rust monotâches réconciliés depuis les corpus réels.
• rules/700-FRAMEWORKS.md et rules/710-TAURI.md — activation de la famille framework et premier profil Tauri 2 issu de la réconciliation KSP/Games.
• ../prompts/006-V0_1_0_START_PROMPT.md — prompt de reprise préparé pour la première baseline réutilisable 0.1.0, à utiliser seulement après publication et vérification post-tag de 0.0.5.

Points d'entrée de 0.0.4

• plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md — périmètre et décisions de la release 0.0.3 ;
• plans/004-V0_0_4_SKELETONS_PLAN.md — périmètre et décisions de la release 0.0.4 ;
• skeletons/000-README.md — contrat de collection des skeleton specifications ;
• skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md — fondation de gouvernance locale composable et sans spécialisation technologique ;
• skeletons/002-RUST_CARGO_WORKSPACE.md — specialization Rust/Cargo workspace composable avec la fondation et les cinq templates existants ;
• templates/001-RUST_CARGO_TOOLING.md et templates/002-CARGO_MANIFESTS.md — adaptation des cinq fichiers Rust/Cargo copiables ;
• templates/003-NEW_SESSION_PROMPT.md — spécification du message manuel après une stable publiée ;
• validation/001-VALIDATION_MATRIX.md, validation/002-RUST_STYLE_AUDITS.md et validation/003-RUST_EXPORT_COMPLETENESS.md — gates PGR et limites des audits Rust facultatifs.