SergioandClaude Opus 5
3d0fa1c7cb
El usuario preguntó si va a poder ejecutar kate desde mirada o si kate «está para KDE y no se hereda». La pregunta separa dos cosas que hoy comparten un solo mecanismo: qué CONTIENE un metapaquete (lo que resolvió el §7.1) y qué PUEDE CORRER en un sistema. MEDIDO sobre la clausura de kate: son 110 recetas, y lo único que suena a Plasma —kwindowsystem, plasma-activities, plasma-wayland-protocols— son LIBRERÍAS. No aparece plasmashell, ni kwin, ni plasma-workspace. O sea que kate necesita Qt6 + KF6 + un compositor, y mirada TIENE compositor: que hoy no corra ahí no es técnico, es que no está instalado. Coste medido: mirada son 41 nodos, kate 110, ya coinciden 24 ⇒ faltan 86, que es traerse Qt6 y KF6. Ese precio no lo cobra KDE, lo cobra Qt. Y la distinción YA EXISTE en el repo sin estar nombrada: mpv, atuq, swayimg y libnotify están declaradas en los CUATRO escritorios —repetidas, no heredadas—, zathura en tres, foot en dos. El repo ya trata las apps distinto de kwin, sólo que copiando la línea en cada perfil. Propuesta escrita: que el metapaquete del escritorio sea el ESCRITORIO (shell, compositor, tema, ajustes) y que las apps salgan a metapaquetes propios instalables desde cualquier sistema, de modo que `takana install kate` funcione desde mirada sin instalar Plasma. Se lleva bien con el §8: con vistas montables, «tengo KDE y GNOME y elijo en el greeter» y «uso kate dentro de GNOME» dejan de ser dos problemas y pasan a ser uno solo — qué clausura se compone para esta sesión. Cuesta mover ~20 declaraciones de targets.toml y no toca ninguna receta ni ningún artefacto: es reclasificar, no reconstruir. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
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 |
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/.