SDD 28 §6.11: la imagen del perfil servidor con gitea ARRANCA y sirve — 200 desde fuera de la VM

PID 1 = arje-zero · gitea encarnado por él (ppid=1) · corriendo como uid=916, la cuenta que declara
`[[user]]` · escuchando en :3000 · `GET /` devuelve 200 con <title>takana git</title> · y su
gitea.db creada por él mismo. Primer servicio de PAQUETE que arranca en una imagen de takana: los
que había venían horneados en el bootstrap.

La cadena entera, eslabón por eslabón: [[user]] → /etc/passwd de la imagen · [[service]] →
service-cards → genesis de la seed → arje encarna → setuidgid → sirve.

Queda escrito lo que NO está probado: el app.ini, el usuario del sitio y los datos se pusieron A MANO
en la VM para llegar al 200 — es justo lo que la mudanza tiene que traer de gioser. Y la imagen no
trae `arjectl`: tras poner la config hubo que reiniciar, porque el backoff de restart se agota y no
hay forma de relanzar un ente en caliente.

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

@@ -994,6 +994,54 @@ el mismo día. Es la diferencia entre una receta «sellada» y una receta *usada
 
 ---
 
+### 6.11 🗄️ La imagen del perfil, con gitea, ARRANCA y SIRVE *(2026-09-14)*
+
+`servidor-image.sh` + QEMU: **PID 1 = `arje-zero`, gitea encarnado por él (`ppid=1`), corriendo como
+`uid=916`, escuchando en :3000 y devolviendo `200` con `<title>takana git</title>`**, con su
+`gitea.db` creada por él mismo. Es el primer servicio de PAQUETE que arranca en una imagen de takana:
+los que había venían horneados en el bootstrap.
+
+La cadena entera, eslabón por eslabón: `[[user]]` → `/etc/passwd` de la imagen · `[[service]]` →
+`takana service-cards` → `genesis` de la seed → arje lo encarna → `setuidgid` → sirve.
+
+#### Los tres fallos que sólo aparecieron AL PROBAR LA IMAGEN
+
+Los tres pasan el sellado, el `hash`, el resolutor de servicios y el armado. Ninguno se ve sin
+arrancar la imagen.
+
+1. **⚠⚠ Escribir en el rootfs hidratado es escribir DENTRO del store.** `takana users --merge` hacía
+   `fs::write` sobre `<rootfs>/etc/passwd`, y ese fichero y el del artefacto `product-rootfs` son
+   **el mismo inode** (medido: 1225824, `2 links`, modo `444`) — el rootfs se arma con hardlinks.
+   Habría mutado un artefacto sellado, y toda imagen futura habría salido con la cuenta metida dentro
+   del producto. Se salvó porque el store es de sólo lectura y salió `Permission denied`: confiar en
+   eso es confiar en un permiso. Ahora escribe por temporal + `rename`, con un control que comprueba
+   que el fichero del store conserva su contenido y baja a 1 link.
+
+2. **La imagen traía el binario, la cuenta… y nadie lo arrancaba.** El `genesis` sólo tenía lo que
+   hornea `takana-bootstrap` (`sshd`, `console-getty`, `hammerd`): `servidor-image.sh` **no inyectaba
+   las Cards** — eso sólo existía en el camino de las imágenes de escritorio. Y ninguna métrica lo
+   dice: `targets.py --services` responde que el perfil lo habilita, y lo habilita; lo que faltaba era
+   el paso que lleva esa declaración a la imagen.
+
+3. **⚡ `trap invalid opcode`: el binario sólo corría en la CPU que lo compiló.** Con la card ya en el
+   genesis, gitea moría al instante dentro de QEMU-TCG. El sandbox exporta `CC` apuntando a un wrapper
+   con `-mcpu=baseline` (y su comentario ya avisaba: «de paso cierra el SIGILL de AVX en qemu64»), y
+   **la fase Go del propio builder lo pisaba** con `CC="zig cc"` a secas, que es `-mcpu=native`. No
+   falla al compilar ni al sellar: falla al ejecutar en otra CPU. Y el `ArtifactHash` no puede
+   cazarlo, porque la CPU del builder no entra en `hash_inputs` — **dos workers distintos sellan bytes
+   distintos bajo la misma dirección**. Arreglado en el builder y en la receta; re-hashea las cinco
+   recetas `cgo = true` (`gitea`, `usql`, `sq`, `gocryptfs`, `naabu`).
+
+#### Lo que NO está probado, y falta para la mudanza
+
+El `app.ini`, el usuario del sitio y los datos se pusieron **a mano** dentro de la VM para llegar al
+200. Eso es exactamente lo que el plan de mudanza tiene que traer de gioser — `/etc/gitea` ya está en
+`scripts/mudanza/rutas-fuera-de-git.txt`.
+
+Y **la imagen no trae `arjectl`**: tras poner la config hubo que REINICIAR para que arje volviera a
+intentarlo. El backoff de `restart` se agota y no hay forma de pedirle a PID 1 que relance un ente en
+caliente. Para una caja de producción eso es una pieza que falta, no una comodidad.
+
 ## 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: