`work_root` sale de `dirname(store)/work`, y con el store en `/store` el padre es `/`: todo el
scratch iba al overlay de 69 G de la jaula, que además es capa DESECHABLE — la caché de fuentes
vivía en algo que se tira. Mientras tanto `/dev/sdc`, 255 G, estaba al 9 %.
De los 6,8 G de `work/sources`, 5,4 G eran DOS COPIAS del mismo commit de tawasuyu: los árboles se
nombran por receta, no por commit, así que cada receta del monorepo cuesta otros 2,7 G. Queda
anotado que es deliberado (aislamiento del ADR 0012) y que no se deduplica de paso.
Arreglado con enlaces a `/work/sergio/work` en vez de con `TAKANA_WORK`: el override existe y
funciona, pero una docena de scripts llama a `takana build` y un export que hay que recordar se
olvida. Comprobado con un build real sin ninguna variable — rc=0, el árbol cayó en sdc y el hash
salió idéntico al de la corrida anterior. Overlay de 6,9 G a 14 G libres.
Anotado también que el worker NO tiene este problema (un solo disco de 196 G), que los enlaces se
van si la jaula se rehace, y que la premisa del `seal` (rename atómico ⇒ mismo filesystem) ya
estaba rota en el hub antes de esto, porque `/work` y `/store` son discos distintos.
Pasó dos veces el mismo día, con el mismo reflog: commit propio, `(start): checkout <otro>`,
`(finish): returning to main`, y ni un `pick` en el medio.
Antes de escribir otra hipótesis, se probó: dos clones de juguete, el otro empuja, yo commiteo local,
`git pull --rebase -q origin main` ⇒ mi commit SE REAPLICA y mi fichero sigue. O sea que `pull
--rebase` hace lo suyo, y lo que falla es que este árbol lo comparten varios agentes y alguien mueve
`refs/heads/main` mientras el rebase está en vuelo.
La receta práctica no cambia (mirar `git log -1` después de cada pull; recuperar con reflog +
cherry-pick), pero el diagnóstico sí: evita ir a buscar el bug al lugar equivocado.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El texto de esta mañana afirmaba que «otro agente movió la rama», y daba como prueba que los commits
que trajo el `pull` cuelgan del commit ANTERIOR al mío. Eso no es prueba de nada: es lo normal
cuando el otro lado empujó desde una máquina que había hecho `fetch` antes — en este caso la laptop,
cuyos tres commits llevan su huso (-04:00) y no pasaron por acá.
Lo MEDIDO es el reflog (entre `start` y `finish` no hay un solo `pick`) y que los diez ficheros
desaparecieron también del ÁRBOL, cosa que un `reset --hard`/`checkout` concurrente sí explicaría.
Queda escrito como hipótesis, que es lo que es.
La receta práctica no cambia y es lo que vale: mirar `git log --oneline -1` después de cada
`pull --rebase`, y si el commit propio no está, `git reflog` + `cherry-pick`.
De paso, descartado el sospechoso obvio: `cosecha-cron.sh` NO hace pull ni reset — commitea acotado
por pathspec y si el push falla sólo lo anota.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Medido hoy en este repo compartido: commit propio con 10 ficheros → push rechazado porque otro
agente empujó → `git pull --rebase` → el commit YA NO ESTÁ, ni en el log ni en el árbol (los diez
ficheros desaparecidos del disco).
El reflog lo explica: entre `pull --rebase (start)` y `(finish)` no hay ni un `pick`. El rebase no
encontró nada que reaplicar porque, para cuando corrió, el commit ya no colgaba de `main` — los tres
commits que trajo el pull tienen de padre al commit ANTERIOR al mío, o sea que otro agente movió la
rama hacia atrás. Con `-q`, el resultado se ve igual que un pull limpio.
La recuperación es `git reflog` + `git cherry-pick <sha>`: vuelve entero. Y la comprobación que
evita el susto es mirar `git log --oneline -1` después de cada `pull --rebase`.
De paso, el corolario del espejo: el push doble puede triunfar en un remoto y fallar en el otro
(gitea rechazó, GitHub aceptó), así que tras recuperar queda un sha huérfano en GitHub con el mismo
contenido. Se repara empujando SÓLO esa URL con `--force-with-lease=main:<huérfano>`, después de
comprobar con `git diff --stat` que no se pierde nada.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El aviso nuevo se metió entre `aísla de verdad.` y `Vale también para git commit -F -`, dejando la
mitad del párrafo viejo colgando del final del nuevo. Sólo reordena; no cambia una palabra.
El párrafo de arriba dice que `git commit -- <rutas>` es lo único que aísla de verdad, y es cierto
para las OTRAS rutas. Para la ruta que uno nombra es al revés de lo que uno supone, y quedó medido en
repo de juguete: con el fichero en `MM` —stageado y modificado por otro agente— el commit se lleva el
ÁRBOL, no lo stageado, y el índice queda en la versión del árbol. Lo que el otro tenía stageado ahí
se pierde.
Corolario práctico, que es lo que salvó el trabajo de otra sesión hoy: un fichero que aparece `MM` y
que uno no tocó no se commitea ni con pathspec. Se avisa.
205 lineas en 73 ficheros de crates, mas la prosa de CLAUDE.md y del skill,
que se me habian quedado afuera de los barridos anteriores (no eran ni recetas
ni docs/ ni scripts/).
EL BARRIDO ANCHO ESTUVO A UN COMMIT DE ROMPER EL CORPUS ENTERO.
El primer intento reescribia los .rs completos, no solo los comentarios. Entre
las lineas de codigo que tocaba estaban SIETE etiquetas de separacion de
dominio, que son ENTRADA DE HASH:
b"hammer-tree-v1" <- el prefijo de ArtifactHash::of_tree (hash.rs:60)
b"hammer-seed-v1" la funcion que hashea TODOS los artefactos:
b"hammer-stage1-rootfs-v2" cambiarla mueve los 4750 hashes del store
b"hammer-product-rootfs-v3"
b"hammer-product-attested-v2"
b"hammer-builder-rootfs-v1"
b"hammer-attest-dev-rootkey-0001!!" <- clave raiz de atestacion, [u8;32]
Revertido y rehecho solo sobre comentarios, esquivando ademas las cadenas
crudas de Rust (r#"..."#) porque el SYSTEM_PROMPT del traductor tiene lineas
que empiezan como comentario.
Controles: las 7 etiquetas siguen ahi, el diff toca CERO lineas de codigo,
605 tests en verde y el hash de zlib sigue en b3:dc363f26.
La leccion es la misma de toda esta etapa: un literal que parece prosa puede
ser entrada de hash, y la unica forma de saberlo es mirar donde se usa.
Los llamadores EJECUTABLES: scripts/ (incluida toda la granja), los runbooks y
CLAUDE.md. Seguro porque la 3a ya garantiza que el worker emite los dos
binarios, y porque en farm-lab-sync.sh el cargo build remoto precede a la
invocación remota en el mismo script.
Verificado: sintaxis de los 49 (bash -n / py_compile — ojo que
why-differs-barrido.sh es Python con extensión .sh) y `takana hash` devuelve
hash real sobre el store.
NO se toca en esta etapa, a propósito:
- La variable de entorno HAMMER=. Es interfaz de los scripts entre sí 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/: es generado, se regenera solo.
- Los ADR y los docs de diseño: texto, y `hammer` sigue funcionando. Van con
la etapa 5, que es la de churn de texto.
Etapa 2 (ADR 0016): el binario canónico es `takana` y `hammer` se sigue
emitiendo. Son DOS [[bin]] al mismo main.rs, no un symlink: la siembra de la
granja excluye /target (un symlink del hub no existiría en el worker) y
`cargo clean` lo borraría. Ningún llamador tocado; los 124 siguen andando.
Adoptados los dos puntos de la hoja de marca que chocaban con contratos:
- `forja` como ALIAS de clap sobre `build`, no como reemplazo. El canónico
sigue siendo el inglés, que es lo que usan scripts, cron y runbooks. Y se
enmienda la regla 4 de CLAUDE.md en el mismo commit: cambiar el
comportamiento dejando escrito el contrato viejo es lo peor de las dos
opciones, porque el otro agente del repo aplica lo que lee.
- `.tkn` como extensión de paquete. Salió barato y por una razón medida: la
extensión no es lógica sino salida — se escribe en UN solo lugar
(main.rs:1800) y el descubrimiento va por índice, no por glob
(PackageEntry.file, repo.rs:75). Los repos con entradas .swm siguen
resolviendo y un repo mixto es válido; cero ficheros .swm versionados.
Los tipos Swm/SwmBuild/swm_bridge no se tocan: son internos, van en la
etapa 4.
287 tests en verde (hammer-cli + hammer-core), incluidos los que fabrican
repos con nombres .swm a mano — que son justamente la prueba de que la
compatibilidad hacia atrás se sostiene.
El dato ya estaba en memoria y aun así se perdió dos veces, así que ahora vive en los sitios
que se leen sin buscarlos: regla 1 bis de CLAUDE.md (que carga todo agente en cada sesión) y
la skill 'granja' del repo. Se compila en dev.gioser.net PARA NO GASTAR HETZNER; no se
levantan cajas hcloud salvo petición explícita.
Y se arregla la fragilidad que salió al mirar: el reaper de cosecha-cron expulsa de .fleet
todo lo que no esté en hcloud, y el LXC se salvaba SÓLO porque su nombre contiene la subcadena
'gioser' y caía en una lista negra que existe para proteger al hub de Hetzner — no tiene nada
que ver con él. Medido con el bloque real del reaper contra un .fleet de juguete:
nombre CON 'gioser' → 'en LISTA NEGRA ⇒ intocable' sobrevive
el MISMO host como 'pruebasia-lxc' → 'ya no existe en hcloud' .fleet VACÍO
O sea que la granja se mantenía conectada por una casualidad de nombre, y con otro nombre
volvía a 'flota vacía' en el primer ciclo sin que nada fallara. Ahora el reaper pregunta por
SSH si el host responde, que es preguntarle a la máquina en vez de al nombre. Verificado en
las dos direcciones, con control:
host vivo, nombre sin 'gioser' → 'no es de hcloud pero RESPONDE ⇒ se queda (€0)'
host que no responde → 'no responde ⇒ lo saco de .fleet' (intención original)
Queda anotado también que .fleet está gitignored: un hub recién clonado nace con la flota
vacía y la granja queda desconectada en silencio — la cosecha dice 'flota vacía', los
artefactos no vuelven, y estado-granja.sh reporta 'no hay worker vivo' con el worker
compilando. Es como se descubrió esto hoy.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
El lock lo sostiene la descripción de fichero abierta y los hijos la heredan. Medido hoy: dos
firefox colgados de una caza sobrevivieron al kill del bwrap que los envolvía y dejaron a la
granja sin poder compilar durante hora y media, sin que nada fallara — el siguiente flock
simplemente espera.
Comprobado en los dos sentidos con control positivo y negativo:
flock lock sh -c 'sleep 25 & exit 0' ⇒ el nieto retiene el lock
flock -o lock sh -c 'sleep 25 & exit 0' ⇒ lock libre
Se añade también cómo diagnosticarlo (fuser -v sobre el fichero de lock, que nombra al proceso
fugado) y se deja anotado que los scripts de scripts/farm/ usan el estilo 'exec 9>' + 'flock 9',
vulnerable igual, como deuda conocida sin barrer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
Medido hoy, y contra mi propia metida de pata: el commit ff0b556 se llevó dentro
un rename y un borrado de otro agente HABIENDO usado `git add <ruta explícita>`
y `git commit` sin -a. O sea, cumpliendo la regla al pie de la letra.
La causa es que el índice es estado COMPARTIDO entre los agentes que trabajan el
árbol: `git commit` commitea el índice entero, no lo que uno acaba de añadir.
Comprobado en un repo de juguete en los dos sentidos:
git add mio.txt && git commit -m … -> arrastra el ajeno.txt que el otro tenía staged
git commit -m … -- mio.txt -> sólo mio.txt; lo del otro queda staged e intacto
La regla decía «sólo rutas explícitas» y esa frase apunta al `add`, que no es
donde está el peligro. Queda apuntando al `commit`, que es donde sí.
Lo levantó la sesión hammer-f8 al ver sus ficheros dentro de mi commit.
La regla existía —kernel_cmd.rs la cita como «Regla 7.bis»— pero no estaba
escrita en ningún sitio que un agente lea, así que nadie la respetó: el ADR
0015 nació proponiendo traer/crear/correr. Queda en CLAUDE.md, que es lo que
se carga en cada sesión.
Con la deuda declarada en vez de tapada: varios scripts/ exponen flags en
castellano y el barrido es su propia unidad de trabajo, porque tocarlos de
paso rompe cron y la granja. Código nuevo nace en inglés desde hoy.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U5cQtQrYNjWJVXVE6aEpQ2
El repo lo trabajan varios agentes a la vez y las dos formas conocidas de
destruir el trabajo ajeno no estaban escritas en ninguna parte que un agente
lea al arrancar.
1. Todo `hammer build` envuelto en flock work/.farm-build.lock. hammer
comparte work/sources/<dep>-<sha>: dos builds que compartan una dep se
pisan el arbol y queda ROTO PARA SIEMPRE (ADR 0012, sin decidir; ~93 de
205 recetas KDE murieron asi al invalidar libdrm). Los scripts de la
granja ya toman ESE fichero, asi que nos serializa tambien con ellos. No
va dentro de hammer build a proposito: se bloquearia contra esos scripts.
2. Nunca `git add -A`: arrastra los ficheros a medias del otro.
Y la regla general del vacio, que es de donde salio todo lo de hoy.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sergio