# À 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.