SergioandClaude Opus 4.8
4fe452848f
El rebuild in-rootfs de Stage 2 cazó un no-determinismo real: stage1 reconstruido en la VM divergía del host (of_tree host=b3:94a4f1… vs VM=b3:ab615b…), aun con el seal hash idéntico (el seal es of_inputs: mismo key ≠ mismos bytes). Diagnóstico (control en el host, sin VM): un rebuild de hammerd en el host es byte-idéntico al cacheado, así que la receta es determinista host-a-host y el cache no está stale. La divergencia es del entorno de build de la VM: `zig cc` default a `-mcpu=native` y hornea la ISA del builder en el C/asm de los build-scripts (blake3, curve25519-dalek). El host tiene SHA-NI+AVX2; `-cpu Broadwell` (VM bajo TCG) no tiene SHA-NI ⇒ codegen distinto ⇒ bytes distintos ⇒ of_tree distinto. Misma raíz que el SIGILL de AVX del runbook §7 (binarios al CPU del builder, no a un baseline genérico). Fix: `-mcpu=baseline` en TODOS los sitios zig cc — CC/CXX del sandbox, los dos wrappers Cargo (.hammer-zig-cc) y CC/HOSTCC de la receta de busybox. Las rutas SIMD del runtime (blake3/sha2) son asm con dispatch en runtime: siguen presentes. Bonus: cierra el AVX/SIGILL del §7 (corre en qemu64 sin -cpu Broadwell). Validado en el host: con baseline hammerd cambia de bytes (1672448 vs 1677584 — confirma que el default no era baseline) y los 3 componentes rebuildan limpio (stage1 rc=0). Nueva referencia CPU-independiente of_tree(stage1-baseline)= b3:4408e44e2ec51c3769deffcd64dd1f6c2010d414418937c3fa7930a0ded3f845. Runbook §8c documenta el cruce del muro Rust-offline (cargo vendor por la NIC, hammerd sellado in-VM en 74m35s) y este diagnóstico+fix. Nota (plan C.2): el flag de CPU no entra en of_inputs ⇒ cambio de toolchain/flags da cache-hit con bytes viejos; cerrar ese "pin de toolchain al hash" es trabajo aparte. Co-Authored-By: Claude Opus 4.8 (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 |
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/.