Feature: Bump de límite lint (700→2000) + auto-alert en wiki_lint_bulk

Resumen

Incremento del límite de SELECT en wiki_lint_bulk de 700 a 2000 páginas y adición de auto-alert visual cuando se alcanza el límite. Responde al footgun documentado en s90: el cron lint con limit:200 hardcoded escondía 111 orphans porque solo veía las 200 páginas más viejas en la tabla.

Integrado en commit s90 (28-05-2026) tras revisión de observabilidad y detectar falta de cobertura en corpus creciente.

Contexto: el footgun

Problema original (s90 retrospectivo):

• Cron wiki-lint.yml ejecutaba wiki_lint_bulk con limit:200 hardcoded.
• Corpus de la wiki creció de ~300 a ~600 páginas en meses.
• Con limit:200, solo se escaneaban las 200 páginas con last_verified más viejo.
• Resultado: 111 orphans (páginas sin referencias) quedaban invisibles; no se ejecutaban acciones de lint sobre ellas.

Raíz: El límite es una heurística para evitar timeout en el SELECT pero no es transparente; el operador no sabía que existían páginas sin escanear.

Solución

A) Bump de límite

Parámetro limit en wiki_lint_bulk incrementado de 700 a 2000:

# .github/workflows/wiki-lint.yml (línea 69)
limit: 2000

Y en /opt/biblioteca-crons/wiki-lint.sh (sed in-place):

sed -i 's/"limit":700/"limit":2000/g' config.yml

Cobertura:

• Corpus actual: ~569 páginas (2026-05-28).
• 2000 cubre 3.5x el corpus actual → margen para ~24 meses de crecimiento a ritmo +30 páginas/semana.

B) Auto-alert: flag limit_reached

Cuando allPages.length >= limit, se activa el flag y se añade una advertencia visible en el summary del log de lint:

const limitReached = allPages.length >= limit;
const limitAlert = limitReached
  ? ` ⚠ LIMIT_REACHED=${limit} (corpus puede haber crecido — subir limit en wiki-lint.yml + /opt/biblioteca-crons/wiki-lint.sh)`
  : '';

// Se incluye en summary + artifacts del log

Ejemplo de salida cuando se alcanza el límite:

{
  "scanned": 2000,
  "limit_reached": true,
  "limit_used": 2000,
  "stale": [...],
  "...": "..."
}

Con en el summary visible:

Lint bulk: 2000 pages · ... applied(...) ⚠ LIMIT_REACHED=2000 (corpus puede haber crecido — subir limit en wiki-lint.yml + /opt/biblioteca-crons/wiki-lint.sh)

Cambios

Operación

El cron lint ejecuta cada noche (hora exacta TBD en infra); cuando limit_reached=true:

1. ✅ El lint sigue ejecutándose normalmente (cubre las 2000 más viejas).
2. 🔔 Se registra en bib_wiki_log (operation=‘lint’) con flag limit_reached: true.
3. 👁️ Operador revisa los logs y ve la advertencia.
4. ⬆️ Si es consistente por varias semanas, bump a 3000 (o arquitectura del SELECT).

Registros de cambios

Decisiones de diseño

• ¿Por qué 2000 y no 3000 o ilimitado?

  • 3000 daría 5x cobertura (muy holgado). 2000 es el punto donde: cobertura suficiente para 24 meses, pero aún forcing un próximo bump (forcing a la pregunta “¿sigue creciendo?”).
  • Ilimitado: riesgo de timeout en SELECT; preferimos límite visible + alerta.

• ¿Por qué el flag limit_reached en artifacts?

  • Permite queryar retroactivamente SELECT * FROM bib_wiki_log WHERE artifacts LIKE '%limit_reached%' o parsing JSON.
  • Dashboard futuro puede graficar “¿cuándo se alcanzó el límite?” como indicador de crecimiento.

• ¿Cadencia de review del flag?

  • Mensualmente: si limit_reached=true en >80% de las noches del mes, bump.
  • Trimestralmente: revisar de todas formas (independentemente del flag).

Véase también

• [[entity—biblioteca—tool—bib-pipeline-stats]]
• [[entity—biblioteca—tool—bib-ask-rejections]]
• [[entity—biblioteca—tool—wiki-lint-bulk]]
• [[concept—biblioteca—supercontexto]]
• [[concept—biblioteca—footgun]]