sergio/takana

Ayer el §5 cerraba los 429 tarballs y anotaba una pista sin usar: los índices traen la FECHA de
cada entrada, y ordenar por fecha resolvería el caso `gtk+ 3.94`. Ya está hecho, así que la nota
pasa de pendiente a resuelto con su medición.

Pero lo que entra al documento no es el resultado, es el TROPIEZO: el primer intento de la regla
era demasiado estricto y produjo un falso negativo real —`glib 2.90`, serie nueva del 6-oct, quedaba
tapada porque la rama de mantenimiento `2.88` recibió un parche el 8-oct—. Una rama que sigue
recibiendo parches es normal; una abandonada lleva años quieta. Eso generaliza: **«más viejo» no
alcanza como señal de abandono, hace falta MUCHO más viejo**, y el umbral se elige lejos de los dos
bordes medidos (dos días / seis años) en vez de calibrarlo contra un caso.

Y el encuadre de lo que compra la fecha, que es lo que hace usable el montón: no es quitar 5 falsos
positivos, es poder decir en qué confiar — 230 hallazgos con fecha que los respalda y 30 sin ella,
separados, porque mezclarlos haría que los buenos se tiraran con los dudosos.

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 785fc293..7d98f9d9 100644
--- a/docs/33-versionado-y-relojes.md
+++ b/docs/33-versionado-y-relojes.md
@@ -77,6 +77,8 @@ falso para la mayor parte — y nadie volvió a medirlo en catorce días:
 2026-10-07:  196 de github cubiertas con el ls-remote que ya estaba · 429 fuera
 2026-10-09:  223 de forja (github+gitlab) · 402 por índice HTTP · 44 fuera
              625 tarballs → 581 contestados en 104 s con 236 peticiones
+             y con la FECHA del índice: 150 verificados · 230 indicios respaldados
+             · 30 sin fecha · 5 ramas abandonadas descartadas
 ```
 
 `.../archive/refs/tags/v1.2.3.tar.gz` y `.../releases/download/1.10/sway-1.10.tar.gz` llevan dentro
@@ -178,15 +180,32 @@ salió.** Sin eso, la comparación de arriba no se puede hacer y el cron vuelve
   tarball, donde la URL dice qué forma buscar; en el de `repo`+`commit` la estrechez es la
   protección y aflojarla cambiaría `al_dia` en 660 recetas que hoy se miden bien.
 
-- **Qué hacer con los 265 INDICIOS, que no son lo mismo que una versión nueva.** Un índice de
-  directorio contesta «¿hay un número mayor?», y eso no es «hay una release más nueva». El caso que
-  lo destapó: `gtk3` baja de `sources/gtk+/3.24/`, y ese directorio todavía guarda las series
-  `3.89`…`3.96` — las alfas de GTK4, de 2017. `3.94 > 3.24` es cierto y semánticamente falso, y
-  **ninguna regla numérica barata lo distingue** (94 es par, mismo major, y el directorio contiene
-  un tarball de verdad). Se informan aparte y con su propia palabra; convertirlos en decisiones es
-  trabajo humano. **La pista que queda sin usar:** los índices traen la FECHA de cada entrada, y
-  `3.24/` está tocado hace meses mientras `3.94/` lleva ocho años quieto — ordenar por fecha en vez
-  de por número resolvería justo este caso, y es su propia unidad de trabajo.
+- ~~**Qué hacer con los 265 INDICIOS**~~ → **resuelto el mismo día con la FECHA del índice, y la
+  pieza trae su propio falso negativo medido.** El problema era real: un índice contesta «¿hay un
+  número mayor?», que no es «hay una release más nueva». `gtk3` baja de `sources/gtk+/3.24/` y ese
+  directorio todavía guarda `3.89`…`3.96`, las alfas de GTK4; `3.94 > 3.24` es cierto y
+  semánticamente falso, y ninguna regla numérica lo distingue. **La fecha sí:**
+
+```
+sources/gtk+/   3.24/  2024-Jul-10      ← lo que usamos
+                3.94/  2018-Jun-26      ← seis años más viejo ⇒ rama muerta
+```
+
+  La regla es la que upstream no puede violar sin querer: *nadie vuelve a tocar una rama
+  abandonada*. Hay tres formatos de fecha en tres servidores y hay que cubrir los tres.
+
+  ⚠ **Y el primer intento era demasiado estricto, con un falso negativo que vale como advertencia
+  general:** descartaba el candidato en cuanto su fecha fuera anterior a la nuestra, y entonces
+  `glib 2.90` —serie nueva del 2026-Oct-06, con 2.90.0 y 2.90.1 dentro— quedaba tapada porque
+  `2.88` recibió el parche 2.88.4 **dos días después**. Una rama que sigue recibiendo parches es
+  normal; una abandonada lleva años quieta. El umbral de un año queda lejos de los dos bordes (dos
+  días / seis años), así que no está calibrado contra ningún caso concreto.
+
+  ⇒ Lo que esto compra no es quitar 5 falsos, es **poder decir en qué confiar**: de 260 hallazgos,
+  **230 con la fecha respaldándolos** y 30 sin fecha comprobable. Nunca se descarta por FALTA de
+  fecha — eso sería perder información real por no tener la corroboración — y los niveles van
+  separados en el resumen, porque mezclarlos haría que los 230 buenos se tiraran con los 30
+  dudosos.
 
 - **Los 44 que no contesta nadie**, con nombre: 8 de `files.pythonhosted.org` (rutas con hash ⇒
   pide la API de PyPI), 5 de `downloads.sourceforge.net` (descarga por redirección), 5 que pinean