sergio/takana

Los 10 crates de librería + CLI renombrados, con los dos binarios congelados y
su razón. Anotada la consecuencia real: renombrar hammer-core mueve los bytes
de hammerd igual, así que el baseline of_tree del selfhost hay que rehacerlo.

Y la medición que cambia el plan: 'la variable HAMMER=' no existe como cosa
única — son 14 variables, ~260 apariciones, y el BINARIO las lee (HAMMER_LAB,
HAMMER_ZIG, HAMMER_WORK, HAMMER_ROOTFS, HAMMER_MIRROR_KEY, HAMMER_LLM_*). Con
knobs de instalador entre ellas y el entorno del worker trayéndolas puestas
desde fuera del repo. Eso es contrato de usuario, no churn: pide leer las dos
con caída a la vieja, que es código, no sed.

Sumada la evidencia del worker: tras reiniciar el servicio compiló los dos
binarios y cerró un ciclo real (dunst sellado, 1/1).

diff --git a/docs/adr/0016-renombre-takana.md b/docs/adr/0016-renombre-takana.md
index 69584579..057a8a6e 100644
--- a/docs/adr/0016-renombre-takana.md
+++ b/docs/adr/0016-renombre-takana.md
@@ -100,7 +100,46 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con
 
    La unit apunta a la RUTA DEL SCRIPT, no al binario, así que nada de la etapa 3 la toca. El
    nombre del fichero de unit y `/opt/hammer` son etapa 6.
-4. **Crates** `hammer-*` → `takana-*` y `hammerd` → `takanad`.
+
+   **Convergido y comprobado (2026-09-09 18:40–18:45Z).** Reiniciado `hammer-farm.service`, el
+   worker compiló los dos binarios y **cerró un ciclo de build real con el nombre nuevo**:
+   `✓ dunst b3:29a79859…`, BUILD-YIELD 1/1, 1 promovido. No es que «no se rompió nada visible»: el
+   camino de construir y sellar se ejercitó entero.
+4. **Crates.** ← *hecho parcialmente (2026-09-09)*. Los 10 de librería + CLI
+   (`hammer-{core,build,bootstrap,overlay,journal,mirror,upgrade,agent,recover,cli}`) son
+   `takana-*`. **Verificado que no mueve el corpus**: `takana hash recipes/zlib.toml` devuelve
+   `b3:dc363f26…`, idéntico a antes. 600 tests en verde.
+
+   **Dos binarios congelados, con razón medida:**
+   - `hammerd` — paquete **y** binario. Es componente de Stage 1 de la distro (musl, busybox,
+     hammerd, arje-zero), arje-zero lo supervisa en el sistema arrancado y `PRESEED=hammerd` lo
+     nombra en `selfhost-verify.sh`.
+   - `hammer-recover` — el paquete es `takana-recover`, **el binario sigue siendo
+     `hammer-recover`**: `hammer-live-install.sh` lo copia a `/usr/sbin/hammer-recover` en sistemas
+     **ya instalados** y hornea un hook de arranque que lo invoca por ese nombre. Renombrarlo no
+     rompe el repo: rompe máquinas instaladas.
+
+   **Consecuencia que hay que anotar igual:** al renombrar `hammer-core`, los bytes de `hammerd`
+   cambian de todos modos —linkea contra un crate con otro nombre y el nombre va en los símbolos—,
+   así que **el baseline `of_tree` del selfhost hay que rehacerlo**. Es efecto de la etapa 4, no de
+   un cambio en `hammerd`.
+
+4 bis. **Las variables de entorno son su propia unidad, no la cola de la 4.** Se midió antes de
+   tocarlas y el problema tiene otra forma que la que suponía el plan: no es «la variable
+   `HAMMER=`», son **14** (`HAMMER`, `HAMMER_DIR`, `HAMMER_BIN`, `HAMMER_STORE`, `HAMMER_MUSL`,
+   `HAMMER_MIRROR`, `HAMMER_TZ`, `HAMMER_KEYMAP`, `HAMMER_KERNEL`, `HAMMER_HOSTNAME`, `HAMMER_ZIG`,
+   `HAMMER_WORK`, `HAMMER_ROOTFS`, `HAMMER_LIVE`, `HAMMER_CACHE`), ~260 apariciones en 58 ficheros,
+   **y el binario las lee**: `HAMMER_LAB`, `HAMMER_ZIG`, `HAMMER_WORK`, `HAMMER_ROOTFS`,
+   `HAMMER_MIRROR_KEY`, `HAMMER_LLM_*`.
+
+   ⇒ **Son contrato de usuario, del mismo tipo que un verbo de CLI**, no churn interno: hay knobs
+   del instalador (`HAMMER_TZ`, `HAMMER_KEYMAP`, `HAMMER_HOSTNAME`), el entorno del worker las trae
+   puestas (`mirror-env.sh`) y quedan fuera del repo, en perfiles de shell y units. Un `sed` las
+   rompe en silencio.
+
+   El patrón correcto es el mismo que el resto del renombre: **leer las dos, preferir la nueva**
+   (`TAKANA_X` con caída a `HAMMER_X`), lo que es un cambio de código en Rust más un barrido de
+   scripts. Va como unidad propia, con su decisión.
 5. **Comentarios de recetas** (692). Gratis en hash, ruidoso en diff: va en un commit propio y solo.
 6. **Retirar el alias.** Y recién entonces, si se quiere, el directorio `/mnt/vvv/hammer` — parando
    el cron y reescribiendo el crontab en el mismo movimiento.