diff --git a/VERSION b/VERSION index dff9f32..837e3ff 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.1.4-alpha.1 +0.1.4-alpha.2 diff --git a/deltas/0.1.4/alpha.2.md b/deltas/0.1.4/alpha.2.md new file mode 100644 index 0000000..78f93ef --- /dev/null +++ b/deltas/0.1.4/alpha.2.md @@ -0,0 +1,214 @@ + + + +# Delta 0.1.4-alpha.2 — réconciliation normative Tauri + +## Objet + +Réconcilier l'owner Tauri `710` et l'étude historique `002` à partir du cadrage `alpha.1` validé, sans matérialiser encore le skeleton `004-TAURI.md`. + +La tranche sépare explicitement les responsabilités Tauri des choix Web déjà possédés par les owners `530/540/550/560`, précise la frontière commande / permission / capability et rend la politique de sélection des capability files visible comme décision de sécurité. + +## Précondition + +Le history `history/0.1.4/alpha.1.md` doit être présent avec statut `PASS` avant application de ce delta. + +`alpha.1` a validé : + +```text +48 / 48 tests PASS +Markdown headers: clean (266 file(s)) +Markdown tables: clean (11 table(s), 266 file(s)) +Markdown links: clean (343 local link(s), 266 file(s)) +0.1.4 alpha.1 structural audit: clean (96 prior pairs, 7 current Tauri hosts classified, no premature skeleton/adoption) +``` + +## Réconciliation de `710-TAURI.md` + +La révision interne passe de `6` à `7`. + +La convention contrôlée est recentrée sur ce que Tauri possède réellement : + +- host Cargo direct `lib + bin` recommandé pour une nouvelle baseline PGR contrôlée ; +- `src-tauri/` reste un layout Tauri supporté et n'est pas déclaré invalide ; +- `build.rs`, configuration Tauri, capabilities, assemblage Rust, hooks et packaging restent dans le scope Tauri ; +- la racine frontend est un point de composition, pas un choix possédé par `710` ; +- TypeScript, Vite, CSS/Sass, framework CSS et package manager restent possédés par leurs owners Web ; +- TS-RS devient un choix conditionnel de frontière typée plutôt qu'une obligation Tauri générale ; +- aucun template technique n'est créé. + +La frontière de sécurité distingue désormais : + +```text +commande enregistrée +permission ACL + scopes +capability assignant les permissions aux fenêtres/webviews +``` + +La tranche exige une décision explicite sur la sélection des capabilities. Elle enregistre le comportement Tauri 2 courant : si `app.security.capabilities` est absent ou vide, les capability files du répertoire `capabilities/` sont inclus par défaut ; une liste explicite permet de sélectionner ceux qui participent au build. + +L'ajout d'un capability file sous auto-inclusion devient donc explicitement une modification de surface de sécurité. La revue doit également considérer le cumul des droits lorsqu'une fenêtre/webview appartient à plusieurs capabilities. + +## Révision de l'étude `002` + +La révision interne passe de `2` à `3`. + +La décision `DEFER` de `0.0.5-alpha.9` reste conservée comme preuve historique mais n'est plus la décision active : + +```text +motif Web historique LIFT +candidat organisationnel ADOPT FOR MATERIALIZATION +matérialisation pendant alpha.2 NO +matérialisation visée alpha.3 +``` + +Le corpus courant reste `1` host Games `0.3.6` + `6` hosts KSP `0.3.19`. La future specification doit composer fondation + Rust/Cargo + Web applicable + Tauri + plateformes ciblées, sans recopier les owners. + +## Mise à jour du plan et de l'index + +`docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md` passe en révision `2` et enregistre : + +- la gate `alpha.1 PASS` ; +- les décisions normatives préparées pour `alpha.2` ; +- l'autorisation conditionnelle de matérialiser `004-TAURI.md` en `alpha.3` ; +- le point transversal découvert lors de l'utilisation de PGR avec SaseDev Knowledge : sémantique `SHOULD`, autonomie post-adoption et future séparation PGR/Knowledge ; +- l'obligation de reprendre ce point lors de la revue d'horizon de fermeture avant de générer le prompt suivant. + +`docs/000-README.md` passe en révision `42` pour refléter l'état réconcilié du profil et de l'étude. + +`ROADMAP.md` et `CHANGELOG.md` restent inchangés. La trajectoire publiée `0.1.5` Games / `0.1.6` KSP / `0.1.7` audits Rust n'est pas réécrite avant la revue d'horizon prévue en fermeture de `0.1.4`. + +## Frontières + +Cette tranche MUST NOT : + +- créer `docs/skeletons/004-TAURI.md` ; +- créer un template `tauri.conf.json`, `build.rs` ou capability générique ; +- créer un contrat `docs/validation/*TAURI*` séparé ; +- modifier `RULES.md` ou `230-ADOPTION.md` pour traiter dès maintenant le point transversal `SHOULD`/autonomie ; +- modifier `ROADMAP.md` ou `CHANGELOG.md` ; +- commencer l'adoption Games ou KSP. + +## Gate opérateur + +Après application du history `alpha.1`, commit/push de `alpha.1`, puis application du présent delta, exécuter depuis la racine du dépôt : + +```bash +cat VERSION + +test -f history/0.1.4/alpha.1.md +test -f deltas/0.1.4/alpha.2.md +test ! -e history/0.1.4/alpha.2.md +test ! -e docs/skeletons/004-TAURI.md + +grep -A4 '^## Statut$' history/0.1.4/alpha.1.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 - <<'PY' +from pathlib import Path +import re + +assert Path('VERSION').read_text(encoding='utf-8').strip() == '0.1.4-alpha.2' + +history = Path('history/0.1.4/alpha.1.md').read_text(encoding='utf-8') +assert re.search(r'## Statut\s+PASS', history) + +assert {p.name for p in Path('deltas/0.1.4').glob('*.md')} == {'alpha.1.md', 'alpha.2.md'} +assert {p.name for p in Path('history/0.1.4').glob('*.md')} == {'alpha.1.md'} + +rule = Path('docs/rules/710-TAURI.md').read_text(encoding='utf-8') +assert rule.startswith('\n') +for phrase in ( + '## Commandes, permissions et capabilities', + 'commande enregistrée → handler natif connu du système d\'invocation', + 'app.security.capabilities', + 'inclut par défaut les capability files du répertoire `capabilities/`', + 'droits cumulés', + 'Le choix ou le renforcement de TS-RS appartient au projet ou au futur skeleton Tauri', + 'host SHOULD être une crate Cargo mixte directement lisible', +): + assert phrase in rule, phrase +for phrase in ( + 'TypeScript et Vite sont fortement recommandés', + 'Bootstrap est la baseline de présentation privilégiée', + 'MUST utiliser TS-RS', +): + assert phrase not in rule, phrase + +study = Path('docs/studies/002-TAURI_SKELETON_DECISION.md').read_text(encoding='utf-8') +assert study.startswith('\n') +for phrase in ( + '## Réexamen décisionnel `0.1.4-alpha.2`', + 'DEFER historique pour absence d\'owners Web LIFT', + 'candidat organisationnel ADOPT FOR MATERIALIZATION', + 'matérialisation visée alpha.3', + 'Le `DEFER` de `0.0.5-alpha.9` reste conservé comme décision historique', +): + assert phrase in study, phrase + +plan = Path('docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md').read_text(encoding='utf-8') +assert plan.startswith('\n') +for phrase in ( + '## Gate `alpha.1` acquise', + '## Réconciliation normative préparée en `alpha.2`', + '## Point transversal découvert pendant la gate `alpha.1`', + 'forte recommandation non obligatoire', + 'sans rechercher automatiquement une version PGR plus récente', + 'howtos, recettes et snippets pratiques vivent dans Knowledge', + 'revue d\'horizon', +): + assert phrase in plan, phrase + +index = Path('docs/000-README.md').read_text(encoding='utf-8') +assert index.startswith('\n') +assert 'owner Tauri 2 réconcilié en `alpha.2`' in index +assert 'candidat organisationnel retenu pour matérialisation contrôlée en `alpha.3`' in index + +roadmap = Path('ROADMAP.md').read_text(encoding='utf-8') +for phrase in ( + '`( ) 0.1.4`', + '`( ) 0.1.5` — adoption réelle de PGR par `sasedev-games`', + '`( ) 0.1.6` — adoption réelle de PGR par `khadhroony-solana-project`', + '`( ) 0.1.7` — audits Python read-only', +): + assert phrase in roadmap, phrase +assert '0.1.8' not in roadmap + +assert not Path('docs/skeletons/004-TAURI.md').exists() +assert not Path('history/0.1.4/alpha.2.md').exists() + +print( + '0.1.4 alpha.2 Tauri normative audit: clean ' + '(ACL boundaries explicit, Web ownership separated, historical DEFER lifted, skeleton still deferred to alpha.3)' +) +PY + +git diff --check +git add VERSION \ + deltas/0.1.4/alpha.2.md \ + docs/000-README.md \ + docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md \ + docs/rules/710-TAURI.md \ + docs/studies/002-TAURI_SKELETON_DECISION.md +git diff --cached --check +git status --short +``` + +Le scope attendu du delta `alpha.2` est : + +```text +M VERSION +A deltas/0.1.4/alpha.2.md +M docs/000-README.md +M docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md +M docs/rules/710-TAURI.md +M docs/studies/002-TAURI_SKELETON_DECISION.md +``` diff --git a/docs/000-README.md b/docs/000-README.md index 80b6184..1115bb7 100644 --- a/docs/000-README.md +++ b/docs/000-README.md @@ -1,5 +1,5 @@ - + # Documentation PGR @@ -23,9 +23,9 @@ Les templates techniques copiables sous `templates/` restent séparés des instr ## 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 actif du réexamen Tauri : audit des hosts Games/KSP actuels, classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, décision contrôlée sur le skeleton et séquencement jusqu'à la stable. -- [`rules/710-TAURI.md`](rules/710-TAURI.md) — owner Tauri 2 à réconcilier avec le corpus courant et la documentation officielle avant toute modification normative. +- [`rules/710-TAURI.md`](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`](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. -- [`studies/002-TAURI_SKELETON_DECISION.md`](studies/002-TAURI_SKELETON_DECISION.md) — décision historique `DEFER`, conditions de sortie et préparation `0.1.1-beta.1` réexaminées par la présente release. +- [`studies/002-TAURI_SKELETON_DECISION.md`](studies/002-TAURI_SKELETON_DECISION.md) — décision historique `DEFER` et réexamen `0.1.4-alpha.2` : motif Web levé, candidat organisationnel retenu pour matérialisation contrôlée en `alpha.3`. - [`../prompts/010-V0_1_4_START_PROMPT.md`](../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 diff --git a/docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md b/docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md index f65eb79..6cf87d5 100644 --- a/docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md +++ b/docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md @@ -1,5 +1,5 @@ - + # Plan 0.1.4 — réexamen Tauri et skeleton contrôlé @@ -234,6 +234,44 @@ normalisation des choix locaux NO `alpha.1` ne crée volontairement pas `docs/skeletons/004-TAURI.md`. La tranche suivante doit d'abord consolider le contrat Tauri actuel, notamment la frontière commandes/capabilities/permissions et la formulation des conventions organisationnelles face aux possibilités officiellement supportées. +## Gate `alpha.1` acquise + +La gate opérateur exécutée le `2026-09-29` est `PASS` : `48/48` tests Python, `266` fichiers Markdown propres, `343` liens locaux propres, audit structurel `96` couples antérieurs / `7` hosts Tauri propre et scope Git exactement conforme au delta. + +Le history `history/0.1.4/alpha.1.md` enregistre cette preuve. Aucun `alpha.1.fix.N` n'est requis. + +## Réconciliation normative préparée en `alpha.2` + +La tranche `alpha.2` resserre le profil `710` sur les responsabilités Tauri réellement possédées : host, orchestration, configuration, ACL/capabilities, plugins, intégration frontend et packaging. Elle retire du profil Tauri le choix direct de la stack Web déjà possédée par les owners `530/540/550/560` et par `003-WEB_FRONTEND.md`. + +Décisions préparées pour la gate : + +```text +710-TAURI.md version 7 +002-TAURI_SKELETON_DECISION.md version 3 +commande / permission / capability séparées +sélection des capabilities décision de sécurité explicite +src-tauri/ supporté, non imposé +host Cargo direct SHOULD pour nouvelle baseline contrôlée +TypeScript / Vite / Sass / Bootstrap owners Web / skeleton, pas owner Tauri +TS-RS conditionnel à la frontière typée réelle +template Tauri DEFER +validation Tauri séparée DEFER +004-TAURI.md toujours absent pendant alpha.2 +``` + +La décision historique `DEFER` de `0.0.5-alpha.9` reste conservée comme preuve historique, mais son motif Web est levé. L'étude révisée autorise donc `alpha.3` à matérialiser la specification `004-TAURI.md` si la présente gate reste propre. + +## Point transversal découvert pendant la gate `alpha.1` + +L'utilisation de PGR pour initialiser SaseDev Knowledge a fait apparaître trois questions de gouvernance qui dépassent le domaine Tauri : + +1. `SHOULD / SHOULD NOT` doit exprimer une forte recommandation non obligatoire, distincte d'un `MUST`, sans transformer automatiquement son écart en échec de gate ou en `OVERRIDE` ; +2. une adoption/instanciation PGR doit produire un projet autonome dont les sessions suivantes utilisent ses propres règles comme autorité, sans rechercher automatiquement une version PGR plus récente ; +3. lorsque SaseDev Knowledge sera suffisamment fonctionnel, PGR devra pouvoir rester concentré sur les contrats de gouvernance réutilisables tandis que howtos, recettes et snippets pratiques vivent dans Knowledge, sans rendre PGR dépendant de Knowledge pour comprendre une règle. + +Ces constats ne constituent pas un défaut du cadrage Tauri `alpha.1` et ne sont donc pas absorbés dans `alpha.2`. Ils MUST être repris dans la revue d'horizon de fermeture de `0.1.4` avant de générer le prompt de la release suivante, afin de décider explicitement si la trajectoire `0.1.5+` doit être réordonnée avant les adoptions Games/KSP. + ## Trajectoire de `0.1.4` ### `alpha.1` — intake, audit et décision de cadrage @@ -288,7 +326,9 @@ Par défaut, l'absence de lacune démontrée signifie **ne pas créer** d'artefa ### `rc.1` — freeze et handoff -Effectuer la gate RC, geler le scope de `0.1.4`, préparer le `CHANGELOG.md` candidate et le prompt ouvrant `0.1.5` consacré à l'adoption Games. Une revue d'horizon est effectuée avant toute réservation au-delà de `0.1.7`. +Effectuer la gate RC, geler le scope de `0.1.4` et préparer le `CHANGELOG.md` candidate. Avant de générer le prompt de la release suivante, effectuer une revue d'horizon qui traite explicitement le point transversal découvert après `alpha.1`. + +Si cette revue confirme la trajectoire existante, le prompt suivant ouvre `0.1.5` pour l'adoption Games. Si elle démontre qu'une release de gouvernance/autonomie doit précéder les adoptions, le roadmap et les numéros suivants sont réordonnés explicitement à ce moment-là plutôt que contournés silencieusement. ### `rel.1` — stable @@ -300,7 +340,7 @@ Promouvoir `0.1.4`, finaliser `README.md`, `ROADMAP.md`, `CHANGELOG.md` et les i La release ne rouvre pas Android `0.1.3` en l'absence de défaut transversal démontré. Les détails générés des projets Android/iOS Tauri restent composés avec leurs owners de plateforme lorsqu'ils sont applicables. -La release ne réserve aucun numéro au-delà de `0.1.7`. Le `CHANGELOG.md` et le `ROADMAP.md` ne sont pas réécrits à l'ouverture `alpha.1` ; ils sont mis à jour dans les phases de fermeture lorsqu'ils décrivent l'état effectivement atteint et la trajectoire confirmée. +La release ne réserve aucun numéro au-delà de `0.1.7`. La trajectoire actuellement publiée conserve `0.1.5` Games, `0.1.6` KSP et `0.1.7` audits Rust jusqu'à la revue d'horizon de fermeture ; cette revue peut la réordonner explicitement si le besoin transversal identifié est confirmé prioritaire. Le `CHANGELOG.md` et le `ROADMAP.md` ne sont pas réécrits prématurément ; ils sont mis à jour dans les phases de fermeture lorsqu'ils décrivent l'état effectivement atteint et la trajectoire confirmée. ## Gate de sortie du plan diff --git a/docs/rules/710-TAURI.md b/docs/rules/710-TAURI.md index 95293d3..d9dc5ac 100644 --- a/docs/rules/710-TAURI.md +++ b/docs/rules/710-TAURI.md @@ -1,5 +1,5 @@ - + # Profil Tauri 2 @@ -54,25 +54,25 @@ Les éléments suivants appartiennent néanmoins au scope Tauri lorsqu'ils exist Leur emplacement exact reste une décision du projet ou du skeleton retenu tant qu'il est supporté par la toolchain. -## Convention renforcée pour les projets contrôlés +## Convention organisationnelle pour les projets contrôlés -Le contrat universel ci-dessus reste compatible avec des projets Tauri imposés de l'extérieur. Pour un **nouveau projet Tauri contrôlé par l'organisation** qui sélectionne le profil strict PGR, les conventions suivantes forment en revanche la baseline recommandée et ne doivent pas être abandonnées sans raison documentée. +Le contrat universel ci-dessus reste compatible avec des projets Tauri imposés de l'extérieur. Pour un **nouveau projet Tauri contrôlé par l'organisation** qui sélectionne le profil strict PGR, le présent owner définit seulement la convention propre au host et à l'intégration Tauri. La sélection de TypeScript, Vite, CSS/Sass, d'un framework CSS ou d'un package manager reste possédée par les owners Web et par la skeleton specification applicable. -Le host SHOULD être une crate Cargo mixte directement lisible, sans couche `src-tauri/` ajoutée uniquement pour reproduire `create-tauri-app`. Le layout recommandé est : +Le host SHOULD être une crate Cargo mixte directement lisible, sans couche `src-tauri/` ajoutée uniquement pour reproduire `create-tauri-app`. Cette recommandation est une convention d'organisation PGR pour les nouveaux projets contrôlés ; elle ne signifie ni que `src-tauri/` est invalide, ni qu'un projet existant doit migrer pour être acceptable. + +La surface Tauri recommandée reste visible à la racine de la crate : ```text / ├── Cargo.toml ├── build.rs -├── package.json -├── tsconfig.json ├── tauri.conf.json ├── capabilities/ ├── src/ -└── frontend/ +└── / ``` -Un fichier comme `vite.config.ts` appartient également à la racine lorsque Vite est le bundler sélectionné. Un projet externe MAY conserver `src-tauri/` ou une autre organisation lorsque cette structure est imposée ou qu'une migration n'apporte pas de valeur suffisante. +`/` représente la racine frontend réellement retenue. Une skeleton PGR MAY choisir `frontend/` comme convention stable, mais `710-TAURI.md` ne transforme pas ce nom en obligation universelle. De même, `package.json`, `tsconfig.json`, `vite.config.ts` ou des sources Sass n'existent que si les owners correspondants sont réellement sélectionnés. Dans le host Rust, le package mixte `lib + bin` constitue l'exception framework explicite à la séparation générale définie par `510-RUST_CARGO.md`. Pour une nouvelle baseline Tauri contrôlée : @@ -86,11 +86,9 @@ Dans le host Rust, le package mixte `lib + bin` constitue l'exception framework Lorsque le workspace possède une crate de logging/tracing commune, le host Tauri l'utilise pour initialiser le runtime de diagnostics. Un plugin Tauri de tracing sert alors d'adapter à la frontière desktop/mobile ; il ne remplace pas l'owner Rust de `tracing-subscriber`, des sinks ou du lifecycle de logging. -Lorsque le frontend sélectionné est TypeScript, les structures, énumérations et DTO Rust **possédés par le host** et partagés avec le frontend MUST utiliser TS-RS comme source de génération dans le profil strict, sauf incompatibilité technique explicitement documentée. Le contrat Rust reste la source de vérité ; les bindings générés ne sont pas modifiés manuellement et SHOULD rester hors Git lorsqu'ils sont entièrement reproductibles. Le skeleton MAY normaliser leur sortie sous `frontend/ts/bindings/`. +Lorsque le frontend sélectionné est TypeScript et que des DTO, structures ou énumérations Rust doivent être partagés, la frontière typée suit [`530-TYPESCRIPT.md`](530-TYPESCRIPT.md). Un générateur tel que TS-RS MAY être retenu comme source de bindings ; le contrat Rust reste alors la source de vérité et les bindings entièrement reproductibles SHOULD rester hors Git. Le choix ou le renforcement de TS-RS appartient au projet ou au futur skeleton Tauri, pas au profil Tauri universel. -Pour les projets contrôlés, `frontend/` est le répertoire recommandé pour les sources Web versionnées. TypeScript et Vite sont fortement recommandés mais restent des `SHOULD`, jamais des obligations universelles. Sass est également fortement recommandé lorsque la chaîne de styles est non triviale ou qu'une dépendance expose des sources Sass/SCSS configurables ; il reste optionnel pour un frontend qui n'en tire pas de valeur. Bootstrap est la baseline de présentation privilégiée lorsque le futur skeleton choisit un framework CSS généraliste, mais il ne devient pas une dépendance Tauri ou Web universelle. Tailwind CSS n'est pas interdit ; son adoption reste une décision explicite du projet. Les règles correspondantes appartiennent aux profils `530`, `550` et `560`, puis au futur skeleton lorsqu'il choisira effectivement cette composition. - -L'intégration d'un plugin SHOULD préférer les étapes explicites décrites par sa documentation — dépendance Cargo, initialisation Rust, package frontend et capabilities nécessaires — afin que chaque modification reste visible et revue. `cargo tauri add` MAY être utilisé lorsque ce raccourci apporte une vraie valeur, mais il n'est pas la voie canonique imposée aux projets contrôlés. +L'intégration d'un plugin SHOULD préférer des étapes explicites ou, si une commande de commodité est utilisée, une revue complète de ses modifications. `cargo tauri add` MAY être utilisé lorsqu'il apporte une valeur réelle ; il n'est pas une voie canonique imposée. WASM reste normalement une unité séparée de la crate Tauri. Une adaptation WASM réutilisable SHOULD donc posséder sa propre crate/package et ses propres profils ; elle n'est intégrée au host Tauri que lorsqu'une composition architecturale explicite l'exige. @@ -150,15 +148,32 @@ Cette classification évite de réécrire `package.json` et `tauri.conf.json` à Les numéros propres aux plateformes, par exemple Android `versionCode`, restent possédés par le profil plateforme concerné et ne sont pas assimilés au SemVer produit. -## Capabilities, permissions et frontière WebView/native +## Commandes, permissions et capabilities -Les capability files et permissions Tauri sont du source de sécurité et SHOULD être versionnés lorsqu'ils définissent intentionnellement la surface exposée au frontend. +Tauri distingue trois responsabilités qui ne doivent pas être confondues : -Le projet SHOULD accorder uniquement les permissions nécessaires aux fenêtres/webviews concernées. Ajouter un plugin ou une commande native ne justifie pas automatiquement une capability globale plus large. +```text +commande enregistrée → handler natif connu du système d'invocation +permission → privilège ACL, avec allow/deny et scopes éventuels +capability → attribution de permissions à des fenêtres/webviews et, le cas échéant, à des origines ou plateformes +``` + +Déclarer un wrapper `#[tauri::command]` ou enregistrer un handler dans l'application n'est donc pas une preuve suffisante de moindre privilège. Le comportement par défaut des commandes applicatives dépend du mécanisme Tauri réellement utilisé ; lorsqu'une commande ou une opération doit être restreinte, le projet MUST matérialiser et valider la politique correspondante au niveau approprié au lieu de supposer que l'enregistrement du handler constitue une ACL. + +Les permissions possèdent les commandes et scopes qu'elles autorisent ou refusent. Les capabilities associent ensuite ces permissions aux fenêtres/webviews concernées. Lorsqu'une fenêtre ou webview appartient à plusieurs capabilities, sa surface effective résulte de leur composition ; la revue MUST donc considérer les droits cumulés, pas chaque fichier isolément. + +Les capability files intentionnels sont du source de sécurité et SHOULD être versionnés. Pour une nouvelle baseline contrôlée, le projet MUST décider explicitement comment les capabilities sont sélectionnées : + +- sélection explicite dans `app.security.capabilities` ; ou +- inclusion automatique des fichiers du répertoire `capabilities/` selon le comportement supporté par la version Tauri retenue. + +Avec Tauri 2 courant, une configuration `app.security.capabilities` absente ou vide inclut par défaut les capability files du répertoire `capabilities/`, tandis qu'une liste explicite permet de sélectionner les capabilities utilisées. Si le projet conserve l'inclusion automatique, ajouter un nouveau capability file MUST être traité comme une modification de la surface de sécurité. Une sélection explicite SHOULD être préférée dès que plusieurs capabilities, fenêtres ou niveaux de privilège rendent l'auto-inclusion moins lisible. + +Le projet SHOULD accorder uniquement les permissions et scopes nécessaires aux fenêtres/webviews concernées. Ajouter un plugin ou une commande native ne justifie pas automatiquement une capability globale plus large. Les schémas générés référencés par les capability files servent à l'outillage et à la validation de configuration ; ils ne deviennent pas pour autant la source normative de la politique de permissions. -Toute permission distante, origine distante ou extension de scope sensible doit être explicitement justifiée et validée comme frontière de sécurité. +Toute permission distante, origine distante ou extension de scope sensible MUST être explicitement justifiée et validée comme frontière de sécurité. ## Plugins diff --git a/docs/studies/002-TAURI_SKELETON_DECISION.md b/docs/studies/002-TAURI_SKELETON_DECISION.md index d6d2667..d3d924d 100644 --- a/docs/studies/002-TAURI_SKELETON_DECISION.md +++ b/docs/studies/002-TAURI_SKELETON_DECISION.md @@ -1,15 +1,15 @@ - + # Décision de skeleton Tauri pour projets contrôlés ## Objet -Cette étude enregistre la décision `0.0.5-alpha.9` sur la matérialisation d'un skeleton Tauri pour les nouveaux projets que l'organisation contrôle. +Cette étude conserve la décision historique `0.0.5-alpha.9` sur la matérialisation d'un skeleton Tauri pour les nouveaux projets que l'organisation contrôle, puis son réexamen formel pendant `0.1.4`. Elle ne redéfinit pas les règles Tauri. Leur owner normatif reste [`../rules/710-TAURI.md`](../rules/710-TAURI.md). Le contrat des skeletons reste possédé par [`../rules/220-SKELETONS.md`](../rules/220-SKELETONS.md). -## Corpus et état observé +## Corpus historique et état observé `0.0.5` Le corpus de réconciliation reste celui de `0.0.5` : @@ -78,7 +78,7 @@ Références vérifiées le `2026-09-25` : - - -## Décision +## Décision historique `0.0.5-alpha.9` Décision `alpha.9` : @@ -232,3 +232,68 @@ création automatique interdite `0.1.4` devra réexaminer le corpus alors courant, les versions/outils réellement soutenus, le profil `710-TAURI.md` et la composition avec `003-WEB_FRONTEND.md`. Il pourra confirmer, modifier ou abandonner le candidat historique. La présente étude ne préjuge pas de cette décision. Le candidat historique `frontend/ + Vite + TypeScript + Sass + Bootstrap + TS-RS` reste donc une observation à réexaminer, pas une baseline déjà approuvée. En particulier, `frontend/`, Vite, Sass et Bootstrap ne deviennent pas des obligations Tauri du seul fait que les owners permettant de les encadrer existent désormais. + +## Réexamen décisionnel `0.1.4-alpha.2` + +`0.1.4-alpha.1` a réaudité le corpus au lieu de prolonger le `DEFER` par inertie. Les baselines réellement fournies sont : + +```text +Games 0.3.6 1 host Tauri +KSP 0.3.19 6 hosts Tauri +``` + +Les `7` hosts actuels convergent encore sur un host Cargo direct `lib + bin`, `build.rs`, `tauri.conf.json`, `capabilities/`, `src/tauri.rs`, une racine frontend dédiée, TypeScript et Vite, sans `src-tauri/`. Games n'exerce toutefois plus les deux hosts du corpus historique, et Bootstrap/Sass/TS-RS, plugins, fenêtres, ACL, ports, bundle/resources et WASM restent suffisamment variables pour ne pas former une baseline Tauri indivisible. + +Les cinq conditions de sortie historiques sont désormais couvertes par les owners Web `530/540/550/560`, `005-WEB_FRONTEND_VALIDATION.md` et `003-WEB_FRONTEND.md`. Le motif Web qui bloquait la matérialisation en `0.0.5` est donc levé. + +La réconciliation de `710-TAURI.md` en révision `7` précise en outre : + +- la distinction entre commande enregistrée, permission et capability ; +- la nécessité de traiter la sélection des capability files comme une décision de sécurité explicite ; +- la composition cumulative des droits lorsqu'une fenêtre/webview appartient à plusieurs capabilities ; +- le statut de `src-tauri/` comme layout supporté, tandis que le host Cargo direct reste une convention PGR recommandée pour les nouvelles baselines contrôlées ; +- l'ownership Web séparé : TypeScript, Vite, Sass/CSS, framework CSS, package manager et génération de bindings ne sont plus choisis par le profil Tauri lui-même ; +- la validation proportionnée par owner plutôt qu'un `tauri build` systématique. + +### Décision active + +La décision active de `0.1.4-alpha.2` est : + +```text +DEFER historique pour absence d'owners Web LIFT +candidat organisationnel ADOPT FOR MATERIALIZATION +skeleton à matérialiser docs/skeletons/004-TAURI.md +matérialisation dans alpha.2 NO +matérialisation visée alpha.3 +``` + +Le `DEFER` de `0.0.5-alpha.9` reste conservé comme décision historique ; il n'est plus la décision active du candidat courant. + +### Composition retenue pour `alpha.3` + +La specification Tauri candidate devra composer, sans duplication normative : + +```text +001-PROJECT_GOVERNANCE_FOUNDATION ++ 002-RUST_CARGO_WORKSPACE ++ 003-WEB_FRONTEND lorsque le projet possède le frontend contrôlé correspondant ++ profil Tauri 710 ++ profils plateforme réellement ciblés +``` + +Le skeleton pourra proposer `frontend/`, TypeScript et Vite comme baseline recommandée pour une nouvelle application contrôlée compatible, mais devra laisser visibles les décisions destinataire et ne pas convertir ces recommandations en obligations Tauri. Sass, Bootstrap, TS-RS, plugins, fenêtres, ports, CSP, bundle targets, ressources et valeurs plateforme restent conditionnels au besoin réel. + +La specification devra également rendre explicite la politique de sélection des capabilities et la revue de la surface de sécurité avant sa gate initiale. + +### Artefacts toujours différés + +Le réexamen ne démontre toujours pas le besoin de créer en `alpha.2` : + +- un template technique Tauri copiable ; +- un contrat de validation Tauri séparé ; +- un catalogue de plugins ou permissions par défaut ; +- un framework CSS universel ; +- un owner iOS, serveur Rust ou deployment/operations par proximité. + +Ces décisions restent à réévaluer après matérialisation de la specification, conformément au plan `0.1.4`. + diff --git a/history/0.1.4/alpha.2.md b/history/0.1.4/alpha.2.md new file mode 100644 index 0000000..936018b --- /dev/null +++ b/history/0.1.4/alpha.2.md @@ -0,0 +1,105 @@ + + + +# History 0.1.4-alpha.2 — réconciliation normative Tauri + +## Statut + +FAIL + +La gate opérateur de `0.1.4-alpha.2` exécutée le `2026-09-29` valide les tests, audits Markdown et contrôles structurels Tauri, mais échoue sur l'hygiène Git : `docs/studies/002-TAURI_SKELETON_DECISION.md` contient une ligne vide finale supplémentaire. La tranche ne peut donc pas être déclarée `PASS` et doit être corrigée par `0.1.4-alpha.2.fix.1`. + +## Baseline opérateur + +Le history `PASS` de `0.1.4-alpha.1` a été ajouté, committé et publié avant application de `alpha.2` : + +```text +commit alpha.1 7f47558 +push fe80dbb..7f47558 master -> master +``` + +La version observée pendant la gate est : + +```text +0.1.4-alpha.2 +``` + +`history/0.1.4/alpha.1.md` est présent et son statut est `PASS`. `history/0.1.4/alpha.2.md` était absent pendant la gate, conformément au workflow. + +## Tests Python + +La suite complète a affiché : + +```text +Ran 48 tests in 0.705s + +OK +``` + +Soit `48/48` tests `PASS`. + +## Audits Markdown + +Les trois audits documentaires ont affiché : + +```text +Markdown header audit: clean (268 file(s)) +Markdown table audit: clean (11 table(s), 268 file(s)) +Markdown link audit: clean (344 local link(s), 268 file(s)) +``` + +## Gate normative Tauri + +Le contrôle spécifique de `alpha.2` a terminé proprement : + +```text +0.1.4 alpha.2 Tauri normative audit: clean (ACL boundaries explicit, Web ownership separated, historical DEFER lifted, skeleton still deferred to alpha.3) +``` + +Il confirme notamment : + +- `710-TAURI.md` en révision `7` avec séparation explicite commande / permission / capability ; +- séparation des responsabilités Tauri et Web ; +- levée du motif historique du `DEFER` dans l'étude `002` ; +- matérialisation du skeleton Tauri toujours réservée à `alpha.3` ; +- absence de `docs/skeletons/004-TAURI.md` pendant cette tranche ; +- trajectoire publiée `0.1.5` Games / `0.1.6` KSP / `0.1.7` audits toujours inchangée pendant `alpha.2`. + +## Échec d'hygiène Git + +`git diff --check` a signalé : + +```text +docs/studies/002-TAURI_SKELETON_DECISION.md:299: new blank line at EOF. +``` + +Après indexation du scope de `alpha.2`, `git diff --cached --check` a signalé exactement la même erreur : + +```text +docs/studies/002-TAURI_SKELETON_DECISION.md:299: new blank line at EOF. +``` + +Le défaut est donc reproductible avant et après staging. Il s'agit d'une ligne vide terminale surnuméraire introduite par le delta, pas d'un écart opérateur. + +Le statut indexé observé est : + +```text +M VERSION +A deltas/0.1.4/alpha.2.md +M docs/000-README.md +M docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md +M docs/rules/710-TAURI.md +M docs/studies/002-TAURI_SKELETON_DECISION.md +``` + +Le scope fonctionnel annoncé est donc respecté, mais la preuve d'hygiène obligatoire échoue. + +## Décision + +`0.1.4-alpha.2` est `FAIL`. + +Le contenu normatif Tauri validé par les contrôles spécifiques n'est pas remis en cause. `0.1.4-alpha.2.fix.1` doit : + +1. supprimer la ligne vide surnuméraire à EOF de l'étude `002` ; +2. ajouter un contrôle automatique monotâche empêchant cette classe de défaut sur les futurs fichiers texte gouvernés ; +3. conserver les décisions Tauri de `alpha.2` sans commencer `alpha.3`.