SergioandClaude Opus 5
56e59b821a
Era el ultimo hueco medible de SDD 25 en esta maquina: H7 tenia el precio en cuatro partes pero no el numero en bytes, que es como se pago H1. Se construyo una copia derivada de linux-generic con UNA sola diferencia en el .config (DEBUG_INFO_DWARF5 + DEBUG_INFO_BTF) y todo lo demas byte a byte igual: bzImage sin BTF : 16 937 984 B bzImage con BTF : 19 473 408 B (+2 535 424 B = +2,42 MiB = +14,97%) seccion .BTF : 7 888 166 B sin comprimir, entran comprimidos 3,11x Contra la unica vara comparable: H1 (MEMCG+PSI) costo +80 KiB / +0,49% del mismo bzImage => BTF cuesta 31 veces eso. No lo decide, pero lo saca de "un re-hasheo y ya". Sobre linux-generic y no sobre linux, que es mas barato: BTF tiene depends on BPF_SYSCALL y el .config sellado de linux lo trae APAGADO, asi que medir ahi habria mezclado dos precios. TRES cosas que salieron construyendo y no leyendo: 1. Una QUINTA parte del precio que nadie habia nombrado: hace falta python3. BTF hace que kbuild descienda a tools/bpf/resolve_btfids, que compila un libbpf vendorizado cuyo Makefile genera bpf_helper_defs.h con un script de Python (Error 127). 2. El numero de Artix fallaba en la direccion CONTRARIA a la esperable. El doc decia que sus 6,4 MB "no dicen nada de uno monolitico y pelado"; el nuestro sale MAS GRANDE, 7,5 MiB. Artix es modular y su .BTF cubre solo el core built-in; el nuestro es monolitico y los tipos de i915+nouveau+radeon+iwlwifi entran todos. 3. Una trampa de kconfig que es CLAUDE.md §3 dentro de make: scripts/pahole-version.sh imprime 0 si pahole no esta en el PATH, el depends on PAHOLE_VERSION >= 122 deja de cumplirse, y olddefconfig BORRA la linea en silencio. El build sale OK y sella un kernel SIN BTF diciendo que todo fue bien. Por eso la receta comprueba el .config PRODUCIDO y sale 1 si no esta. Salio OK, lo que ademas paga la parte (3) del precio: el pahole estatico de ayer se encuentra y se ejecuta DENTRO del sandbox. El artefacto de medicion se borro a proposito: `hammer kernel contract --sealed` lo listaba como SIN COMPROBAR (no declara [[target]], que es lo que exige H8), o sea un aviso permanente en un fichero que el cron commitea cada 30 min. Un aviso fijo que no corresponde a ningun problema es como se deja de leer un vigia. La receta derivada queda en la evidencia. Nada del corpus se re-hasheo: la derivada vive fuera de recipes/ y el catalogo se le presta por symlinks. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
Documentación de diseño de hammer
Estos documentos son la fuente de verdad del diseño. El código los implementa; cuando haya discrepancia, o se corrige el código o se actualiza el SDD con un commit que explique por qué.
Software Design Documents (SDD)
| # | Documento | Qué cubre |
|---|---|---|
| 00 | Visión y filosofía | Por qué existe, qué problema resuelve, la actitud de ingeniería |
| 01 | Arquitectura general | El modelo de dos mundos, componentes, flujo de datos |
| 02 | El laboratorio de build | Sandbox, zig cc, recetas, CAS, grafo de dependencias |
| 03 | Hidratación y store | Store content-addressed, hardlinks a FHS, patchelf, rollback |
| 04 | Overlay de experimentación | overlayfs en caliente, try/commit/discard |
| 05 | Diario de mutaciones | fanotify, log append-only, config-sin-ser-declarativa |
| 06 | Formato .swm |
Manifiesto de mutación compartible, esquema, firma |
| 07 | Bus de init y de agente | /run/init.control, /run/agent.sock, protocolo |
| 08 | Integración de la IA | El bucle agéntico, seguridad, intención → .swm |
| 09 | Modelo de confianza | Reproducibilidad, verificar-no-confiar, log de transparencia |
| 10 | Roadmap | Fases, MVP, primer entregable |
| 11 | Bootstrap from-scratch | Track posterior: Stage 0/1/2, auto-alojamiento, semilla pinned |
| 12 | arje como init real del Stage 1 |
Contrato de runtime: seed card, hammerd supervisado, CRASHED real |
| 16 | harkaq: la jaula de hammer | Landlock+seccomp sobre el bwrap actual; política = clausura; evidencia negativa de hermeticidad |
Runbooks (operativos)
| Runbook | Para qué |
|---|---|
| Validar Stage 1 booteando en QEMU | stage0→stage1→initramfs→QEMU; criterios de éxito y troubleshooting |
Architecture Decision Records (ADR)
Decisiones tomadas, con su contexto y consecuencias. Ver adr/.