Contesta el segundo pendiente del §7.duodecies: `pacha`/`pacha-secretos` en `perfil.servidor`. La respuesta a la pregunta de origen es **NO**, y es la CONTRARIA a la del escritorio. Premisa medida, no supuesta: la Card de `pacha-secretos` es `scope=system` y entra al `genesis`, o sea que arje arranca el daemon EN EL ARRANQUE. De ahí se sigue que un sembrador en la imagen no llega a tiempo por construcción — en el arranque no hay nadie logueado; `abrir_almacen()` decide una vez en `main()` y no vuelve a mirar; y `agora-cli unlock` de una sesión ssh siembra en el llavero de ESA sesión. Declararlo dejaría la función PARECIENDO cerrada, que es peor que el hueco. Queda escrito al lado de las dos raíces, en `targets.toml`, para que nadie copie la decisión del escritorio. Y al ir a medirlo, el control POSITIVO salió rojo — con la seed en `/proc/keys` el daemon decía que no había identidad — y eso destapó el defecto de verdad: los CINCO lectores de la seed hacían `.ok().flatten()` (o un `_ =>`), que convierte «el llavero no se pudo consultar» en «no hay identidad desbloqueada». La causa del rojo la mide la sonda de syscalls: en el LXC `add_key` funciona y `keyctl(KEYCTL_SEARCH)` da `ENOSYS` ⇒ se puede sembrar y no cosechar. El peor de los cinco no era un mensaje feo: `pacha-cli` guardaba los dotfiles SIN CIFRAR, en silencio, con la identidad del usuario desbloqueada. Arreglado en tawasuyu (`4f2b5eac7`) con `pacha_llavero::SeedDeSesion` —tres estados, tres textos— y `Reason` en `net.tawasuyu.Secretos1`. Pin de las dos recetas `23a292863` → `cd9acd0d9` ⇒ `b3:e8038352` (4,6 M) y `b3:a9fb8c17` (8,5 M), mirados por dentro y probados como artefacto: el daemon sellado ahora dice «motivo=el llavero de sesión NO se pudo consultar (… os error 38) — esto no es «no hay identidad»». Tres cosas más que quedaron medidas por el camino: - la guarda pegada al build **se disparó sola por primera vez**: el latido revirtió `pacha.toml` entre las dos construcciones de la misma tanda; - el muro del `Cargo.lock`, quinta vez, y la arista que faltaba era la mía de esa mañana: se la llevó un «merge de git en «main» (import)». Bisecado con `git log -S`; - el índice Y el árbol compartidos de tawasuyu tenían una versión de `pacha-boveda-llimphi` ANTERIOR al arreglo de `7917fbb96`. Lo delató el test de regresión, no el diff.
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/.