sergioandClaude Opus 5
9273880745
Diagnóstico completo. No es daño de la campaña del split ni un fallo de store-gc. LO MEDIDO, en orden: 1. 86 nodos del perfil sin artefacto en su hash vigente. 2. NO lo causó el split: revertidas una por una todas las recetas tocadas hoy (3 bibliotecas base, 30 hojas, dbus, 38 de la 2ª tanda) el número NO se movió de 198 en ningún caso. 3. La FRONTERA son 7 recetas —las únicas cuyas deps sí están al día—: dbus, libnl, libpcap, libxkbcommon, lm-sensors, perl-xml-parser, vulkan-loader. Las otras 79 cuelgan de ellas. 4. Las 7 son SOMBRAS de incoming-kde, no las canónicas. Las del corpus están al día, y por eso el problema es INVISIBLE desde el grafo del corpus — que es justo el que yo miraba. 5. No fue store-gc: sus hashes vigentes no figuran en ningún manifiesto de borrado, y tres nunca se podaron. (Lo sospeché porque la regla de «superado» es por NOMBRE y una sombra comparte nombre con la canónica; la sospecha era razonable y los manifiestos la descartan.) 6. Ni el hub ni el worker los tienen. No están en otro sitio: NO ESTÁN. LA CAUSA DE FONDO, que importa más que KDE: la cola se construyó en workers EFÍMEROS, el sync del store es unidireccional (worker→hub) y esos workers ya no existen. Cuando algo del sustrato compartido cambió después, las sombras se re-hashearon y nadie las reconstruyó, porque el hub nunca fue la máquina donde vivía ese escritorio. ⇒ Con flota efímera y sync unidireccional, un escritorio puede dejar de ser reconstruible-desde-el-store SIN QUE NINGÚN INDICADOR LO DIGA. El grafo seguía reportando 162/162 desde un JSON generado semanas antes. Coste de arreglarlo: 86 reconstrucciones en la granja, empezando por las 7 de la frontera. No hay muro técnico conocido — son recetas que ya construyeron. Es cómputo, no investigación. Co-Authored-By: Claude Opus 5 (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 |
| 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/.