SergioandClaude Opus 5
d8778e4dd9
Faltaba decir en el ADR lo que se confunde solo: "pinear" no significa que la imagen no se actualice. El digest es la IDENTIDAD, igual que en el rootfs del lab. Lo que se pinea es el suelo; lo que instalás adentro con dnf/pacman ni está pineado ni puede estarlo, y se actualiza normal. Subir la base de versión es barato PRECISAMENTE por D3: manifiesto = verdad, upper = caché ⇒ cambiar el digest y recrear. Y el riesgo del pin (que upstream borre el tarball) ya lo resolvió ADR 0013: la URL no entra en la identidad, sólo el sha256, así que espejar es gratis. Curaduría decidida con el usuario — TRES, cada una por un trabajo distinto: - Arch bootstrap (juegos: multilib 32-bit y SteamOS es Arch ⇒ extiende D6), - Ubuntu base LTS (binarios comerciales: es contra lo que se compilan), - Steam Runtime sniper (la única SELLABLE: inmutable ⇒ file_drop al store). Fedora queda BYO: hace el mismo trabajo que Arch en el slot "fresco" y una tercera cadena mutable es la normalización que §NO-resuelve 3 quiere evitar. Los pines de las dos primeras están VERIFICADOS contra upstream hoy (Arch 2026.09.01 sha 895661bd…, Ubuntu 24.04.3 sha 6bc2cde3…); el de sniper NO, y se dice que no en vez de suponerlo. Y queda anotado que hacerlas compartibles más adelante no pide diseño nuevo: una imagen pineada es cuerpo inmutable direccionado por contenido ⇒ ADR 0014 se le aplica tal cual. Lo único que hay que mirar antes de publicarlas a terceros es licencia y marca, que no es una pregunta técnica. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U5cQtQrYNjWJVXVE6aEpQ2
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/.