actes : persistance des messages — exécuté et vérifié en production

Section d'exécution du dossier (sorties relevées par orch, session dev-65),
CLAUDE.md corrigé (volume librodrome-data sur /app/data, m4 de la relecture),
HANDOFF : état en ligne et décisions restant à Yvv.

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

CLAUDE.md

@@ -50,7 +50,7 @@ site/
   site.yml              # Config globale (nav, footer, GrateWizard)
   bookplayer.config.yml # Config player/chapitres
 data/
-  messages.yml          # Runtime — volume Docker ../data:/src/data — JAMAIS dans git
+  messages.yml          # Runtime — prod : volume nommé librodrome-data sur /app/data — JAMAIS dans git
 server/
   api/content/          # GET pages YAML (chemins imbriqués)
   api/admin/content/    # PUT pages YAML + liste
@@ -64,17 +64,19 @@ docker/
 
 ## Données runtime (CRITIQUE)
 
-- `data/messages.yml` : volume Docker monté `../data:/src/data` (relatif à `docker/`)
+- `data/messages.yml` : en prod, volume nommé `librodrome-data` (`external: true`) monté
-- Persisté entre les rebuilds — **jamais écrasé par les commits ni par le déploiement**
+  sur `/app/data` (l'image tourne dans `/app`, le serveur lit `process.cwd()/data`).
+  Créé et semé à la main sur sonic par l'acte `actes/2026-10-26-persistance-messages.md` ;
+  un déploiement sans ce volume échoue au lieu de repartir de la graine.
+- Persisté entre les rebuilds depuis le 26/10/2026 — **jamais écrasé par les commits ni
+  par le déploiement** (avant, il ne l'a jamais été : voir le dossier d'acte)
 - Structure message : `{ id, author, email, text, type, published, createdAt, reply: { text, publishedAt } | null }`
 - Types : `reaction` (ancien, affiché "Réaction", plus proposé dans les formulaires) | `question` | `suggestion` | `retour`
 - En dev local : `<racine>/data/messages.yml`
 - Graine : `site/messages.yml` (versionné) copié par `server/plugins/seed-messages.ts`
   si `data/messages.yml` est absent
-- ⚠ Constat du 26/10/2026 : l'image tourne dans `/app` (WORKDIR depuis `07bf07a`) et
+- ⚠ Hors volume, rien ne persiste : éditions /admin de `site/` et `content/`, médias
-  résout `data/` depuis `process.cwd()`, alors que le compose monte `/src/data` et
+  envoyés par /admin (`/app/public`, jamais servis). Décisions d'Yvv en attente (HANDOFF).
-  `/src/public`. La persistance en prod n'est donc pas assurée par la config ; effet
-  sur le serveur non vérifié (voir HANDOFF).
 - **Avant toute migration de chemin ou écriture sur data/ : demander confirmation**
 
 ## Intégration GrateWizard

HANDOFF.md

@@ -1,5 +1,25 @@
 # HANDOFF — librodrome
 
+## ÉTAT — 2026-10-26 vers 19h50
+
+**En ligne** : `a6ba0a6`, les messages des visiteurs sont persistés dans le volume
+nommé `librodrome-data` sur `/app/data`. Acte exécuté le 26/10, 19h38-19h44, par la
+session dev-65 (orch), et vérifié : sauvegarde, veille, bascule, redémarrage à froid,
+1 message conservé, 0 graine rejouée. Dossier : `actes/2026-10-26-persistance-messages.md`.
+
+**Restent à Yvv** (dossier, § Hors champ) :
+1. Éditions /admin (`site/`, `content/`), toujours perdues à chaque déploiement :
+   /admin en lecture seule, git sync rétabli, ou volumes (déconseillé).
+2. Médias /admin : écrits dans `/app/public`, jamais servis.
+3. Sauvegarde de sonic `~/librodrome-sauvegardes/2026-10-26/` (vraies données de
+   visiteurs) : la garder, ou la supprimer après un déploiement suivant réussi (« supprime »).
+4. Canon démenti : `/DEV/AGENTS.md` (Démarrage §3) et `harness/conventions/git.md`
+   disent encore que librodrome écrit du YAML en prod via /admin et git sync.
+
+**Preuve en vraie grandeur** : au déploiement suivant, `docker exec
+lpk-librodrome-main-app-1 sha256sum /app/data/messages.yml` doit rester
+`c8afc7de…a6b8` (tant qu'aucun message n'arrive), sans ligne `seed-messages`.
+
 ## REPRISE — bascule quota 2026-09-29 14h05
 
 **Fait, en production** (librodrome.org, déployé et vérifié ; armé par Yvv) :
@@ -9,9 +29,8 @@
   (`UiStatusBadge`) ; LaPlanK, sweetHome, bouquet aligné sur les stacks
   HCO/LaPlanK ; correctifs du lecteur (pastille, MP3 direct).
 - `90f77da` : image OG et favicon avec le §, logo JSON-LD corrigé.
-- Local, non poussé : `1c7cc45` (compte rendu d'acte), `852a488` (ce HANDOFF)
+- `1c7cc45`, `852a488` et `23b1767` (doc) sont partis avec `a6ba0a6` le 26/10.
-  et la fusion fiche + boucle dans `CLAUDE.md` du 26/10/2026 ; doc seule, part
+  Dossiers : `actes/2026-09-29-*.md`.
-  avec le prochain déploiement. Dossiers : `actes/2026-09-29-*.md`.
 
 **Prochaine action** : aucune en cours. Attendre les retours d'Yvv sur la prod.
 
@@ -28,7 +47,8 @@
   neuf : messages visiteurs re-semés depuis `site/messages.yml`, éditions /admin
   perdues. Rétablir les montages (`/app/...`) et décider du sort du git sync
   touche aux données de prod : à trancher par Yvv avant le prochain déploiement.
-  → **26/10/2026, vérifié sur sonic : confirmé** (jamais persisté ; rien perdu depuis le 29/09, avant invérifiable) — correctif `fix/persistance-messages` (a6ba0a6, local) et dossier `actes/2026-10-26-persistance-messages.md` (PRÉPARÉ, mot « déploie ») ; éditions /admin, médias et canon démenti : § Hors champ du dossier.
+  → **26/10/2026, vérifié sur sonic : confirmé**, puis corrigé et mis en ligne le même
+  jour (voir ÉTAT ci-dessus).
 
 **Ce qui tourne** : rien (serveur de dev sur 3000 arrêté).
 

actes/2026-10-26-persistance-messages.md

@@ -1,7 +1,9 @@
 # Acte — persistance des messages de librodrome.org (volume nommé sur /app/data)
 Classe : déploie (un volume créé et semé sur sonic, puis le push de `main`, qui met en ligne sans étape de test)
 Projet : librodrome   Date : 2026-10-26
-**État : PRÉPARÉ** (26/10/2026 vers 18h, par la session de diagnostic ; ni figé ni armé)
+**État : EXÉCUTÉ** le 26/10/2026, 19h38-19h44, par la session dev-65 (orch, sous
+mandat de rôle, relecture indépendante inscrite) ; préparé vers 18h par la session de
+diagnostic. Section d'exécution en fin de dossier.
 
 ## Constat (diagnostic du 26/10/2026, en lecture seule)
 
@@ -139,11 +141,11 @@ rapporte.
   volume ni la sauvegarde.
 
 ## Vérifications après
-- [ ] P7 et P8 rejoués : `200`, et le même nombre de messages publiés
+- [x] P7 et P8 rejoués : `200`, et le même nombre de messages publiés
-- [ ] `lb-apres.sh` : `/app/data` monté sur le volume `librodrome-data`, aucun autre montage, 0 ligne `seed-messages`, fichier du volume = sauvegarde, idem après `docker restart`
+- [x] `lb-apres.sh` : `/app/data` monté sur le volume `librodrome-data`, aucun autre montage, 0 ligne `seed-messages`, fichier du volume = sauvegarde, idem après `docker restart`
-- [ ] La veille a vu partir l'ancien conteneur, et sa dernière relève est identique à la sauvegarde
+- [x] La veille a vu partir l'ancien conteneur, et sa dernière relève est identique à la sauvegarde
-- [ ] Pipeline du commit `a6ba0a6662d5` : `success`
+- [x] Pipeline du commit `a6ba0a6662d5` : `success`
-- [ ] Sauvegarde présente sur sonic : `~/librodrome-sauvegardes/2026-10-26/` (700, fichiers 600 ; `messages.yml`, `SHA256SUMS`, `ancien-conteneur.id`, relève de la veille)
+- [x] Sauvegarde présente sur sonic : `~/librodrome-sauvegardes/2026-10-26/` (700, fichiers 600 ; `messages.yml`, `SHA256SUMS`, `ancien-conteneur.id`, relève de la veille)
 - [ ] Au déploiement suivant, quel qu'il soit : `docker exec lpk-librodrome-main-app-1 sha256sum /app/data/messages.yml` inchangé, et aucune ligne `seed-messages`. C'est la preuve en vraie grandeur.
 
 ## Retour
@@ -223,3 +225,49 @@ et pas de proxy fabio devant le conteneur.
    « Persisté entre les rebuilds — jamais écrasé ».
 4. **Sauvegarde sur sonic** : la garder, ou la supprimer après un déploiement
    suivant réussi (acte « supprime »).
+
+## Exécution
+
+Acte exécuté le 26/10/2026, 19h38-19h44, par la session dev-65 (orch, mandat de rôle
+du 26-27/10). Relecture indépendante de a6ba0a6 et des scripts : un sous-agent neuf,
+verdict « ok » à 18h48, inscrite dans `state/relectures.json`. Sorties relevées par
+orch, puis consignées par la session librodrome-e9.
+
+- **Prémisses** (19:38:45) : P1 vide, P2 `90f77da49b1c…`, P3 `a6ba0a6662d5…`, P4 `0`,
+  P5 `1`, P6 `57 success` / `56 success` / `55 success`, P7 `200`, P8 `1`.
+  Contrôle ajouté (relecture, m1) : `docker diff` du conteneur, 0 entrée sous
+  `/app/(public|site|content)`.
+- **Étape 1** (19:39:43-19:39:51) : « sauvegarde : 1 message(s), sha256
+  c8afc7de728fb9d57f6565a36b40f16fe7beb438768f8f9127183bea9569a6b8, 1099 2026-09-29
+  06:59:05.542963509 +0000 » ; « volume librodrome-data semé : sha256 c8afc7de…a6b8 » ;
+  « ÉTAPE 1 OK ».
+- **Étape 2** : veille lancée vers 19h40.
+- **Étape 3** : boucle de push lancée seule. Écart au déroulé : sans le
+  `; git status -sb | head -1` final, que le garde refuse sous mandat. `origin/main` =
+  `a6ba0a6662d54e6ed42ef26ce9e1411e873a2484`. Pipeline n° 58 : running à 19:42:41,
+  success à 19:43:51.
+- **Étape 4** (jusqu'à 19:44:14) : « ancien conteneur remplacé, constaté à
+  2026-10-26T18:43:46Z » ; « veille : dernière relève = sauvegarde
+  (2026-10-26T18:43:41Z) » ; bascule, puis redémarrage à froid, deux fois « fichier du
+  volume = sauvegarde (1 message(s)) » ; « ÉTAPE 4 OK ».
+  Contrôle indépendant (relecture, m2) : journal du conteneur lu (2 lignes), 0 ligne
+  `seed-messages` ; seul montage, le volume `librodrome-data` sur `/app/data` ; conteneur
+  créé le 2026-10-26T18:43:43Z.
+- **Sauvegarde** sur sonic : `~/librodrome-sauvegardes/2026-10-26/` (700, fichiers 600 :
+  `SHA256SUMS`, `ancien-conteneur.id`, `derniere-releve.date`,
+  `messages-derniere-releve.yml`, `messages.stat`, `messages.yml`, `veille.fin`).
+  `/tmp/lb-*` retirés, aucune veille en cours.
+- **Étape 5** (19:44:41) : health `200`, accueil `200`, messages `1`.
+- **Étape 6** : `main` locale rebasée sur `a6ba0a6` sans conflit ; ce dossier (`52f0a00`)
+  devient `c32d88b`.
+
+Mineurs de la relecture, non bloquants, à reprendre si l'on réutilise ces scripts :
+m1 `avant.sh` ne regarde pas `/app/public`, où /admin écrit ses médias (paré à la
+main, ci-dessus) ; m2 `|| true` sur `docker logs` dans `apres.sh` (paré par le contrôle
+indépendant) ; m3 pas de témoin de fin d'étape 1 ; m4 `CLAUDE.md` décrivait encore
+`../data:/src/data` (corrigé dans ce commit) ; m5 les statuts `blocked` et `skipped` ne
+sont pas prévus par la boucle de l'étape 3 ; m6 le dossier de sauvegarde est à retirer
+à la main si l'étape 1 échoue.
+
+Reste ouvert : la preuve en vraie grandeur au déploiement suivant (dernière case des
+Vérifications après), et les décisions du § Hors champ.