# SDD 21 — Manual del piloto: qué hago yo, paso a paso Escrito 2026-08-07, a pedido del usuario: «un tipo manual, todos los pasos que tengo que ir haciendo en las tres etapas que marcan esos dos codos». El inventario de lo que falta está en el [SDD 20](20-catalogo-publicable-y-completa.md). **Esto es lo otro**: lo que hace el humano, en orden, con el comando al lado y el motivo debajo. Un comando por vez — nada de bloques largos para pegar a ciegas. **Convención**: `$` = lo tecleás vos. Si un paso puede hacerlo el agente solo, dice **[agente]** y sólo tenés que pedirlo. --- # ETAPA 0 — La rutina, siempre Esto no es una etapa con final: es lo que se hace cada vez que se enciende la máquina. Si algo de acá falla, todo lo demás corre sobre arena. ### 0.1 Después de CADA reinicio: dos comprobaciones ``` $ git -C ~/hammer fsck ``` Un crash puede dejar el `.git` corrupto. Si esto grita, **parar y avisar antes de seguir trabajando**: un commit encima de un repo roto empeora el problema. ``` $ pgrep -x crond ``` Si no imprime un número, **el latido está muerto y no se nota**: la cosecha del worker, la siembra de recetas y la regeneración del grafo dejan de correr en silencio. arje-zero como PID 1 no arranca cronie, así que pasa en cada arranque. Se revive con: ``` $ sudo /usr/bin/crond -s ``` Tiene que ser esa ruta y ese flag. **`rc-service` FALLA** — ya se probó. ### 0.2 El disco, una vez al día ``` $ df -h /home ``` Por debajo de **50 G libres**, actuar. La válvula es: ``` $ cd ~/hammer && ./scripts/store-gc.sh --aplicar ``` ⚠️ **En PRIMER PLANO, mirando la pantalla.** No en segundo plano, no con `&`, no con `nohup`. El 2026-08-07 este script informó «364 artefactos borrados, 24G liberados» **sin haber borrado ninguno** — corriendo en segundo plano el borrado no se materializaba y el `echo` se creía el `rm`. Ahora lleva un guardián que recuenta sobre el disco y sale con error si sobrevivió algo, pero la regla de correrlo en primer plano sigue en pie. Recupera ~24 G por ciclo de trabajo (los artefactos *superados*). Si hace falta más, el orden de reservas, de barata a cara, está en la nota `capacidad-disco-proyeccion`. ### 0.3 El respaldo ``` $ cd ~/hammer && ./scripts/respaldo-storagebox.sh ``` **Es interrumpible y continuable**: podés cortarlo con Ctrl-C o apagar el laptop cuando quieras, y al relanzarlo sigue donde quedó — incluso a mitad de un fichero grande. Corré esto siempre que vayas a tener la máquina encendida un rato largo. Dato medido en la oficina el 2026-08-07: el uplink da **8 Mbps de subida, iguales por cable y por wifi** ⇒ el cuello está en la conexión del local, no en tu laptop, y **enchufar el cable no cambia nada**. Los 128 G del store no caben en una sentada; por eso el script sube primero el *cerebro* (estado + repo, que es lo que no se puede perder) y después el store. ### 0.4 El worker ``` $ hcloud server list ``` Si `hworker-1` aparece, está facturando. Se apaga solo: lleva un *dead-man* propio que lo **borra** (no lo apaga — apagado seguiría facturando) tras 1 hora sin builds. Para ver si está trabajando de verdad **mirá los procesos, no la carga**: durante el `sleep 180` del bucle la carga marca 0 y parece idle sin estarlo. --- # ETAPA 1 — De hoy a «la distro está PUBLICABLE» El orden está elegido para que lo bloqueante vaya primero y lo caro después. **La trampa clásica es invertirlo**: pasarse meses con el navegador y descubrir el día del anuncio que no se puede publicar. ### Paso 1 — Destrabar las 12 recetas en deuda **[agente]** Es un solo agujero visto desde cuatro grafos: la cadena GUI de la cascada de mesa. No se pueden construir en el laptop (zig-skew rompe cairo) y fallan en el worker porque su rootfs no trae python3 ni cmake. El arreglo correcto es **declarar las herramientas en `[deps]` de cada receta, NO engordar el rootfs del worker**. Engordarlo parece más rápido y es justo lo que rompe la reproducibilidad: el build pasaría a depender de qué hay instalado en una máquina concreta. Vos: pedirlo, y tener el worker arriba. ### Paso 2 — Terminar las licencias **[agente]** Quedan 913 de 1141, casi todas CLIs Go/Rust. Se automatiza con evidencia real y sin red: `Cargo.toml` trae el campo `license` y los módulos Go traen su `LICENSE` en el árbol. Para ver dónde estamos en cualquier momento: ``` $ cd ~/hammer && ./scripts/licencias.sh ``` **Lo que te toca decidir a vos**: cuando una licencia sea ambigua, se deja vacía. No se rellena a ojo. Un hueco contado es deuda; un hueco rellenado a ojo es una mentira sobre la que alguien va a construir. ### Paso 3 — El texto de la licencia dentro del paquete **[agente]** Va en `takana pack`, **no** en la fase `install` de las recetas. Las fases entran al `ArtifactHash`, así que hacerlo ahí re-hashearía las 1141; pack es aguas abajo y sale gratis. ### Paso 4 — El espejo de fuentes **[agente]** construye; **vos** decidís dónde vive y pagás el alojamiento. Es la obligación de la GPL que más se malinterpreta: no es «que el código exista en internet», es que quien recibe el binario pueda obtener **de nosotros** la fuente correspondiente. Como cada receta pinea `tarball` + `sha256`, es mecánico y encima verificable. **Tiene que existir antes de la primera descarga pública.** Decisión tuya: el Storage Box ya tiene 1 TiB y sobra sitio — puede servir de espejo de fuentes sin gastar un euro más, pero no está pensado para servir tráfico web. Conviene decidirlo antes. ### Paso 5 — Las claves de firma 🔑 **esto es tuyo, no delegable** Hoy hay firma de índice; falta el nivel de arriba. Hace falta: 1. Generar una **clave raíz fuera de línea** — en una máquina que no esté en internet, y que **nunca** toque este laptop ni el worker. 2. Guardar el respaldo de esa clave **en papel o en un medio que no esté conectado**, en otro sitio físico. 3. Generar claves de firma intermedias, rotables, firmadas por la raíz. 4. Escribir el procedimiento de qué hacer si se filtra una. **Por qué te toca a vos**: una clave raíz que un agente puede leer no es una clave raíz. Y firma sin gestión de claves es teatro — peor que no firmar, porque da confianza falsa. ### Paso 6 — La imagen en metal Falta **re-quemar el USB** (está a medias). ``` $ lsblk -o NAME,SIZE,TRAN,MODEL ``` ⚠️ **Identificá el disco por tamaño/modelo/transporte, NUNCA por nombre.** Los nombres bailan entre arranques. Y **jamás quemar a un NVMe**: ahí vive tu sistema. Al validar imágenes de escritorio, **con pantalla, nunca sólo `-nographic`**. Dos trampas ya pagadas caro: `/dev/console` es el serial, así que cada capa tiene que escribir a `/dev/tty0` para que la veas; y para COSMIC en QEMU `-vga none` es **obligatorio** (virtio-gpu suma una VGA ⇒ dos salidas, y el panel se ancla en la que no estás capturando), con `-smp 8` porque el panel tiene deadline de arranque. ### Paso 7 — Probar la actualización de verdad **[agente]** monta el ensayo; **vos** mirás el resultado. Instalar N, actualizar a N+1, que arranque. Y **rollback**, que con un store direccionado por contenido debería ser barato — es la ventaja natural de esta arquitectura, y conviene que sea función de primera clase antes de publicar, no después. ### Paso 8 — `cups` y `bluez` **[agente]**. Impresión y bluetooth. Sin esto la distro se siente incompleta aunque todo lo demás ande. ### Paso 9 — La infraestructura pública - Espejo de paquetes: **~30 G** separando los `-debug` en paquetes aparte (el 79% del store es información de depuración). **Vos**: contratar el alojamiento. - Sitio de descarga con sumas y firmas, y las instrucciones para verificarlas. - **Publicar la evidencia de reproducibilidad**: los `ArtifactHash` de la clausura de cada imagen. Esto es *el* diferenciador — es lo que convierte «somos reproducibles» en algo que un extraño puede comprobar. No lo dejes para después: es lo único que nadie más está ofreciendo. - Un canal de reportes y una dirección para avisos de seguridad. ### Paso 10 — Antes de anunciar: el ensayo general Ensayar el ciclo completo de seguridad **con un CVE de mentira**: detectar, construir, firmar, publicar, y que le llegue a una máquina instalada. Si esto no está ensayado, el primer CVE real te encuentra improvisando. --- # ETAPA 2 — De PUBLICABLE a «la distro está COMPLETA» Acá ya estás publicado y tenés usuarios. Cambia el modo de trabajo: **cada cosa que agregues tiene que llegarles por el canal de actualización**, así que la Etapa 1 §7 tiene que estar sólida. ### Paso 1 — Los WMs Wayland ligeros (empezá por acá) Es la mejor relación esfuerzo/resultado que queda: no hay una torre de C debajo. En orden: 1. **`wlroots`** — la base de la que cuelgan casi todos. Sin esto no hay nada más. 2. Los compositores: **`sway`**, `labwc`, `river`, `niri`. 3. Los accesorios, **sin los cuales un WM no se usa de verdad**: `waybar`, `fuzzel`/`wofi`, `swaybg`, `swayidle`, `swaylock`, `grim`, `slurp`, `wl-clipboard`. Hoy de toda esa familia sólo existen `foot` y `mako`. ### Paso 2 — Las aplicaciones baratas, que son las que más se notan `imv` (imágenes), `zathura` (PDF), `mpv` (vídeo), un gestor de archivos, un editor gráfico. Cada una es una tarde, y juntas cambian por completo la sensación de la distro. **Medido: hoy no hay ninguna aplicación gráfica de terceros.** ### Paso 3 — La deuda de fondo, antes de crecer más - Las **16 recetas con `compiler = "gcc"`**. Las 12 de Rust son un solo problema: falta el unwinder de libgcc. - El **no-determinismo de 92 paquetes** (rutas `/src` en secciones `.debug_*`). El arreglo global re-hashea ~720 recetas ⇒ **es una decisión tuya de arquitectura**, y conviene tomarla cuando el corpus sea lo más chico posible. Cada mes que pasa es más caro. - **ADR 0012, la carrera del árbol de fuentes**: pendiente y sin decidir. Aviso registrado: *un lock sólo en la extracción parece correcto y NO lo es.* ### Paso 4 — LibreOffice Caro pero acotado. Antes que el navegador. ### Paso 5 — El navegador 🏔️ **Presupuestalo como un frente propio, no como una receta.** Firefox es Rust + C++ + su propio sistema de build, y arrastra cbindgen, nasm, nodejs y una cadena de `*-sys` con C++ — que es justo la frontera que el techo MSRV del sandbox (1.96) no cruza todavía. O sea que **antes de Firefox hay que subir el techo del sandbox**; empezar por la receta es empezar por el final. **Decisión tuya y de las primeras**: marca. Redistribuir Firefox con su nombre y logo exige cumplir la política de Mozilla (por eso Debian tuvo Iceweasel). Cumplir o rebrandear — pero decidido antes de construir, no después. --- # ETAPA 3 — Después de COMPLETA: que siga viva La distro deja de ser un proyecto de construcción y pasa a ser uno de **mantenimiento**. Lo que hay que sostener: 1. **Cadencia de release** escrita y cumplida. Una distro sin ritmo previsible pierde usuarios aunque sea técnicamente mejor. 2. **Seguridad continua**: seguir CVEs de lo empaquetado y publicar actualizaciones. Esto no se pausa. Es el compromiso real que asumís al publicar. 3. **La reconstrucción desde cero, cronometrada, en una máquina limpia.** Repetirla periódicamente: es la prueba de que el proyecto no depende de este laptop — que es exactamente la preocupación que originó el respaldo del 2026-08-07. Si un día deja de funcionar, te enterás por el ensayo y no por una desgracia. 4. **El reconstructor independiente**: otra máquina, idealmente de otra persona, que reconstruya y compare hashes en continuo. Es el objetivo final del invariante de takana — el día que un tercero confirme bit a bit lo que publicamos, la promesa deja de ser nuestra palabra. 5. **Contribuciones de fuera**: si llega gente, hace falta cómo aceptar recetas sin bajar el listón (revisión, firma, y que el aporte no rompa la reproducibilidad). --- ## Lo que yo haría el lunes que viene En este orden, y sin saltarse: 1. `pgrep -x crond` y revivirlo. Sin latido no hay cosecha. 2. Dejar corriendo el respaldo mientras trabajás. 3. Pedir el arreglo del rootfs del worker → caen las 12 recetas en deuda. 4. Pedir la automatización de las 913 licencias. 5. **Generar la clave raíz fuera de línea.** Es lo único de la lista que no puede hacer nadie más que vos, y es el que más tarda en poder empezarse si se posterga.