sergio/takana

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih

diff --git a/docs/25-tasas-del-kernel.md b/docs/25-tasas-del-kernel.md
index 18cf1c14..417632d6 100644
--- a/docs/25-tasas-del-kernel.md
+++ b/docs/25-tasas-del-kernel.md
@@ -328,6 +328,16 @@ Tres decisiones que valen la pena nombrar:
 3. **Distingue apagado de ausente** — un símbolo que el `.config` ni nombra puede ser un
    renombrado entre versiones. Cuenta igual como capacidad ausente, pero se informa aparte; y un
    kernel sin perfil declarado queda **SIN COMPROBAR** en vez de contar como aprobado.
+4. **Distingue vigente de superado** (agregado al pagar H1) — el store guarda **todos** los
+   sellados, no el último. Mirándolos a todos por igual, arreglar la receta dejaba el gate rojo
+   para siempre por artefactos que nadie va a volver a construir, y **un portón que no puede
+   ponerse verde deja de leerse**. Ahora cada sellado se compara con el `ArtifactHash` que la
+   receta de hoy produce —la misma vigencia de `hammer hash --check`, lab incluido—: el vigente
+   bloquea; el superado sale en su propia sección con lo que le falta, porque sigue siendo cierto
+   que una máquina que arranque ese kernel corre sus Cards con lo que ese kernel traiga. Y dos
+   negativas explícitas: si la vigencia no se puede resolver se comprueba **todo** y se dice por
+   qué, y **cero vigentes con superados a la vista sale ≠0**, no verde — el vacío leído como
+   presencia (CLAUDE.md §3) es justo el fallo que este guardián vino a arreglar.
 
 Estado medido hoy: **2 de 11 configs sellados cumplen su perfil** (los dos `linux`), los 9 de
 perfil `anfitrion-cards` fallan por `MEMCG`. El kernel vivo de esta máquina pasa las 11 exigidas.
diff --git a/docs/runbooks/armador-de-kernel.md b/docs/runbooks/armador-de-kernel.md
index 88c22ad1..2891a34d 100644
--- a/docs/runbooks/armador-de-kernel.md
+++ b/docs/runbooks/armador-de-kernel.md
@@ -191,9 +191,17 @@ construir, copiala a `recipes/incoming-kernel/` **temporalmente** (sus `deps.bui
 el catálogo padre) y sacala después. El artefacto sellado sobrevive; la receta se regenera con el
 comando de arriba.
 
-⚠ La copia guardada lleva `-j1` en la fase `compile`, no el `-j"$(nproc)"` que emite `plan`. Fue una
-concesión a la memoria de gioser — y **cambia el `ArtifactHash`** (ver SDD 22 §13). El artefacto
-`b3:8ffd5710…` corresponde a la variante `-j1`.
+⚠ La copia guardada **ya no lleva** el `-j1` de la primera vuelta: al pagar SDD 25 H1 (MEMCG+PSI)
+hubo que regenerarla contra la base nueva, y ese re-hasheo obligado fue el momento barato para
+soltar la concesión y volver al `-j"$(nproc)"` que emite `plan` — capar el paralelismo en la receta
+cambia el `ArtifactHash` aunque el binario sea idéntico (SDD 22 §13), y el throttling va por
+entorno. Historia de los hashes: `b3:8ffd5710…` era la variante `-j1` sin MEMCG; la vigente es
+`b3:b026fe14…`.
+
+⚠ **Regenerar la derivada NO alcanza para que el MEMCG de la base llegue acá**: la receta derivada
+**inlinea** la fase `configure` de su base. Cambiar `recipes/linux-metal.toml` y no regenerar deja
+la derivada con el configure viejo, y el gate lo ve (el sellado sale como vigente sin la
+capacidad).
 
 ## 5. Diff-back — después de construir