premier essaie

A_FAIRE.md

@@ -0,0 +1,91 @@
+# À faire avant la première installation
+
+Deux points restés en suspens à la livraison du paquet, à traiter quand tu voudras
+déployer. Rien ici n'est bloqué par le code : tout fonctionne, il manque des
+informations que seul toi peux fournir.
+
+---
+
+## 1. Remplacer l'URL de démonstration et déposer la release
+
+Le `manifest.toml` porte une URL **fictive** (`gitea.example.org`) : le paquet ne
+pouvait pas connaître ton vrai domaine Gitea au moment de sa création. En l'état,
+l'installation échouerait au téléchargement de l'archive.
+
+### Ce qu'il faut faire
+
+**a. Créer la release du code.** Sur le dépôt `mabibli` (celui du code C#, pas
+celui-ci) :
+
+```
+git tag v0.1.0
+git push origin v0.1.0
+```
+
+Puis créer la release correspondante dans l'interface Gitea et y téléverser
+l'archive `build/dist/mabibli-0.1.0-linux-x64.tar.gz`.
+
+⚠️ L'archive fait **68 Mo** — c'est normal, le publish est *self-contained* et
+embarque le runtime .NET. C'est précisément ce qui évite d'installer
+`dotnet-runtime` sur le serveur YunoHost.
+
+**b. Régénérer le manifeste avec la vraie URL :**
+
+```
+./build/publier-release.sh --base-url <ton URL Gitea réelle>
+```
+
+Le script recompile, produit l'archive, calcule son `sha256` et l'inscrit dans le
+`manifest.toml` avec la bonne URL. Committer ensuite le manifeste modifié.
+
+**c. Chercher les autres occurrences du domaine fictif**, qui ne sont pas couvertes
+par le script :
+
+```
+grep -rn "gitea.example.org" .
+```
+
+Elles se trouvent dans `manifest.toml` (champ `upstream.code`), `README.md`, et
+`conf/systemd.service` (directive `Documentation=`).
+
+### Comment vérifier
+
+Le `sha256` du manifeste doit correspondre à l'archive réellement déposée :
+
+```
+sha256sum build/dist/mabibli-0.1.0-linux-x64.tar.gz
+grep sha256 manifest.toml
+```
+
+S'ils diffèrent, l'installation s'interrompra à la vérification d'intégrité — ce qui
+est le comportement souhaité, mais autant le savoir avant.
+
+---
+
+## 2. L'application exige un domaine entier, pas un sous-chemin
+
+**Contrainte technique, pas un choix.** MaBibli doit être installée sur
+`mabibli.mondomaine.tld`, et **non** sur `mondomaine.tld/mabibli`.
+
+### Pourquoi
+
+Deux éléments sont figés **à la compilation** du client Blazor WebAssembly :
+
+- la balise `<base href="/">` de `index.html`, qui détermine la racine de toutes les
+  URL de l'application ;
+- les empreintes d'intégrité inscrites dans `service-worker-assets.js`, qui
+  garantissent que le service worker sert bien les fichiers attendus.
+
+Réécrire ces valeurs sur le serveur au moment de l'installation casserait les
+empreintes, donc le service worker, donc le fonctionnement hors-ligne. Et comme
+rien n'est recompilé côté serveur — c'est tout l'intérêt du déploiement
+self-contained —, il n'existe pas de solution propre pour un sous-chemin.
+
+Le paquet déclare donc l'application en `full_domain` auprès de YunoHost, qui
+demandera un domaine dédié à l'installation.
+
+### Si tu voulais lever cette contrainte plus tard
+
+Il faudrait produire une archive **par chemin d'installation**, ou recompiler sur le
+serveur. Les deux annulent le bénéfice du self-contained. À moins d'un besoin réel,
+un sous-domaine reste la bonne réponse.