sergio/takana

La tabla del §6.3 era del 10 de septiembre. Hoy, entera:

  2 store entero        ✅ 1632 artefactos, 0 vacíos (eran 1362) · ⚠ /store al 88%
  4 la granja late allá ❌ el latido SIGUE en gioser
  6 dominios vivos 200  ✅ los 8 contra 2.29.29.217, `sergio` incluido
  7 respaldo desde allá ⬖ el script corre y LISTA el Storage Box desde la caja
  1,3,8 ✅ · 5 ⬖ (sirve, no consume: reproducir exige el lab entero)

La puerta 4 es ahora UNA LÍNEA DE CRONTAB. La caja ya tiene git, python3, rsync, ssh, takana, flock,
la llave del worker y el `.fleet`; le faltaban dos costuras y están hechas: `store -> /store` (el
script espera ./store, acá es partición) y `target/release/takana -> /usr/bin/takana` (no hay árbol
de build en una caja instalada). Prueba de sólo lectura: `estado-granja.sh` desde la caja ve al
worker, lee el grafo KDE y dice «CRON DE COSECHA: NO instalado».

NO lo instalé, por el mismo motivo que tejido: con el cron en las dos máquinas, las dos harían
`rsync --delete` al worker y las dos cosecharían y commitearían. El latido se INTERCAMBIA, no se
duplica, y es el último movimiento antes del borrado.

De paso, el repo de /opt/takana estaba 5 días atrasado y quedó en origin/main exacto (0 diferencias),
con tar de respaldo de los 92 ficheros previos. ⚠ Esos 92 no eran trabajo local: era contenido que
YA estaba río arriba metido en el árbol sin commitear — un árbol que parece sucio y está atrasado.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

diff --git a/docs/28-servidor-de-produccion.md b/docs/28-servidor-de-produccion.md
index 6be4ca08..ea0871c0 100644
--- a/docs/28-servidor-de-produccion.md
+++ b/docs/28-servidor-de-produccion.md
@@ -2353,6 +2353,54 @@ El de `tupu` es el más instructivo porque casi produce un diagnóstico al revé
 **tamaño constante** (es una serie de tamaño fijo), así que «no cambió de bytes» tampoco probaba
 nada. Lo que decide es el `mtime`, medido dos veces con 40 s de por medio.
 
+### 6.40 🚪 Las ocho puertas, medidas de nuevo *(2026-09-16)* — y la que falta es UNA
+
+La tabla del §6.3 es del 10 de septiembre. Re-medida hoy, entera:
+
+| # | puerta | estado | medido |
+|---|---|---|---|
+| 1 | arranca takana puro, se entra por SSH | ✅ | sigue en pie |
+| 2 | el store está entero | ✅ | **1632 artefactos, 0 vacíos** (eran 1362) · ⚠ `/store` al 88 %, 11,3 G libres |
+| 3 | los cuatro grafos idénticos | ✅ | §6.7 |
+| 4 | **la granja late en la caja nueva** | ❌ | **el latido sigue en gioser**: la caja no tiene el cron |
+| 5 | el repo se sirve y el host se actualiza solo | ⬖ | sirve; consumir exige el lab entero (SDD 27 §4) |
+| 6 | cada dominio vivo responde 200 desde fuera | ✅ | **los 8 contra `2.29.29.217`** — y `sergio` ya entre ellos |
+| 7 | el respaldo corre desde la caja | ⬖ | el script **corre y lista** el Storage Box desde la caja; falta una corrida completa |
+| 8 | lo fósil, anotado y decidido | ✅ | §6.9 + `docs/state/mudanza-decisiones.txt` |
+
+#### La puerta 4 es ahora una línea de crontab — y por qué no la puse
+
+La caja ya tiene **todo** lo que el latido necesita, comprobado uno por uno: `git`, `python3`,
+`rsync`, `ssh`, `takana`, `flock`, la llave del worker en `/root/.ssh/github5` y el `.fleet` con
+`dev.gioser.net`. Le faltaban dos costuras y están hechas:
+
+```
+  /opt/takana/store              -> /store            (el script espera `./store`; acá es partición)
+  /opt/takana/target/release/takana -> /usr/bin/takana (no hay árbol de build en una caja instalada)
+```
+
+Y el repo de `/opt/takana`, que estaba **5 días atrasado**, quedó en `origin/main` exacto (0
+diferencias contra el remoto), con un tar de respaldo de los 92 ficheros que el árbol tenía antes.
+⚠ Esos 92 no eran trabajo local: eran **contenido que ya estaba río arriba** —el cambio de SSH a
+HTTPS de las recetas de tawasuyu, entre otros— metido en el árbol sin commitear. Un árbol «sucio»
+que en realidad está *atrasado*, que es el mismo espejismo que el §5 del informe de tawasuyu
+describe para el monorepo.
+
+Prueba de sólo lectura desde la caja, que es lo más lejos que se puede llegar sin cambiar nada:
+
+```
+  ▶ dev.gioser.net (154.197.1.13)   load: 2.72 · store: 895 artefactos
+  ══ AVANCE KDE ══  197/198 sellado
+  ══ CRON DE COSECHA ══  ⚠ NO instalado en el crontab
+```
+
+**No lo instalé, y el motivo es el mismo que el de `tejido`**: con el cron puesto en las dos
+máquinas, las dos harían `rsync --delete` del repo al worker y las dos cosecharían y commitearían.
+El latido **se intercambia, no se duplica** — se apaga en gioser y se enciende acá, en ese orden, y
+es el último movimiento antes del borrado.
+
+⇒ **de las ocho, una sola está en rojo, y es una decisión de corte, no trabajo pendiente.**
+
 ## 7. Reusar los scripts que ya existen, y no escribir de nuevo
 
 Pedido explícito del usuario. El inventario de lo que ya hace el trabajo: