sergio/takana

Escribi hace un rato que el bloqueante del frente C era «la semilla del
toolchain» y que ninguna de las dos cajas la tenia. Falso, y el error es de
metodo: hice `ls /store/*seed-*`, vi solo `seed-zig` y concluí que faltaba otra
— pero `bootstrap stage1` toma `--seed <clase>` con DEFAULT `zig`, o sea que
seed-zig ES la semilla que pide. Estaba sellada todo el tiempo.

Comprobado ejecutandolo: arranca, encuentra musl/busybox/util-linux/hammerd ya
en cache y solo construye arje-zero.

⇒ El control del stage1 —reconstruir y comparar el of_tree contra el ancla de
selfhost-verify.sh— es ejecutable en el hub. El frente C queda con tres pasos
concretos y ninguno bloqueado: hacer el cambio B, re-anclar el EXPECT_REF (el
of_tree cambia por definicion y re-anclarlo es parte del cambio), y el boot test
del producto en el worker con KVM=0.

La leccion es sobre mi: declare un bloqueante a partir de un `ls` y el nombre de
un fichero, sin leer la bandera que decide que semilla se pide. Un `--help`
costaba un comando y me ahorraba inventar un muro que no existia.

diff --git a/docs/plan-botar-busybox.md b/docs/plan-botar-busybox.md
index d8e1ea66..cf8ba67d 100644
--- a/docs/plan-botar-busybox.md
+++ b/docs/plan-botar-busybox.md
@@ -300,29 +300,31 @@ en el hash del rootfs, que es más reproducible que copiarlo al vuelo.
 
 ⇒ **B es más chico y más limpio.** Es la que hay que hacer.
 
-### ⚠ Por qué NO se hizo: no es verificable hoy en ninguna de las dos cajas
-
-Tocar `STAGE1_COMPONENTS` cambia el `of_tree` del stage1, y el único control que existe es
-reconstruirlo y comparar contra el ancla de `scripts/selfhost-verify.sh`
-(`EXPECT_REF=b3:d152f060…`). Para eso hace falta `takana bootstrap stage1`, y eso pide la **semilla
-del toolchain**. Medido:
-
-    hub    : /store/*seed-*            ⇒ sólo `seed-zig`
-    worker : /opt/takana/store/*seed-* ⇒ sólo `seed-zig`
-
-**Ninguna de las dos tiene la semilla del toolchain.** Y el otro control, `product-boot-test.sh`,
-necesita QEMU: el hub no tiene ni `/dev/kvm` ni qemu; el worker tiene `qemu-system-x86_64` sin KVM,
-o sea que puede correr por emulación TCG (`KVM=0`), pero eso valida el PRODUCTO, no el stage1.
-
-⇒ Cambiar la raíz de confianza del arranque sin poder reconstruirla ni arrancarla es exactamente la
-clase de cambio que este repo no hace. **Lo que falta no es decidir ni escribir: es poder medir.**
-
-Para destrabarlo hacen falta dos cosas, en este orden:
-1. **la semilla del toolchain sellada** en alguna de las dos cajas (`takana bootstrap stage0`), que
-   es lo que habilita reconstruir el stage1 y comparar el `of_tree`;
-2. el `product-boot-test.sh` en el worker con `KVM=0` para el lado del producto.
-
-Con esas dos, el cambio B es media hora de código y una tarde de emulación.
+### ❌ ME EQUIVOQUÉ: el stage1 SÍ se puede reconstruir acá
+
+Escribí en este mismo documento que el bloqueante era «la semilla del toolchain» y que **ninguna de
+las dos cajas la tenía**. **Falso.** Miré `ls /store/*seed-*`, vi sólo `seed-zig` y concluí que
+faltaba otra — pero `bootstrap stage1` toma `--seed <clase>` con **default `zig`**, o sea que
+`seed-zig` ES la semilla que pide. Estaba sellada todo el tiempo.
+
+Comprobado corriéndolo: `takana bootstrap stage1 --seed-hash b3:3ce721ec…` arranca, encuentra
+`musl`, `busybox`, `util-linux` y `hammerd` ya en caché y sólo construye `arje-zero`.
+
+⇒ **El control del stage1 (reconstruir y comparar el `of_tree` contra el ancla de
+`selfhost-verify.sh`, `EXPECT_REF=b3:d152f060…`) es ejecutable en el hub.** Lo que queda del frente
+C es, en orden:
+
+1. hacer el cambio **B** (pre-colocar el shim del loader en `assemble_and_seal`, quitar las dos
+   líneas del driver, `busybox → simi` en `STAGE1_COMPONENTS` y `bin/busybox → usr/bin/simi` en
+   `ATTEST_PATHS`);
+2. reconstruir el stage1 y **re-anclar** el `EXPECT_REF` — el `of_tree` cambia por definición, y
+   ese re-ancla es parte del cambio, no un efecto colateral;
+3. `product-boot-test.sh` en el **worker** con `KVM=0` (tiene `qemu-system-x86_64` y no tiene
+   `/dev/kvm`; el hub no tiene ninguno de los dos) para el lado del producto.
+
+**La lección, que es sobre mí:** declaré un bloqueante a partir de un `ls` y el nombre de un
+fichero, sin leer la bandera que decide qué semilla se pide. *Un `--help` habría costado un comando
+y me ahorró inventar un muro que no existía.*
 
 ## La métrica, y el guardián que falta