⚠ la comprobación que faltaba: DOS commits se habían quedado en el gitea viejo

Comparados los 845 refs de los dos lados, repo por repo. Dos diferencias: una esperada
(`sergio/takana` main, el nuevo por delante con los commits del cutover — fast-forward verificado)
y una que NO: `tawasuyu/tawasuyu` tenía en el viejo `b69008eb` (freebsd) y `02a9535f` (shuma,
**19:48**), quince minutos DESPUÉS del snapshot final.

Por qué: el gitea viejo había resucitado por OpenRC y un cliente con el DNS cacheado (el CNAME
anterior tenía TTL 600) lo empujó a gioser aunque el autoritativo ya dijera la caja. Hacían falta
las dos condiciones a la vez.

Recuperados con un push del ref exacto desde el clon local; la UI del nuevo ya muestra `02a9535f`.
Segunda pasada: 845/845 y una sola diferencia, la esperada. En metadatos, `action` tenía tres filas
posteriores al snapshot (los mismos dos repos) y CERO issues/comentarios/releases.

El orden para el resto de la mudanza: bajar el TTL ANTES del corte · apagar el origen de verdad (los
dos supervisores) ANTES de tocar el DNS · comparar refs después, siempre · y dejar el origen apagado
un rato antes de borrarlo, precisamente para poder comparar.

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

docs/28-servidor-de-produccion.md

@@ -1216,6 +1216,35 @@ perfecta. Pasó en las dos máquinas antes de mirar el script (`SB_PORT=23`).
 
 **Pendiente**: que ese respaldo sea periódico, no de una vez. Es un renglón en el cron de la caja.
 
+### 6.16 ⚠ SÍ se perdieron dos commits en la ventana — y cómo se detectó
+
+La pregunta correcta después de un cutover no es «¿arrancó?» sino **«¿entró algo en el viejo
+mientras tanto?»**. Se contesta comparando **todos los refs de los dos lados**:
+
+```sh
+for r in <repos>/*/*.git; do git -C "$r" for-each-ref --format="$r %(refname) %(objectname)"; done | sort
+```
+
+845 refs a cada lado, y **dos diferencias**. Una era esperada (`sergio/takana` main, el nuevo por
+delante con los commits posteriores al corte — `merge-base --is-ancestor` confirma fast-forward). La
+otra **no**: `tawasuyu/tawasuyu` tenía en el VIEJO dos commits que el nuevo no tenía —
+`b69008eb` (freebsd) y `02a9535f` (shuma, **19:48**)—, o sea **quince minutos después del snapshot
+final**.
+
+**Por qué entraron**: el gitea viejo había resucitado (§6.15, OpenRC) y un cliente con el DNS
+**cacheado** —el CNAME anterior tenía TTL 600— lo empujó a gioser aunque el autoritativo ya dijera
+la caja. Las dos condiciones a la vez: un origen que revive y una caché que todavía apunta.
+
+**Recuperados** con un `git push` del ref exacto desde el clon local al gitea nuevo; la UI del nuevo
+ya muestra `02a9535f`. Segunda pasada de comparación: **845/845 y una sola diferencia, la esperada**.
+Y del lado de los metadatos, `action` tenía tres filas posteriores al snapshot (los mismos dos
+repos) y **cero** issues, comentarios o releases: no se perdió nada que no fueran esos commits.
+
+**La lección para el resto de la mudanza**, en orden: (1) bajar el TTL **antes** del corte, no
+durante; (2) apagar el origen de verdad —los DOS supervisores— **antes** de tocar el DNS; (3)
+comparar refs después, siempre, porque es la única prueba de que no se perdió nada; y (4) dejar el
+origen apagado un rato **antes** de borrarlo, precisamente para poder hacer esta comparación.
+
 ## 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: