diff --git a/docs/11-bootstrap.md b/docs/11-bootstrap.md
index 3b33a6bd..45a463c2 100644
--- a/docs/11-bootstrap.md
+++ b/docs/11-bootstrap.md
@@ -172,7 +172,41 @@ hammer bootstrap --all                # las tres + reporte de reproducibilidad
   del roadmap. ☐
 - **Kernel:** importado pinned ahora; from-source después. ☐
 
-## 7. Hecho cuando
+## 7. Auto-alojamiento: el builder rootfs (camino a Stage 2 pleno)
+
+La verificación de reproducibilidad de Stage 2 ya está operativa y probada: `of_tree` (content-hash
+de bytes) + `verify_against`, y los 4 componentes reconstruyen **bit-idéntico** (ver
+[runbook §8/§8b](runbooks/stage1-vm-boot.md)). Lo que falta es el **rebuild *dentro* del rootfs
+usando sólo sus herramientas** — y ahí aparece el obstáculo real:
+
+> El Stage 1 que booteamos es un **runtime** (musl+busybox+hammerd+arje-zero): **no trae compilador**
+> (ni `zig`, ni `make`/autotools, ni `cargo`/rust, ni `linux-headers`, ni `bwrap`). No puede
+> reconstruir nada. El rebuild in-rootfs exige un **builder rootfs**: Stage 1 + el toolchain adentro.
+
+### 7.1 Qué necesita el builder rootfs
+
+Para correr `hammer bootstrap stage1` **dentro** de sí mismo: el binario `hammer` (estático), las
+recetas, la **semilla** (`zig`, ya un artefacto sellado), `make`+autotools, `cargo`+rust,
+`linux-headers`, y `bwrap` (el lab anida un sandbox ⇒ userns sin privilegios dentro del chroot/VM).
+
+### 7.2 Dos niveles de pureza (fasable)
+
+- **(a) Builder pragmático** — el toolchain entra al rootfs **desde Alpine** (apk), no construido por
+  hammer. Demuestra el **mecanismo** (rebuild in-rootfs + `of_tree(stage1)==of_tree(stage1')`) y
+  cierra la reproducibilidad *end-to-end*, sin ser aún auto-alojamiento puro.
+- **(b) Auto-alojamiento puro** — el toolchain lo **construye hammer desde fuente** (recetas para
+  make/autotools, y el gran tramo: rust/llvm o un rustc bootstrappeado). Es el end-state; el más
+  caro (construir rust desde cero). Se llega **incrementalmente**, reemplazando una a una las piezas
+  Alpine por componentes hammer, con Stage 2 verificando cada paso.
+
+### 7.3 Enganche con lo ya hecho
+
+`stage2` ya ancla `of_tree(stage1)`; el builder produce `stage1'` y `verify_against` emite el
+veredicto. El determinismo necesario está cubierto (paths fijos `/src`, `SOURCE_DATE_EPOCH`, locks
+deterministas). El sub-ítem es: **ensamblar el builder** (variante de `assemble_rootfs` que hidrata
+el toolchain) y **correr el rebuild anidado** en la VM.
+
+## 8. Hecho cuando
 
 `hammer bootstrap --all` produce un rootfs que, ejecutado en la VM destino, **reconstruye su
 propio toolchain y userland con hashes idénticos a los publicados**, sin que ninguna