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
-
Búsqueda de targets: Consulta D1 por pages
status='active'conrelatedNULL, vacío o[], ordenadas porlast_verified DESC(up tolimit). -
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).
-
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)).
-
Escritura quirúrgica (solo si
dry_run=false):writeRelatedToPage()reemplaza SOLO la línearelated:del front-matter.- Refresca la sección
## Véase tambiéncon 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:
| Función | Propósito |
|---|---|
safeJsonArray() | Parseo defensivo de arrays JSON (returns [] en error) |
writeRelatedToPage() | Edición quirúrgica: actualiza related: + ## Véase también en .md |
wikiEnrichRelated() | Handler principal: loop, búsqueda de candidatos, llamada a Haiku, escritura condicional |
Consultas D1:
SELECT slug, title, type, tags ... WHERE status='active' AND related EMPTY(targets).- 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 (
.mdreescrito) → reconciliación → D1 (viafeature--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