Commit Graph
222 Commits
Author SHA1 Message Date
sergio b9da01631d estado: cosecha granja 2026-07-23T00:26:38Z — avance del árbol KDE 2026-07-22 20:26:38 -04:00
sergioandClaude Opus 4.8 85b5a9bc46 yupana: instrumentar duración de build en el worker → camino crítico PESADO
El peso que le faltaba a las ondas: sin él, critical-path = nº de pasos; con él,
ETA real en segundos.

INSTRUMENTACIÓN (worker):
  scripts/farm/build-timed.sh envuelve `hammer build` midiendo la pared y la
  registra en $STORE/.times/<hash>-<host>.json — un SIDECAR del store, NUNCA
  dentro del artefacto. La duración es no determinista (varía por máquina/carga)
  ⇒ no puede tocar el ArtifactHash. Keyed por hash (CAS-safe: dos workers no se
  pisan) + host (varias muestras por receta). Viaja al hub con el rsync de store
  que ya hace la cosecha; ninguna herramienta del store lo confunde con artefacto.
  Sólo builds REALES (pared ≥ UMBRAL 3s) — los cache-hits no envenenan la mediana.
  campana-deuda.sh ahora construye vía build-timed.sh (transparente, mismo exit).

CONSUMO (hub): yupana._tiempos() carga name→mediana de segundos; keystones
computa el CAMINO CRÍTICO pesado = longest weighted path del subgrafo de deuda
(peso = segundos de build). La cadena más larga hay que construirla en SERIE
aunque haya ∞ workers ⇒ es la ETA con paralelismo infinito. Degrada con gracia:
sin datos, peso=1 y el camino crítico = nº de pasos (lo que ya daban las ondas).

Verificado: con muestras sintéticas da "ETA 19 min sobre 5 pasos, kio → kparts →
frameworkintegration → breeze → plasma-integration"; sin datos degrada a "5 pasos
(SIN datos)". store/.times está git-ignorado (metadata de máquina, no se commitea).

LÍMITE honesto (en la cabecera de build-timed.sh): `hammer build` arrastra deps ⇒
la pared incluye deps no selladas. En orden topológico (drenar) las deps ya están
selladas y la pared mide sobre todo ESTA receta — cota superior buena para pesar.
La precisión exacta pediría instrumentar el sellado dentro de hammer-build (Rust).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-22 20:25:09 -04:00
sergioandClaude Opus 4.8 4f609080df yupana: los 2 "bugs" de duplicados eran falsos positivos MÍOS — detector afinado, 0 reales
El usuario pidió arreglar itstool y la sombra de dbus. Apliqué el reflejo
(`yupana radio` + diff completo antes de tocar) y NINGUNO era un bug: ambos eran
patrones deliberados y documentados que mi detector, demasiado superficial, leyó
mal. Si los "arreglaba" a ciegas rompía dos builds.

  · dbus: corpus/dbus (estático) e incoming-kde/dbus (dinámico) NO son redundantes
    — qtbase linkea libdbus-1.so dinámicamente para Qt6DBus. El detector comparó
    sólo versión+sha+deps, no el BUILD. Borrar la sombra rompía KDE.
  · itstool: es un STUB documentado (`[source]=carrier`). El itstool real es
    Python con libxml2-bindings ausentes en el lab; este genera un script inline y
    sólo PRESTA el tarball de gettext-tiny. Apuntarlo al itstool real rompía
    appstream (radio 5) con un source que ni compila acá.
    Los 3 *-hello son el mismo patrón carrier; prison/prison-scanner una variante
    cross-nombre (misma fuente, WITH_ZXING distinto).

FIX = el detector, no las recetas. Tres señales que le faltaban:
  1. huella de BUILD en la firma de sombra (estático≠dinámico ⇒ no redundante).
  2. CARRIER: ≤1 receta del grupo construye la fuente ⇒ el resto presta el tarball.
     Señal: ¿invoca make/meson/cmake/ninja/cargo? (comentarios strippeados — la
     prosa "invocación de meson" de un stub daba falso builder, lo cazó el guardián).
  3. variante cross-nombre: ≥2 builders con BUILD distinto = deliberado, no bug.
Resultado: 0 colisiones reales (invariante c se cumple), 4 carrier + 14 variantes
+ 12 sombras justificadas, todas benignas.

Guardián extendido: ancla que el detector agrupa por FUENTE (itstool↔gettext-tiny)
y NO cría lobos (itstool=carrier, dbus=variante deliberada).

LECCIÓN: el reflejo del radio/diff antes de tocar evitó dos borrados destructivos
guiados por un falso positivo de mi propia herramienta. Medir antes de creer, aun
a la propia yupana.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-22 20:14:10 -04:00
sergioandClaude Opus 4.8 619a30187c yupana: keystones — el camino crítico real, con la matemática correcta (AND, no OR)
`yupana keystones` rankea los nudos EN DEUDA por cuánto trabajo BLOQUEADO libera
su sellado (cierre inverso transitivo restringido a la deuda). Sellá de arriba
hacia abajo y la cascada cae lo antes posible.

CORRIGE UN ERROR MÍO: dije "árbol de dominadores = keystones". Lo medí y es
FALSO. El dominador ingenuo asume alcanzabilidad OR (basta un camino), pero
construir es AND (hacen falta TODAS las deps): kcoreaddons depende de dbus/libdrm
/mesa además de qtbase ⇒ hay un camino de desbloqueo que evita qtbase y el
dominador-OR lo pierde. La métrica correcta bajo AND es el cierre inverso
transitivo. Y el crudo lo gana el toolchain (make gatea 313, inútil) ⇒ el
keystone accionable es el cierre restringido a la deuda, y sólo cuenta si el
nudo mismo está en deuda (un sellado ya está disponible, no gatea nada).

Estado actual (qtbase ya sellado, era EL keystone con 117 gateados):
   kio        36   ← sellarlo libera 36 recetas KDE bloqueadas
   kparts     19
   kcmutils   17
   ksvg       14
   libplasma  13
Ése es el camino crítico ahora.

El dominador SÍ entra, en su uso legítimo: la columna `exclusivo` = retención
estilo GC (nodos que sólo dependen de mí). kwin=9 (sus plugins privados),
libksysguard=3. Responde "si suelto esta feature, cuánto más puedo soltar".

Sin datos nuevos (no necesita duración de build). Cuando instrumentemos tiempos,
el mismo cierre se vuelve camino crítico PESADO (ETA real).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-22 20:03:56 -04:00
sergioandClaude Opus 4.8 0f3a1dc394 yupana: invariante (c) CANÓNICO — detector de duplicados por evidencia de fuente
`yupana duplicados` caza nudos que son el MISMO paquete bajo nombres/colas
distintos, agrupando por lo que BAJA (sha/url), no por el nombre. Clasifica:

  colisión-fuente — mismo sha, familias de nombre DISTINTAS ⇒ casi seguro un
                    sha copiado por error. ACCIONABLE.
  variante        — mismo sha, misma familia (zlib/zlib-shared, mesa-*) ⇒
                    diversificación deliberada estático/shared, OK (14 vistas).
  sombra          — mismo nombre en >1 cola; redundante si versión+sha+deps
                    coinciden (una sobra), justificada si difieren.

HALLAZGO INMEDIATO — el detector encontró un bug real en su primera corrida:
  itstool.toml dice versión 2.0.7 pero su url+sha apuntan al tarball de
  gettext-tiny (29cc165e…). Construiría la fuente equivocada. radio itstool=1,
  gettext-tiny=78 ⇒ el sha copiado es el de itstool.
Otras 3 colisiones son demos (adwaita-hello/libadwaita, sourceview-hello/
gtksourceview, radio 0) o subcomponentes (prison/prison-scanner) — a revisar,
no urgentes. Y 1 sombra redundante: incoming-kde/dbus es byte-idéntica a
corpus/dbus (mismo hash de artefacto) ⇒ los 114 consumidores KDE podrían
apuntar a corpus/dbus sin rebuild.

NO funde nada solo: reporta a docs/state/duplicados.json y deja el juicio al
humano (como el triaje). El radio de cada nudo dice cuál es el canónico (el de
mayor radio). Guardián extendido: test-yupana-radio.py falla si el detector
deja de ver colisiones de fuente (agrupar por nombre en vez de sha = invariante
c ciego).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-22 19:59:20 -04:00
sergio e5e3f9e281 estado: cosecha granja 2026-07-22T23:55:39Z — avance del árbol KDE 2026-07-22 19:55:39 -04:00
sergio 42f198f97e estado: cosecha granja 2026-07-22T23:24:35Z — avance del árbol KDE 2026-07-22 19:24:35 -04:00
sergio ea5b27dba4 estado: cosecha granja 2026-07-22T22:43:17Z — avance del árbol KDE 2026-07-22 18:43:17 -04:00
sergioandClaude Opus 4.8 9b67268a65 triaje: los 170 candidatos de frontera clasificados, y la cadena se ejerce entera
Evidencia dura primero: NINGUNO de los 170 bloquea un build. Toda receta que
pide uno de estos ya está sellada al menos una vez ⇒ hammer construye sin
ninguno. Eso descarta empíricamente "hueco de build" para los 170 y deja sólo
la pregunta de runtime.

VEREDICTOS
  provisto  11 — no faltan: ya los da otra receta con otro nombre. nixpkgs parte
                 en varios paquetes lo que acá es uno solo. Verificado contra el
                 store: wayland-scanner→wayland, mesa-libgbm→mesa (nuestros tres
                 mesa producen libgbm.so.1), libxcb-*→xcb-util-*, poppler-qt6→
                 poppler, gmp-with-cxx→gmp, uname→coreutils.
  nix-ismo   5 — andamiaje de nixpkgs (env wrappers, helpers del stdenv, glibc
                 asomando por su libc).
  opcional 150 — software real que nixpkgs habilita y hammer no necesita, con el
                 porqué agrupado: systemd (usamos arje-zero), X11 heredado (el
                 escritorio es Wayland), Vulkan/shaders, audio/multimedia,
                 conectores de BD, tooling de docs/tests, bindings Python de Qt,
                 paquetería ajena (tenemos .swm).
  hueco      4 — gaps de RUNTIME, no de build: shared-mime-info (sin base MIME
                 no hay tipos de fichero), xwayland (ninguna app X11 corre),
                 polkit-qt-1 (sin diálogos de autorización), qqc2-breeze-style
                 (los controles QML caen a un estilo genérico).

CORRIGE UN ERROR MÍO DE P3: dije que mesa-libgbm/libglvnd eran "el muro de
GBM/EGL". Falso — libgbm ya lo produce nuestro mesa. El muro era softpipe vs
llvmpipe, no un paquete ausente.

CUARTO VEREDICTO NUEVO (`provisto`) con su propio lazo: sale a alias-triaje.txt
y seed-graph.py lo carga en MAPA ⇒ esos 11 nombres dejan de contarse como hueco
para siempre. Junto con nixismos-triaje.txt, el sembrador aprende de su triaje.

Y LA CADENA SE EJERCE ENTERA POR PRIMERA VEZ: los 4 huecos entraron como raíces
de escritorio-kde → nacieron 4 nodos `wanted` (raíces 11, sin receta 4; el grafo
sigue cerrando, --check exit 0) → seed-graph los sembró (42 aristas conocidas,
21 candidatos nuevos de frontera) → drenar.py los ordena marcándolos [semilla],
que es la regla de la fuente única a la vista. qqc2-breeze-style no cae en la
onda 1 porque sus deps SEMBRADAS la traban (kcodecs, kirigami…): el andamio
funcionando como se diseñó.

De paso: qtbase se selló mientras corría esto ⇒ la onda 1 de KDE se abrió de 1 a
13 recetas. El cuello de botella que reportó P4 ya está destrabado.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-22 18:30:19 -04:00
sergioandClaude Opus 4.8 ec28a9b394 catálogo objetivo P5: tandas a archivo, y el triaje que cierra el lazo
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>
2026-07-22 18:20:30 -04:00
sergioandClaude Opus 4.8 b08e582c89 catálogo objetivo P4: la cola de la granja pasa a ser derivada del grafo
drenar.py parte la deuda en ONDAS topológicas (una receta sólo espera por deps
que también estén en deuda; las selladas ya están en el store). Onda 1 =
construible ya; dentro de cada onda, orden por `unblocks` desc.

Da lo que una lista plana no da: el orden correcto, la PROFUNDIDAD real de la
cadena (pasos secuenciales = el reloj de pared) y qué paraleliza sin pisarse.

   base                0 en deuda   imagen completa
   cli                 0 en deuda   imagen completa
   escritorio-kde     77 en deuda   12 ondas   onda 1 = 1 receta: qtbase
   escritorio-mirada   4 en deuda    2 ondas   onda 1 = 3

HALLAZGO: el escritorio KDE está serializado detrás de UNA receta. qtbase
destraba 117 nodos y es lo único de la onda 1 — hasta que no esté sellada no hay
nada que paralelizar, por más workers que se enciendan. Cambia la pregunta de
"¿cuántas faltan?" (77, poco informativo) a "¿cuál es el camino crítico?".

Dos correcciones salidas de mirar la salida:
· el grafo se elige por la `cola` declarada en targets.toml, NO por cuál tiene
  más nodos: incoming-kde SOMBREA recetas canónicas, así que medir
  escritorio-mirada contra el grafo KDE medía una imagen que nadie construye
  (3 en deuda en vez de 4). El mismo atajo estaba en seed-graph.py --frontera;
  corregido en los dos.
· regla de la fuente única implementada en deps_de(): manda la receta si existe,
  la semilla sólo si el nodo es `wanted`, marcando procedencia en la salida.

Enchufado al latido: cosecha-cron regenera docs/state/drenaje.json junto al
grafo y lo commitea ⇒ cola derivada y versionada, el git diff entre ciclos
muestra qué salió de la deuda. NO lanza builds: eso cuesta € y sigue siendo
decisión explícita (farm-up + campana-deuda.sh).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-22 18:14:37 -04:00
sergio 417dfd52c1 estado: cosecha granja 2026-07-22T22:07:48Z — avance del árbol KDE 2026-07-22 18:07:48 -04:00
sergioandClaude Opus 4.8 0093c1f19c catálogo objetivo P3: sembrador de aristas desde nixpkgs, calibrado contra la verdad
seed-graph.py extrae deps de la metadata de nixpkgs sin construir nada (leerla
no viola el ADR 0004, que prohíbe *construir* con nix). `--calibrar` mide la
semilla contra la única verdad disponible: las recetas escritas a mano.

VEREDICTO (60 recetas, 686 deps):
   directas     recall 39%*, precisión 59% (269 de 455)
   transitivas  recall 84%,  precisión  6% (390 de 6760)
   * contra la verdad APLANADA — comparación injusta, y el modo transitivo
     prueba que la información sí está; sólo falta aplanarla.

Decisión: sembrar aristas DIRECTAS, la transitividad la hace el grafo. hammer
aplana la clausura en [deps].build (cada dep = capa --overlay-src), nixpkgs
declara directas y propaga; reproducir el aplanado arrastra 4629 nodos fantasma
del bootstrap de nixpkgs.

Lo que enseñó la calibración (3 rondas, cada fix salido de un dato):
· 4 clases de discrepancia, no 1: convención hammer (make/binutils/linux-headers,
  implícitas en el stdenv de nix), variante nuestra (zlib vs zlib-shared),
  provisto por el lab (cargo/rustc — las recetas Rust declaran deps=[]), y recién
  después ruido real. Contarlas juntas hacía parecer irreducible lo clasificable.
· desalineación aburrida y arreglable: caja (libx11/libX11), implementación
  (gettext→gettext-tiny, ninja→samurai), versión pegada al pname, hooks del
  stdenv. Precisión 45%→59%; "sin attr en nixpkgs" 22/40 → 6/60.
· el escritorio KDE cuelga de kdePackages., no del top-level: sin ese fallback
  el perfil objetivo era insembrable.

Hallazgo de secuencia: hay 0 nodos `wanted` (targets.toml se pobló por
lift-and-shift de lo existente), así que el sembrador no tenía a quién sembrar.
De ahí `--frontera <perfil>`: siembra las recetas que YA existen y reporta lo que
nixpkgs pide y hammer no puede construir. 137 candidatos en escritorio-kde
(kdoctools ×6, milou, polkit-qt-1, libkscreen, y mesa-libgbm/libglvnd/spirv-tools
= el muro de GBM/EGL ya documentado), 51 en cli, 46 en escritorio-mirada.

Cada candidato es una HIPÓTESIS a clasificar a mano: dep opcional no habilitada,
nix-ismo por filtrar, o hueco real. Nada se promueve a receta automáticamente.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-22 18:01:08 -04:00
sergioandClaude Opus 4.8 a27d9a94a4 catálogo objetivo P2: estado wanted + membresía de perfil en el grafo
El grafo cruza ahora el corpus con el manifiesto de objetivo:

· estado `wanted` — una raíz declarada sin receta se materializa como nodo de
  frontera. Se crea ANTES de buscar huérfanas a propósito: un objetivo declarado
  no es una arista colgando, así `--check` conserva su significado (verificado:
  exit 0, grafo CIERRA, topo OK). `wanted` ≠ `unhashable`.
· campo `perfiles[]` por nodo — qué imágenes lo alcanzan desde sus raíces.
· bloque `by_profile` — el "cuánto falta", POR IMAGEN.

Primeros números, derivados de raíces y no de listas a mano:
   base               51/51   listo
   cli                74/74   listo
   escritorio-mirada  27/31   (falta libinput, mesa-swrast, mirada-{compositor,greeter})
   escritorio-kde     85/162  faltan 77   ← de 7 raíces, antes ilegible
   674 recetas no las alcanza NINGUNA imagen (catálogo, no distro)

La clausura es COTA INFERIOR mientras haya nodos `wanted`: sus deps no se
conocen hasta construirlos (o sembrarlas, P3). Está documentado en el header.

`totals.recipes` sigue contando sólo recetas con fichero (los consumidores lo
leen como tamaño del corpus); `totals.nodes` incluye la frontera. La vista HTML
regenera sin cambios de contrato.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-22 17:43:40 -04:00
sergioandClaude Opus 4.8 3a64b603d7 catálogo objetivo P1: manifiesto de perfiles — el set de la distro deja de ser un string de shell
El destino de la distro vivía en 2 strings de product-userland-from-repo.sh, 1
de mirada-usb.sh y 55 tandas planas. Ahora en docs/state/targets.toml: un perfil
= una imagen enviable, listando sólo las RAÍCES (lo que se pide por nombre); la
clausura la calcula el grafo, no un humano.

4 perfiles: base (26), cli (46, hereda base), escritorio-mirada (14),
escritorio-kde (7 raíces, cola incoming-kde). scripts/targets.py expande hereda
(transitivo, con detección de ciclo) preservando el orden — mirada lo necesita.

Lift-and-shift verificado: las 3 listas expandidas son byte-idénticas a los
strings que reemplazan. Ninguna imagen cambia de contenido.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-22 17:41:01 -04:00
sergioandClaude Opus 4.8 c963b24b5e ADR 0012: registrar como PENDIENTE el dilema del árbol de fuentes (caché vs workspace)
Queda una carrera abierta que el lock de script NO cierra: `build-farm.sh` corre `xargs -P2` y dos
recetas de la misma cola que compartan dep se pisan igual, porque `fetch` nombra el árbol de forma
determinista y sin nada del constructor.

El fondo no es "falta un lock", es que el árbol cumple DOS papeles que se contradicen bajo
concurrencia: caché direccionada por contenido (clave = nombre+sha, re-extraer es caro) y workspace
mutable de build (lib.rs lo parchea, aísla el workspace Cargo y vendorea EN EL SITIO, y después el
sandbox lo bind-montea). Por eso un lock alrededor de la extracción parece correcto y NO lo es: un
segundo proceso puede borrar un árbol que un bwrap ya está compilando.

El ADR deja las tres salidas (lock por árbol durante todo el build / árbol privado por build /
separar caché inmutable + copia privada) con su contra concreta cada una —incluida que el worker
corre ext4, sin reflink, así que la copia de la opción C es real— y los tres números que habría que
medir para elegir en vez de opinar.

Se ancla en los dos sitios donde alguien va a chocar: el ADR indexado en docs/README.md (de paso se
agregan 0009-0011, que faltaban) y un comentario en el propio `fetch_tarball` que dice explícitamente
que no se arregle a medias.

Va como PENDIENTE y no decidido a propósito: hay otro agente sobre este repo y esto es lo que evita
que la carrera se "arregle" de una forma que parece bien y deja el bug.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-22 17:34:50 -04:00
sergio 062ae142aa estado: cosecha granja 2026-07-22T21:23:35Z — avance del árbol KDE 2026-07-22 17:23:35 -04:00
sergioandClaude Opus 4.8 75c33fffe5 plan: catálogo objetivo — manifiesto de perfiles + estado wanted en el grafo
El grafo de lo que EXISTE cierra perfecto (768 nodos, 0 huérfanas, topo OK).
El de lo que la distro DEBE tener no existe: vive en 2 strings de shell de
product-userland-from-repo.sh, uno de mirada-usb.sh y 55 tandas planas. De ahí
que "cuánto falta" no tenga respuesta.

Plan en 5 piezas: targets.toml (perfiles = imágenes, listando RAÍCES y dejando
que la clausura salga del grafo), estado `wanted` + membresía de perfil en
build-state.py, siembra de aristas desde metadata upstream sin construir, y el
drenaje topológico donde harkaq reemplaza la arista hipotética por la medida.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-22 17:13:40 -04:00
sergio 0639d8a53d estado: cosecha granja 2026-07-22T20:51:43Z — avance del árbol KDE 2026-07-22 16:51:43 -04:00
sergio 660f86c3f3 estado: cosecha granja 2026-07-22T10:31:59Z — avance del árbol KDE 2026-07-22 06:31:59 -04:00
sergio 6c1a4a8b37 estado: cosecha granja 2026-07-21T14:30:04Z — avance del árbol KDE 2026-07-21 10:30:04 -04:00
sergioandClaude Opus 4.8 a1ceaf6ff9 docs: runbook para relanzar el escritorio KDE en QEMU
Cómo relanzar (run-qemu-desktop.sh), verificar sin ojos humanos (screendump por el
monitor QEMU + STATUS del serial), reconstruir la imagen, y la tabla de los 7 fixes
que lo hacen andar + los gotchas de operación (serial stale, pkill auto-mata, OVMF
VARS stale → TianoCore). Para relanzar/verificar, no rediagnosticar.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-20 14:01:02 -04:00
sergio b209205ba8 estado: cosecha granja 2026-07-18T20:37:15Z — avance del árbol KDE 2026-07-18 16:37:15 -04:00
sergio 441c0dfba9 estado: cosecha granja 2026-07-18T19:01:00Z — avance del árbol KDE 2026-07-18 15:01:00 -04:00
sergio 01bfee7a6a estado: cosecha granja 2026-07-18T16:59:38Z — avance del árbol KDE 2026-07-18 12:59:39 -04:00
sergio 25ce9c0cce estado: cosecha granja 2026-07-18T16:22:58Z — avance del árbol KDE 2026-07-18 12:22:58 -04:00
sergio 70e31b9ff2 estado: cosecha granja 2026-07-18T10:30:40Z — avance del árbol KDE 2026-07-18 06:30:40 -04:00
sergio 1c73e38cb3 estado: cosecha granja 2026-07-18T10:00:50Z — avance del árbol KDE 2026-07-18 06:00:51 -04:00
sergio ee5f128594 estado: cosecha granja 2026-07-18T09:30:43Z — avance del árbol KDE 2026-07-18 05:30:43 -04:00
sergio 6c6cc9ec84 estado: cosecha granja 2026-07-18T06:00:28Z — avance del árbol KDE 2026-07-18 02:00:28 -04:00
sergio 509ec89608 estado: cosecha granja 2026-07-18T05:30:28Z — avance del árbol KDE 2026-07-18 01:30:28 -04:00
sergio 87fede06de estado: cosecha granja 2026-07-18T05:00:28Z — avance del árbol KDE 2026-07-18 01:00:28 -04:00
sergio 1b0af4ebf8 estado: cosecha granja 2026-07-18T04:30:27Z — avance del árbol KDE 2026-07-18 00:30:27 -04:00
sergio 9316604e2e estado: cosecha granja 2026-07-18T04:00:28Z — avance del árbol KDE 2026-07-18 00:00:28 -04:00
sergio a2d510edbb estado: cosecha granja 2026-07-18T03:30:28Z — avance del árbol KDE 2026-07-17 23:30:28 -04:00
sergio 6134dc7cb0 estado: cosecha granja 2026-07-18T03:00:34Z — avance del árbol KDE 2026-07-17 23:00:34 -04:00
sergio e59470b166 estado: cosecha granja 2026-07-18T02:31:17Z — avance del árbol KDE 2026-07-17 22:31:18 -04:00
sergio 58f0fe3000 estado: cosecha granja 2026-07-18T02:00:45Z — avance del árbol KDE 2026-07-17 22:00:45 -04:00
sergio 8c29fd0bd9 estado: cosecha granja 2026-07-18T01:31:33Z — avance del árbol KDE 2026-07-17 21:31:33 -04:00
sergio 037cb24d56 estado: cosecha granja 2026-07-18T01:01:03Z — avance del árbol KDE 2026-07-17 21:01:03 -04:00
sergio 8115d91072 estado: cosecha granja 2026-07-18T00:30:35Z — avance del árbol KDE 2026-07-17 20:30:35 -04:00
sergioandClaude Opus 4.8 2a52d7804f granja: cron infinito de cosecha+siembra (recoger/sembrar cada 30min) — latido sin tokens
El worker efímero muele KDE 24/7; este cron en el laptop recoge su store sellado
(worker->laptop, CAS merge seguro), siembra recetas nuevas (laptop->worker) y regenera
el grafo de estado, commiteando SÓLO docs/state/*.json (el avance que el humano sigue).
NO promueve incoming-kde->canónico (decisión de clasificación humana). Robusto a
worker-ausente (dead-man ya lo mató por idle). KDE: 66/206 sellado.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 20:12:09 -04:00
sergio 7bf9af40b1 kde: qtbase + módulos Qt sellados (qtsvg/qtshadertools/qtlanguageserver); snapshot 2026-07-17 16:01:09 -04:00
sergioandClaude Fable 5 fd750c0b55 wawafs: §9 layouts de instalación — el corte ro/rw es de mounts, no de particiones (casos / único y /home+/var)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-17 16:00:30 -04:00
sergioandClaude Fable 5 50ca9ca300 wawafs (SDD 18): el store como FS del sistema vivo — CAS+erofs+fs-verity sobre ext4; gates medidos (kernel sin EROFS/FS_VERITY)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-17 15:42:25 -04:00
sergioandClaude Opus 4.8 b1322c8f47 kde: +base libs selladas (libtool/mpfr/libX*/xcb-util*/mtdev/libnl/libva/leptonica…)
Tanda de base libs KDE construidas en el laptop mientras qtbase compila en background. qtbase (la
raíz, ↑117) va por 400/2163 objetos. libsndfile falló por fetch de red (no código).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 13:45:38 -04:00
sergioandClaude Opus 4.8 ff79dc5e28 estado+kde: el grafo ahora cubre la cola incoming-kde; base KDE desbloqueada en el laptop
MOTIVO: 'estábamos haciendo kde'. La cola recipes/incoming-kde/ (206 recetas) era punto ciego del
grafo (sólo miraba recipes/ top-level). Modo --kde: build-state.py/build-state-view.py cubren la cola
KDE (sombreando canónicas homónimas sibling-first, como el sandbox) → build-state-kde.{json,html}.

CAUSA de la deriva (193/206 en deuda): fui YO — esta sesión re-sellé pkgconf y samurai (arreglos
static), y 194 recetas KDE declaran pkgconf, 142 samurai ⇒ re-hash en cascada de todo el árbol. El
sistema determinista funcionando: cambia un input base, cascan los dependientes. Deuda legítima.

DESBLOQUEO (el 'GUI rompe en el laptop' era sólo cairo/pango, NO la base): construida en el laptop
toda la base KDE guiado por el orden de ataque del grafo — extra-cmake-modules, util-macros,
xorgproto, xcb-proto, wayland, libdrm, dbus, icu4c, util-linux, fontconfig, pixman, glib, freetype,
harfbuzz, fribidi, libXau/libXdmcp, la cadena X11 (xtrans/libxcb/libX11/libXext/libXrender/libXfixes/
libXi), la familia xcb-util, libxkbcommon, wayland-protocols, mesa (24.0.9 iris-only, sin LLVM), y
los -shared. KDE 9→39 selladas. qtbase (↑117, la raíz) quedó DESBLOQUEADO y compilando.

DISCO: el build llenó el disco (100%). Liberados 82G borrando work/sources (57G, se re-extrae solo)
y .farm-harvest (26G, verificado 100% redundante en el store, CAS).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 13:27:55 -04:00
sergioandClaude Opus 4.8 a267cf4f48 estado: clasificación Rust corregida (había ~180 Rust escondidas como C) + musl
Señal fuerte para Rust: la receta copia su binario de target/release/ en las fases. Medido 225
recetas, 0 con dep go ⇒ sin falsos positivos con Go (findutils entra bien: es uutils/findutils, find
en Rust). LÍMITE: un crate BuildSys::Cargo PURO sin fase install propia (zellij) no deja rastro en el
TOML y cae a 'c' — sólo se ve bajando la fuente, que el generador no hace.

Efecto: clases c 322→141, rust 45→226 (la mayoría eran Rust auto sin fase cargo explícita). Y la
LECTURA de la deuda cambia: la deuda C REAL es sólo 8 (casi toda saldada esta sesión), no 74. Lo que
queda es Rust (15, CLI pesados → granja), GUI (29 → granja), Go (5 → worker), kernel (4).

musl sellado (base). Avance: sealed 703→704, debt 53→52.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 12:36:23 -04:00
sergioandClaude Opus 4.8 d111b5f040 estado: sistema-base C saldado en el laptop (deuda 85→53, sealed 671→703)
Tres tandas más de C-base de sistema, todas verifican (MIENTEN 0): perl (background, desbloquea 8),
la cadena curl/ca-certificates/gnupg, y bwrap dosfstools e2fsprogs gzip htop iproute2 iputils jq kbd
lz4 libsodium libuv mandoc parted pciutils procps-ng rsync shadow strace usbutils dhcpcd git vim
wget openssh tmux xorriso wpa_supplicant libssh2.

Avance acumulado de la sesión: sealed 647→703 (+56), debt 109→53. La deuda C-base cayó 74→18, y de
esos 18 la mayoría son Rust CLI mal-clasificados como 'c' (amp/broot/delta/gitui/zellij…) + musl.
La deuda que queda es GUI (29, granja), Rust (5), kernel (4), go (5).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 12:33:05 -04:00
sergioandClaude Opus 4.8 748a0c7d29 estado: +14 C-base más selladas (deuda 101→85; C-base 74→50)
Segunda tanda de sistema-base en el laptop, todas C puras listas: libudev-zero mtdev libevdev npth
libusb libevent libassuan libksba socat less nano sed gawk doas. MIENTEN 0 en las link=static.

Avance acumulado de la sesión: sealed 647→671 (+24), debt 109→85. La deuda C-base bajó 74→50; la
GUI (29) sigue intacta para la granja, como manda el orden de ataque (glib/wayland/pixman ↑).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 12:08:04 -04:00