renombre: los instaladores pasan a takana-* — y el peligro no era el fichero, era el PROTOCOLO

ADR 0016 los listaba entre los CONGELADOS; el usuario pidió descongelarlos al abrir el SDD 28. La
enmienda queda escrita en el propio ADR, que si no la etiqueta deja de describir el hecho.

`hammer-install.sh` → `takana-install.sh`, `hammer-live-install.sh` → `takana-live-install.sh`,
`hammer-banner.txt` → `takana-banner.txt`, `BRIEFING-hammer.md` → `BRIEFING-takana.md`.

**Lo que hacía caro esto no es el nombre del fichero.** El instalador se inyecta en el ISO como
`/usr/bin/hammer-install` y su éxito se detecta con un `grep` de `HAMMER-INSTALL-OK` desde TRES
scripts de prueba. Renombrar un solo lado los deja casando NADA — sin fallar —, que es literalmente
el modo en que `atribuir-fallos.py` quedó mudo cuando el renombre movió el target de `tracing`.
Se renombraron las dos puntas en el mismo commit (`/usr/bin/takana-install`,
`TAKANA-INSTALL-OK/FAIL`, `TAKANA_INSTALL_*`, `work/takana-install.img`, `/run/takana-install`),
se comprobó por `grep` que no quede ningún token viejo fuera del ADR, y —lo que decide— se CORRIÓ
`install-tui-test.sh`: 4/4 casos verdes.

Las tres `TAKANA_INSTALL_*` caen al nombre viejo (`${TAKANA_INSTALL_X:-${HAMMER_INSTALL_X:-}}`):
el llamador puede ser un ISO anterior al renombre. Misma convención que `TAKANA_ROOT_PW` unas
líneas más arriba en ese mismo script.

NO se tocó `/usr/sbin/hammer-recover` ni su hook de arranque —renombrarlo rompe máquinas YA
INSTALADAS, no el repo—: sobrevive intacto dentro del script renombrado, verificado por conteo
antes y después (8 ocurrencias). Tampoco `hammerd`, `hammer-edit` (su `name` está en la ruta del
store), `/var/lib/hammer`, `HAMMER_LIVE` ni los siete literales de hash.

De paso: `scripts/.hammer-banner.txt.kate-swp` era un swap de editor commiteado por error. Fuera.

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

docs/adr/0010-arranque-grafo-mirada.md

@@ -132,7 +132,7 @@ muerto antes del takeover).
    - **host-side** `scripts/install-image-efi.sh` — GPT+ESP+root/store/state, ESP con mtools de takana,
      ext4 con `mke2fs -d` bajo `unshare -r`; **validado VERDE en OVMF** (`scripts/efi-disk-boot-test.sh`:
      firmware → BOOTX64.EFI → pivote → arje-zero PID1).
-   - **live-side** `scripts/hammer-live-install.sh` rama EFI — detecta `/sys/firmware/efi` y hace
+   - **live-side** `scripts/takana-live-install.sh` rama EFI — detecta `/sys/firmware/efi` y hace
      **MBR con ESP tipo 0xEF** (UEFI arranca una ESP MBR igual que GPT ⇒ alcanza busybox
      fdisk/mkfs.vfat/mount, sin GPT-tool ni mtools en el live). El kernel EFI-stub viaja en el payload
      (`iso-image.sh INSTALLER=1` bundlea `bzImage-efi`). **Validación 2-stage VERDE en OVMF**

docs/adr/0016-renombre-takana.md

@@ -223,9 +223,32 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con
    reescribir historia es peor que un mensaje incompleto. El detalle vive acá.)*
 
    **Congelados y verificados con controles:** `/opt/hammer`, `/var/lib/hammer`, `/usr/bin/hammer`,
-   `/mnt/vvv/hammer`, la URL de gitea, `hammer-farm.service`, `hammer-live-install.sh`,
-   `BRIEFING-hammer.md`, `hammerd`, `hammer-recover`, `HAMMER_LIVE`, `.hammer-zig-cc`,
+   `/mnt/vvv/hammer`, la URL de gitea, `hammer-farm.service`, ~~`hammer-live-install.sh`~~,
+   ~~`BRIEFING-hammer.md`~~, `hammerd`, `hammer-recover`, `HAMMER_LIVE`, `.hammer-zig-cc`,
    `.hammer-cargo-vendor` y dos identificadores más que aparecieron al barrer:
+
+   > **ENMIENDA 2026-09-09 — dos de esos congelados se descongelaron por decisión del usuario**
+   > («renombrá todos los `hammer` que vayas encontrando, como ese `hammer-install`»), al abrir el
+   > frente del [SDD 28](../28-servidor-de-produccion.md). Renombrados:
+   > `hammer-install.sh` → `takana-install.sh`, `hammer-live-install.sh` → `takana-live-install.sh`,
+   > `hammer-banner.txt` → `takana-banner.txt`, `BRIEFING-hammer.md` → `BRIEFING-takana.md`.
+   >
+   > **Lo que hacía peligroso este renombre no era el fichero: era el PROTOCOLO.** El instalador se
+   > inyecta en el ISO como `/usr/bin/hammer-install` y su éxito se detecta con un `grep` de
+   > `HAMMER-INSTALL-OK` desde **tres** scripts de prueba (`iso-install-test.sh`,
+   > `efi-install-test.sh`, `install-tui-test.sh`). Renombrar un solo lado deja los tests casando
+   > **nada** — sin fallar, exactamente el modo en que `atribuir-fallos.py` quedó mudo al renombrar
+   > el target de `tracing`. Se renombraron **las dos puntas** en el mismo commit
+   > (`/usr/bin/takana-install`, `TAKANA-INSTALL-OK/FAIL`, `TAKANA_INSTALL_*`), se comprobó por
+   > `grep` que no quedara ningún token viejo, y se **corrió** `install-tui-test.sh`: 4/4 verdes.
+   >
+   > **Lo que NO se tocó, y sigue congelado por la misma razón de antes**: el binario
+   > `/usr/sbin/hammer-recover` y su hook de arranque (renombrarlo rompe **máquinas ya instaladas**,
+   > no el repo) — sobrevive intacto dentro del script renombrado, verificado por conteo antes y
+   > después. Tampoco `hammerd`, `hammer-edit`, `/var/lib/hammer`, `HAMMER_LIVE` ni los siete
+   > literales de hash. Y las tres variables `TAKANA_INSTALL_*` **caen al nombre viejo**
+   > (`${TAKANA_INSTALL_X:-${HAMMER_INSTALL_X:-}}`), porque el llamador puede ser un ISO anterior al
+   > renombre — la misma convención que `TAKANA_ROOT_PW` unas líneas más arriba en ese script.
    - `hammer-build-state/1` — el `schema` del estado generado. Nadie lo valida, pero el valor de un
      identificador de esquema **es** ser estable; renombrarlo no gana nada.
    - `hammer-edit` — es una **receta con artefacto sellado**: su `name` está en la ruta del store