vigía: provee.py — qué publica de verdad el catálogo, y desde dónde se alcanza

El triaje de apps falló TRES veces, cada vez por una pregunta distinta y cada vez la
anterior daba verde:

  1. ¿existe la receta en el disco?       — el método original
  2. ¿la ALCANZA el consumidor?           — wf-recorder grababa mudo: sus backends de
     audio existían, pero en colas hermanas, que una receta del corpus no ve
  3. ¿la VARIANTE sellada publica la ABI? — imv: mesa existe, es alcanzable, y aun así
     no sirve; las tres variantes no publican libGL.so ni gl.pc

Las tres son la misma equivocación disfrazada: preguntarle al CATÁLOGO lo que sólo
sabe el ARTEFACTO. Este vigía indexa los .pc y las librerías (.a y .so, porque
find_library no mira pkg-config) de todos los artefactos sellados y contesta quién
publica cada nombre y desde qué colas es pedible, aplicando sibling-first: lo del
corpus lo ve todo el mundo, lo de una incoming-* sólo esa cola.

Es el hermano de BUILD de vigia-sonames.py, que cubre la mitad de RUNTIME. La de build
se paga antes: es la que decide si el configure de una receta nueva va a morir.

Tres decisiones de forma que salieron de usarlo y verlo fallar:
- el nombre se busca flojo: gl, gl.pc, libGL.so.1 y librsvg (que tiene que encontrar
  librsvg-2.0.pc) dan lo mismo. El nombre que trae un APKBUILD casi nunca lleva la
  versión, y comparar a lo bruto daba falsos «nadie lo publica».
- agrupado por receta, no por fichero: mesa publica cuatro ficheros de EGL y repetirla
  cuatro veces convierte el informe en ruido justo cuando hay que leerlo rápido.
- --desde <cola> sale con código 1 si algo no se alcanza ⇒ sirve de puerta en cron/CI.

Verificado contra los dos casos conocidos: --desde corpus con lo que swayimg pide da
0, y con lo que imv pedía (gl, opengl) da 1. Barrido completo ~9 s con caché por
ArtifactHash en work/.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XB2iEmxeLZgzqNfhWChrLo

docs/plan-apps-usuario-final.md

@@ -163,6 +163,19 @@ día y subió a **5.5**. La cadena quedó verificada de punta a punta: `swayimg
 ni sólo «¿la alcanza?», sino **«¿la variante sellada publica el `.pc` y el `.so` que el consumidor
 pide?»**. Se contesta mirando el artefacto, no el catálogo.
 
+Y como acá cada punto ciego se convierte en un guardián, esa pregunta ya tiene instrumento:
+**`scripts/provee.py`**, que indexa los `.pc` y las librerías de TODOS los artefactos sellados y
+contesta quién publica cada nombre y desde qué colas se alcanza. Los tres defectos del método caen
+con un solo comando:
+
+```sh
+scripts/provee.py --desde corpus gl opengl     # ✗ nadie lo publica  → exit 1  (el caso imv)
+scripts/provee.py exiv2 librsvg                # ✓ existen, alcanzables SÓLO desde su cola
+```
+
+Es el hermano de build de `vigia-sonames.py`, que cubre la mitad de runtime. **El triaje de la
+próxima app empieza por acá**, no por contar `makedepends` contra `recipes/*.toml`.
+
 ## Los dos veredictos que corrigen al ADR
 
 ### Firefox NO es montón A
@@ -219,6 +232,11 @@ de mentir.
 
 ## Reproducir la medición
 
+⚠ **Ya no se reproduce así.** Lo que sigue describe el método ORIGINAL, que es el que falló las
+tres veces documentadas arriba; se deja escrito para que se entienda de dónde salieron los números
+de la tabla. El triaje de una app nueva se hace hoy cruzando sus `makedepends` contra
+`scripts/provee.py --desde corpus`, que pregunta por el artefacto y no por el catálogo.
+
 `/tmp/.../triaje-apps.py` fue un script de una sola vez; si hace falta repetirlo, lo que hace es:
 bajar el APKBUILD de cada candidata, extraer `makedepends`/`depends`, quitarles el sufijo `-dev`, y
 cruzar contra `recipes/*.toml` + `recipes/incoming-*/*.toml`, separando una lista fija de nombres