gioser

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1389Shell 137Markdown 80Rust 802602 Definiciones

runbook: el contrato de capacidades, al lado del diff-back

`diff-back` contesta «¿el .config honra el PLAN?»; el contrato contesta la otra
mitad, «¿el kernel trae lo que el userland usa por nombre?». Son distintas: un
kernel puede honrar su plan al pie de la letra y no tener MEMCG, que nunca
estuvo en ningún plan porque nadie lo pidió.

Queda dicho también que hoy sale ROJO a propósito (2 de 11) y por qué.

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

72159adb32571c6835d5c80021d56a752c6210e8 · por Sergio · (hace 1 mes) · padre bfa3c6445 · ver el árbol en este commit

Delta semántico

Ninguna definición cambió: el cambio es de texto, documentación o datos.

1 archivos · +30 −0

diff --git a/docs/runbooks/armador-de-kernel.md b/docs/runbooks/armador-de-kernel.md
index 76221f12..88c22ad1 100644
--- a/docs/runbooks/armador-de-kernel.md
+++ b/docs/runbooks/armador-de-kernel.md
@@ -208,6 +208,36 @@ Clasifica cada símbolo pedido en cumplido / **incumplido** (el `.config` dice o
 (el kernel ni lo menciona: la bandera fue un no-op), con la procedencia de quién lo pidió. Sale
 distinto de cero si el config no honra el plan.
 
+## 6. El contrato de capacidades — antes de dar un kernel por bueno
+
+`diff-back` contesta «¿el `.config` honra el PLAN?». Falta la otra mitad: **«¿el kernel trae lo que
+el userland usa por nombre?»**. Son preguntas distintas — un kernel puede honrar su plan al pie de
+la letra y no tener `CONFIG_MEMCG`, que nunca estuvo en ningún plan porque nadie lo pidió (SDD 25
+§4: por eso `memory.max` no existe y arje escribe al vacío dejando sólo un `warn!`).
+
+```sh
+hammer --store ./store kernel contract --sealed          # todos los kernels sellados del store
+hammer kernel contract --config <art>/boot/config-7.1.2  # uno suelto (el perfil sale del nombre)
+hammer kernel contract --profile anfitrion-cards         # el kernel VIVO de esta máquina
+hammer kernel contract --list                            # qué promete hammer, y quién lo consume
+```
+
+Sale distinto de cero si falta una capacidad **exigida por el perfil**. Tres cosas que conviene
+saber antes de leer su salida:
+
+- **Corre por perfil.** `docs/state/kernel-contract.toml` mapea artefacto → perfil. `linux` es
+  `qemu-serial` (no hospeda Cards, y su hash es el baseline del selfhost-verify); los demás son
+  `anfitrion-cards`. Un artefacto **sin fila** sale **SIN COMPROBAR**, que no es lo mismo que
+  aprobado.
+- **Se mira contra el `.config` producido**, nunca contra la receta: entre el `scripts/config -e X`
+  y el `.config` está `olddefconfig`.
+- **Hoy sale rojo a propósito**: 2 de 11 configs sellados cumplen. Es H1 de SDD 25 sin pagar
+  (`-e MEMCG -e PSI` re-hashea los kernels ⇒ va en tanda). Cuando se pague, este comando es la
+  prueba.
+
+**Una capacidad nueva entra al contrato con consumidor —ruta y símbolo— o no entra.** «Estaría
+bueno tenerlo» pertenece a un bundle del catálogo, no acá.
+
 ---
 
 ## Lo que todavía NO está