sergio/takana

`rust` en la cola del worker llegó MUCHO más lejos: compiló las 386 crates del stage1 y murió al
empezar `Building stage1 library artifacts (stage1 -> stage1)`:

    error: error loading target specification: could not find specification for target
           "x86_64-alpine-linux-musl"

Es la OTRA MITAD del muro 4 y sólo se ve en el stage 2: usar el triple de Alpine funciona mientras
el compilador que manda es el del LAB —Alpine le PARCHEA esa especificación a su rustc— y deja de
funcionar en cuanto toma el relevo el rustc recién construido, que es upstream puro y no la conoce.
El triple que hace falta para ARRANCAR el build es el que el PRODUCTO del build no tiene.

Tres salidas, con la elegida: parchear `rustc_target` para registrar el triple (lo que hace Alpine;
queda DENTRO del compilador y vale en todos los stages). El `RUST_TARGET_PATH` + JSON es más barato
pero un target por JSON como HOST es terreno que rustc no soporta bien. Y volver al canónico no
tiene candidato a stage0: el prebuilt oficial trae esa std pero no puede compilar proc-macros.

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

diff --git a/docs/31-compilador-de-rust.md b/docs/31-compilador-de-rust.md
index f66e68b6..9a33a110 100644
--- a/docs/31-compilador-de-rust.md
+++ b/docs/31-compilador-de-rust.md
@@ -73,6 +73,36 @@ el binario corre. Una distro sin compilador de C puede compilar Rust igual.
    cmake, y con el wrapper de zig la prueba de ABI falla. `CC=gcc CXX=g++`, igual que en `llvm21`
    y `cmake`.
 
+## 4.bis El SEXTO muro, que la granja encontró sola *(2026-09-15)*
+
+`rust` entró a la cola del worker y llegó **mucho más lejos**: compiló las **386 crates del stage1** y
+murió justo al empezar `Building stage1 library artifacts (stage1 -> stage1)`:
+
+    error: error loading target specification: could not find specification for target
+           "x86_64-alpine-linux-musl"
+      = help: did you mean `x86_64-unknown-linux-musl`?
+
+**Es la otra mitad del muro 4, y sólo se ve en el stage 2.** Usar el triple de Alpine funciona
+mientras el compilador que manda es el del LAB —Alpine le PARCHEA esa especificación a su rustc— y
+deja de funcionar en el instante en que toma el relevo **el rustc que acabamos de construir**, que es
+upstream puro y no la conoce. O sea: el triple que hace falta para arrancar el build es el que el
+producto del build no tiene.
+
+Las salidas, por orden de honestidad:
+
+1. **Parchear `rustc_target` para registrar `x86_64-alpine-linux-musl`**, que es literalmente lo que
+   hace Alpine en su APKBUILD. Un fichero de spec copiado de `x86_64_unknown_linux_musl.rs` y una
+   línea en `supported_targets!`. El triple queda DENTRO del compilador, así que vale en todos los
+   stages.
+2. `RUST_TARGET_PATH` + un `.json` generado por el propio stage0
+   (`--print target-spec-json`) — más barato, pero un target por JSON como **host** es terreno que
+   rustc no soporta bien: la std del host se construye con el spec built-in.
+3. Volver al triple canónico y resolver el «can't find crate for std» del stage0 por otro lado. Hoy
+   no hay candidato: el prebuilt oficial trae esa std pero **no puede compilar proc-macros** (muro 2),
+   así que no sirve de stage0 para el bootstrap.
+
+⇒ La 1 es la que Alpine ya demostró que funciona, y es la que sigue.
+
 ## 5. Lo que falta decidir
 
 - **Dónde vive el toolchain.** Hoy `rust-toolchain-bin` está en `perfil.servidor` (799 M; un