Sergio
98c9e4daa6
Cuatro arranques fríos en serie, el perfil partiendo del 5 que dejó la corrida del umbral: S1 pin 0 antes 5 después 1 el navegador ✓ +97 s S2 sin pin antes 1 después 2 el navegador ✓ +98 s S3 sin pin antes 2 después 3 (matada a los 60 s) S4 sin pin antes 3 después 4 EL DIÁLOGO ✗ en 420 s Tres cosas: · la tasa, por fin con perfil sano: dos corridas independientes y pegadas, +97 y +98 s, contra los +123/+195/+197/+204 de antes. Con el anfitrión descargado el mismo artefacto pinta en la mitad del tiempo ⇒ el número es de la máquina y la carga tanto como del producto, y se publica con sus condiciones; · el umbral se reprodujo solo y en otra secuencia: S4 arrancó con 3, sumó a 4 y abrió el diálogo — segunda medición independiente del mismo borde, esta vez identificando la ventana por `min_size` y no por el título (que está traducido, así que un grep por «Troubleshoot Mode» en una imagen en castellano no engancha y su ausencia se lee como la conclusión contraria); · ⚠ y una corrida que PINTA no limpia el contador: S2 pintó y dejó 2. Más todavía, `toolkit.startup.last_success` vale lo mismo en las CUATRO (1789494795, las 17:53) ⇒ el gancho de cierre no corrió ni una vez, ni en las que pintaron. Pintar no es terminar de arrancar. Entonces «quién limpia el contador» SIGUE SIN MEDIR, y el propio documento decía que esta serie lo cerraría: no lo cierra, y queda escrito así. Hace falta una corrida que deje al navegador terminar de arrancar y salir limpio. Lo más caro es para el instrumento: con `--until-paint` cada corrida suma uno, pinte o no, así que una serie se rompe sola a la cuarta — que es lo que pasó ayer sin que nadie lo viera. El arnés ahora AVISA cuando el contador está en 3 («esta corrida va a abrir el diálogo, no el navegador») y la receta para una serie queda escrita: pinnear `--crashes 0` en cada corrida, que resetea la base (S1 lo muestra partiendo de 5). También cae una candidata mía, con un cero que viene con control (medido por la otra sesión): el pref no tiene default en este build, así que fijarlo en 0 SÍ se persiste y el «ausente» no era el pin.
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/.