Sergio
de660fc10f
Segundo hueco de RUNTIME del triaje de la frontera. Nadie lo pide para construir —por eso el escritorio sellaba completo sin él— pero sin este módulo los controles QML de Plasma (botones, sliders, combos, los menús de los applets y de los KCM) se dibujan con el estilo genérico de Qt. No lo reemplaza qqc2-desktop-style: aquél es el estilo de escritorio integrado con KStyle; éste es la implementación QML nativa de Breeze, la que Plasma 6 usa por defecto. Dos cosas que no eran obvias: 1. Se llama casi igual que el vecino y viene de otro tarball. qqc2-DESKTOP-style sale de Frameworks 6.27.0; qqc2-BREEZE-style sale del release de Plasma 6.7.2, el mismo de breeze/kwin/plasma-workspace. Copiar la URL del vecino da 404. El sha256 va contrastado contra el .sha256 que publica KDE al lado del tarball, no sólo contra lo que bajó acá: la primera descarga volvió con 0 bytes y su sha256 era el de la cadena vacía — un vacío que se lee como éxito. 2. La lista de deps no es la del vecino copiada: sale de la clausura de find_dependency de los KF6*Config.cmake que ya están en el store. Ese recorrido enseñó algo reutilizable: casi todo lo que esos configs piden (X11, XCB, Wayland, OpenSSL, BZip2, LibLZMA) vive dentro de un `if (NOT TRUE)` — la rama de build ESTÁTICO — y por lo tanto es código muerto en nuestro corpus, que compila KF6 dinámico. Por eso acá no hay libX11 ni xorgproto, coherente con Wayland-only. El find_package(X11) del CMakeLists raíz no es REQUIRED, así que falla en silencio sin romper el feature_summary(FATAL_ON_MISSING_REQUIRED). Confirmado a posteriori: los NEEDED del plugin son exactamente los 5 KF6 que la clausura predijo (KirigamiPlatform, IconThemes, ColorScheme, GuiAddons, ConfigCore) más Qt6 Quick/Gui/DBus/Core. La fase install verifica por CONTENIDO, no por presencia: qmldir de org.kde.breeze y de org.kde.breeze.impl no vacíos, Button.qml presente y el plugin de plataforma de kirigami instalado. Un módulo QML sin su qmldir ocupa disco y arranca con el estilo genérico sin decir nada. Salieron 83 controles y 3 .so. Selló al primer intento y REPRODUCE bit a bit (verificar-repro.sh 1/1). corpus 788/788 · escritorio-kde 166/166 · grafo CIERRA · gate --check OK Quedan 2 wanted en KDE: xwayland y polkit-qt-1. Nota sobre el diff de los cinco grafos: cambian los `dependientes_total` de las deps de esta receta en TODAS las vistas, no sólo en --kde. Es correcto y está documentado en build-state.py: ese campo se calcula sobre el grafo entero (todas las colas del disco), que es la corrección del bug de libdrm.
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/.