Handler MCP: wiki_enrich_related

Propósito

Enriquecer el campo related[] (referencias semánticas a otras páginas wiki) de una o más páginas wiki usando candidatos basados en embeddings semánticos. Utiliza Vectorize (Workers AI) para buscar pages temáticamente relevantes.

Firma y entrada

async function wikiEnrichRelated(
  args: {
    limit?: number,           // máx páginas a procesar (defecto 10, cap 50)
    dry_run?: boolean,        // si true, solo reporta sin escribir (defecto true)
    where?: string,           // cláusula WHERE SQL para filtrar targets (defecto: 'status = "active"')
    actor?: string,           // quién dispara la pasada; por defecto 'agent-enrich' (usado en el log de coste)
  },
  db: D1Database,
  env: Env
): Promise<string>

Args:

• limit: número máximo de páginas wiki a procesar. Capped en 50.
• dry_run: si true (por defecto seguro), retorna sugerencias sin modificar D1 ni el repositorio. Si false, escribe related[] en D1 y pushea cambios al MD (via Git API).
• where: cláusula WHERE SQL para seleccionar páginas target. Defecto: status = 'active'. Ej: "type = 'feature_page'" para solo features.
• actor: identifica quién dispara la pasada (humano o agente). Se usa como actor de la fila que se deja en bib_wiki_log. Defecto 'agent-enrich'.

Dependencias del entorno (Env):

• ANTHROPIC_API_KEY: requerido para Haiku (selección final de candidatos + grounding).
• AI (Workers AI binding): requerido para embedTexts y searchChunks (Vectorize).
• D1Database: acceso a bib_wiki_pages y chunks de wiki (D1).
• GITHUB_TOKEN: si dry_run=false, para escribir al repo.

Lógica principal

Para cada página target (t en targets):

1. Embed y search:

   • Vectoriza el título (t.title) con embedTexts(env.AI, [t.title]).
   • Busca chunks wiki similares: searchChunks(env, vec, 18, { sourceType: 'doc' }).
   • Extrae slugs únicos del sourcePath de cada chunk (regex: /^(?:src\/content\/)?wiki\/(.+?)\.md$/).
   • Evita duplicar el slug de la propia página (seen Set).

2. Validación en DB:

   • Consulta bib_wiki_pages para obtener slug + title de candidatos válidos (status=‘active’).
   • Limita a MAX_CANDIDATES=25 primeros.

3. Selección final (Haiku):

   • Si hay candidatos, llama a Haiku con el título + candidatos.
   • Haiku elige 2-4 candidatos mejores (criterio: relevancia temática + complementariedad).
   • Retorna suggested: [{ slug, title }, ...].

4. Escritura (solo si dry_run=false):

   • Actualiza D1: línea related: en el YAML front-matter del MD.
   • Refresca sección ”## Véase también”.

Registro de coste (bib_wiki_log)

Desde el 10-09-2026 (commit b7bfcf74, #169 — hallazgo del verificador en Opus de la regeneración del Atlas, ficha ws3), cada pasada de wiki_enrich_related deja una fila en bib_wiki_log. Antes era la única tool de la wiki que gastaba IA (llamadas a Haiku) sin dejar rastro de coste, a diferencia de wiki_curator_review, bib_run_drift_check_batch o wiki_lint_contradictions, que sí lo hacían.

• Se acumulan input_tokens/output_tokens de todas las llamadas a Haiku de la pasada — una fila por pasada, no una fila por página procesada.
• operation: 'query' si dry_run=true, 'update' si dry_run=false.
• actor: args.actor si se pasa; si no, 'agent-enrich'.
• cost_usd: calculado con haikuCostUsd(totalInput, totalOutput) — también se añade a la respuesta JSON de la tool.
• Si el INSERT en bib_wiki_log falla, no rompe la pasada: se añade un resultado {slug: '(log)', error: 'wiki_log_error:...'} a la lista de results, pero processed/applied se devuelven igual.
• La fila solo se escribe si hubo al menos una llamada a Haiku (haikuCalls > 0); una pasada sin targets no deja fila.

Respuesta

{
  "processed": 5,
  "applied": 2,
  "dry_run": true,
  "cost_usd": 0.00034,
  "total_tokens": 1240,
  "results": [ ... ]
}

Véase también

• [[feature—biblioteca—candidatos-semanticos-vectorize]]
• [[entity—functions—service—archivo-core]]
• [[concept—infra—vectorize]]
• [[concept—biblioteca—embedding]]
• [[concept—saas—supercontext]]