SDD 28 §6.3-6.4: puerta 2 en verde, el disco arreglado, y la puerta 3 choca con un muro estructural

**Puerta 2 ✅**: 1362 artefactos reales, 0 vacíos. (El primer conteo dio «3 vacíos» y eran
`.mirror-tmp`, `.bootstrap-tmp` y `.divergen` — directorios de trabajo, no artefactos: el chequeo
tiene que acotar por el patrón `<hash>-<nombre>`, no listar el directorio.)

**El disco**: la imagen ocupaba 7 G de 76,3 y los otros 69 eran inalcanzables. Arreglado; `/store`
en la caja pasó de 487 M a **68,7 G**. Con eso el store de 55 G entra en disco local y **la mudanza
ya no depende de desenganchar el volumen de gioser** — que era la parte que paraba la granja.

**Puerta 3 🚧 BLOQUEADA, y no por configuración.** Al ir a computar los grafos:

    $ python3 -c "print(1)"
    sh: python3: not found        <- y `command -v python3` decía /usr/bin/python3

Está y no arranca: es un ELF DINÁMICO que pide `/lib/ld-musl-x86_64.so.1`, y **en la imagen no hay
ningún cargador dinámico**. Tampoco en el store: el artefacto `musl` publica sólo lo estático
(`libc.a`, `crt*.o`, headers) — no hay `libc.so` ni `ld-musl` en NINGÚN artefacto del corpus. Lo que
hace que esto funcione en gioser es el rootfs Alpine del LAB.

Contado sobre la imagen: **23 binarios inertes de 726**. La suite binutils entera, más perl, python3,
sqlite3, flex y nft.

Frena la mudanza porque TODO el instrumental del proyecto es Python (build-state, targets, yupana,
hydrate-profile, drenar, triaje): un servidor takana no puede correr ni una de sus herramientas.

Las tres salidas —publicar el cargador desde musl (toca Stage 1 y mueve el baseline del selfhost),
python/perl estáticos (frente propio), o aceptar que el instrumental vive en el hub (contradice
apagar gioser)— son decisión de ADR. Queda escrito, medido, y sin tocar nada de Stage 1 de rebote.

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

docs/28-servidor-de-produccion.md

@@ -511,6 +511,77 @@ caja nueva y que el dato se verifica por contenido.**
 751 sobre el MISMO corpus) y por eso se sacó del JSON. Si los grafos difieren, mirar primero si la
 diferencia es «cuánto de esto tengo en disco» y no «qué existe».
 
+### 6.3 Estado de las puertas *(2026-09-10)*
+
+| # | puerta | estado |
+|---|---|---|
+| 1 | arranca takana puro y se entra por SSH | ✅ §3.8 |
+| 2 | el store está entero | ✅ **1362 artefactos reales, 0 vacíos** |
+| 3 | los cuatro grafos idénticos | 🚧 **bloqueada** — ver §6.4 |
+| 4 | la granja late en la caja nueva | 🚧 bloqueada por lo mismo |
+| 5 | el repo se sirve y el host se actualiza de sí mismo | ⬖ mitad: sirve (§5.1), no consume (§5.4) |
+| 6–8 | dominios vivos · respaldo · fósiles decididos | pendientes |
+
+**Puerta 2, medida acotando al patrón `<hash>-<nombre>`**: 1362 artefactos, **0 vacíos**. Los 3 sin
+`.hammer/recipe.toml` son `stage1-rootfs`, `product-rootfs` y `seed-zig` — productos de bootstrap,
+que por diseño no salen de una receta. (El primer conteo dio «3 vacíos» y eran `.mirror-tmp`,
+`.bootstrap-tmp` y `.divergen`: directorios de trabajo con punto inicial, no artefactos. El chequeo
+tiene que acotar por el patrón, no listar el directorio.)
+
+**De paso, el disco**: la imagen ocupaba 7 G de los 76,3 G de la caja y los otros 69 eran
+inalcanzables. Arreglado en `install-image.sh` — el store pasa a ser la ÚLTIMA partición (la única
+que puede crecer sin mover datos) y el wrapper de `/sbin/init` la extiende en el primer arranque.
+Medido en la caja: **`/store` = 68,7 G**, contra los 487 M de antes. Con eso el store de 55 G entra
+en el disco local y **la mudanza no depende de mover el volumen de gioser**.
+
+### 6.4 ⚠ El muro de la puerta 3: la imagen trae 23 binarios que NO PUEDEN CORRER
+
+Al ir a computar los grafos en la caja:
+
+```
+$ python3 -c "print(1)"
+sh: python3: not found          ← y `command -v python3` decía /usr/bin/python3
+```
+
+No es que falte: **está y no arranca**. `/usr/bin/python3.12` son 23 MB y es un ELF **dinámico**:
+
+```
+Requesting program interpreter: /lib/ld-musl-x86_64.so.1
+NEEDED  libc.so
+```
+
+**Y en toda la imagen no hay ningún cargador dinámico.** Tampoco en el store: el artefacto `musl`
+publica sólo lo estático (`libc.a`, `crt*.o`, headers) — **no hay `libc.so` ni
+`ld-musl-x86_64.so.1` en ningún artefacto del corpus**. Lo que hace que estos binarios funcionen en
+gioser es el **rootfs Alpine del LAB**, que sí lo trae (`.dev-fs/alpine/lib/ld-musl-x86_64.so.1`).
+
+Es la fuga de [[needed-colgante-libstdcxx]] otra vez, y esta vez en el piso de abajo: *sella,
+reproduce y no corre*, porque pide algo que sólo existe en el laboratorio.
+
+**Contado sobre la imagen: 23 binarios inertes de 726 (703 estáticos están bien).** Son la suite
+`binutils` entera (`ar as ld nm objcopy objdump ranlib readelf strip addr2line c++filt elfedit gprof
+size ld.bfd`), más **`perl`**, **`python3`**, **`sqlite3`**, **`flex`** y **`nft`**.
+
+**Por qué frena la mudanza y no es un detalle**: *todo* el instrumental del proyecto es Python —
+`build-state.py`, `targets.py`, `yupana.py`, `hydrate-profile.py`, `drenar.py`, `triaje.py`. Un
+servidor takana no puede correr ni una de sus propias herramientas. La puerta 3 (los cuatro grafos)
+y la 4 (la granja) dependen de eso.
+
+**Y no se arregla de paso.** Las salidas son tres y ninguna es barata:
+
+1. **Publicar el cargador** — que `musl` emita `libc.so` + `ld-musl-x86_64.so.1`. Es lo correcto y lo
+   más chico en concepto, pero toca un componente de **Stage 1**: mueve el baseline `of_tree` del
+   selfhost y hay que rehacerlo a propósito, no de rebote.
+2. **Construir python/perl estáticos** — el camino que evita el cargador, y es un frente propio:
+   Python estático con módulos de extensión es notoriamente arisco.
+3. **Aceptar que el instrumental vive en el HUB** y que el servidor sólo sirve. Es la respuesta
+   honesta a corto plazo, pero contradice «mover allá todo lo que tengo acá»: el hub seguiría siendo
+   gioser, que es justo lo que se quiere apagar.
+
+Es decisión de ADR, y de las que conviene tomar mirando también el [SDD 27 §4](27-perfiles-instalables-y-el-instalador.md):
+las dos preguntas —«¿el cliente reproduce o hidrata?» y «¿el cliente puede correr lo que le
+mandamos?»— son la misma pregunta sobre qué es un sistema takana **sin laboratorio**.
+
 ### 6.2 Lo que la mudanza tiene que producir, además de la mudanza
 
 El usuario lo pidió explícito: **que este experimento saque recetas y las pruebe**. La caja vieja es