runbook: el volumen es de UN server, y el latido de gioser va por cron

Deja escrito lo que costo 21 G el 2026-08-22: `farm-up.sh N` apunta los N
workers al mismo VOL_NAME y un volumen de Hetzner se adjunta a un unico server,
asi que correr sharded exige un volumen POR worker. Con el comando exacto.

Y la linea de crontab del latido, que vive FUERA del repo y se perderia si
gioser se rehace. Incluye por que las dos rutas van absolutas: cron arranca en
$HOME y la redireccion del log se abre ahi, no donde uno cree.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xd5DComN9Nu47TBpYMBHBn

docs/runbooks/harkaq-granja-volumen.md

@@ -34,6 +34,50 @@ scripts/farm/harkaq-vol.sh status
 - El bucle **borra el artefacto `-hkm` tras medir** (envenenaba la caché en la 1ª campaña) y gatea
   por ABI≥7 + binario-con-jaula (no medir ciego).
 
+## Un volumen se adjunta a UN server (2026-08-22, costó 21 G)
+
+`farm-up.sh N` crea N workers en un bucle y **todos apuntan al mismo `VOL_NAME`**. Como un volumen
+de Hetzner se adjunta a un único server, del segundo en adelante no queda nada que adjuntar. La
+campaña de reconstrucción corrió sharded (`SHARD=i/N`) en dos workers: hworker-1 tomó
+`harkaq-cosecha` y hworker-2 nació sin volumen, construyó el shard 1/2 entero en su disco raíz y el
+dead-man se lo llevó a las 03:27Z. **397 artefactos sellados, 584 sin copia en ningún otro sitio**
+(la lista quedó en `work/perdidos-hworker2.txt`).
+
+Lo caro no fue la falta de detección: `farm-up` **ya imprimía** `⚠ el store NO quedó en el volumen ⇒
+lo que construya se PIERDE`. Lo imprimió esa noche, con esas palabras, y siguió adelante armando el
+dead-man y sembrando la cola. Un aviso que no detiene el pipeline no es un guardián cuando no hay
+nadie leyendo el log.
+
+Desde entonces `farm-up` **corta** (`sin_volumen()`): pregunta antes quién tiene el volumen tomado,
+ya no se traga el error del `attach`, y si el store no queda anclado borra el server recién creado
+(vacío, para no dejar un idle facturando) y sale 1. Para correr sharded hace falta **un volumen por
+worker**:
+
+```sh
+VOL_NAME=harkaq-cosecha-1 scripts/farm/farm-up.sh 1
+VOL_NAME=harkaq-cosecha-2 scripts/farm/farm-up.sh 1
+SIN_VOLUMEN_OK=1 scripts/farm/farm-up.sh 1     # worker deliberadamente desechable
+```
+
+## El latido en gioser va por cron, no por sesión
+
+`latido.sh` cuelga el bucle de **tu sesión de shell**, y eso es lo correcto *en el laptop*: no hay
+systemd y cronie sólo existe en uno de los dos arranques. En gioser la premisa se invierte — es un
+server, no hay sesión permanente, y crond sí corre. El mismo 2026-08-22 el rescate de hworker-2
+dependía de que un agente estuviera despierto mirando, y la respuesta llegó después del auto-borrado.
+
+```crontab
+*/30 * * * * HOME=/home/sergio PATH=/usr/local/bin:/usr/bin:/bin /mnt/vvv/hammer/scripts/farm/cosecha-cron.sh >>/mnt/vvv/hammer/work/cosecha-cron.log 2>&1
+```
+
+Rutas **absolutas** las dos: cron arranca en `$HOME`, así que una ruta relativa al script no
+resuelve y —peor— la redirección del log se abre en el directorio equivocado. El script hace su
+propio `cd "$ROOT"`, trae su `flock`, tolera workers ausentes y **no baja el store** (sólo el
+manifiesto de nombres) ⇒ no puede llenar el disco. Parar = borrar la línea.
+
+Lo que el latido **no** cubre: los artefactos siguen viviendo sólo en el volumen hasta que alguien
+haga una pasada de respaldo. El volumen tiene borrado protegido, pero es UNA copia.
+
 ## Parar de emergencia
 ```sh
 hcloud server list | grep hkw       # ver workers