diff --git a/docs/31-compilador-de-rust.md b/docs/31-compilador-de-rust.md
index 9a33a110..eeb0c014 100644
--- a/docs/31-compilador-de-rust.md
+++ b/docs/31-compilador-de-rust.md
@@ -103,6 +103,62 @@ Las salidas, por orden de honestidad:
 
 ⇒ La 1 es la que Alpine ya demostró que funciona, y es la que sigue.
 
+## 4.ter ✅ EL ESCALÓN 2 SELLÓ *(2026-09-16 00:18)*
+
+**`rust` 1.97.0 desde fuente: `b3:015a07fb…`, 353 M.** Construido por la granja, en el worker, desde
+`llvm21` del corpus y el stage0 del lab.
+
+Los controles, corridos en la caja (que sí tiene el cargador musl; el worker no):
+
+    $ rustc --version
+    rustc 1.97.0 (2d8144b78 2026-07-07) (built from a source tarball)     ← NUESTRO
+    $ rustc --print target-list | grep alpine
+    x86_64-alpine-linux-musl                                              ← EL PARCHE, DENTRO
+    $ cargo --version
+    cargo 1.97.0 (c980f4866 2026-06-30) (built from a source tarball)
+
+Y compila: `--emit=obj` da un objeto de 3,5 K y `--crate-type=rlib` una biblioteca de 6,4 K, las dos
+sin tocar el enlazador.
+
+### Los dos muros de esta tanda
+
+6. **El triple de Alpine no existía en el producto.** Resuelto con `rust-alpine-target.patch`, que lo
+   registra en `rustc_target` — un spec copiado del canónico con `crt_static_default = false` (sin
+   eso no hay dylibs y sin dylibs no hay proc-macros) y una línea en `supported_targets!`. Es lo que
+   hace Alpine. **El control no es que el build pase: es que `--print target-list` lo liste.**
+7. **`openssl-sys`, a la hora y media de build.** `tools = ["cargo"]` lo arrastra. La dep que entró es
+   **`openssl-threads` y no la canónica**: el `Configure` de openssl apaga los threads en cuanto ve
+   `-static` en LDFLAGS, y cargo es masivamente multihilo. Más `OPENSSL_STATIC=1`/`OPENSSL_DIR=/usr`,
+   porque el lab publica `.a` y ningún `.so`.
+
+### 🧱 Muro 8, ya medido: el compilador no trae con qué ENLAZAR
+
+En una caja sin `cc` —o sea, en cualquier takana que no sea un hub— el enlace falla:
+
+    $ rustc hola.rs -C linker-flavor=ld.lld
+    error: linker `lld` not found
+    $ rustc hola.rs -C linker=/usr/bin/ld -C link-self-contained=yes
+    /usr/bin/ld: cannot find -lgcc
+
+La causa está en el log del propio build, en una línea que parece informativa:
+
+    skipping llvm-tools (x86_64-alpine-linux-musl): external LLVM
+
+Al usar un LLVM externo —que es lo que queremos, porque `llvm21` es del corpus— **x.py se salta las
+herramientas de LLVM, y `rust-lld` es una de ellas**. El prebuilt oficial sí lo trae, y por eso el
+escalón 1 enlazaba y éste no. Y `llvm21` tampoco sirve de repuesto: **no publica ningún `lld`**
+(medido: 1,6 G de artefacto, cero binarios `lld`).
+
+⇒ Las salidas son dos, y hay que elegir: **(a)** `[rust] lld = true` en el `bootstrap.toml`, que
+construye `rust-lld` desde el `llvm-project` vendoreado en el tarball —el toolchain queda completo y
+autosuficiente—; o **(b)** publicar `lld` desde `llvm21` y fijar el linker en un
+`/etc/cargo/config.toml` del sitio. La (a) es la que hace que «tener compilador de Rust» signifique
+lo que parece.
+
+⚠ Y lo que esto enseña del método: **el artefacto selló, reproduce y no enlaza**. Es la familia de
+[[subcomando-sin-driver]] en el corazón del toolchain — un compilador que compila y no produce un
+ejecutable. Un `build ok` no es la prueba; la prueba es el objeto en el disco y el binario corriendo.
+
 ## 5. Lo que falta decidir
 
 - **Dónde vive el toolchain.** Hoy `rust-toolchain-bin` está en `perfil.servidor` (799 M; un