Grounding gate + triage reforzado en el archivero (PR1/4 hardening escritas)

Contexto

El archivero de bib_ask (en functions/api/mcp/handlers/archivo.ts) captura respuestas de síntesis como draft concept_pages para que el Curator las promocione a active. Sin embargo, se detectó un problema real: el modelo de síntesis alucinaba referencias a rutas de código que no existían (ej.: signage/services/deployment.py). Estos drafts sucios se acumulaban en la cola de Curator, contaminando la wiki con referencias falsas (violando Regla 13: sin alucinaciones en fuentes).

Síntomas observados:

• Drafts citando archivos inexistentes.
• Meta-preguntas (“¿existe una página sobre X?”) archivadas como knowledge reutilizable (son búsquedas, no síntesis).
• Respuestas parciales o con lagunas que el Curator no podía promover.

Decisión

Introducir 3 capas de validación en el archivero (orden ascendente de costo/inteligencia):

Capa 0: Pre-filtro barato anti meta-pregunta (regex, archivo.ts)

Patrones como:

• ¿existe/hay una página/doc sobre X?
• ¿qué slugs/páginas existen sobre X?
• ¿hay documentación de Y?

Se rechazan antes de tocar Haiku: son búsquedas de navegación, no síntesis. La query archive=true y la respuesta corta gatillan archiveOutcome.reason = 'pre-filter:meta-question'. Ahorro: una llamada Haiku per pregunta meta.

Capa 1: Grounding gate LLM-free (groundingCheck(), wiki.ts)

Antes de invocar triage Haiku, extraemos todas las rutas de código multi-segmento que la respuesta cita (regex en answer):

/\b([a-z0-9_]+\/[a-z0-9_./\-]+\.(?:py|ts|tsx|js|mjs|go|rs|java|sql))\b/gi

Ejecutamos 1 sola query D1 contra bib_nodes:

SELECT DISTINCT file_path FROM bib_nodes 
WHERE file_path IS NOT NULL 
  AND (LOWER(file_path) LIKE ? OR LOWER(file_path) LIKE ? OR ...)

Regla de rechazo: si la respuesta cita rutas y <50% resuelven, no se archiva (skipped_reason: grounding:unresolved_code_refs). Una ruta inventada tumba 1/1.

Comportamiento fail-open: si D1 falla, pasamos la respuesta (retorna ok=true, cited=cited.length) — el triage Haiku sigue siendo la barrera principal.

Respuestas puramente conceptuales (sin rutas) pasan siempre: cited=0 → ok=true.

Capa 2: Triage Haiku reforzado (wikiArchiveAnswer())

El prompt Haiku ahora rechaza explícitamente:

• Meta-preguntas sobre la propia wiki/docs.
• Respuestas con lagunas/incertidumbre (“no encontré”, “no hay información”, “no se menciona”).
• Respuestas que dejan PARTE de la pregunta sin responder.

Criterios positivos: pregunta técnica concreta + 2+ fuentes + síntesis completa (>500 chars).

Directiva: “Duda → archive:false. Preferimos frugal (wiki limpia > wiki grande).”

Justificación

Conservador: solo hace el archivero MÁS selectivo. Nunca archiva de menos algo que hoy pasaría bien; únicamente rechaza lo que:

1. Es obvio ruido (meta-pregunta).
2. Cita código inexistente (alucinación detectada).
3. Falla triage Haiku (ya existente, solo reforzado).

Costo/beneficio:

• Capa 0 (regex): O(1), puro string. Evita 1 llamada Haiku per meta-pregunta (~10-15% según logs).
• Capa 1 (grounding): O(1) query D1, ~50-100ms. Atrapa alucinaciones antes de gastar el triage. Fail-open garantiza que errores de DB no polutan la wiki.
• Capa 2 (Haiku): existente, solo más estricto. No añade latencia, refina el criterio.

Regla 13 (sin alucinaciones): el grounding gate hace imposible capturar una respuesta que cite rutas falsas. Si pasa ambas capas, las referencias de código son verificables.

Serie PR1/4: hardening de escribas

Esta es PR1/4 de un plan multi-sesión:

• PR1 (esta): grounding gate + triage reforzado (validación en origen).
• PR2: sync frontmatter ↔ D1 (coherencia de metadatos).
• PR3: de-dup de nodos + reconcile (eliminar duplicados viejos).
• PR4: enrichment agent (CF Queues, enriquecimiento async de fuentes).

Notas

Page aislada (temporal): el Bibliotecario (archivero, triage, curator) aún no tiene documentación de arquitectura en la wiki. Esta decision page los cita implícitamente. Cuando se documenten esas entidades (concept—biblioteca—sistema-escribas, runbook—biblioteca—triage-curator), actualizar los enlaces aquí.

Véase también

• [[feature—biblioteca—hardening-archivero-grounding]]
• [[decision—20260529—plan-hardening-post-master-hito-a]]