sergioandClaude Opus 5
11a9ead671
El SDD 27 §2 dice que el repo mezcla tres capas —piso, escritorio, extras— en una sola
lista por escritorio, y que esa es la causa de que la composición no esté definida. El
firmware es un cuarto caso que el SDD no nombra y que sigue la misma lógica: no es un
escritorio ni un toolbox, es lo que hace falta para que un METAL CONCRETO arranque con todo
su hardware vivo.
Por eso va como perfil propio y se compone, en vez de duplicarse en los cuatro escritorios:
scripts/targets.py cli metal-tigerlake escritorio-kde
Otro metal = otro perfil de estos con su propia receta firmware-<plataforma> derivada del
mismo linux-firmware. Ese es el punto de haber partido el firmware en base + derivada.
La máquina, medida con lspci/cpuinfo sobre el metal real:
CPU i7-11370H · family 6 · model 140 (0x8c) · stepping 1 ⇒ intel-ucode/06-8c-01
GPU TigerLake-LP GT2 [Iris Xe] [8086:9a49] ⇒ i915 / xe
WiFi Intel Wi-Fi 6 AX201 [8086:a0f0] ⇒ iwlwifi
Audio 500 Series HD Audio [8086:a0c8] ⇒ snd_sof_pci_intel_tgl
Y zsh entra en `cli`, no en `base`: base define el shell del SISTEMA (bash) y esto es el
del usuario. Dos hechos distintos, como `paquetes` y `servicios` un piso más abajo.
El runbook deja el encargo para el worker, y su parte útil son los dos muros que aparecieron
al cruzar ficheros que nadie había leído juntos:
1. takana-live-install.sh:275 bifurca «UEFI ⇒ rama EFI-stub soberana», y metal-usb-sdboot.sh
dice que el EFI-stub «en el firmware del usuario se cuelga tras Measured initrd PCR 9».
ES EL MISMO FIRMWARE. El lazo de instalación EFI está validado en OVMF, que no tiene ese
quirk ⇒ el instalador va a pasar la prueba y colgarse en el metal de destino. La salida
es llevar el instalador a systemd-boot, que es el camino ya probado en esta máquina.
2. El instalador reparticiona en MBR el disco entero, y ese disco tiene /home con 893 G
usados. Si la instalación conserva /home o se lleva el disco con respaldo previo es
decisión del usuario, no del runbook — y hasta que se decida, no correrlo sobre el NVMe.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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/.