1# SDD 29 — La mudanza: imagen portable, pasos exportables, y una app que censa, confirma y ejecuta
2
3Escrito 2026-09-11, a pedido del usuario, corrigiendo el rumbo del SDD 28:
4
5> «quiero que estas máquinas sean un ejemplo. Tú dices "falta caddy", pero caddy es una instalación
6> mía particular. Quiero que quede una imagen instalable siempre desde Hetzner o cualquier otro
7> servicio, poder ejecutar una instalación paso a paso y que los pasos sean exportables para
8> reproducirlos en cualquier lado; y que si estoy mudando, la app mudadora detecte qué servicios hay,
9> qué contenido, confirme con el usuario qué se muda y qué se borra, y deje al servidor nuevo
10> corriendo. Todo automático, sin IA.»
11
12## 0. La corrección que ordena todo
13
14El SDD 28 derivó hacia «poner ESTA caja a punto»: instalar caddy, copiar claves, montar discos. Eso
15es configurar un servidor, no construir un producto. **caddy no es un hueco de la imagen: es una
16instalación particular del usuario, y el programa tiene que DESCUBRIRLA, no traerla.**
17
18La imagen lleva lo que hace a un sistema takana. Todo lo demás —qué servicios corren, qué dominios
19sirven, qué datos pesan— **se censa en la máquina vieja**, se confirma con el usuario, y se ejecuta.
20
21Y hay una consecuencia de método que conviene decir fuerte: **todo lo que hice a mano en el SDD 28 es
22la especificación de este programa.** Censar, cruzar declaración contra realidad, separar vivo de
23fósil, confirmar, copiar, verificar. Cada paso fue determinista; ninguno necesitó juicio salvo
24«¿esto se muda o muere?», que es justamente lo que se le pregunta al usuario. **No hace falta IA: hace
25falta que esté escrito.**
26
27## 1. Las tres etapas
28
29```
30   CENSO                  PLAN                      APLICACIÓN
31   censar.py    →    <censo>.toml (decisiones)  →   ejecutar, idempotente
32   sólo lee          revisable · exportable         deja el server corriendo
33```
34
35El fichero del medio es el producto real: **es «los pasos exportables»**. Se revisa, se versiona, se
36lleva a otro proveedor, se vuelve a correr. Un plan que se ejecutó es también el registro de lo que
37se hizo.
38
39## 2. Etapa 1 — el censo *(implementado: `scripts/mudanza/censar.py`)*
40
41**La regla que lo ordena: cruzar lo DECLARADO contra lo VIVO**, y reportar tres clases:
42
43| clase | qué es | por qué importa |
44|---|---|---|
45| `vivo` | declarado **y** corriendo | candidato a mudarse |
46| `declarado-muerto` | declarado, sin proceso | candidato a morir |
47| **`no-declarado`** | **corriendo, sin declaración** | **el trabajo real: nadie sabe cómo levantarlo** |
48
49No es teoría — cada regla salió de un error medido:
50
51- **`rc-status` decía `stopped` de caddy, gitea, sshd, cronie y act-runner, y los cinco estaban
52  vivos.** Un censo que lea el init y no `/proc` produce un plan que no arranca.
53- **De 29 dominios del Caddyfile, sólo 10 están vivos**: 13 no tienen DNS, 2 dan 502, y **4 ya
54  resuelven a otra máquina** — su bloque de config es fósil aunque el sitio funcione. Por eso el
55  censo compara la IP del DNS contra las IPs de la máquina: sin eso, `ya-mudado` se lee como `vivo`.
56- **El caddy de la caja nueva murió en un reinicio y nadie lo notó**, porque estaba arrancado a mano
57  y no declarado. Ésa es la clase `no-declarado`, y es la que duele.
58- **`du -sh` no dice cuánto ocupa COPIAR** un árbol con hardlinks (medido: 60 G vs 85 G). El censo
59  reporta los dos números.
60- **Los nombres no coinciden entre init y proceso**: `act-runner`/`act_runner`, `crond`/`cronie`,
61  `dbus-daemon`/`dbus`, `fail2ban-server`/`fail2ban`. Sin normalizar, el mismo servicio sale a la vez
62  como `no-declarado` y `declarado-muerto`: las dos clases que más importan, las dos mal.
63- **Lo descartado se cuenta, no se esconde.** Un proceso con `ppid==1` que no es un servicio suele
64  ser un huérfano, y eso es un hallazgo (los `firefox` fugados que dejaron la granja sin compilar
65  hora y media fueron exactamente eso).
66
67⚠ **Y el criterio que decide si el censo sirve**: un guardián con hallazgos falsos se ignora entero.
68La primera versión daba 28 `no-declarado` con ruido; tras normalizar nombres da 18, y son reales
69(`matilda`, `pacha`, `puerta-…`, `adb`, `ModemManager`). Afinarlo no es cosmética: es la diferencia
70entre que alguien lo lea o no.
71
72## 3. Etapa 2 — el plan *(implementado: `scripts/mudanza/planear.py`)*
73
74El censo emite cada entrada con `decision = ""`. El plan es ese fichero con las decisiones puestas
75(`muda` / `muere`), más el orden y las dependencias. Requisitos:
76
771. **Nada sin decidir se ejecuta.** Una entrada vacía aborta: el silencio no es consentimiento.
782. **Lo que muere se dice por su nombre**, con su tamaño, antes de borrar nada.
793. **El plan es exportable y re-ejecutable** en otro proveedor. Es el artefacto que el usuario pidió.
804. **Un TUI para llenarlo**, y también editable a mano — el fichero es la interfaz, el TUI es comodidad.
81
82### ⚠ No todo lo que corre allá tiene sentido acá — y hay que DISCRIMINARLO con motivo
83
84Correr en el origen no significa que aplique en el destino. Un servidor en un datacenter no tiene
85bluetooth, ni módem, ni batería, ni pantalla — y algunos servicios no sólo sobran: **pelean** con el
86destino. `planear.py --revisar` muestra todo agrupado, con su recomendación **y su razón**:
87
88| familia | motivo | ejemplos en gioser |
89|---|---|---|
90| hardware local | una caja remota no tiene ese dispositivo | `bluetoothd` `ModemManager` `upowerd` `adb` |
91| escritorio o pantalla | un servidor no los tiene | `waypipe` |
92| red del destino | **pelearían**: el destino la configura con su propio init | `NetworkManager` `dhcpcd` |
93| lo provee el init del destino | no se muda | `udevd` `dbus-daemon` `elogind` `polkitd` `agetty` |
94
95**11 de 37 servicios de gioser caen ahí.** Y el motivo no es cortesía: *una recomendación sin razón
96no se puede discutir, así que o se acepta a ciegas o se ignora entera* — las dos son malas.
97
98#### La recomendación DERIVADA, que es la más fuerte
99
100Si el binario de un servicio vive en un árbol que **no se muda**, el servicio no va a poder arrancar
101allá. Eso no hace falta saberlo: se calcula, cruzando el `cmdline` que el censo leyó de `/proc`
102contra las decisiones de datos. Probado en los dos sentidos:
103
104```
105/mnt/vvv → muere :  puerta-f6e393ff  ⇒  NO mudar — «su binario vive en /mnt/vvv, que NO se muda»
106/mnt/vvv → muda  :  puerta-f6e393ff  ⇒  mudar    — «corre y sirve 34221, y NADIE lo declara»
107```
108
109**Por eso los DATOS se deciden primero**: de ellos se deriva la recomendación de los servicios, y al
110revés no se puede calcular. La revisión lo hace en ese orden y lo explica.
111
112#### Y lo que NO se recomienda solo
113
114Los **datos** salen sin recomendación, a propósito: qué datos valen no se deduce de la máquina.
115`terapeuta.ec` eran 279 M sin DNS y el usuario decidió que murieran; nada en el sistema podía
116decidir eso por él.
117
118### Lo implementado
119
120`planear.py --censo <f> --target <host> [--decide] --out plan.toml`
121
122- **Aborta con código 2** si queda algo sin decidir, listando qué. Probado.
123- `--decide` recorre lo pendiente y propone (`vivo`→muda, `ya-mudado`/`backend-caido`→muere,
124  `no-declarado`→muda). **La sugerencia se imprime, nunca se aplica sola.**
125- **Cada paso lleva su comando literal y su verificación**, así que el plan se ejecuta a mano, línea
126  por línea, sin la herramienta y sin este repo. Eso es «los pasos exportables».
127- El preflight dimensiona con el **tamaño de copia** (hardlinks expandidos), no con `du`; y si algún
128  tamaño resultó ilegible lo dice en vez de contarlo como 0 — un 0 inventado apaga el chequeo justo
129  cuando hace falta.
130- El paso «muere» **no borra nada**: lista con nombre y tamaño lo que se pierde al apagar el origen.
131
132### ⚠ El dato que vuelve accionable a un `no-declarado`: su invocación
133
134Decir «este servicio no está declarado» es nombrar el problema. Lo que hace falta para resolverlo es
135**cómo se está ejecutando ahora**, y eso se lee de `/proc`. El censo captura `cmdline` y `cwd` de
136cada servicio vivo, y el plan los emite en el paso:
137
138```
139#   cmdline: /mnt/vvv/tawasuyu/target/debug/deps/puerta-f6e393ffbef3999e
140#   cwd    : /mnt/vvv/tawasuyu/shared/tejido
141#   puertos: 34221, 44961
142```
143
144Ese servicio de gioser es **un binario de `target/debug/deps/`** corriendo en producción, con dos
145puertos, que ninguna declaración conoce. Una vez apagada la máquina vieja eso no se reconstruye de
146memoria. Ahora está escrito.
147
148⚠ Se lee `cmdline` y `cwd`, **nunca `environ`**: el entorno suele traer tokens y contraseñas, y un
149censo que se guarda en un fichero y se comparte no puede llevarlos.
150
151## 4. Etapa 3 — declarar y aplicar *(`declarar.py` implementado)*
152
153### 4.0 `declarar.py` — de «corre y nadie sabe cómo» a una Semilla que arranca
154
155Es el paso que cierra la mudanza: **copiar un binario no lo levanta al arrancar**. Toma la
156invocación que el censo leyó de `/proc` y emite `seed.card.json`.
157
158**Por qué no alcanza con `arje-absorb`**: absorb traduce sysvinit/runit/dinit/openrc a una Semilla y
159está bien hecho, pero lee **la declaración del init ajeno** — justo la que miente. En gioser
160`rc-status` daba `stopped` para cinco servicios vivos, y los `no-declarado` no aparecen en ninguna
161declaración por definición. Absorber la declaración reproduce el agujero. Los dos se complementan:
162absorb para lo declarado, esto para lo que corre.
163
164Medido sobre gioser: **37 de 37 servicios vivos declarados, cero fallos.** La tarjeta de caddy sale
165con su invocación real (`/usr/bin/caddy run --config /etc/caddy/Caddyfile --adapter caddyfile`), que
166es exactamente lo que faltaba para que no muriera en el próximo reinicio.
167
168**Tres reglas:**
169
1701. **Un servicio sin `cmdline` legible NO se emite**, y se dice por su nombre. Una tarjeta que no
171   puede arrancar es peor que una ausente: la ausente falla ruidosamente al primer arranque, la rota
172   arranca el sistema y deja el servicio caído sin que nada avise.
1732. **El `cwd` se preserva envolviendo.** El payload `Native` de arje acepta `exec`/`argv`/`envp` y
174   **no `cwd`** (comprobado sobre la semilla real del producto). 9 de los 37 servicios de gioser
175   dependen de su directorio; sin envolver arrancarían en `/` y fallarían de un modo difícil de
176   atribuir. Se emite `sh -c 'cd … && exec …'`, el idioma que la propia tarjeta de `sshd` ya usa.
1773. **IDs deterministas** derivados del nombre ⇒ el mismo censo produce la misma semilla **byte a
178   byte** (verificado con `sha256`), así que dos corridas se comparan con `diff`. Un fichero
179   generado que cambia en cada corrida no se puede revisar.
180
181⚠ **`envp` va vacío a propósito**: el censo no lee `/proc/<pid>/environ` porque trae tokens. Un
182servicio que dependa de variables necesita que alguien las escriba, y se avisa.
183
184⚠ **Un bug que costó el 70 % del censo y vale como lección**: `cmdline` y `cwd` se leían en un solo
185comando, y como `readlink /proc/<pid>/cwd` exige permiso de ptrace, en cualquier proceso de root el
186comando entero salía ≠0 y se descartaba **también el `cmdline`**, que sí se podía leer. 26 de 37
187servicios quedaban sin invocación —el dato que da sentido al censo— y el fallo se leía como «no se
188pudo». **Una sonda que falla es un dato; no puede arrastrar a las que funcionaron.**
189
190### 4.0 bis · De dónde sale cada binario — «instalá el paquete» no es una instrucción
191
192El paso de servicio decía «instalá el binario/paquete en el destino», que es lo que uno ya sabía. La
193respuesta útil sale de cruzar **dos hechos**: quién posee el fichero en el ORIGEN (se lo pregunta el
194censo al gestor de paquetes de esa máquina, en un solo lote) y si el corpus de takana tiene una
195receta con ese nombre. Tres casos, tres trabajos distintos:
196
197| clase | qué significa | qué hay que hacer |
198|---|---|---|
199| `receta-takana` | takana ya sabe construirlo | instalarlo del repo firmado — **no** copiar el binario |
200| `paquete-ajeno` | lo trae el gestor del origen | escribir una receta, o `qorpa` (ADR 0015) |
201| `suelto` | **nadie lo provee**: puesto a mano | llevarlo con su entorno, o escribirle receta |
202
203**Medido sobre gioser (37 servicios vivos):** 4 `receta-takana` · 4 `paquete-ajeno` · **11 `suelto`**
204· 7 sin binario legible. Los sueltos viven en `/usr/local/bin` o en un home — `qdrant`, `matilda`,
205`pacha-secretos`, `act_runner`, `shuma-gateway`— y **son los que se pierden al apagar el origen**.
206
207⚠ **Y corrigió un error mío.** En el SDD 28 escribí que `gitea` no tenía receta y que «es la que más
208peso tiene». Las dos cosas eran falsas: `recipes/gitea.toml` existe y está sellada. Lo afirmé de
209memoria; el programa fue a mirar. Es exactamente para esto que existe.
210
211⚠ **Y un fallo del propio clasificador, que vale como regla**: calculaba la raíz del repo con un
212`dirname` de menos, así que no encontraba ninguna receta y **contestaba `suelto` a todo** — incluido
213`caddy`. Un clasificador que contesta siempre lo mismo no clasifica. Ahora falla ruidosamente si no
214encuentra el catálogo, en vez de dar una respuesta falsa con forma de respuesta.
215
216### 4.0 ter · Alternativas: elegir el equivalente, con una recomendación que no sea gusto
217
218Un servicio casi nunca es insustituible: nginx, apache y caddy sirven HTTP; redis y valkey son caché.
219`planear.py` agrupa por **familia funcional**, muestra qué equivalentes tiene takana, y recomienda —
220pero **no «el mejor» en abstracto**: un gusto disfrazado de dato es peor que no recomendar.
221
222Los criterios son hechos comprobables, en este orden:
223
2241. **El que YA CORRE, si takana lo construye.** Y la razón es el costo real: *cambiar de servidor web
225   no es cambiar un binario — es reescribir la configuración entera*. Eso casi siempre pesa más que
226   cualquier ventaja teórica del otro.
2272. Si el que corre **no** está en el catálogo pero un equivalente sí, se recomienda ése — porque es
228   el que takana puede construir, firmar y reproducir — **diciendo lo que cuesta**.
2293. Si no hay ninguno, se dice eso. **No se sugiere «usá otro» cuando ese otro tampoco está.**
230
231Medido contra el catálogo real:
232
233```
234caddy  → alternativas: **caddy**✓  nginx✗  apache✗  lighttpd✗  traefik✓  haproxy✗
235         recomendado: caddy — es el que YA corre y takana lo construye (sellado).
236                      Cambiar obliga a REESCRIBIR la configuración entera.
237
238nginx  → recomendado: caddy — el que corre (nginx) no está en el catálogo; de la familia
239                      sí están sellados: caddy, traefik. Cambiar implica reescribir la
240                      configuración: es una decisión, no un trámite.
241
242redis  → alternativas: redis✗  valkey✗  memcached✗
243         recomendado: NINGUNO — de la familia «caché en memoria» no hay nada en el
244                      catálogo. Hay que escribir la receta del que se elija.
245```
246
247⚠ **El dato que la recomendación destapa**: de servidores web el corpus sólo tiene **`caddy` y
248`traefik`**. No hay nginx, ni apache, ni lighttpd. Saberlo antes de mudar vale más que la
249recomendación misma.
250
251Si se elige un equivalente, queda en el censo (`alternativa = "…"`) y **el plan lo dice en su paso**,
252con la advertencia arriba de todo: la configuración del origen no sirve tal cual.
253
254### 4.0 quater · El perfil: el software del servidor nuevo se DECLARA, no se instala
255
256`declarar.py --perfil-out` emite además un `[perfil.<label>]` listo para `docs/state/targets.toml`.
257
258**Por qué un perfil y no una lista de `install`.** Mudar servicio por servicio a una caja viva es lo
259que uno haría en cualquier distro, y en takana va contra el diseño: el software de una máquina se
260**declara** y viene en la imagen, reproducible y firmado. Un servidor armado a fuerza de
261instalaciones sueltas no se puede volver a construir — que es exactamente el problema que esta
262mudanza existe para no repetir: **el `caddy` de gioser no tiene dueño ni receta, y se pierde con la
263máquina**.
264
265Y hay un impedimento medido, no estético: `takana install` **reproduce desde fuente**, y eso exige el
266LAB entero en el cliente ([SDD 28 §5.4](28-servidor-de-produccion.md)). Una caja de destino no lo
267tiene. El perfil esquiva el problema por el lado correcto: el software entra **al armar la imagen**,
268en el hub, que sí tiene lab.
269
270Generado desde el censo de gioser:
271
272```toml
273[perfil.gioser-mudado]
274descripcion = "servicios mudados desde momento — generado por scripts/mudanza/declarar.py"
275hereda = ["base"]
276paquetes = [
277  "caddy",
278  "gitea",
279  "python3",  # python3, uvicorn
280]
281```
282
283Verificado que el instrumental lo acepta: `scripts/targets.py gioser-mudado` expande a **33 raíces**.
284
285⚠ **Y dice lo que NO puede cubrir**, uno por uno con su motivo: 34 servicios entre `suelto`,
286`paquete-ajeno` y `desconocido`. *Un perfil que se calla lo que le falta sale N/N describiendo un
287servidor incompleto* — la lección de `foot` en `escritorio-sway`, que llegó a 121/121 sellado y sin
288emulador de terminal.
289
290### 4.1.bis Los tres artefactos declarativos
291
292Con esto la mudanza deja de ser una secuencia de comandos y pasa a producir **tres documentos que
293reconstruyen el servidor desde cero**:
294
295| artefacto | qué declara | lo consume |
296|---|---|---|
297| `[perfil.<x>]` → `targets.toml` | **qué software** lleva | `servidor-image.sh` al armar la imagen |
298| `seed.card.json` | **qué corre y cómo** | `arje-zero` al arrancar |
299| `plan.toml` | **qué datos y en qué orden** | `aplicar.py`, o un humano línea por línea |
300
301Ninguno de los tres es un log de lo que se hizo: los tres son entradas que se vuelven a ejecutar.
302Ésa es la diferencia entre mudar un servidor y poder mudarlo otra vez.
303
304### 4.0 quinquies · Traducir la configuración — `traducir.py`
305
306Cambiar de nginx a caddy no es cambiar un binario: es **reescribir la configuración**. `traducir.py`
307hace la parte mecánica y —sobre todo— **dice con número de línea lo que NO pudo traducir**.
308
309#### Doctrina heredada de `soltar`/`paskaq` (tawasuyu)
310
311`soltar` desencadena datos presos en formatos cautivos (Btrieve, Paradox, `.mdb`). El dominio es otro
312—datos, no configuración— pero sus principios son exactamente los que hacía falta, y se adoptan tal
313cual:
314
315- **Elisión honesta.** «Lo que no se pudo leer se reporta con offset y motivo.» Acá cada directiva no
316  entendida sale con su línea y su texto. **Un traductor que descarta en silencio te deja un servidor
317  sin una redirección o sin una regla de auth, y el sitio parece funcionar.**
318- **No adivinar en silencio**: toda heurística queda como decisión explícita, no aplicada de tapadillo.
319- **Procedencia total**: cada bloque del resultado dice de qué línea del original salió.
320- **Determinista**: mismo fichero, misma salida.
321
322Y lo que NO es: un traductor completo de nginx. Traduce el núcleo común y **declara todo lo demás**.
323*Uno honesto que cubre el 70 % y dice cuál es el 30 % restante es útil; uno que aparenta cubrir el
324100 % es una trampa.*
325
326#### ⚠ Validar con el binario real encontró dos bugs, y uno cambiaba el sentido
327
328Leer la salida no alcanzaba. Pasarla por `caddy validate` —con el caddy del propio corpus— destapó:
329
3301. **`ambiguous site definition`**: en nginx dos `server` con el mismo `server_name` se distinguen por
331   su `listen`; en Caddy, por el **esquema de la dirección**. Sin traducir eso, los bloques colisionan
332   y el fichero ni carga.
3332. **Y el grave**: un `if (...) { return 403; }` salía como `respond 403` **incondicional** — el sitio
334   entero devolviendo 403. La directiva vivía dentro de un bloque que yo mismo había declarado
335   intraducible, y se absorbía igual al bloque de afuera.
336
337   Eso es peor que la pérdida silenciosa que la doctrina de `soltar` advierte: **no pierde, CAMBIA el
338   sentido**. Ahora todo lo que está dentro de un bloque opaco sale como `SIN-TRADUCIR` con su motivo:
339   *«sacarla de ahí le cambiaría el sentido — dejaría de ser condicional»*.
340
341Con los dos arreglados, el caddy del corpus contesta **`Valid configuration`**.
342
343#### Y la receta de caddy, terminada
344
345El `caddy` del corpus era un **import de nix en crudo**: su cabecera decía «PUNTO DE PARTIDA, no
346final» y su `commit` era el TAG flotante `v2.11.4` — contra el ADR 0006, porque un tag se mueve y la
347receta pasa a construir otra cosa sin que el hash lo note. Anclado a `e2eee6a7…` con `takana pin`; el
348hash se movió a propósito. 77 MB estáticos, **0 intérpretes requeridos**, y un `file-server` de
349prueba contesta 200.
350
351Importaba terminarla por una razón medida: **el `caddy` de gioser no tiene dueño** — binario puesto a
352mano, sin paquete y sin receta — y se pierde con la máquina. Con la receta, el servidor nuevo lo
353declara y lo reconstruye.
354
355### 4.1 El aplicador *(implementado: `scripts/mudanza/aplicar.py`)*
356
357`aplicar.py --plan plan.toml [--dry-run] [--only <clase>] [--paso N] [--hecho N]`
358
359**La regla que lo define: un paso que no se ejecutó NO se marca como hecho.** Un plan tiene pasos de
360dos naturalezas y confundirlas es la forma más fácil de dar una mudanza por buena sin estarlo:
361
362- **ejecutable** — tiene comandos de verdad (copiar, comprobar espacio);
363- **manual** — su `cmd` son COMENTARIOS («instalá el paquete», «cambiá el registro A»). No hay nada
364  que correr, y **un aplicador que ejecuta un bloque de comentarios obtiene exit 0 y lo marca «ok»**.
365  Ésa es la peor mentira posible: deja el servicio caído con el informe en verde.
366
367Acá un paso manual queda `pendiente-humano`, la corrida **no** se considera completa (sale con ≠0), y
368se confirma con `--hecho N` — que además **se niega** si el paso sí tenía comandos: «corrélo, no lo
369marques».
370
371**Se le cree a la verificación, no al exit code.** El `rsync` que llenó el disco devolvió **0** y
372dejó 1367 artefactos vacíos. Un paso pasa a `ok` sólo si su verificación pasa; si el comando salió
373bien y la verificación falló, queda `sospechoso`, que se informa como peor que un fallo.
374
375**Y las verificaciones están TIPADAS** (`cmd` / `humano`): «la columna Available debe ser > X» no es
376un comando, y darla por buena porque «no dio error» es exactamente cómo un aplicador miente.
377
378**Reanudable**: el estado vive en `<plan>.estado.json`, escrito con temporal + `fsync` + `rename` —
379la misma lección que costó un upgrade entero en el SDD 28 §6.13. Re-correr saltea lo ya hecho.
380
381#### ⚠ Y una verificación que era decorativa
382
383La primera versión del paso de datos verificaba así:
384
385```
386ssh … 'du -sh <p>; find <p> -maxdepth 1 -type d -empty | wc -l'
387```
388
389Imprimía el número de vacíos **y devolvía 0 igual**. En la primera corrida real dio «✓ verificado: 2»
390— donde ese 2 eran dos directorios vacíos en destino. Un guardián que siempre pasa no es un guardián.
391
392Ahora **compara**: cuenta los ficheros de los dos lados y falla si no coinciden. Probado con rotura a
393propósito y con el control que tiene que pasar:
394
395```
396copia NO hecha  → ficheros: origen=5 destino=0  ⇒ FALLA
397copia hecha     → ficheros: origen=5 destino=5  ⇒ PASA
398```
399
400Ejecuta el plan contra la máquina nueva. Requisitos, todos pagados en el SDD 28:
401
4021. **Idempotente y reanudable.** Cada copia grande se cortó al menos una vez.
4032. **Verifica en DESTINO, no en origen.** «Lo copié» no prueba nada: el `rsync` que llenó el disco
404   dejó 1367 artefactos vacíos y sólo se vio contando en el destino.
4053. **Los servicios `no-declarado` se declaran**, no se replican a mano. Es la salida natural hacia
406   `arje-absorb`, que ya traduce sysvinit/runit/dinit/openrc a una Semilla — pero **leyendo la
407   declaración, que es justo la que miente**: hay que alimentarlo con el censo.
4084. **Deja el servidor corriendo**, y lo prueba desde afuera: cada dominio `vivo` del plan tiene que
409   contestar 200 contra la IP NUEVA antes de dar la mudanza por hecha.
410
411## 5. La imagen, independiente del proveedor
412
413Lo que hoy la ata a Hetzner es poco y está medido:
414
415- **Arranque: ✅ RESUELTO (2026-09-11).** La imagen ahora arranca por **BIOS y por UEFI**, y es la
416  misma imagen. Layout: `p1` BIOS-boot · `p2` ESP FAT32 · `p3` `/` · `p4` estado · `p5` store.
417
418  **Un solo `grub.cfg`**: el `core.img` de i386-pc y el `BOOTX64.EFI` de x86_64-efi apuntan los dos a
419  `(hd0,gpt3)/boot/grub`, así que hay una sola línea de comando y un solo sitio donde editarla. Dos
420  imágenes hermanas obligarían a elegir por proveedor y a que divergieran — y ya divergían: la
421  hermana EFI documentaba etiquetas `takana-*` que su propio código no escribe (corregido).
422
423  **No se usa EFI-stub directo acá** (sí lo hace `install-image-efi.sh`, ADR 0010): el stub arrancado
424  por la ruta fallback recibe LoadOptions VACÍO, así que necesita la cmdline HORNEADA en el kernel, y
425  la de `linux-generic` sólo trae la consola — sin `root=`. Hornearla ataría la línea de comando al
426  ArtifactHash del kernel. Con GRUB EFI la cmdline vive en el `grub.cfg`, que es donde se edita.
427
428  **Verificado con la MISMA imagen en los dos firmwares**, hasta SSH:
429
430  | | UEFI (OVMF) | BIOS (SeaBIOS) |
431  |---|---|---|
432  | `/sys/firmware/efi` | **presente** | ausente |
433  | PID 1 | `arje-zero` | `arje-zero` |
434  | raíz · store | `sda3` · `sda5` | `sda3` · `sda5` |
435- **Red**: `netup` hace DHCPv4 y ya cubre el caso difícil (IP `/32` con la puerta fuera del prefijo,
436  que es lo de Hetzner). Falta IPv6 estático y los metadatos de otros proveedores.
437- **Instalación**: `rescue → dd → reboot` no es de Hetzner: sirve en cualquier entorno de rescate con
438  SSH. Lo único propio es cómo se ENTRA a ese rescate, que es una línea por proveedor.
439- **Disco**: ya se resuelve solo — el store es la última partición y crece al disco entero en el
440  primer arranque.
441
442⇒ **la imagen está más cerca de ser portable que la herramienta de mudarse.** Por eso el orden es
443censo → plan → aplicación, y la portabilidad de la imagen va en paralelo.