SergioandClaude Opus 5
3c628deeb6
purpose 6.27.0 — el marco de «compartir» de KDE. 23 plugins (código de barras, bluetooth, portapapeles, correo, imgur…) más sharefileitemaction.so, que añade «Compartir» al menú de Dolphin. Era el último hueco. La receta de okular lo degradaba con el flag oficial FORCE_NOT_REQUIRED_DEPENDENCIES y su cabecera decía «los que no tenemos sellados» — un ESTADO, no una preferencia. Ahora sale de esa lista. ⚠ Y va ENGANCHADO, no sólo autorado: una receta que nadie alcanza no arregla nada. okular sale de la lista de degradados; gwenview y spectacle lo declaran (ninguna lo mencionaba: construían sin él y el CMake se lo saltaba en silencio). Coste medido antes de tocar: las tres son hojas con 0 dependientes transitivos ⇒ 3 builds, sin cascada. La prueba es el enlace, no la intención: las tres referencian libKF6Purpose (2 cada una). Un tropiezo con su lección: el CMake abortó pidiendo tres MÓDULOS QML —org.kde.prison, org.kde.kitemmodels, org.kde.kcmutils— que no salen de ningún find_package. Los pide con ecm_find_qmlmodule, o sea que comprueba que el IMPORT exista, no que la librería esté enlazada. Las tres recetas ya existían y publicaban su qmldir; sólo faltaba pedirlas. Un requisito que no se ve leyendo los find_package. KAccounts6 NO se pide: su find_package va sin REQUIRED y arrastraría toda la torre de kaccounts/signond que esta distro no tiene. Verificado: REPRODUCE bit a bit · tarball en el mirror · escritorio-kde 304/304 sellado, deuda 0. FRONTERA: 0 HUECOS. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
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 |
| 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/.