sergio/takana

El §4 estaba mal orientado y lo dice el propio instalador: takana-live-install.sh:275-283 toma la
rama EFI-STUB SOBERANA (el bzImage ES el binario EFI, cmdline horneada porque la ruta fallback
entrega LoadOptions vacío) y cierra en :495 con «sin GRUB ni systemd-boot». No había nada que
migrar. Y el cuelgue histórico en este metal no era del EFI-stub: era el initrd de 100 MB (ADR 0010
paso 2) — el «Measured initrd PCR 9» es su medición TPM. Hoy el pivote son ~770 K y está VERDE en
OVMF. El muro 1 no es de diseño: es una prueba que falta en el metal.

Decisión del usuario: systemd-boot es systemd ⇒ no. metal-usb-sdboot.sh queda como herramienta de
DIAGNÓSTICO (editar la cmdline en vivo), nunca camino de instalación.

Encargo del usuario: «no borrar particiones, elegir y hasta redimensionar inteligentemente». El §5
se reescribe con lo que hay medido: hoy el instalador hace «o» en busybox fdisk (tabla NUEVA), MBR
sobre un NVMe de 1,8 T y ext2. Lo que ya tenemos: survey del terreno, la NVRAM por efivarfs sin
efibootmgr, y parted 3.7 / e2fsprogs 1.47.4 / util-linux 2.42.2 / dosfstools / mtools SELLADOS. Lo
que falta, nombrado: modo «partición destino», GPT, encoger, y el límite que no es de software —un
fs montado no se encoge, así que redimensionar /home exige otro medio.

§6 nuevo: instalar desde otro SO. Desde Linux casi todo existe — el binario es ELF ESTÁTICO, corre
en cualquier x86-64. Desde Windows: WSL2 no tiene efivarfs, un .exe nativo es un port, y la vía
Wubi está bloqueada por -d NTFS3_FS en los cuatro kernels.

Y el §3 queda pagado: las cinco selladas con hash vigente, zsh «statically linked», perfil 5/5.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

diff --git a/docs/runbooks/instalador-laptop-tigerlake.md b/docs/runbooks/instalador-laptop-tigerlake.md
index 6b5ad27d..e6a068ec 100644
--- a/docs/runbooks/instalador-laptop-tigerlake.md
+++ b/docs/runbooks/instalador-laptop-tigerlake.md
@@ -1,8 +1,11 @@
 # Runbook — el instalador para la laptop del usuario (TigerLake), y los dos muros que tiene delante
 
-> **Estado: ENCARGO, no cerrado.** Las recetas de este runbook se escribieron el 2026-09-16 desde el
-> propio laptop —que no tiene lab ni store— así que **ninguna está sellada**. Lo que sigue es el
-> trabajo para el worker, en orden, con lo que ya está medido separado de lo que hay que averiguar.
+> **Estado: ABIERTO — pero el §3 ya está PAGADO.** Las recetas se escribieron el 2026-09-16 desde el
+> propio laptop —que no tiene lab ni store— así que nacieron sin sellar; **el 2026-09-23 se verificó
+> que las cinco están selladas con su hash VIGENTE** (ver §3). Lo que queda abierto es el arranque en
+> el metal y, sobre todo, **el instalador no destructivo del §5**, que pasó a ser el trabajo central
+> del frente por decisión del usuario (2026-09-23). El §4 se REESCRIBIÓ: systemd-boot queda
+> descartado y no hacía falta.
 > Hermano de [`kde-qemu-desktop.md`](kde-qemu-desktop.md) y [`cosmic-desktop.md`](cosmic-desktop.md),
 > de los que reusa todo el andamiaje.
 
@@ -44,6 +47,13 @@ instalador.
 
 ## 3. La tanda — qué construir, en orden
 
+> ✅ **HECHO y verificado el 2026-09-23.** Las cinco están selladas con el hash vigente en el store
+> del worker, y `firmware-tigerlake` re-selló el 2026-09-17 al ganar la dep `wireless-regdb`
+> (upstream sacó `regulatory.db` de `linux-firmware`). El perfil `metal-tigerlake` da **5/5** en
+> `docs/state/build-state.json`. Y el riesgo que este runbook anotaba **no se materializó**: `file`
+> sobre `bin/zsh` dice `statically linked`. Lo que sigue en esta sección queda como MÉTODO, para
+> cuando alguna de las cinco haya que rehacerla.
+
 El orden importa: `firmware-tigerlake` depende de las dos de firmware y falla ruidosa si no las
 encuentra materializadas.
 
@@ -69,75 +79,145 @@ fichero abierta y los nietos la heredan.
   como dep. No ablandar la aserción: ese contador es la única defensa contra un `/lib/firmware` a
   medias, que no falla al construir y falla meses después en el metal como «no hay WiFi».
 
-## 4. ⚠ Muro 1 — la rama EFI del instalador es justo la que se cuelga en este firmware
-
-Éste es el hallazgo que ordena el trabajo, y sale de cruzar dos ficheros que nadie había leído juntos.
-
-`scripts/takana-live-install.sh:275-281` detecta el firmware y bifurca:
-
-> `--- Detección de firmware: UEFI ⇒ rama EFI-stub SOBERANA (ADR 0010 paso 5); BIOS ⇒ MBR+GRUB ---`
-
-O sea: en esta laptop, que es UEFI, el instalador tomaría **la rama EFI-stub**. Y
-`scripts/metal-usb-sdboot.sh` dice, en su tercera línea:
-
-> *Alternativa de BRINGUP al boot por EFI-stub directo (que **en el firmware del usuario se cuelga
-> tras 'Measured initrd PCR 9'**, por el quirk de LoadOptions del firmware).*
-
-**Es el mismo firmware.** El lazo completo de instalación EFI está validado en OVMF
-(`scripts/efi-install-test.sh`), y OVMF no tiene ese quirk. Así que el instalador probablemente
-funcione perfecto en la prueba y se cuelgue en el metal de destino.
-
-Las tres salidas, en orden de coste:
-
-1. **Llevar el instalador a systemd-boot**, que es el camino ya probado en este metal: pasa una
-   cmdline limpia y entrega el initrd por `LoadFile2`, esquivando el quirk. El precio está escrito y
-   aceptado como deuda: `systemd-bootx64.efi` es un binario ajeno del host — crutch de bringup.
-2. **Arrancar el medio por systemd-boot y dejar que instale la rama EFI-stub.** No sirve: el disco
-   instalado arrancaría por EFI-stub y se colgaría igual, sólo que después de borrar Artix.
-3. **Loader soberano propio.** Es el `TODO` que ya está anotado y no es trabajo de una sesión.
-
-⇒ **Recomendado: (1).** Y el test de aceptación no es OVMF: es el USB arrancando en el metal.
-
-## 5. ⚠ Muro 2 — el particionado, y una pregunta que es del usuario
-
-`takana-live-install.sh` particiona en **MBR**, incluida su rama EFI (una ESP tipo `0xEF` en tabla
-MBR, que UEFI acepta igual). Sobre el disco de esta laptop eso tiene dos consecuencias:
-
-- El NVMe es de **1,8 T**. MBR direcciona hasta 2 T: entra por poco, pero es el borde exacto del
-  formato y no hay razón para quedarse ahí cuando el disco ya es GPT.
-- El instalador **reparticiona el disco entero**. Hoy ese disco tiene `/home` con **893 G usados de
-  1,1 T** — el trabajo del usuario, incluido `~/tawasuyu` (497 G).
-
-> **Pregunta abierta, y es decisión del usuario, no del runbook:** ¿la instalación conserva `/home`
-> —instalando sólo sobre la raíz de 164 G— o se lleva el disco entero con respaldo previo? El
-> instalador hoy no sabe hacer lo primero: no tiene modo «usar esta partición y no tocar las otras».
-
-Mientras eso no se decida, **no correr el instalador sobre `/dev/nvme0n1`.** El camino sin riesgo es
-el USB: `metal-usb-sdboot.sh` produce una imagen para `dd` a un pendrive y no toca el disco interno.
-
-## 6. Orden de trabajo propuesto
-
-1. Construir la tanda del §3 y verificar que `zsh` sale estático y que `firmware-tigerlake` reporta
-   los tres contadores distintos de cero.
-2. Armar un USB de prueba con el perfil compuesto y **arrancarlo en el metal**:
-   ```sh
-   scripts/targets.py cli metal-tigerlake escritorio-kde      # la lista de la imagen
-   scripts/metal-usb-sdboot.sh                                 # → work/hammer-metal-usb.img
-   ```
-   Lo que se valida acá no es el escritorio: es **el firmware**. Que asocie el WiFi, que el display
-   tome el DMC y que el DSP de audio levante. Son las tres cosas que hoy sólo funcionan porque las
-   presta la Artix instalada.
-3. Recién entonces, el instalador: la rama systemd-boot del §4 y la decisión de particionado del §5.
-4. Y sólo después, KDE/GNOME/COSMIC en metal con GPU real — hoy los tres corren por llvmpipe, que en
-   QEMU es correcto y en una Iris Xe es tirar la GPU a la basura.
-
-## 7. Lo que este runbook NO resuelve
+## 4. Muro 1 — CAE POR DECISIÓN: systemd-boot queda descartado, y no hacía falta
+
+> **Decisión del usuario, 2026-09-23: systemd-boot es systemd ⇒ NO.** Esa elección era circunstancial
+> — un crutch de bringup — y el arranque soberano ya existe. Lo que sigue corrige lo que este mismo
+> runbook recomendaba el 2026-09-16, que estaba mal orientado.
+
+Lo que decía el §4 viejo: «el instalador toma la rama EFI-stub y ésa es la que se cuelga; llevémoslo
+a systemd-boot». Al leer el instalador se ve que **la premisa estaba invertida**:
+
+- `scripts/takana-live-install.sh:275-283` — la rama UEFI es **EFI-stub SOBERANO**, ADR 0010 paso 5:
+  el `bzImage` ES el binario EFI, se copia a `\EFI\BOOT\BOOTX64.EFI`, y la cmdline va **horneada**
+  en `CONFIG_CMDLINE` porque la ruta fallback entrega `LoadOptions` VACÍO. Cierra en `:495` diciendo
+  «sin GRUB ni systemd-boot». **No hay nada que migrar: ya es soberano.**
+- El cuelgue histórico en este metal **no era del EFI-stub**, era del **initrd de 100 MB**
+  (ADR 0010 paso 2, y el «Measured initrd PCR 9» es justamente la medición TPM de ese initrd). El
+  initramfs de hoy es un **pivote de ~770 K** (`findfs LABEL=hammer-root` → `switch_root`), y con él
+  el EFI-stub directo está **validado VERDE en OVMF** (`scripts/efi-disk-boot-test.sh`).
+
+⇒ **El muro 1 no es un muro de diseño: es una prueba que falta.** Nadie arrancó todavía el EFI-stub
+con el initrd chico **en este metal**. Lo que colgó en su día fue otra cosa, ya arreglada.
+
+`scripts/metal-usb-sdboot.sh` se queda donde está, con su rol reducido y dicho en voz alta:
+**herramienta de diagnóstico** (permite editar la cmdline en vivo con `e`, que es oro cuando algo no
+arranca), **nunca el camino de instalación**. Su `systemd-bootx64.efi` sale de un rootfs de Arch del
+home del usuario: binario ajeno, sin hash, fuera del store.
+
+## 5. Muro 2 — el particionado es el trabajo de verdad: elegir, conservar, redimensionar
+
+> **Encargo explícito del usuario, 2026-09-23:** *«sí hay que poder no borrar particiones, elegir y
+> hasta redimensionar inteligentemente»*. Deja de ser una pregunta abierta y pasa a ser la unidad de
+> trabajo principal de este frente.
+
+Hoy el instalador hace lo contrario de eso, y conviene verlo exacto antes de cambiarlo
+(`takana-live-install.sh`, rama UEFI):
+
+| qué hace hoy | por qué no sirve para esta laptop |
+|---|---|
+| `busybox fdisk` con un guion de `o` (tabla NUEVA) + 4 primarias | **borra la tabla entera**; adiós a todo lo que haya |
+| tabla **MBR**, con la ESP como tipo `0xEF` | el NVMe es de 1,8 T — MBR direcciona hasta 2 T: el borde exacto del formato, sin razón para quedarse ahí |
+| root/store/estado en **ext2** | el disco instalado se merece ext4; es la misma `mke2fs` |
+| tamaños por variables `ROOT_MB`/`STORE_MB`, resto = estado | no hay forma de decir «usá ESTA partición y no toques las otras» |
+
+**Lo que ya está de nuestro lado**, y es más de lo que parece:
+
+- `takana boot entry survey` **ya lee el terreno sin tocarlo**: firmware, ESPs, espacio libre y
+  **vecinos** (nombra un `\EFI\Microsoft` si lo hay). El instalador ya lo invoca antes de escribir.
+- `takana boot entry` completo —`list`/`add`/`backup`/`restore`/`reconcile`— escribe la NVRAM por
+  `efivarfs` **sin `efibootmgr`** (`crates/takana-cli/src/efi_boot.rs`). Es lo que permite instalar
+  **al lado** de otro sistema en vez de encima: entrada propia, `BootOrder` reconciliado, y un
+  `backup` del estado de arranque ANTES de tocarlo.
+- Las herramientas de disco **ya están selladas en el corpus**, no hay que construir nada nuevo:
+
+  | receta | versión | lo que aporta |
+  |---|---|---|
+  | `parted` | 3.7 | GPT, mover/crear particiones |
+  | `e2fsprogs` | 1.47.4 | `resize2fs` (encoger ext4), `mke2fs -d` |
+  | `util-linux` | 2.42.2 | `sfdisk` (editar la tabla sin recrearla), `lsblk`, `blkid`, `wipefs` |
+  | `dosfstools` | 4.2 | la ESP |
+  | `mtools` | 4.0.49 | poblar la ESP sin root ni loop |
+
+**Lo que falta, nombrado:**
+
+1. **Un modo «partición destino»** en el instalador: recibir `/dev/nvme0n1p2`, formatearla, **no
+   tocar la tabla**, reusar la ESP que ya existe y registrar la entrada NVRAM. Es el 80 % del valor
+   y el 20 % del trabajo.
+2. **GPT en vez de MBR** cuando la tabla es nueva: `sfdisk`/`parted` ya están; `busybox fdisk` sale.
+3. **Encoger** (`resize2fs` + `sfdisk` reescribiendo sólo esa entrada). ⚠ **Límite físico, no de
+   software: un filesystem montado NO se encoge** — ext4 sólo crece online. Encoger `/home` exige
+   que esté desmontada ⇒ **hay que correr el instalador desde otro medio**, no desde la Artix viva.
+   Eso no lo arregla ningún instalador: es la razón por la que el USB sigue haciendo falta.
+4. **NTFS: no lo podemos redimensionar hoy.** No hay receta de `ntfs-3g`/`ntfsprogs` (⇒ sin
+   `ntfsresize`) y los cuatro kernels traen `-d NTFS3_FS` deshabilitado. Para esta laptop da igual
+   —es Artix— pero es un bloqueo duro para «instalar al lado de Windows» de cara al público.
+5. **`backup` de la NVRAM y de la ESP antes de escribir**, ofrecido por defecto. Ya existe el
+   subcomando; falta que el instalador lo llame.
+
+## 6. Instalar desde OTRO sistema operativo, sin medio live
+
+La pregunta del usuario (2026-09-23) es si se puede romper con la instalación tradicional y tener un
+**instalador standalone** que corra desde Windows o desde otro Linux. La respuesta se parte en dos, y
+son muy distintas.
+
+### Desde otro Linux (incluida la Artix que está instalada): casi todo existe
+
+`target/release/takana` es un **ELF estático** (`statically linked`, musl): se copia a cualquier
+Linux x86-64 y corre **sin instalar nada, sin deps, sin root de esa distro más que para el disco**.
+Eso ya es un instalador standalone; lo que falta es el envoltorio. Las piezas:
+
+| pieza | estado |
+|---|---|
+| leer el terreno | ✅ `takana boot entry survey` |
+| escribir la entrada de arranque | ✅ `takana boot entry add` (efivarfs, sin efibootmgr) |
+| deshacer si algo sale mal | ✅ `takana boot entry backup` / `restore` |
+| traer los bits | ✅ `takana mirror` (por hash, verificando `of_tree`) y `takana hydrate` |
+| elegir partición / redimensionar | ❌ el §5 |
+
+Caso de uso inmediato: instalar takana **en una partición libre** desde la Artix corriendo, y
+reiniciar eligiendo en el firmware. Sin USB y sin viaje físico. El límite es el del §5.3: lo que no
+se puede es tocar la partición que estás usando.
+
+### Desde Windows: posible, pero es un proyecto propio
+
+Tres caminos, de menor a mayor honestidad sobre lo que cuestan:
+
+1. **WSL2** — corre el binario estático tal cual, y `wsl --mount --bare` le da el disco crudo. Pero
+   WSL2 es una VM **sin firmware UEFI real: no hay `efivarfs`**, así que la entrada de arranque no
+   se puede escribir desde ahí; habría que crearla desde Windows con `bcdedit` (que sí sabe añadir
+   una *firmware application*). Es el camino barato y deja una costura fea.
+2. **Un ejecutable Windows nativo** — Rust compila a `windows-msvc`, pero toda la capa de disco y de
+   NVRAM es Linux-específica: habría que reescribirla sobre `\\.\PhysicalDrive` y
+   `SetFirmwareEnvironmentVariable`. Es *el* instalador standalone de verdad, y es su propia unidad
+   de trabajo — no una sesión.
+3. **Fichero-imagen en NTFS al estilo Wubi** (no tocar particiones en absoluto) — **bloqueado hoy**:
+   el kernel se construye con `-d NTFS3_FS`, así que el pivote no podría montar el contenedor. Pide
+   rebuild del kernel y un initramfs que sepa hacer loop.
+
+Para **esta** laptop no hace falta nada de Windows: el sistema que hay es Linux. Windows entra
+cuando el objetivo sea que lo instale **otra gente** (SDD 19, lanzamiento público).
+
+## 7. Orden de trabajo
+
+1. **Hidratar el hub.** Las cinco del §3 están selladas con el hash vigente **en el worker**, no en
+   el `/store` de esta caja (acá quedan versiones viejas, p. ej. `14789737…-firmware-tigerlake`).
+   Sin eso no se arma ninguna imagen desde el hub.
+2. **USB de prueba y arrancarlo en el metal.** Lo que se valida NO es el escritorio: es **el
+   firmware** —que asocie el WiFi, que el display tome el DMC, que levante el DSP de audio— y, con
+   el mismo viaje, **el EFI-stub soberano con el initrd chico** (§4), que es la prueba que falta.
+3. **El instalador no destructivo** del §5: primero el modo «partición destino» (1 y 2), después el
+   redimensionado (3).
+4. **Recién entonces** tocar el disco de la laptop.
+5. Y después, los escritorios con GPU real: hoy los cuatro corren por llvmpipe, que en QEMU es
+   correcto y en una Iris Xe es tirar la GPU a la basura.
+
+## 8. Lo que este runbook NO resuelve
 
 - **La laptop sigue sin poder hidratar.** Su `.dev-fs/alpine` tiene 104 paquetes contra los 110 de
   `lab-toolchain.lock`, así que calcula `ArtifactHash` distintos y no encuentra nada del store
-  compartido. Hasta que `farm-lab-sync.sh` corra hacia acá, todo lo de este runbook pasa por el
-  worker.
+  compartido. Hasta que `farm-lab-sync.sh` corra hacia allá, todo pasa por el worker.
 - **`kitty`, el terminal del usuario, no tiene receta.** `foot` sí está sellada y es el terminal
   Wayland del proyecto; sirve de puente, pero no es lo que él usa.
-- **Los escritorios en metal con aceleración.** Distinto problema del firmware: es mesa con el driver
-  Iris real en vez de llvmpipe.
+- **Los escritorios en metal con aceleración.** Distinto problema del firmware: es mesa con el
+  driver Iris real en vez de llvmpipe.