sergioandClaude Opus 5
deee75eca5
§II.1 decía «medido: no hay ninguno — de toda la familia sólo existen foot y mako». Ya no: 10 recetas selladas, 12 binarios, el perfil escritorio-sway cerrando 121/121 y ARRANCANDO en QEMU con evidencia. La hipótesis que traía la sección —«son baratos, no hay torre de C debajo»— se cumplió: KDE y GNOME fueron campañas de semanas, esto salió en una noche. Y se añade la lección que corrige cómo hay que leer TODO el documento: el grafo prueba que una imagen SE ARMA, no que ARRANQUE. Entre 121/121 y una pantalla con algo dibujado hubo SEIS muros y ocho ciclos de imagen —PATH vacío, libz.so.1 ausente del rootfs, un backend de libseat que nuestra receta no construye, /run de sólo lectura, los datos XKB, y la falta de tipografías— y ninguno era una dependencia de build, así que ninguno podía salir en el grafo. Con el método incluido, porque es lo que más se olvida: el veredicto es CONTAR COLORES del PPM, no leer el log. Hubo un arranque con todo verde (salida activada, modo correcto, «Commit of 1 outputs succeeded», workspace creado) y la captura 100% negra. ⇒ Corolario escrito en una sección nueva: cuando este documento diga que algo «cierra», hay que leerlo como «se puede intentar», no como «funciona». Los tres escritorios que aún no se validaron con pantalla deben esa misma distancia, y no conviene prometer fechas contra el número del grafo. waybar queda anotado como fuera-por-medición (gtkmm-3.0 = GTK3 + bindings C++ + 8 recetas), con yambar en su lugar. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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/.