sergioandClaude Opus 4.8
ec28a9b394
tandas/README.md declara los 55 ficheros ARCHIVO de campañas pasadas (no se
borran: su git log es la crónica de cada frente) y documenta de dónde sale el
trabajo ahora. import-batch.sh -f sigue vivo como vía de escape, no como camino.
Lo que faltaba para que la cola fuera derivada de verdad era el paso humano, y
estaba sin forma: 137 candidatos clasificables sólo en la cabeza de alguien.
triaje.py les da forma durable — docs/state/frontera-triaje.toml, 170 candidatos
unificados de los 3 perfiles. Cada veredicto cierra un lazo distinto:
hueco → raíz en targets.toml ⇒ nace un nodo `wanted`, el sembrador lo
siembra y el drenaje lo ordena (= trabajo nuevo para el worker)
opcional → registrado, deja de reaparecer como pregunta
nix-ismo → vuelve a seed-graph.py como descarte ⇒ el sembrador APRENDE de su
propio triaje y cada corrida sale más limpia
Sincronizar NUNCA pisa un juicio humano: agrega los nuevos y marca ausente=true
los que dejaron de aparecer (progreso, o cambio de nixpkgs — se ve en el diff).
`sugerencia` propone con evidencia mecánica pero `veredicto` arranca en
`pendiente`: la heurística abarata el juicio, no lo cierra.
Lazo verificado punta a punta: python3-3.14.6-env marcado nix-ismo → --aplicar
lo escribe al descarte → seed-graph.normalizar() lo devuelve clasificado y deja
de contarlo como hueco. Probado y revertido; los 170 siguen pendientes.
Cadena cerrada y corriendo: targets.toml → build-state.json → drenaje.json →
worker, regenerada por el latido cada 30min. El único paso que pide una persona
es el triaje.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.4 KiB
2.4 KiB
tandas/ — ARCHIVO de campañas pasadas
Estos 55 ficheros son historia, no la cola de trabajo. Se conservan porque documentan qué se
importó y por qué en cada campaña (el git log de cada uno es la crónica del frente Go, del
base-system, del stack GUI). No se borran. Pero el trabajo nuevo ya no sale de acá.
Por qué dejaron de ser la cola
Una tanda era una lista plana escrita a mano. Eso tenía tres problemas que no se veían mientras funcionaba:
- No decía el orden. 40 nombres sin aristas: cuál primero, qué destraba qué, qué se puede paralelizar — todo quedaba en la cabeza del que construía.
- No decía cuánto faltaba. Una tanda terminada no significaba una imagen completa; nadie sabía la distancia al objetivo porque el objetivo no estaba escrito en ningún lado.
- Había que autorarla. El worker quedaba idle esperando que un humano escribiera la próxima lista — el problema que vps-nunca-idle intentaba parchear a mano.
De dónde sale el trabajo ahora
Todo se deriva del grafo de estado. El flujo completo, y qué comando corre cada paso:
docs/state/targets.toml ← QUÉ debe tener la distro (perfiles = imágenes, sólo RAÍCES)
│ scripts/build-state.py
▼
docs/state/build-state.json ← QUÉ hay, qué falta (`wanted`), qué depende de qué
│ scripts/drenar.py --todos
▼
docs/state/drenaje.json ← EN QUÉ ORDEN: ondas topológicas por imagen
│
▼ el worker muele la onda 1: scripts/farm/campana-deuda.sh <recetas>
Y para descubrir lo que todavía no está declarado:
scripts/seed-graph.py --frontera <perfil> → docs/state/seed-frontera.json (candidatos a hueco)
scripts/triaje.py → docs/state/frontera-triaje.toml (veredicto humano)
scripts/triaje.py --aplicar → raíces nuevas para targets.toml + descarte del sembrador
El triaje es el único paso que requiere un humano: decidir si un candidato es hueco real, dep opcional que no queremos, o andamiaje de nixpkgs. Todo lo demás se deriva.
Qué sigue vivo acá
import-batch.sh -f tandas/<x>.txtsigue funcionando para importar una lista puntual a mano. Es la vía de escape, no el camino principal.- Los subdirectorios
needs-review-*ystaged-fallidos*son resultados, no colas: recetas que fallaron un smoke-test y esperan diagnóstico.