Sergio
d078e5285f
Los tests no eran el punto: el punto era que un servicio DECLARADO en una receta termine supervisado por PID 1. `product-boot-test.sh` sobre el product-rootfs de la ruta real da `ok card sshd en la seed` y `PRODUCT_SSH_OK uid=0`, sin ningún eslabón escrito a mano: recipes/openssh.toml [[service]] → sidecar dentro del artefacto sellado → service_cards() → genesis de /ente/seed.card.json → arje-zero encarna sshd → la sesión SSH responde. Y HABÍA QUE DESCARTAR QUE LO MOVIERA ESTE CAMBIO: el product-rootfs salió con hash distinto (5011955a… → 8639894332…). No fue la seed — las dos son BYTE-IDÉNTICAS (diff del JSON, cero diferencias). Cambiaron `netup`, que es otro artefacto que cuando se selló el viejo, y por arrastre `ente/attest.json`, que registra su BLAKE3. O sea: la constante y la receta producen la misma seed, comprobado sobre el árbol real y no sólo en un test. Y queda escrito por qué el ESCRITORIO no se puede arrancar supervisado todavía, que es corpus y no diseño: gnome-shell en deuda (bloqueado sólo por evolution-data-server, que tiene blocked_by vacío) y sway sin sellar. Sin compositor no hay sesión. NO se cablearon los scripts de imagen a ciegas: inyectar cards en un genesis que no se puede bootear es escribir código que nadie puede contradecir, y este mismo doc ya tiene el ejemplo de qué pasa entonces (el SDD 06 afirmando meses un lector que no existía).
Documentación de diseño de takana
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 takana | 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 |
| 30 | Los servicios que trae un paquete | [[service]] en la receta → Card de arje; por qué arje-absorb no cubre una distro construida desde fuente; los tres árboles de servicios y cuál es el canónico |
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/.