Sign the macOS bundle with an ad-hoc identity

.github/workflows/publish-release.yml

@@ -110,4 +110,4 @@ jobs:
           gh release create "$RELEASE_TAG" release-assets/* \
             --verify-tag \
             --title "EnvEdit $RELEASE_TAG" \
-            --notes "Paquets Linux, Windows et macOS générés automatiquement après validation de main. L'installateur macOS reste expérimental et les installateurs ne sont pas signés ni notarisés."
+            --notes "Paquets Linux, Windows et macOS générés automatiquement après validation de main. L'installateur macOS reste expérimental. Son bundle porte une signature ad hoc vérifiable et n'est pas notarié. Les installateurs Linux et Windows ne sont pas signés."

README.md

@@ -195,8 +195,9 @@ git push origin vX.Y.Z
 
 La CI produit des builds Windows/macOS **expérimentaux** ; elle ne valide pas encore
 les parcours manuels et la parité de sauvegarde exigés par `ACCEPTANCE.md`. Leur
-distribution comme versions prises en charge reste différée. Les installateurs ne
-sont pas encore signés ni, pour macOS, notarisés. Aucun déploiement n'est déclenché
+distribution comme versions prises en charge reste différée. Le paquet macOS porte
+une signature ad hoc vérifiable. Il n'est pas notarié. Les installateurs Linux et
+Windows ne sont pas signés. Aucun déploiement n'est déclenché
 par une PR ni par un simple push sur `main`.
 
 La configuration réside dans `$XDG_CONFIG_HOME/envedit/catalog.json` (ou

docs/plans/20261030162015-signature-macos-valide-plan.md

@@ -0,0 +1,95 @@
+---
+name: Signature macOS techniquement valide
+overview: Le bundler macOS signe le bundle en ad hoc avant de produire le DMG, et les textes du prochain build décrivent ce niveau.
+todos:
+  - id: D1.1
+    content: Signer le bundle macOS en ad hoc
+    status: done
+  - id: D2.1
+    content: Aligner les textes sur la signature ad hoc
+    status: done
+statut: "✅ Validé"
+creation: "30/10/2026 16:24"
+modification: "02/11/2026 13:34"
+---
+
+# Plan : Signature macOS techniquement valide
+
+**Statut** : ✅ Validé
+
+| Specs | Recette | Review |
+|:------|:--------|:-------|
+| [`20261030162015-signature-macos-valide-specs.md`](../specs/20261030162015-signature-macos-valide-specs.md) | [`20261030162015-signature-macos-valide-recette.md`](../recettes/20261030162015-signature-macos-valide-recette.md) | [`20261030162015-signature-macos-valide-review.md`](../reviews/20261030162015-signature-macos-valide-review.md) |
+
+---
+
+> **À l'implémentation.** `/imp-work` n'exécute que les développements `🔨 À développer`. Ne pas redéfinir le besoin. Ne pas écrire le cahier. Ne pas passer en `✅ Validé`.
+>
+> **Cascade.** Une modification de ce plan entraîne **obligatoirement** une révision de la recette **si** le cahier existe.
+>
+> **Backlog.** Seul `imp-backlog` met à jour `BACKLOG.md`. Ce fichier ne l'écrit pas.
+
+---
+
+## D1 — Prochain paquet macOS à signature cohérente
+
+| Spec | [S1](../specs/20261030162015-signature-macos-valide-specs.md) |
+|:-----|:---|
+
+> je veux que la vérification de signature réussisse sur le prochain paquet macOS, tout en restant distincte d'une distribution publique identifiée
+
+### D1.1 — Signer le bundle macOS en ad hoc
+
+**Statut** : ✅ Validé
+
+#### Solution technique
+
+Dans `src-tauri/tauri.conf.json`, ajouter `bundle.macOS.signingIdentity` avec la valeur `"-"`. C'est l'identité ad hoc de `codesign`. Au `tauri build`, le bundler signe alors le `.app` avant de construire le DMG. `hardenedRuntime` reste à son défaut, `true` : la signature porte le runtime durci.
+
+Sans cette identité, `keychain()` ne reçoit ni certificat ni identité et ne signe pas. Le binaire garde la signature du linker (`adhoc,linker-signed`), `Contents/Resources` existe, et `codesign --verify` lève `errSecCSResourcesNotFound`. La signature ad hoc écrit `Contents/_CodeSignature/CodeResources` et fait réussir la vérification. `TeamIdentifier` reste vide, donc l'évaluation pour une distribution identifiée échoue encore.
+
+La commande de build ne change pas. Aucun secret. La version 1.0.0 déjà publiée n'est pas reconstruite ni réémise.
+
+Les suites automatiques du dépôt ne construisent pas ce bundle et ne lisent pas sa signature. Le contrôle de D1.1 est le scénario manuel du cahier.
+
+#### Notes d'implémentation
+
+`signingIdentity` est en place. Aucun test automatisé ne vise `tauri.conf.json` : contrôle ciblé NON_EXÉCUTÉ. La reconstruction locale du bundle est INDISPONIBLE : `cargo` et `rustc` sont absents de cette machine. Le scénario R1.1 reste à jouer là où la toolchain Rust est installée.
+
+#### Code existant concerné
+
+| Chemin | Rôle |
+|:-------|:-----|
+| `src-tauri/tauri.conf.json` | Configuration de bundle. Aucun bloc `macOS` aujourd'hui. |
+| `.github/workflows/publish-release.yml` | Lance `npm run tauri build -- --bundles dmg` sans identité. La commande reste. |
+| `.github/workflows/prepare-release.yml` | Même commande de bundle macOS expérimental. Elle reste. |
+
+---
+
+## D2 — Textes alignés sur ce niveau de signature
+
+| Spec | [S2](../specs/20261030162015-signature-macos-valide-specs.md) |
+|:-----|:---|
+
+> je veux que la documentation et la note de la prochaine publication disent la vérité sur ce niveau de signature
+
+### D2.1 — Aligner les textes sur la signature ad hoc
+
+**Statut** : ✅ Validé
+
+#### Solution technique
+
+Deux phrases disent aujourd'hui que les installateurs ne sont pas signés. Après D1.1, c'est faux pour le paquet macOS du prochain build.
+
+Dans `README.md`, remplacer « Les installateurs ne sont pas encore signés ni, pour macOS, notarisés. » par une phrase qui dit : le paquet macOS porte une signature ad hoc vérifiable ; il n'est pas notarié ; les installateurs Linux et Windows ne sont pas signés. La phrase suivante, sur l'absence de déploiement par une PR ou un push sur `main`, reste.
+
+Dans `.github/workflows/publish-release.yml`, la note passée à `gh release create` dit « les installateurs ne sont pas signés ni notarisés ». La remplacer par : l'installateur macOS reste expérimental, son bundle porte une signature ad hoc vérifiable et n'est pas notarié, les installateurs Linux et Windows ne sont pas signés. Le reste de la note (génération après validation de `main`) reste.
+
+`ACCEPTANCE.md`, `IMPLEMENTATION.md`, `SPEC.md`, `TECHNICAL.md` et `docs/DEVELOPMENT.md` disent que la validation fonctionnelle macOS est différée. Ces phrases restent vraies. On n'y touche pas.
+
+#### Code existant concerné
+
+| Chemin | Rôle |
+|:-------|:-----|
+| `README.md` | Phrase « Les installateurs ne sont pas encore signés ni, pour macOS, notarisés. » |
+| `.github/workflows/publish-release.yml` | Note `--notes` de `gh release create`. |

docs/recettes/20261030162015-signature-macos-valide-recette.md

@@ -0,0 +1,113 @@
+---
+name: Signature macOS techniquement valide
+overview: Vérifier que le prochain paquet macOS a une signature cohérente, qu'il reste refusé comme distribution identifiée, et que les textes disent ce niveau.
+creation: "30/10/2026 16:24"
+modification: "02/11/2026 13:46"
+---
+
+# Recette : Signature macOS techniquement valide
+
+| Specs | Plan | Review |
+|:------|:-----|:-------|
+| [`20261030162015-signature-macos-valide-specs.md`](../specs/20261030162015-signature-macos-valide-specs.md) | [`20261030162015-signature-macos-valide-plan.md`](../plans/20261030162015-signature-macos-valide-plan.md) | [`20261030162015-signature-macos-valide-review.md`](../reviews/20261030162015-signature-macos-valide-review.md) |
+
+> Cahier **manuel + automatique**, guidé par `/imp-recette`. Haut : tests manuels (`R1.n`) — init `🧪 À recetter`, date `—`. Seul l'utilisateur passe une ligne manuelle en `✅ Validé` (date `jj/mm/aaaa`). Bas : `## Tests automatiques` — init `⏳ Non lancé`, date `—`. `/imp-test` évalue tous les contrôles attendus de chaque couple visé, avec une preuve de lancement ; un lancement incomplet ou indisponible ne devient pas vert.
+>
+> **Cascade.** Une modification des specs ou du plan entraîne **obligatoirement** une révision de cette recette.
+>
+> **Backlog.** Seul `imp-backlog` met à jour `BACKLOG.md`. Ce fichier ne l'écrit pas.
+
+---
+
+## R1 — Prochain paquet macOS à signature cohérente
+
+| Spec | [S1](../specs/20261030162015-signature-macos-valide-specs.md) |
+|:-----|:---|
+
+> je veux que la vérification de signature réussisse sur le prochain paquet macOS, tout en restant distincte d'une distribution publique identifiée
+
+### R1.1 — Vérifier la signature du prochain paquet
+
+| Statut | Date | Spec | Plan | Review |
+|:-------|:-----|:-----|:-----|:-------|
+| ✅ Validé | 02/11/2026 | [S1](../specs/20261030162015-signature-macos-valide-specs.md) | [D1.1](../plans/20261030162015-signature-macos-valide-plan.md) | [V1.1](../reviews/20261030162015-signature-macos-valide-review.md) |
+
+**Contexte**
+
+Un Mac Apple Silicon. Le paquet à contrôler est celui produit par le build qui contient le correctif, pas le DMG déjà publié en 1.0.0.
+
+**Je fais**
+
+1. Construire le paquet macOS depuis la branche du correctif : `npm run tauri build -- --bundles dmg`.
+2. Ouvrir l'application produite dans ce paquet.
+3. Lancer `codesign --verify --deep --strict` sur cette application, puis `codesign -d --verbose=4`.
+4. Lancer `spctl --assess --type execute` sur la même application.
+5. Ouvrir la release GitHub `v1.0.0` et comparer son asset macOS à celui qui était déjà publié.
+
+**Il doit se passer**
+
+La vérification de signature réussit. L'évaluation pour une distribution identifiée échoue. La release `v1.0.0` n'a pas changé d'asset.
+
+**Je dois voir**
+
+- `valid on disk` et `satisfies its Designated Requirement`.
+- Une signature ad hoc avec runtime durci, des ressources scellées, et `TeamIdentifier=not set`.
+- `spctl` répond `rejected`.
+- L'asset macOS de `v1.0.0` est toujours celui publié le 29 octobre 2026.
+
+---
+
+## R2 — Textes alignés sur ce niveau de signature
+
+| Spec | [S2](../specs/20261030162015-signature-macos-valide-specs.md) |
+|:-----|:---|
+
+> je veux que la documentation et la note de la prochaine publication disent la vérité sur ce niveau de signature
+
+### R2.1 — Lire les textes du prochain build
+
+| Statut | Date | Spec | Plan | Review |
+|:-------|:-----|:-----|:-----|:-------|
+| ✅ Validé | 02/11/2026 | [S2](../specs/20261030162015-signature-macos-valide-specs.md) | [D2.1](../plans/20261030162015-signature-macos-valide-plan.md) | [V2.1](../reviews/20261030162015-signature-macos-valide-review.md) |
+
+**Contexte**
+
+Le README du dépôt et la note que le workflow de publication joindra à la prochaine release. Les documents qui reportent la validation fonctionnelle macOS sont encore ceux d'aujourd'hui.
+
+**Je fais**
+
+1. Lire le paragraphe de `README.md` qui décrit la signature des installateurs.
+2. Lire la note `--notes` de `gh release create` dans `.github/workflows/publish-release.yml`.
+3. Relire les phrases de `ACCEPTANCE.md` et `IMPLEMENTATION.md` qui reportent la validation macOS.
+
+**Il doit se passer**
+
+Les deux premiers textes décrivent une signature macOS vérifiable et l'absence de notarisation. Les phrases de validation différée sont toujours là.
+
+**Je dois voir**
+
+- Le README dit que le paquet macOS a une signature ad hoc vérifiable, qu'il n'est pas notarié, et que les installateurs Linux et Windows ne sont pas signés.
+- La note de la prochaine publication dit la même chose, et que l'installateur macOS reste expérimental.
+- `ACCEPTANCE.md` et `IMPLEMENTATION.md` disent encore que la validation macOS est différée.
+
+---
+
+## Tests automatiques
+
+> Filet **du projet** — pas de pont `D1.n` ↔ ligne, pas d'id `R`, pas d'étapes à jouer à la main. Une ligne par couple environnement × type **réellement disponible**. Clé = Environnement + Type. États et preuve de lancement : contrat de `imp-test/SKILL.md`, section Cahier. Un vert historique ne prouve pas que le code courant a été testé.
+>
+> Aucune suite sur le projet → une phrase ici, **pas** de ligne inventée.
+
+| Environnement | Type | Statut | Date |
+|:--------------|:-----|:-------|:-----|
+| front | unitaire | ✅ Validé | 30/10/2026 |
+| src-tauri | unitaire | ✅ Validé | 30/10/2026 |
+| legacy | unitaire | ✅ Validé | 30/10/2026 |
+
+Preuve du 30/10/2026 16:36. Commit `58c1570`, changements non commités : `README.md` `b357c7dcef74`, `src-tauri/tauri.conf.json` `ef3971e87764`, `.github/workflows/publish-release.yml` `b6c436090221`.
+
+- front unitaire — `npm test` (`vitest run`). PASS. 3 fichiers, 21 tests, 0 échec, 0 ignoré.
+- src-tauri unitaire — `cargo test --locked --manifest-path src-tauri/Cargo.toml`. PASS. `src/lib.rs` : 21 tests, 0 échec, 0 ignoré. `src/main.rs` et doctests : 0 test.
+- legacy unitaire — `python3 -m pytest` dans `legacy/python-gtk`. PASS. 25 tests, 0 échec.
+
+Tentative historique du 30/10/2026 16:31 : front PASS (21), src-tauri et legacy INDISPONIBLES. Elle ne vaut plus pour l'état actuel.

docs/reviews/20261030162015-signature-macos-valide-review.md

@@ -0,0 +1,73 @@
+---
+name: Signature macOS techniquement valide
+overview: Les deux développements livrés correspondent aux specs et au plan. Aucun correctif.
+todos: []
+creation: "30/10/2026 16:31"
+modification: "30/10/2026 16:31"
+---
+
+# Review : Signature macOS techniquement valide
+
+| Specs | Plan | Recette |
+|:------|:-----|:--------|
+| [`20261030162015-signature-macos-valide-specs.md`](../specs/20261030162015-signature-macos-valide-specs.md) | [`20261030162015-signature-macos-valide-plan.md`](../plans/20261030162015-signature-macos-valide-plan.md) | [`20261030162015-signature-macos-valide-recette.md`](../recettes/20261030162015-signature-macos-valide-recette.md) |
+
+---
+
+> **À l'implémentation.** `/imp-work` n'exécute que les correctifs `🔨 À développer`. Ids `V1.n` ↔ `D1.n`. Ordre du fichier **et** des `todos` : 🚨 Critique → ⚠️ Important → 💡 Mineur (à égalité : ordre du plan). Avancement : **ce fichier seulement**. Ne pas écrire le cahier. Ne pas passer en `✅ Validé`.
+>
+> **Backlog.** Seul `imp-backlog` met à jour `BACKLOG.md`. Ce fichier ne l'écrit pas.
+
+---
+
+## Synthèse
+
+D1.1 et D2.1 sont `🧪 À recetter`. Le code touche les trois chemins du plan et rien d'autre. `bundle.macOS.signingIdentity` vaut `"-"`. `hardenedRuntime` n'est pas écrit, donc le défaut du bundler reste. Les commandes de build des workflows ne changent pas. Le README et la note de publication disent une signature ad hoc vérifiable, l'absence de notarisation, et que Linux et Windows ne sont pas signés. Les documents de validation macOS différée ne sont pas modifiés. Aucun écart, aucun bug dans ce diff, aucun correctif.
+
+---
+
+## Écarts specs ↔ code
+
+RAS.
+
+---
+
+## Régressions et impacts
+
+RAS. Le diff n'atteint pas le parseur, la sauvegarde ni l'interface.
+
+---
+
+## Conventions du projet
+
+RAS. Le JSON reste en indentation de 2. Les phrases ajoutées restent dans le registre du README et de la note existante.
+
+---
+
+## Bugs
+
+RAS.
+
+---
+
+## Performances
+
+RAS.
+
+---
+
+## Optimisations
+
+RAS.
+
+---
+
+## Refactorings
+
+RAS.
+
+---
+
+## Sécurité
+
+RAS. Aucun secret ajouté. L'identité `"-"` n'est pas un certificat.