Files
takana/docs
Sergio 5fd8746445 atuq §7.terdecies: «no hay identidad» era también «no pude preguntar» — y en pacha-cli eso guardaba los dotfiles EN CLARO
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.
2026-09-21 21:41:43 +00:00
..

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 stage0stage1→initramfs→QEMU; criterios de éxito y troubleshooting

Architecture Decision Records (ADR)

Decisiones tomadas, con su contexto y consecuencias. Ver adr/.

# Decisión
0001 Rust para el tooling y daemons
0002 Validar sobre Alpine antes de la distro propia
0003 zig cc como compilador por defecto del lab
0004 No escribir nuestro propio Nix
0005 Hidratación por hardlinks
0006 Commits fijados, no HEAD vivo
0007 arje como init propio del track posterior
0008 Bootstrap en 3 stages, zig como semilla
0009 Código direccionado por contenido (estilo Unison)
0010 Arranque por grafo: el menú de boot como navegación del grafo
0011 Etapa Escritorio: campaña KDE Plasma 6
0012 El árbol de fuentes es caché y workspace a la vez — PENDIENTE, dilema abierto