sergioandClaude Opus 5
85c25619ad
La paridad cosmic no se demuestra con un cliente nuestro (eso probaria que nos entendemos con nosotros mismos), se demuestra con la herramienta que usa el resto del mundo. wlr-randr habla wlr-output-management-unstable-v1, que mirada sirve. Entra a base-system-1 con ese rol acotado. C sobre meson, 28 KB, trae el XML del protocolo adentro: solo wayland-client. Tarball de release y no el -/archive/ autogenerado de GitLab, que no es estable byte a byte y rompe el sha256 pinneado con el tiempo. Queda anotado en la receta lo que hoy NO puede hacer, para no acusar al paquete: en mirada apply/test de zwlr_output_configuration_v1 contestan failed, asi que wlr-randr lista bien y no cambia nada. Cuando mirada implemente el apply, esta misma receta pasa a probar tambien el apply. Por lo mismo no entran kanshi ni way-displays: no son herramientas sino una funcion —perfiles de salida por hotplug— y su lugar es adentro de mirada, que ya tiene el estado. Instalarlos hoy seria ademas inutil. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.