SergioandClaude Opus 5
66abf69ebf
De 186 pendientes a 178. Cada veredicto con la prueba en la receta:
libxdamage opcional gtk3/gtk4/mutter con el backend X11 apagado
libsysprof-capture opcional gjs profiler=disabled, mutter profiler=false
protobuf opcional opencv -DWITH_PROTOBUF=OFF (módulo DNN)
fftw-single opcional pulseaudio fftw=disabled (ecualizador)
⚠ DOS OPCIONALES CON COSTE, que no es lo mismo que gratis:
libopus pipewire opus=disabled ⇒ el servidor de audio no codifica Opus. NO afecta a
reproducirlo en el navegador (atuq trae su propio códec, medido en su día).
bluez pipewire Y pulseaudio con -Dbluez5=disabled ⇒ LA DISTRO NO TIENE AUDIO POR
BLUETOOTH. No es un olvido de esta frontera: viene de cómo se construyeron esas dos
recetas. Habilitarlo exige traer bluez y RE-HASHEAR las dos, que no es gratis.
Queda escrito para que sea una decisión explícita y no un descubrimiento.
⚠ DOS HUECOS REALES:
desktop-file-utils provee update-desktop-database, que construye la caché MIME→APLICACIÓN.
Comprobado que NINGÚN artefacto del store lo trae. Con shared-mime-info ya
dentro, el escritorio sabe qué TIPO es un fichero y sigue sin saber CON QUÉ
abrirlo: el «abrir con» no funciona. Compañero natural del hueco de ayer.
purpose el marco de «compartir» de KDE (gwenview, okular, spectacle). La receta de
okular lo degrada con el flag oficial FORCE_NOT_REQUIRED_DEPENDENCIES y su
cabecera dice «los que no tenemos sellados»: un estado, no una preferencia.
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/.