Commit Graph
2 Commits
Author SHA1 Message Date
Sergio 8730aad34e takana etapa 3b: las 49 invocaciones pasan a ./target/release/takana
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.
2026-09-09 18:25:58 +00:00
SergioandClaude Opus 5 e6cfb470f1 vigía: provee.py — qué publica de verdad el catálogo, y desde dónde se alcanza
El triaje de apps falló TRES veces, cada vez por una pregunta distinta y cada vez la
anterior daba verde:

  1. ¿existe la receta en el disco?       — el método original
  2. ¿la ALCANZA el consumidor?           — wf-recorder grababa mudo: sus backends de
     audio existían, pero en colas hermanas, que una receta del corpus no ve
  3. ¿la VARIANTE sellada publica la ABI? — imv: mesa existe, es alcanzable, y aun así
     no sirve; las tres variantes no publican libGL.so ni gl.pc

Las tres son la misma equivocación disfrazada: preguntarle al CATÁLOGO lo que sólo
sabe el ARTEFACTO. Este vigía indexa los .pc y las librerías (.a y .so, porque
find_library no mira pkg-config) de todos los artefactos sellados y contesta quién
publica cada nombre y desde qué colas es pedible, aplicando sibling-first: lo del
corpus lo ve todo el mundo, lo de una incoming-* sólo esa cola.

Es el hermano de BUILD de vigia-sonames.py, que cubre la mitad de RUNTIME. La de build
se paga antes: es la que decide si el configure de una receta nueva va a morir.

Tres decisiones de forma que salieron de usarlo y verlo fallar:
- el nombre se busca flojo: gl, gl.pc, libGL.so.1 y librsvg (que tiene que encontrar
  librsvg-2.0.pc) dan lo mismo. El nombre que trae un APKBUILD casi nunca lleva la
  versión, y comparar a lo bruto daba falsos «nadie lo publica».
- agrupado por receta, no por fichero: mesa publica cuatro ficheros de EGL y repetirla
  cuatro veces convierte el informe en ruido justo cuando hay que leerlo rápido.
- --desde <cola> sale con código 1 si algo no se alcanza ⇒ sirve de puerta en cron/CI.

Verificado contra los dos casos conocidos: --desde corpus con lo que swayimg pide da
0, y con lo que imv pedía (gl, opengl) da 1. Barrido completo ~9 s con caché por
ArtifactHash en work/.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XB2iEmxeLZgzqNfhWChrLo
2026-09-03 11:40:40 +00:00