sergio/takana

El §5 cerraba la vigilancia de los 625 tarballs con «hace falta un campo tipo `[source.upstream]`
con dónde mirar y qué patrón; es su propia unidad». Eso es cierto en general y **falso para el
grueso**, y la frase se quedó catorce días sin que nadie la midiera: **196 de los 625 son de
github.com** y esas URLs ya traen el repo y la versión escritos, así que el mismo `git ls-remote`
del §2.1 las cubre. 82 bajan una versión más vieja que la publicada.

Lo que sí queda sin decidir son las 429 restantes, y el enunciado cambia: **no piden una pista por
receta, piden un listado por host**, porque están concentradas (kde 108, gnome 70, gnu 32,
xorg/x.org 29, gitlab.freedesktop 26, kernel.org 18, qt.io 12). Siete patrones cubrirían ~287.

El bloque medido del 2026-09-23 se deja INTACTO: es el registro de lo que se midió ese día, y
reescribirlo borraría la prueba de que el diagnóstico cambió. La corrección va al lado, con su
propia medición y su fecha.

También entra la otra mitad de la lección, que es tan importante como la cobertura: la primera
versión de esa extensión era un **generador de ruido** (9 falsos de 91, medidos) y hubo que acotar
la comparación a la misma serie de tags, sesgando hacia el silencio y contando lo descartado.

Y el estado de cabecera, que decía «la primera pieza implementada»: ya son dos —la vigía, ahora
cableada al cron, y `bump-repo.py`, el aplicador atómico del §3.1 con la política del §3.2 metida
en el comando— y se añade el pendiente nuevo: cuándo re-pinear `recipes/takana.toml`, que pinea el
repo que la contiene.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

diff --git a/docs/33-versionado-y-relojes.md b/docs/33-versionado-y-relojes.md
index a0d1fa90..8e712afe 100644
--- a/docs/33-versionado-y-relojes.md
+++ b/docs/33-versionado-y-relojes.md
@@ -1,8 +1,15 @@
 # SDD 33 — Versionar takana: cómo se llama una versión, qué reloj mira qué, y qué se cambia solo
 
-> **Estado: PROPUESTA, con la primera pieza IMPLEMENTADA y medida** (2026-09-23):
-> `scripts/fuentes/upstream-vigia.py`. Lo demás está decidido y no construido, y se dice cuál es
-> cuál.
+> **Estado: PROPUESTA, con DOS piezas implementadas y medidas.**
+> — `scripts/fuentes/upstream-vigia.py` (2026-09-23), el reloj de río arriba. **Cableado al cron el
+>   2026-10-07** con puerta diaria: hasta ese día había corrido UNA vez a mano y su informe llevaba
+>   catorce días congelado, que es el modo de falla que §2.1 describe para los guardianes.
+>   Extendido el mismo día a 196 de los 625 tarballs (§5).
+> — `scripts/fuentes/bump-repo.py` (2026-10-07), el **aplicador atómico por repositorio** del §3.1,
+>   con la política del §3.2 metida EN EL COMANDO: con un repo de terceros se niega (rc=2) salvo
+>   `--third-party`. Dos bumps aplicados: tawasuyu (35 recetas, 35/35 selladas) y nuestro propio
+>   repo (5 recetas que estaban en **cinco commits distintos**).
+> El resto está decidido y no construido —§4, rearmar los medios por el CIERRE— y se dice cuál es cuál.
 
 ## 0. La pregunta
 
@@ -59,10 +66,33 @@ Medido el 2026-09-23, primera corrida completa:
 
 **Por qué sólo git, y por qué eso ya es la mitad.** `git ls-remote` funciona contra cualquier
 servidor sin API, sin token y sin clonar — es lo mismo que ya hace `takana pin`. Con eso se cubren
-las 660 que pinean `repo` + `commit`. Un tarball no tiene equivalente general: saber si hay una
-versión nueva pide una pista por receta (dónde mirar, con qué patrón), y eso es su propia unidad de
-trabajo. **Se cuentan y se dicen**, no se adivinan: 625 recetas fuera del radar es un dato, no un
-silencio.
+las 660 que pinean `repo` + `commit`. **Se cuentan y se dicen**, no se adivinan: 625 recetas fuera
+del radar es un dato, no un silencio.
+
+⚠ **Y lo que seguía era falso para el grueso. Corregido el 2026-10-07.** Decía: «un tarball no tiene
+equivalente general: saber si hay una versión nueva pide una pista por receta». Cierto en general,
+falso para la mayor parte — y nadie volvió a medirlo en catorce días:
+
+```
+625 recetas con tarball
+196 de github.com ⇒ la URL YA TRAE el repo y la versión  ⇒  el MISMO ls-remote las cubre
+ 82 bajan una versión más vieja que la que upstream publica
+429 siguen fuera, pero CONCENTRADAS en pocos hosts (no dispersas): ver §5
+```
+
+`.../archive/refs/tags/v1.2.3.tar.gz` y `.../releases/download/1.10/sway-1.10.tar.gz` llevan dentro
+todo lo que hacía falta. No se necesitaba API, ni token, ni campo nuevo: se necesitaba **leer la
+URL**. ⇒ *Una frase que cierra una línea de trabajo hay que volver a medirla: el límite puede haber
+sido del primer intento y no del problema.*
+
+⚠ **Y la primera versión de esa cobertura era un generador de ruido**, que es la otra mitad de la
+lección. Comparar contra el tag más nuevo del repo sin mirar su SERIE da basura en cuanto upstream
+publica varias — **9 falsos de 91, medidos**: `cronie` baja `cronie-1.7.2` y decía «hay v4.3»;
+`bash-completion` baja `2.18.0` y decía «hay 20060301-alt06». La comparación se acota al mismo
+prefijo no numérico y la misma cantidad de componentes, **sesgando hacia el silencio**, y lo
+descartado se cuenta y se dice (11 sin serie comparable, 4 que bajan por sha, 50 sin tags). Un
+guardián cuyos hallazgos son casi todos falsos no se apaga: se deja de leer, y entonces tampoco se
+ve el hallazgo verdadero.
 
 ⚠ **Sale 0 siempre.** Un guardián que falla porque upstream sacó una versión nueva grita todos los
 días y en una semana nadie lo mira ([[guardianes-el-ruido-los-mata]]).
@@ -115,8 +145,29 @@ salió.** Sin eso, la comparación de arriba no se puede hacer y el cron vuelve
 
 ## 5. Lo que este documento NO decide
 
-- **La pista por receta para los tarballs** (625). Hace falta un campo tipo `[source.upstream]` con
-  dónde mirar y qué patrón; es su propia unidad.
+- ~~**La pista por receta para los tarballs** (625)~~ → **la premisa era falsa para el grueso, y
+  196 ya están cubiertas** *(2026-10-07)*. Decía que «hace falta un campo tipo `[source.upstream]`
+  con dónde mirar y qué patrón». Cierto en general; falso para la mayor parte: **196 de los 625
+  tarballs son de `github.com`**, y en esas URLs el repo y la versión **ya están escritos**
+  (`.../archive/refs/tags/v1.2.3.tar.gz`, `.../releases/download/1.10/sway-1.10.tar.gz`), así que
+  el mismo `git ls-remote --tags` del §2.1 las cubre sin API, sin token y sin pista por receta.
+  Primera corrida: **82 bajan una versión más vieja que la publicada**. ⇒ *Una frase que cierra una
+  línea de trabajo hay que volver a medirla: el límite puede haber sido del primer intento y no del
+  problema.*
+
+  **Lo que SÍ queda sin decidir son las 429 restantes, y no piden una pista por receta: piden un
+  listado por host.** Están concentradas, no dispersas — `download.kde.org` 108,
+  `download.gnome.org` 70, `ftp.gnu.org` 32, `xorg.freedesktop.org`+`www.x.org` 29,
+  `gitlab.freedesktop.org` 26, `kernel.org` 18, `download.qt.io` 12, y 142 repartidas en otros 75
+  hosts. Siete patrones cubrirían ~287. La vigía las **nombra por host** en su informe en vez de
+  resumirlas: «429 sin mirar» se lee como silencio, «108 en download.kde.org» se lee como la
+  próxima tarea.
+
+- **Cuándo re-pinear `recipes/takana.toml`**, que pinea el repo que la contiene. El bump atómico del
+  2026-10-07 dejó las 5 recetas de nuestro repo en el mismo commit —estaban en **cinco distintos**—
+  pero esa receta vuelve a quedar por detrás en el commit siguiente, el del propio bump. Perseguir
+  «al día» no tiene sentido; lo que vale es que las cinco compartan commit. **Re-pinear es una
+  decisión de release, y no está tomada.**
 - **Si el nombre lleva mes o semana.** Depende de cada cuánto se publique de verdad, y eso todavía
   no se sabe porque hoy se publica a mano.
 - **Firmar lo publicado.** Los `.sha256` de al lado comprueban la descarga, no la procedencia. El