SergioandClaude Opus 5
26a0dd31c7
Al reescribir el §6.8 corté el texto entre «lo que NO está probado» y `## 7`, y entre medio no había sólo eso: vivían ahí §2.ter (el modo `[source] dir`), §2.quater (los tres fallos que destapó abrirlo en pantalla), §2.quinquies (los tres mecanismos de la v0.3) y §2.sexies (lo que quedó probado y con qué). Ciento veinte líneas de método pagado con horas. Recuperadas de HEAD~1 y comprobadas byte a byte con `diff` contra el original, no a ojo. La causa, que es la de siempre en este repo: usé un ANCLA («hasta el próximo `## 7`») dando por hecho que el documento estaba en el orden en que yo lo imaginaba. El §6.8 lo había insertado yo mismo antes del §2.ter hace unas horas, así que el ancla saltaba por encima de cuatro secciones. Un ancla es una etiqueta, no una propiedad del documento — la misma familia que la cabecera de hunk que nombra la función anterior. Lo que lo hizo visible en el mismo minuto fue mirar el `git show --stat`: 210 líneas cambiadas en un fichero donde yo había escrito 45. La regla 2 del CLAUDE.md manda mirarlo para el ALCANCE del commit, pero sirve igual para el tamaño del cambio. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UgNtJEFetMYbXax5dVUjZZ
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 |
| 26 | atuq: el envoltorio Gecko |
Navegador propio como artefacto DERIVADO de firefox (no fork de fuente); la toolchain clang como puerta de PGO/LTO; qué se promete y qué no |
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/.