sergio/takana

La receta ya declara su servicio (SDD 30) y `perfil.servidor` lo habilita. El ArtifactHash NO se
mueve (`b3:391a613e…` antes y después): `[[service]]` está fuera de `hash_inputs`.

⚠ Primero, una corrección del commit anterior: declaraba `gitea` en `perfil.servidor` con SEIS
LÍNEAS DE COMENTARIO y sin la línea `"gitea",`. El perfil cargó igual, el grafo no dijo nada y el
paquete simplemente no estaba. Lo cazó `targets.py --services` al resolver el label: «lo declara
gitea, que NO pertenece al perfil». Un comentario que explica una entrada que no existe se lee como
la entrada.

La card no encarna el binario directo: **gitea se niega a correr como root** (`[F] Gitea is not
supposed to be run as root`), así que va por `setuidgid`. Y comprueba dos cosas del SITIO antes de
arrancar, saliendo 78 con un mensaje que las nombra: `/etc/gitea/app.ini` y el usuario `gitea`. Un
gitea sin config no falla — arranca y ofrece el asistente de «crear administrador» a quien pase.

Probado en el worker con el argv exacto y `env -i`, que es lo que arje hace de verdad. Tres fallos
que con una shell normal no se ven NUNCA:

· `exec setuidgid …` a secas ⇒ `sh: exec: line 0: setuidgid: not found`. El `sh` de busybox de la
  imagen no trae `FEATURE_SH_STANDALONE`: no despacha sus applets, los busca en `PATH`, y PID 1 no
  garantiza ninguno. Todo con ruta absoluta (`/bin/grep`, `/usr/bin/setuidgid`).
· sin `PATH` en el `envp` ⇒ `git not found: executable file not found in $PATH`. **gitea lanza
  `git` como subproceso**, y el mensaje se lee como «falta git» con git instalado y raíz de `base`.
  Un envp vacío no es «limpio»: es sin PATH.
· sin `cd` ⇒ `fatal: error reading '/root/.git'`. El cwd se hereda y gitea corre `git config` en él.
  `Service` no tiene campo `cwd`, así que va en el argv, a la vista.

Con eso: escucha, `GET /` responde **200** y el proceso corre como `gitea`. Las dos guardas
verificadas por separado (78 y su mensaje cada una). El worker quedó limpio y censado: sin usuario,
sin /etc/gitea, sin /var/lib/gitea, sin symlinks y sin procesos.

Y `/etc/gitea` entra en las rutas de la mudanza: el `app.ini` guarda los SECRETOS generados (gitea
los escribe en el propio fichero, que por eso tiene que ser suyo, `gitea:gitea 0660`).

⚠ Lo que queda abierto y está anotado en la receta: **el usuario `gitea` no existe en el producto**.
`/etc/passwd` de la imagen es la constante `takana_bootstrap::PRODUCT_PASSWD` y sólo trae `root` y
`sshd`. El SDD 30 sacó las Cards de una constante de Rust y las puso en la receta; los USUARIOS
siguen donde estaban las Cards. Hasta que se declaren, el usuario llega con los datos del sitio.

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

diff --git a/docs/state/targets.toml b/docs/state/targets.toml
index a6f16aeb..727909df 100644
--- a/docs/state/targets.toml
+++ b/docs/state/targets.toml
@@ -1292,9 +1292,8 @@ paquetes = [
   # los 26 repos que sólo existen en la máquina que se borra dejan de estar solos en cuanto su origen
   # vive acá. Sus datos son 2,0 G de ficheros y una sqlite (`DB_TYPE = sqlite3`), así que mudarlos es
   # copiar un directorio — lo que NO es trivial es el binario, ver el encabezado de `recipes/gitea.toml`.
-  # ⚠ Declarado como PAQUETE, todavía no en `servicios`: para arrancarlo hace falta el `[[service]]`
-  # del SDD 30 con su `app.ini`, su usuario y su ruta de datos. Instalado y sin levantar es honesto;
-  # ponerlo en `servicios` sin la Card sería declarar un arranque que no existe.
+  # Su `[[service]]` está en la receta y el perfil lo arranca (abajo, en `servicios`).
+  "gitea",
   # `curl`/`wget`: bajar del mirror y del repo. `takana install --repo https://…` los necesita del
   # lado del cliente, y son también la única forma de diagnosticar un origen caído desde la caja.
   "curl", "wget",
@@ -1346,4 +1345,9 @@ paquetes = [
 # Es la versión servicios de la lección de `foot` — la métrica mide la clausura de lo declarado y no
 # puede ver lo que falta en la declaración. Comprobado antes de escribir esta línea: el resolutor
 # avisaba «`openssh` está en la imagen y TRAE este servicio, pero el perfil no lo arranca».
-servicios = ["sshd"]
+# `gitea` (2026-09-14): el servidor git de la mudanza. Se habilita acá y el CÓMO lo dice su receta.
+# ⚠ Su card comprueba dos cosas del SITIO antes de encarnar —`/etc/gitea/app.ini` y el usuario
+# `gitea` en `/etc/passwd`— y sale con 78 si falta alguna. Es a propósito: las dos vienen con los
+# datos de la mudanza, y un gitea que arranca sin su config ofrece el asistente de «crear
+# administrador» a quien pase. Hasta que la mudanza traiga ambas, este servicio NO levanta y lo dice.
+servicios = ["sshd", "gitea"]
diff --git a/recipes/gitea.toml b/recipes/gitea.toml
index 04fe611d..34aa5c30 100644
--- a/recipes/gitea.toml
+++ b/recipes/gitea.toml
@@ -58,3 +58,68 @@ go build -trimpath -tags 'bindata sqlite sqlite_unlock_notify' \
   -o /out/usr/bin/gitea .
 """
 install   = "true"
+
+# ── EL SERVICIO QUE ESTE PAQUETE TRAE (SDD 30) ──────────────────────────────────────────────────
+# Fuera de `hash_inputs`: declarar esto NO re-hashea gitea.
+#
+# ⚠ GITEA SE NIEGA A CORRER COMO ROOT, y no es un aviso: es un `[F]` y sale. Medido:
+#
+#     [F] Gitea is not supposed to be run as root. If you need to use privileged TCP ports
+#         please instead use `setcap` and the `cap_net_bind_service` permission.
+#
+# Por eso el `argv` hace `setuidgid gitea` (applet de busybox, comprobado presente) en vez de
+# encarnar el binario directo. Existe `GITEA_I_AM_BEING_UNSAFE_RUNNING_AS_ROOT`; el nombre de la
+# variable ya dice por qué no se usa.
+#
+# ══ LAS DOS GUARDAS, Y POR QUÉ FALLAN RUIDOSAMENTE ═════════════════════════════════════════════
+# Un servidor git sin su `app.ini` y sin su usuario **arranca igual** y se planta más tarde, o peor:
+# arranca con la config de instalación y ofrece el asistente de «crear administrador» a quien pase.
+# Las dos cosas que faltan son del SITIO, no del paquete —vienen de la mudanza junto con los datos—
+# así que la receta no las inventa: comprueba que estén y muere con un mensaje que las nombra.
+#
+#   · `/etc/gitea/app.ini`  ⇒ es config del sitio: dice dónde está la DB y con qué dominio se sirve.
+#   · el usuario `gitea`    ⇒ dueño de `/var/lib/gitea`. **HOY NO EXISTE EN EL PRODUCTO**: el
+#     `/etc/passwd` de la imagen es la constante `takana_bootstrap::PRODUCT_PASSWD` y sólo trae
+#     `root` y `sshd`. El SDD 30 sacó las Cards de una constante de Rust y las puso en la receta; los
+#     USUARIOS siguen donde estaban las Cards. Mientras eso no se declare, el usuario entra con los
+#     datos del sitio (el origen ya lo tiene: `gitea:x:…:/var/lib/gitea`).
+#
+# `arje` no tiene readiness por unidad, así que —igual que el card de `sshd`— lo que haya que esperar
+# o comprobar va DENTRO del `argv`, a la vista, y no escondido en un wrapper.
+#
+# ⚠ TODO con ruta ABSOLUTA (`/bin/grep`, `/usr/bin/setuidgid`), y no por estilo: el `sh` de busybox
+# de la imagen NO está compilado con `FEATURE_SH_STANDALONE`, así que **no despacha sus propios
+# applets** — los resuelve por `PATH`, y PID 1 no garantiza ninguno. Medido: `exec setuidgid …` a
+# secas muere con `sh: exec: line 0: setuidgid: not found`, y el servicio quedaría reintentando para
+# siempre por un `PATH` vacío. En la imagen los symlinks existen (`/usr/bin/setuidgid -> busybox`);
+# nombrarlos completos es lo que hace que eso no dependa del entorno que herede el proceso.
+#
+# ══ LOS DOS QUE SÓLO APARECEN CON EL ENTORNO DE VERDAD (medidos 2026-09-14 en el worker) ═══════
+# arje pasa un `envp` EXPLÍCITO y no hereda el del padre. Corriendo la card con `env -i` —que es lo
+# que de verdad va a pasar— salieron dos fallos que con una shell normal no se ven nunca:
+#
+#   1. `PATH` en el `envp`. **gitea lanza `git` como SUBPROCESO** (`git.InitFull`). Sin `PATH` muere
+#      con `git not found: executable file not found in $PATH`, que se lee como «falta git» cuando
+#      git está instalado y es raíz de `perfil.base`. El envp vacío no es «limpio»: es sin PATH.
+#   2. `cd /var/lib/gitea` en el `argv`. El cwd se HEREDA, y gitea corre `git config` en él: con el
+#      cwd del padre el arranque muere con `fatal: error reading '/root/.git'` — un mensaje que
+#      habla de git y de root, y no de que a la card le falte un directorio de trabajo. `Service` no
+#      tiene campo `cwd`, así que va en el argv, a la vista.
+#
+# ⚠ Y `app.ini` tiene que ser ESCRIBIBLE por `gitea`: si le falta un secreto (p. ej. `JWT_SECRET`)
+# lo genera y lo guarda **en el propio fichero**; con el ini de root muere con `permission denied`.
+# En una instalación mudada ya vienen todos, pero el modo correcto es `gitea:gitea 0660`.
+#
+# ══ VERIFICADO DE PUNTA A PUNTA ════════════════════════════════════════════════════════════════
+# Con este argv exacto y `env -i`: escucha en su puerto, `GET /` responde **200**, y el proceso
+# corre como **gitea**. Las dos guardas probadas por separado: sin `app.ini` ⇒ 78 con su mensaje;
+# con `app.ini` y sin el usuario ⇒ 78 con el suyo.
+[[service]]
+label      = "gitea"
+id         = "01M2EKDA00NKYGE2BB5DFH1EFF"
+exec       = "/bin/busybox"
+argv = ["sh", "-c", "test -f /etc/gitea/app.ini || { echo 'gitea: falta /etc/gitea/app.ini — es config del SITIO, viene con los datos' >&2; exit 78; }; /bin/grep -q '^gitea:' /etc/passwd || { echo 'gitea: no existe el usuario `gitea` en /etc/passwd y gitea NO corre como root' >&2; exit 78; }; cd /var/lib/gitea || exit 78; exec /usr/bin/setuidgid gitea /usr/bin/gitea web --config /etc/gitea/app.ini"]
+envp       = [["PATH", "/usr/bin:/bin"], ["HOME", "/var/lib/gitea"], ["GITEA_WORK_DIR", "/var/lib/gitea"], ["USER", "gitea"]]
+networking = "full"
+cgroup     = "arje.slice/gitea"
+restart    = { initial_ms = 1000, max_ms = 30000 }
diff --git a/scripts/mudanza/rutas-fuera-de-git.txt b/scripts/mudanza/rutas-fuera-de-git.txt
index fc456d8d..666a1eb3 100644
--- a/scripts/mudanza/rutas-fuera-de-git.txt
+++ b/scripts/mudanza/rutas-fuera-de-git.txt
@@ -25,6 +25,7 @@
 /etc/caddy                # la configuración del servidor web: los vhosts, que son el mapa de lo que esta máquina sirve
 /etc/nginx                # ídem, si quedó algo del servidor anterior
 /etc/letsencrypt          # certificados y cuentas ACME
+/etc/gitea                # el `app.ini` del gitea: dónde está su DB, con qué dominio se sirve y sus SECRETOS generados
 /var/lib/gitea            # los repos servidos, la sqlite y las claves del gitea
 /etc/arje/cards.d         # las tarjetas de arje: qué arranca esta máquina
 /ente                     # la Semilla de arje-zero