# À faire avant la première installation

État au 2026-08-18. Ce qui est fait est conservé en bas de page : le savoir *pourquoi*
c'était à faire reste utile à la prochaine version.

---

## 1. Rendre le dépôt du code accessible sans authentification — BLOQUANT

`ynh_setup_source` télécharge l'archive **sans jeton**. Tant que le dépôt `mabibli`
est privé, l'installation échoue au téléchargement.

### Le symptôme, et pourquoi il induit en erreur

Constaté le 2026-08-18, sans authentification :

```
/mathieu/mabibli                      → 404
/mathieu/mabibli/releases             → 404
/api/v1/repos/mathieu/mabibli         → 404
```

Gitea répond **404 et non 403** à un visiteur anonyme sur un dépôt privé, pour ne pas
révéler son existence. Le symptôme est donc **exactement le même** que « la release
n'a pas été créée » ou « le fichier n'a pas été téléversé ». Ne pas chercher du côté
de la release avant d'avoir réglé la visibilité : les deux causes sont indiscernables.

Que le dépôt existe bien est vérifiable autrement, par SSH (clé, donc authentifié) :

```
git ls-remote --tags origin
```

### Ce qu'il faut faire

Dans Gitea, sur le dépôt `mathieu/mabibli` : *Settings → Danger Zone → Make
repository public*. Le code est déjà sous AGPL-3.0-or-later, la publication est
cohérente avec la licence.

Si le dépôt doit rester privé, il faut héberger l'archive ailleurs, sur une URL
publique, et faire pointer `--base-url` dessus. Un jeton dans l'URL du manifeste
serait à écarter : le manifeste est lu par YunoHost et lisible sur le serveur.

---

## 2. Créer la release et y téléverser l'archive

À faire (ou à vérifier — voir point 1, tant que le dépôt est privé on ne peut pas
savoir si c'est déjà fait).

Le tag est déjà poussé : `v0.1.0` → `922fd02`. Reste à créer la release
correspondante dans l'interface Gitea et à y téléverser :

```
build/dist/mabibli-0.1.0-linux-x64.tar.gz
```

⚠️ **L'archive à téléverser est celle produite le 2026-08-18**, `sha256`
`e3316bd05cd71234403695bab405f48009d8d6186b0074235396d622c8c0caef`. Une archive plus
ancienne traînant sur le disque ne correspondrait plus au manifeste, et
l'installation s'interromprait à la vérification d'intégrité — comportement voulu,
mais autant ne pas s'y heurter.

⚠️ Elle fait **69 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.

### Comment vérifier

```
curl -fsSLI "https://git.akbar.nohost.me/mathieu/mabibli/releases/download/v0.1.0/mabibli-0.1.0-linux-x64.tar.gz" | head -1
```

Doit répondre `HTTP/2 200`, **sans être connecté**. Et 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
```

---

## 3. Committer et pousser le paquet

Le manifeste corrigé n'est pas encore poussé. `yunohost app install <url du dépôt>`
lit le manifeste **depuis Gitea**, pas depuis la copie locale : sans ce push,
l'installation repartira sur l'ancienne URL fictive.

```
git add -A && git commit && git push
```

---

# Contrainte permanente — ce n'est pas une tâche

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

---

# Fait

## L'URL de démonstration a été remplacée — 2026-08-18

Le `manifest.toml` portait une URL **fictive** (`gitea.example.org`) : le paquet ne
pouvait pas connaître le vrai domaine Gitea au moment de sa création. Constaté en
conditions réelles — l'installation s'arrête net au `Prefetching asset main`.

Corrigé par `./build/publier-release.sh`, qui recompile, vérifie le publish, produit
l'archive, calcule son `sha256` et l'inscrit dans le manifeste avec la bonne URL.
`https://git.akbar.nohost.me/mathieu/mabibli/releases/download` est désormais la
valeur **par défaut** de `--base-url` dans le script : l'option n'est plus à passer.

Les occurrences hors manifeste, que le script ne touche pas, ont été traitées à la
main : `README.md` et `conf/systemd.service` (directive `Documentation=`). Le
contrôle reste `grep -rn "gitea.example.org" .` — il ne doit plus rien remonter que
ce fichier-ci.

## L'archive ne va plus dans git — 2026-08-18

`build/dist/` est ignoré. L'archive vit dans la release Gitea ; committée, elle
ajouterait 69 Mo d'historique **par version**, définitivement.