Sergio
223dc47c64
Al ir por la segunda app del montón A salió que la premisa del ADR —«no lo bloquea nada
estructural, falta escribirlas»— vale para mpv y no para el resto. Medido contra el catálogo real
(1079 recetas) cruzando los makedepends del APKBUILD de Alpine de cada candidata:
· firefox → pide gtk+3.0-dev. Firefox NO tiene backend GTK4. Más X11 y un toolchain wasi que
no existe acá. La memoria decía «le falta subir el techo MSRV»: eso es cierto y es
LO MENOR. ⇒ NO es montón A.
· obs → pide qt6-qtbase/qtsvg, y Qt6 vive SÓLO en incoming-kde. Una receta del corpus no
alcanza una cola hermana ⇒ OBS hoy sólo puede ser una app DE KDE, no de las cuatro
imágenes. Más X11 y 20 recetas.
· chromium, libreoffice, gimp → peores, y los tres con GTK3 encima.
La consecuencia estratégica, que es lo que hay que decidir despierto: TODOS los navegadores Linux
son GTK3 (Firefox y derivados) o Chromium (que arrastra GTK3 y Qt6). «Tener navegador» no es un
ticket de recetas: es elegir entre autorar GTK3 o darle el navegador a qorpa (ADR 0015). La segunda
es coherente con lo ya decidido, y el navegador es justamente el proceso al que menos ganas dan de
darle el sistema entero.
Lo que SÍ está a mano, y es el hallazgo útil: `wf-recorder` sale con CERO recetas faltantes y cero
muros —su cierre quedó completo cuando entró mpv— y cubre el caso de uso principal por el que uno
instala OBS. Después `imv` (7 faltantes, todos cargadores de formato opcionales).
El método incluye su propio control: mpv, que YA ESTÁ SELLADA, aparece con 16 faltantes, que son
exactamente las perillas que su receta apaga a propósito. La columna que decide no es «cuántas
faltan» sino «cuántos MUROS», porque un muro no se paga escribiendo una receta sino cambiando una
decisión.
Documentación de diseño de hammer
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 hammer | Landlock+seccomp sobre el bwrap actual; política = clausura; evidencia negativa de hermeticidad |
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/.