Sergio
30765ca376
Las otras tres recetas cgo (sq, usql, gitea) dan DERIVA, no no-determinismo: sus dos reconstrucciones coinciden entre sí y el artefacto guardado era el de antes del arreglo. Ya están al día. Y de paso se les fue una deuda que NO era de reproducibilidad sino de PORTABILIDAD: el `x_cgo_sigaction` de sq y usql —código C de cgo, sin guarda de CPU en runtime— venía con AVX2 horneado, de cuando el driver pisaba el `-mcpu=baseline`. Un binario así no falla al construir ni al sellar: falla al EJECUTAR en una CPU sin AVX2, con SIGILL. Ahora los tres salen baseline (cero ymm, cero zmm en esa función). ── El límite del libro, anotado en su encabezado ────────────────────────────────────── `gocryptfs` acabó con CUATRO filas al MISMO hash: dos NO-DETERMINISMO y dos reproduce, y las cuatro son ciertas. La clave (receta, hash) no puede distinguir antes y después de un arreglo del FRAMEWORK, porque la fase generada no entra en `hash_inputs` — a propósito, para no re-sellar 362 recetas cada vez que se toca un driver. Corolario, que es lo caro: tras tocar un driver, lo sellado NO se rehace solo. Hay que forzarlo receta por receta, y si nadie lo hace el store se queda con artefactos que ya nadie construiría así.
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/.