Sergio
80319d9bab
Etapa 2 (ADR 0016): el binario canónico es `takana` y `hammer` se sigue emitiendo. Son DOS [[bin]] al mismo main.rs, no un symlink: la siembra de la granja excluye /target (un symlink del hub no existiría en el worker) y `cargo clean` lo borraría. Ningún llamador tocado; los 124 siguen andando. Adoptados los dos puntos de la hoja de marca que chocaban con contratos: - `forja` como ALIAS de clap sobre `build`, no como reemplazo. El canónico sigue siendo el inglés, que es lo que usan scripts, cron y runbooks. Y se enmienda la regla 4 de CLAUDE.md en el mismo commit: cambiar el comportamiento dejando escrito el contrato viejo es lo peor de las dos opciones, porque el otro agente del repo aplica lo que lee. - `.tkn` como extensión de paquete. Salió barato y por una razón medida: la extensión no es lógica sino salida — se escribe en UN solo lugar (main.rs:1800) y el descubrimiento va por índice, no por glob (PackageEntry.file, repo.rs:75). Los repos con entradas .swm siguen resolviendo y un repo mixto es válido; cero ficheros .swm versionados. Los tipos Swm/SwmBuild/swm_bridge no se tocan: son internos, van en la etapa 4. 287 tests en verde (hammer-cli + hammer-core), incluidos los que fabrican repos con nombres .swm a mano — que son justamente la prueba de que la compatibilidad hacia atrás se sostiene.
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/.