sergioandClaude Opus 4.8
50960d3c38
Primer entregable de release engineering (SDD 13 nuevo): scripts/install-image.sh produce una imagen GPT que se BOOTEA SOLA en QEMU (`-drive file=img`, sin -kernel ni firmware extra) — SeaBIOS → MBR → GRUB → kernel del propio disco → arje-zero PID 1. Capaz de arrancar en hardware real. Layout: vda1=BIOS boot (ef02), vda2=/ (con /boot/bzImage + /boot/grub), vda3=/store, vda4=/var/lib/hammer. Reusa el particionado sin-root de B3 (sfdisk + mke2fs -d bajo unshare -r + dd conv=sparse) y el wrapper /sbin/init. GRUB instalado SIN root ni loop: grub-bios-setup sondea el disco físico del host (/dev/nvme…, 660 root:disk) para adivinar el root device del dir -d y falla sin privilegios. Lo reemplaza un patch binario determinista sobre la ABI estable de GRUB i386-pc: grub-mkimage arma core.img; un script Python escribe core.img en la BIOS boot partition y parchea los punteros (boot.img off 0x5c kernel_sector → LBA de core.img; core.img off 0x1F4 blocklist.start → resto de core.img), con asserts de los valores por defecto (1 y 2) para fallar ruidoso si la ABI cambia. boot.img va al MBR sin pisar la GPT protective (sólo 440 B). Verificado in-VM (KVM, sin -kernel): SeaBIOS → GRUB 2.14 → Linux 6.16.12 → vda1..4 detectadas, vda2 root + vda3/vda4 montadas por el wrapper (0 errores) → arje-zero PID 1 + hammerd (store=/store journal=/var/lib/hammer/journal). Co-Authored-By: Claude Opus 4.8 <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/.