Sergio
a66346fb05
`takana install zsh --repo https://repo.gioser.net --trust ./trust --require-signed` ⇒ `release: trusted (by release)`, 1331 ficheros en 0,286 s, zsh 5.9 corriendo. 173 paquetes anclados, 0 sin ancla, certificado CN=repo.gioser.net de Let's Encrypt. Tres cosas que sólo se supieron al poder entrar como root, y que el guion ahora sabe: · `caddy reload` NO funciona acá: el Caddyfile lleva `admin off` y el reload habla por ese admin (de ahí que el :2019 estuviera siempre cerrado). La recarga real es `arjectl restart caddy` — caddy es un Ente de arje con Restart{1000,30000}, no un proceso suelto. · Un restart levanta los 19 dominios o ninguno, así que el guion saca un TESTIGO de la config previa (acá gitea.gioser.net), espera a que responda, y si no vuelve restaura y revierte. Comprobado después: los 8 dominios vivos siguen en pie. · El certificado tarda más que la comprobación: el guion dio «todavía no responde» y la misma URL daba 200 segundos después. El mensaje ahora manda reintentar antes de ir a leer logs. Y dos fallos míos, medidos: backticks dentro de comillas y de un heredoc sin entrecomillar se EJECUTAN (salió un `journalctl: not found` en mitad de un mensaje de ayuda), y `[ -n "$X" ] && echo` como última orden mata el guion entero bajo `set -e`. El espejo provisional sin firmar de takana.gioser.net/repo se borró: con el firmado en pie, un origen sin firma no es un origen.
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/.