Files
takana/docs/state
Sergio c719fe211a estado: cascada de kirigami reconstruida — 39/39 al hash nuevo, cero fallos
El arreglo del no-determinismo de kirigami movió su ArtifactHash (41eea38e… →
a72b1626…) y con él el de todo lo que cuelga: 37 dependientes directos, 39
transitivos (entran `frameworkintegration` y `plasma5support` por vía indirecta).

Reconstruidas las 39 en orden topológico y con UN solo `flock -o` para toda la
tanda. Comprobado aparte del log: para las 39 existe `store/<hash-de-hoy>-<nombre>`.
Las gordas: kwin 3027s, plasma-workspace 1958s, okular 810s, kirigami-addons 816s.

⚠ A mitad de tanda, `kirigami-addons` y `kdf` murieron con «No space left on
device» — y es otra vez la trampa de siempre: NO eran recetas rotas. El disco de
`/mnt/vvv` estaba al 100%. Las dos reconstruyen bien con sitio libre.

Dos cosas se arreglaron a raíz de eso:
  · `poda-fuentes.sh` con su suelo de 24 h liberaba CERO, porque los 30 árboles
    eran todos de hoy — la lección de `cache-ci-no-envejece` otra vez: un guardián
    calibrado a una escala que el dato nunca alcanza no protege. Con `--horas 1`
    y luego `--horas 0` se recuperaron 14 G.
  · la tanda ahora poda el árbol de CADA receta al terminarla (sólo el suyo: las
    deps son compartidas, borrarlas en vuelo es el ADR 0012). Con eso
    `work/sources` se mantuvo en 54-71 M durante el resto de la cascada en vez de
    crecer sin freno.

El `never: 1` que aparece en el grafo KDE es `minga`, una receta nueva de otro
agente, sin perfil y ajena a esta cascada.
2026-09-14 20:41:34 +00:00
..