gioser

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1430Shell 145Markdown 87Rust 852973 Definiciones

⎇ 8541febca5b8fca832c728aa41e5fbe7c23dea32 tandas/README.md Markdown · 51 líneas · 2.4 KB Historia crudo

catálogo objetivo P5: tandas a archivo, y el triaje que cierra el lazo ec28a9b39 · sergio · 

1# tandas/ — ARCHIVO de campañas pasadas
2
3**Estos 55 ficheros son historia, no la cola de trabajo.** Se conservan porque documentan qué se
4importó y por qué en cada campaña (el `git log` de cada uno es la crónica del frente Go, del
5base-system, del stack GUI). No se borran. Pero **el trabajo nuevo ya no sale de acá**.
6
7## Por qué dejaron de ser la cola
8
9Una tanda era una lista plana escrita a mano. Eso tenía tres problemas que no se veían mientras
10funcionaba:
11
121. **No decía el orden.** 40 nombres sin aristas: cuál primero, qué destraba qué, qué se puede
13   paralelizar — todo quedaba en la cabeza del que construía.
142. **No decía cuánto faltaba.** Una tanda terminada no significaba una imagen completa; nadie sabía
15   la distancia al objetivo porque el objetivo no estaba escrito en ningún lado.
163. **Había que autorarla.** El worker quedaba idle esperando que un humano escribiera la próxima
17   lista — el problema que [[vps-nunca-idle]] intentaba parchear a mano.
18
19## De dónde sale el trabajo ahora
20
21Todo se deriva del grafo de estado. El flujo completo, y qué comando corre cada paso:
22
23```
24docs/state/targets.toml          ← QUÉ debe tener la distro (perfiles = imágenes, sólo RAÍCES)
25        │  scripts/build-state.py
26        ▼
27docs/state/build-state.json      ← QUÉ hay, qué falta (`wanted`), qué depende de qué
28        │  scripts/drenar.py --todos
29        ▼
30docs/state/drenaje.json          ← EN QUÉ ORDEN: ondas topológicas por imagen
31        │
32        ▼  el worker muele la onda 1:  scripts/farm/campana-deuda.sh <recetas>
33```
34
35Y para descubrir lo que todavía no está declarado:
36
37```
38scripts/seed-graph.py --frontera <perfil>   → docs/state/seed-frontera.json   (candidatos a hueco)
39scripts/triaje.py                           → docs/state/frontera-triaje.toml (veredicto humano)
40scripts/triaje.py --aplicar                 → raíces nuevas para targets.toml + descarte del sembrador
41```
42
43El triaje es el único paso que **requiere un humano**: decidir si un candidato es hueco real, dep
44opcional que no queremos, o andamiaje de nixpkgs. Todo lo demás se deriva.
45
46## Qué sigue vivo acá
47
48- `import-batch.sh -f tandas/<x>.txt` sigue funcionando para importar una lista puntual a mano. Es
49  la vía de escape, no el camino principal.
50- Los subdirectorios `needs-review-*` y `staged-fallidos*` son **resultados**, no colas: recetas que
51  fallaron un smoke-test y esperan diagnóstico.

README.md

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:

  1. 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.
  2. 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.
  3. 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á