Propósito

Agente automático que enriquece backlinks en páginas wiki con related vacío. Busca candidatos por tags o type, valida con Haiku 2 que los slugs existan, y propone 2-4 backlinks genuinamente relacionados. Implementa s195 del Supercontexto — sustituto del blueprint Queues + Batch API, usando cron nocturno paginado sin infraestructura nueva.

Firma del Tool MCP

wiki_enrich_related(
  limit?: number,        // Máximo de pages a procesar (default 10, max 50)
  dry_run?: boolean      // Si false, escribe al .md + D1 (default TRUE)
)

Flujo de enriquecimiento

1. Búsqueda de targets: Consulta D1 por pages status='active' con related NULL, vacío o [], ordenadas por last_verified DESC (up to limit).

2. Generación de candidatos: Por cada target page:

   • Si tiene tags: busca pages activas con alguno de sus tags (máx 25 candidatos).
   • Si no: busca pages activas del mismo type (máx 25 candidatos).

3. Validación con Haiku 2:

   • Prompt al modelo: página actual + lista de candidatos (slug + título).
   • Sistema: pide 2-4 slugs que existan en la lista (grounding, nada inventado).
   • Respuesta esperada: {"related": ["slug1", "slug2", ...]}
   • Parseo y validación: filtra respuesta contra Set(candidatos.map(c => c.slug)).

4. Escritura quirúrgica (solo si dry_run=false):

   • writeRelatedToPage() reemplaza SOLO la línea related: del front-matter.
   • Refresca la sección ## Véase también con wikilinks Obsidian [[slug]].
   • Actualiza D1 tabla bib_wiki_pages.
   • Retorna SHA del commit de repo.

Operación segura por defecto

• dry_run=true (default): Solo reporta sugerencias sin tocar repo ni D1.
• Límite bajo: Máx 50 pages/invocación para respetar budget de subrequests de CF Workers.
• Grounding: Valida cada slug contra candidatos existentes — zero hallucinations.

Arquitectura

Helpers principales:

Consultas D1:

1. SELECT slug, title, type, tags ... WHERE status='active' AND related EMPTY (targets).
2. Para cada target: SELECT slug, title WHERE status='active' AND (tags LIKE ? OR type=?) (candidatos).

Respuesta

JSON estructurado:

{
  "processed": 5,
  "applied": 2,
  "dry_run": true,
  "total_tokens": 1240,
  "results": [
    {
      "slug": "entity--core--model--organization",
      "suggested": ["entity--core--model--tenant", "entity--core--service--organization-hierarchy"],
      "applied": true,
      "commit_sha": "abc123def..."
    },
    {
      "slug": "concept--saas--multi-tenancy",
      "suggested": [],
      "reason": "no candidates"
    }
  ]
}

Uso típico (cron nocturno)

// Configurado en OPS para ejecutar nightly
await handleWiki(db, {
  action: 'wiki_enrich_related',
  limit: 15,          // 15 pages/noche
  dry_run: false      // Aplicar cambios
}, env);

Primero se ejecuta con dry_run=true para validar resultados; tras confirmación manual, se activa dry_run=false.

Impacto arquitectónico

• Antes: Blueprint CF Queues + Anthropic Batch API (enfrequency overhead, 50% discount complexity).
• Ahora: Cron nocturno paginado (sin infra nueva, simple, budget-friendly).
• Fuente de verdad: repo (.md reescrito) → reconciliación → D1 (via feature--supercontext--reconcile-d1-repo).

Véase también

• [[entity—biblioteca—tool—wiki-lint-contradictions]] — tool hermana para detectar contradicciones
• [[entity—biblioteca—tool—bib-pipeline-stats]] — observabilidad del pipeline del Bibliotecario
• [[feature—supercontext—enrichment-agent-blueprint]] — implementación anterior (superseded)
• [[concept—biblioteca—arquitectura-supercontexto]] — contexto general de la Biblioteca
• [[concept—workspace—supercontexto-05-crons]] — otros automatismos nocturnos del Supercontexto
• [[feature—supercontext—reconcile-d1-repo]] — reconciliación repo ↔ D1
• [[concept—workspace—supercontexto-02-bibliotecario]] — el Bibliotecario como subsistema