¿se puede borrar gioser ya? — el barrido, y un hallazgo que cambia el orden

La condición del usuario está cumplida y medida: la caja sella recetas de takana y de tawasuyu desde
fuente (puriy-costura al mismo hash que predice el hub), tiene compilador propio, driver de C y el
latido empujando. Y los diez dominios de gioser.net/tawasuyu.net resuelven a la caja.

Dos hallazgos del barrido. terapeuta.ec, andino.ec y mercedes.andino.ec NO RESUELVEN en ningún lado
—NXDOMAIN desde dos resolvedores— aunque gioser las siga sirviendo por IP: para el público ya están
caídas. Y el que cambia el orden de las cosas: A GIOSER YA NO SE ENTRA. El 22 está cerrado desde el
laptop, desde la caja y desde el worker; 443, 80 y 2345 abiertos; hcloud dice `running`.

Eso importa porque quedan 127 de 150 entradas de datos sin decidir, y hoy no se pueden bajar sin modo
rescate. O sea: lo que bloquea el borrado no es capacidad —la caja ya reemplaza a gioser— sino datos
sin clasificar en una máquina en la que ya no se puede entrar.

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

docs/29-mudanza.md

@@ -1075,3 +1075,44 @@ Lo que hoy la ata a Hetzner es poco y está medido:
 
 ⇒ **la imagen está más cerca de ser portable que la herramienta de mudarse.** Por eso el orden es
 censo → plan → aplicación, y la portabilidad de la imagen va en paralelo.
+
+## 10. ¿Se puede borrar gioser ya? — el barrido del 2026-09-18
+
+La condición que puso el usuario fue: **«no borramos gioser hasta tenerte corriendo de aquel lado,
+con capacidad de compilar tawasuyu y las recetas de takana»**. Eso está cumplido y medido:
+
+| capacidad | prueba |
+|---|---|
+| recetas de takana, desde fuente | `linux-firmware`, `wireless-regdb`, `firmware-tigerlake`, `intel-ucode`, `sof-firmware` selladas **en la caja** |
+| recetas de tawasuyu, desde fuente | `puriy-costura` clonada, vendoreada, compilada y sellada **al mismo hash que predice el hub** |
+| compilador propio | `rust` 1.97.0 sellado; `rustc`/`cargo` corren en la caja |
+| driver de C | `/usr/bin/cc` (SDD 28 §6.52); compila C y proc-macros |
+| el latido | el cron de cosecha commitea Y empuja (13:01 del 18-09) |
+
+**Los dominios ya no dependen de gioser.** Los diez de `gioser.net`/`tawasuyu.net` resuelven a la
+caja. Las excepciones son `terapeuta.ec`, `andino.ec` y `mercedes.andino.ec`, y el hallazgo es otro:
+**no resuelven en NINGÚN lado** —NXDOMAIN desde dos resolvedores— aunque gioser las siga sirviendo
+por IP (`curl --resolve` da 200). O sea que para el público **ya están caídas**, y lo que se perdería
+al apagar gioser es un sitio que hoy nadie puede alcanzar por su nombre.
+
+### ⚠ Y el dato que cambia el orden de las cosas: a gioser ya NO SE ENTRA
+
+```
+  gioser 204.168.193.248   22/tcp cerrado · 2222 cerrado · 22022 cerrado
+                          443 abierto · 80 abierto · 2345 abierto
+  hcloud dice `running`
+```
+
+Probado desde **tres** orígenes distintos —el laptop, la caja y el worker—: el 22 está cerrado en los
+tres. La web contesta, el ssh no. `hcloud` lo ve `running`. **La administración de gioser está
+perdida**; para sacar cualquier cosa más haría falta el modo rescate de Hetzner.
+
+Eso importa porque **quedan 127 de 150 entradas de datos SIN DECIDIR** en
+`docs/state/mudanza-decisiones-pendientes.txt` (23 ya tienen decisión: 6 `muda`, 3 `respalda`,
+14 `muere`). Entre las indecisas hay cosas que sólo el usuario puede clasificar —`/var/lib/gitea`,
+`/home/sergio/.claude`, `/var/lib/sigma`, showreels…— y **hoy no se pueden bajar sin rescate**.
+
+> **Lo honesto, en una línea:** *técnicamente* la caja ya reemplaza a gioser; lo que bloquea el
+> borrado no es capacidad sino **datos sin clasificar en una máquina en la que ya no se puede entrar**.
+> El orden correcto es: rescate → bajar lo que el usuario marque → recién ahí borrar.
+> ⛔ Y nada de esto se hace sin que el usuario lo pida por su nombre: gioser es servidor protegido.