Files
takana/docs
SergioandClaude Opus 5 f611751f86 atuq: el diálogo de la bóveda no abre, y el muro no es de la bóveda — ninguna ventana llimphi pinta
`boveda` (b3:59ffd74b) y `shuma-pregunta` (b3:99763eca) sellaron en el worker. Ninguno de los dos abre
ventana, y el error no habla de contraseñas:

    panicked at llimphi-hal/src/lib.rs:1032: index out of bounds: the len is 0 but the index is 0

Esa línea es `caps.formats[0]`: la surface no tiene NI UN formato. La cadena, medida eslabón por
eslabón con RUST_LOG=wgpu_hal=debug:

    No (or unknown) windowing system ((None, Some(..))) present. Using surfaceless platform
    Trying native-render → No config found! · Trying presentation → No config found!

El `None` es `raw_display_handle`, y no es del arnés: es lo que llimphi hace A PROPÓSITO en su camino
de escritorio, con el comentario al lado («Sin display: este camino no tiene ventana todavía»). Sin
display handle wgpu abre el display EGL surfaceless, que no publica configs con WINDOW_BIT ⇒ la
surface no es presentable ⇒ cero formatos ⇒ panic.

No se nota en una máquina con Vulkan, porque ese camino elige Backends::PRIMARY y a Vulkan el display
no le hace falta. Y **ninguna imagen de takana tiene Vulkan**: las tres recetas de mesa se compilan
con `-Dvulkan-drivers=` vacío, y `vulkan-loader` sólo existe en incoming-kde sin que ningún perfil lo
declare (y un loader sin driver no es un driver). ⇒ toda app llimphi de escritorio cae al camino GL y
no puede abrir ventana. Reproducido en TRES binarios y dos versiones de wgpu: shuma-pregunta y boveda
(29) y llimphi-counter (27).

Los controles, porque la conclusión es fuerte: pedir Vulkan explícito da NoAdapter y no hay ICD ni
libvulkan en ninguna capa (la premisa está medida); con softpipe el fallo es OTRO y anterior —wgpu
pide compute shaders y softpipe se queda en GL 3.3—, así que llegar hasta acá ya exige llvmpipe; y el
compositor está levantado con su socket y su WAYLAND_DISPLAY.

Lo que esto dice del producto: el consentimiento de la bóveda no puede pedir permiso en ninguna imagen
de hoy, y como un lanzamiento fallido se traduce a «no» (Command::new falla ⇒ return false), el usuario
vería una bóveda que niega todo sin un solo error.

Se arregla en llimphi (que pase el display handle; la función `instancia_con` ya existe ahí al lado) o
con un driver Vulkan por software en el corpus. No se arregla en takana ni en el arnés.

Entra igual lo que sí se puede afirmar:
· `scripts/test-atuq-boveda-metal.py`, seis etapas declaradas, la A en VERDE — sin la app dueña el
  host contesta locked:true, que es la medición del §7.sexies ahora vigilada. Cada etapa dice qué
  afirma y la B nombra el muro en vez de dejar que se rediagnostique;
· `recipes/wtype.toml` — el corpus no tenía NINGUNA forma de meter una tecla en un compositor: todos
  los arneses de scripts/wlr miran, ninguno toca. Sellado y en ningún perfil: es instrumento.

⚠ Y una trampa del arnés, mía, que costó tres corridas: exportaba GALLIUM_DRIVER=softpipe, o sea que
yo mismo lo clavaba al driver débil. mesa-swrast y mesa-llvmpipe se ven como dos nombres de lo mismo
—«mesa por software»— y la diferencia decide si el arnés existe.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-18 10:48:06 +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