Consigne ce que le paquet YunoHost a appris de sa propre mesure

Trois items ouverts d'IDEES.md instruits sur pieces, et deux conclusions
renversees en chemin — c'est ce que ces notes servent a ne pas refaire.

Le paquet n'avait presque rien a simplifier : neuf fichiers, 209 lignes de
code, de 9 a 49 lignes chacun. Ce qui donnait l'impression de volume, ce sont
les 306 lignes de commentaires, qui documentent chacune une panne reellement
constatee. Tout le poids etait dans publier.sh, 1,4 fois le paquet reuni.

Le menu interactif de choix de version paraissait le meilleur candidat a la
coupe, jusqu'a ce que les neuf montees de version montrent six correctifs ET
trois sauts mineurs. Il sert une fois sur trois : mesurer avant de tailler vaut
aussi pour l'outillage.

L'icone du paquet : logo.png n'est lu par personne. Les logos du catalogue
vivent dans le depot YunoHost/apps, ou MaBibli n'est pas ; la tuile du portail
accepte un logo televerse depuis la 12.1, et le manifeste exige deja 12.1.38.
Il n'y a donc rien a corriger dans le depot.

La RAM est mesuree et ram.runtime porte a 256M. Le pic n'est pas le lookup
ISBN, contrairement a l'intuition, mais « Nouveautes » sur un auteur tres
reedite — cas qui n'a pas encore ete mesure et qui croit avec le fonds.

Le README cesse de decrire --archive-seule comme une brique de CI et retire le
« --version est obligatoire ici », piege qui n'existe plus.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -2006,10 +2006,134 @@ Les deux scripts sont fondus dans `build/publier.sh`, qui refuse maintenant de p
 **avant de compiler** si le tag existe déjà (en nommant le commit du tag et celui de
 HEAD) ou si le dépôt du code a des modifications non committées.
 
-⚠️ Le mode `--archive-seule` conserve la brique réutilisable en CI, mais **sous le même
-nom** : il compile et archive sans toucher ni au manifeste ni à git, donc il ne peut
-rien laisser à moitié publié. Ne pas recréer de second script — c'est la coexistence de
-deux commandes voisines qui était le défaut, pas leur contenu.
+⚠️ Le mode `--archive-seule` conserve, **sous le même nom**, ce que le second script
+savait faire : il compile et archive sans toucher ni au manifeste ni à git, donc il ne
+peut rien laisser à moitié publié. Ne pas recréer de second script — c'est la
+coexistence de deux commandes voisines qui était le défaut, pas leur contenu.
+
+### ⚠️ `--archive-seule` n'est PAS une brique de CI — rangé le 2026-08-22
+
+C'est ce que cette section a affirmé jusqu'au 2026-08-22, et c'était faux. Le `README`
+du dépôt du code s'en sert depuis toujours pour tout autre chose, sur une trentaine de
+lignes : c'est le **chemin de reprise à la main** quand `publier.sh` échoue en cours de
+route (section B.3).
+
+La distinction n'est pas académique. Sur la foi de « une brique pour une CI qui n'existe
+pas », le mode partait à la casse ; sur celle de « le seul moyen de finir une
+publication interrompue sans re-déclencher les garde-fous », il reste. **Un usage qui
+n'a jamais servi n'est pas un usage inutile quand c'est un extincteur** — et l'historique
+du shell confirme qu'il n'a effectivement jamais été lancé, faute d'avoir jamais eu à
+reprendre à la main.
+
+Ce que le rangement a changé, et qui vaut au-delà de ce script :
+
+| Avant | Après |
+|---|---|
+| 8 ramifications sur `archive_seule`, dont **3 assouplissaient un garde-fou** | 5, dont **une seule** exprime la différence de mode |
+| le dépôt sale n'était **pas signalé du tout** — l'archive contenait en silence du travail non committé | tous les contrôles s'exécutent et **avertissent** |
+| la version retombait sur celle du **manifeste**, donc sur la version **déjà publiée** | même calcul dans les deux modes |
+| le dépôt git n'était exigé qu'en publication (4 tests `-d .git` plus bas) | exigé une fois, en tête ; le reste du script est inconditionnel |
+
+⚠️ **Le piège que la version retombée sur le manifeste créait était documenté au lieu
+d'être corrigé** : le `README` portait un « `--version` est obligatoire ici », qui
+n'existe plus. Une reprise veut la version qu'on était en train de publier — c'est
+exactement ce que l'incrément propose.
+
+⚠️ **`refuser()` sépare le CONSTAT du CONSEIL**, et ce n'est pas de la cosmétique : le
+constat reste vrai dans les deux modes, le conseil non. « Choisissez un numéro libre »
+est juste pour une publication et faux en reprise, où le tag visé est justement celui
+qu'on veut retrouver.
+
+⚠️ **Les cinq variables d'environnement jumelles ont disparu** (`MABIBLI_SOURCE_DIR`,
+`MABIBLI_BASE_URL`, `MABIBLI_URL_RELEASES`, `MABIBLI_OUTPUT_DIR`, `MABIBLI_VERSION`) :
+chacune doublait une option qu'elle ne faisait que répéter, l'aide en listait dix pour
+cinq réglages, et rien ne disait laquelle l'emportait. Ne pas les réintroduire pour une
+CI hypothétique — une CI passe des options aussi bien que des variables.
+
+### Ce que la mesure a montré, et qu'il ne faut pas re-chercher ailleurs
+
+Le paquet lui-même **n'a rien à simplifier** : neuf fichiers, **209 lignes de code** au
+total, de 9 à 49 lignes chacun. Ce qui donne l'impression de volume, ce sont les **306
+lignes de commentaires** — qui documentent chacune une panne réellement constatée
+(guillemetage d'`Environment=`, `ProtectHome=tmpfs`, `WorkingDirectory`, `.backup` en
+WAL). Les couper rendrait les fichiers plus courts et le paquet plus dangereux.
+
+Tout le poids est dans `publier.sh` : **298 lignes de code avant rangement, soit 1,4
+fois tout le paquet réuni**, dont un tiers pour choisir un numéro de version et analyser
+des drapeaux.
+
+⚠️ **Le menu interactif de version, lui, reste** : il paraissait le meilleur candidat à
+la coupe, jusqu'à ce que les neuf montées de version montrent **six correctifs et trois
+sauts mineurs**. Il sert une fois sur trois. Mesurer avant de tailler vaut aussi pour
+l'outillage.
+
+### L'icône du paquet — `logo.png` n'est lu par personne (établi le 2026-08-22)
+
+`mabibli_ynh/logo.png` existe (256×256, RGBA, 824 o, même dessin que l'application) et
+**aucun composant ne le lit**. La question posée par IDEES.md est donc tranchée :
+
+- **le catalogue YunoHost ne lit pas le dépôt de l'application.** Les logos vivent dans
+  le dépôt *du catalogue* (`YunoHost/apps`, dossier `logos/`, nommé d'après l'identifiant
+  de l'app). MaBibli n'y est pas, et n'a pas vocation à y être : il s'installe depuis une
+  URL Gitea privée ;
+- **la tuile du portail** affichait un substitut pour toute application hors catalogue en
+  YunoHost 12.0, sans recours. **Depuis 12.1, le logo se téléverse** — et le manifeste
+  exige déjà `yunohost >= 12.1.38`.
+
+⚠️ **Il n'y a donc rien à corriger dans le dépôt** : c'est un geste sur le serveur, dans
+l'interface d'administration, avec le fichier déjà présent. Ne pas repartir en chasse au
+chemin de fichier manquant, ni ajouter une clé `logo` au manifeste — le format v2 n'en a
+pas.
+
+⚠️ À ne pas confondre avec les icônes **de la PWA** (`favicon.png`, `icon-192.png`,
+`icon-512.png`), qui sont dans le dépôt du code et en place depuis le lot A3.
+
+### `ram.runtime` mesuré et porté à 256M (2026-08-22)
+
+`50M` et `200M` étaient posés à l'estime. **Mesuré sur le serveur** : pic réel de
+**208 793 600 o, soit 199,1 Mio** — contre 200M déclarés, c'est-à-dire **0,4 % de
+marge**. Porté à `256M` ; `ram.build` reste à `50M`. YunoHost s'en sert pour refuser une installation :
+trop haut, on interdit une installation qui aurait marché ; trop bas, on la laisse finir
+en OOM.
+
+⚠️ **Rien d'utile ne sort d'une machine de développement.** Un `dotnet run` ne dit rien
+de la consommation d'un publish self-contained sous systemd — namespaces, durcissement,
+absence de SDK. Le relevé utile est celui du service en marche, après une navigation
+ordinaire **puis** après un lookup ISBN (c'est là que le client HTTP et le parseur de
+notices travaillent) :
+
+```
+cat /sys/fs/cgroup/system.slice/mabibli.service/memory.peak
+```
+
+⚠️ **`systemctl show -p MemoryPeak` ne renvoie RIEN sur le serveur** (mesuré le
+2026-08-22) : la propriété n'y est pas exposée, et la commande réussit en silence. On
+croit lire un pic, on lit un instantané. Passer par le cgroup, qui garde le maximum.
+
+⚠️ **`memory.current` inclut le cache de fichiers**, donc les 69 Mo de binaire
+self-contained mappés. Une bonne part du chiffre est récupérable sous pression et n'est
+pas un besoin réel — et le GC de .NET laisse en outre enfler son tas tant que la machine
+est large. Le relevé majore donc le besoin, il ne le mesure pas.
+
+⚠️ **Le pic n'est PAS le lookup ISBN**, contrairement à l'intuition : une notice. C'est
+le bouton **« Nouveautés »** d'un auteur très réédité — jusqu'à dix pages de 100 notices
+SRU en parallèle, leur XML parsé, plus le catalogue entier chargé pour le rapprochement.
+
+⚠️ **Ce cas-là n'a pas encore été mesuré** : les 199,1 Mio l'ont été pendant un lookup
+ISBN. Le vrai plafond est donc au-dessus, et il **croît avec la taille du fonds**, le
+rapprochement chargeant tout le catalogue. À reprendre quand la bibliothèque aura
+beaucoup grossi.
+
+⚠️ **L'asymétrie qui a tranché la valeur** : déclarer trop haut refuse une installation
+qui aurait marché — visible, immédiat, contournable en connaissance de cause. Déclarer
+trop bas laisse l'installation se faire pour finir en OOM plus tard, sous une opération
+lourde, sans que rien ne désigne la cause. Même raisonnement que « une tranche d'ISBN en
+moins se lit encore ; une tranche fausse trompe ».
+
+⚠️ **`ram.build` ne désigne pas une compilation** : rien n'est compilé sur le serveur,
+c'est tout l'intérêt du self-contained. Il couvre le téléchargement et la
+**décompression** d'une archive de 69 Mo. Chercher la valeur du côté d'un build .NET
+donnerait un chiffre juste répondant à la mauvaise question.
 
 ### Deux pièges systemd, tous deux invisibles hors d'un vrai serveur