tawasuyu

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1182Shell 87Rust 63Markdown 541592 Definiciones

ADR 0016: etapa 3 cerrada, con la evidencia del ciclo de cron

Se commitea DESPUÉS de verificar, no antes: el ADR afirma que el cron corrió
limpio con los scripts migrados, y ese ciclo (18:30:00Z → 18:32:21Z) ya está
en el log — siembra ✓, manifiesto ✓, los 9 JSON del grafo regenerados por
build-state.py invocando takana, estado pusheado, cero errores.

Documenta además cómo converge el worker, que se midió en vez de suponerse:
/opt/hammer no es un clon git sino rsync, hammer-farm.service corre el loop
como servicio largo, y los dos estados intermedios (antes y después de
reiniciarlo) son coherentes porque la 3a puso los dos binarios en los cargo
build antes de tocar ninguna invocación.

d47cafa05d1ec5bc2a21e4722c3ad484065e86e7 · por Sergio · (hace 1 mes) · padre 1d0d50cc9 · ver el árbol en este commit

Delta semántico

Ninguna definición cambió: el cambio es de texto, documentación o datos.

1 archivos · +34 −2

diff --git a/docs/adr/0016-renombre-takana.md b/docs/adr/0016-renombre-takana.md
index 2a86a830..69584579 100644
--- a/docs/adr/0016-renombre-takana.md
+++ b/docs/adr/0016-renombre-takana.md
@@ -66,8 +66,40 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con
    `/target`, así que un symlink hecho en el hub no existiría en el worker, y `cargo clean` lo borra.
    Cuesta una recompilación del `main.rs` y un warning de cargo («present in multiple build targets»)
    que se va solo en la etapa 6. Los dos nombres funcionan; no se tocó ningún llamador.
-3. **Llamadores** (124 ficheros): `scripts/`, `scripts/farm/`, runbooks, `CLAUDE.md`. En tandas
-   chicas, con `flock -o` cuando toque algo que construya.
+3. **Llamadores.** ← *hecho (2026-09-09)*, en dos commits y en este orden, que no es cosmético:
+   - **3a** — los `cargo build --release --bin hammer` pasan a `--bin takana --bin hammer` (6
+     sitios). Va **solo y primero**: el worker compila desde fuente (`farm-worker-loop.sh`) y la
+     siembra excluye `/target`. Si se cambiaran antes las invocaciones, habría una ventana en la
+     que el worker sincroniza scripts nuevos y sólo tiene el binario viejo — y eso **no falla
+     ruidosamente: deja de cosechar en silencio**.
+   - **3b** — las 49 invocaciones de `./target/release/hammer` → `takana`, en `scripts/`,
+     `docs/runbooks/` y `CLAUDE.md`. Verificado con `bash -n`/`py_compile` los 49 (ojo:
+     `why-differs-barrido.sh` es Python con extensión `.sh`) y, sobre todo, con el **ciclo real
+     del cron** inmediatamente posterior al cambio: `2026-09-09T18:30:00Z → 18:32:21Z`, siembra ✓,
+     manifiesto ✓, los 9 JSON del grafo regenerados (los produce `build-state.py`, que ahora invoca
+     `takana`) y estado commiteado+pusheado. Cero errores. Esa es la prueba que importa: la
+     regeneración del khipu pasa por el binario renombrado.
+
+   **Excluido a propósito de la etapa 3:**
+   - La variable de entorno `HAMMER=`. Es interfaz entre scripts y hay llamadores que la fijan;
+     renombrarla va con la etapa 4.
+   - `docs/evidencia/` y los `HANDOFF-*`: son **registro** de lo que se corrió ese día. Reescribir
+     un comando dentro de una evidencia la falsifica.
+   - `docs/state/`: generado, se regenera solo.
+   - ADRs y docs de diseño: texto, y `hammer` sigue funcionando. Van con la etapa 5.
+
+   **Cómo converge el worker** (medido el 2026-09-09, no supuesto). Su checkout vive en
+   `/opt/hammer`, **no es un clon git** —lo pone el rsync de la siembra— y `hammer-farm.service`
+   está `enabled` allá, corriendo `farm-worker-loop.sh` como servicio largo. En el momento del
+   cambio el worker tenía scripts viejos y binario del 6-sep: **coherente**. Los dos estados
+   intermedios también lo son, y por eso la 3a iba primero:
+   - *Antes de reiniciar el servicio*: el loop viejo en memoria sigue llamando `hammer` y
+     recompilando `--bin hammer`, que existe. Funciona.
+   - *Después de reiniciar*: el loop nuevo compila **los dos** y usa `takana`; si `takana` todavía
+     no existe, `rebuild_si_hace_falta` compila y devuelve 0 —salta el ciclo, no aborta—.
+
+   La unit apunta a la RUTA DEL SCRIPT, no al binario, así que nada de la etapa 3 la toca. El
+   nombre del fichero de unit y `/opt/hammer` son etapa 6.
 4. **Crates** `hammer-*` → `takana-*` y `hammerd` → `takanad`.
 5. **Comentarios de recetas** (692). Gratis en hash, ruidoso en diff: va en un commit propio y solo.
 6. **Retirar el alias.** Y recién entonces, si se quiere, el directorio `/mnt/vvv/hammer` — parando