SergioandClaude Opus 5
e2bcd96feb
Entró como 4.7 —la última sin Lua— sólo porque no había receta de luajit. Con luajit sellada, sube a la actual. Lo que se gana: el motor de configuración pasó a ser Lua (src/luaengine.cpp), y con él los perfiles de teclas y el .lua de ejemplo. Formatos: suma qoi, ttf y xbm a los de 4.7. Dos cambios de forma que sacan dos deps: `compositor` ya no pide json-c (la integración con sway se rehizo sin JSON) y la man page viene PRE-GENERADA en extra/swayimg.1 en vez de armarse con scdoc. -Ddoc=false porque ese target regenera markdown con dos scripts de Python y lo que instala son .md, no páginas de manual. Corregido de paso el comentario de las opciones apagadas: son DOS por cola, no una. `svg` pide librsvg-2.0 (sólo en incoming-gnome) y `exif` pide exiv2 (sólo en incoming-kde). Las dos existen en el disco y ninguna es alcanzable desde el corpus. Por eso este visor no muestra metadatos EXIF, y queda escrito dónde está el hueco. Evidencia de que la cadena cierra, no sólo de que sella: `swayimg -e` ejecuta Lua dentro del visor y reporta «Lua 5.1 · jit=true · LuaJIT 2.1.1787165859» — que es exactamente el relver de nuestra receta de luajit, o sea que el intérprete que corre es el que construimos. Un script con error de sintaxis se reporta como error de Lua. NEEDED sigue siendo sólo libc.so. Los cinco grafos quedan en N/N con cero deuda. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XB2iEmxeLZgzqNfhWChrLo
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/.