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.
This commit is contained in:
Sergio
2026-09-09 18:33:31 +00:00
parent 1d0d50cc95
commit d47cafa05d
+34 -2
View File
@@ -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