Supercontexto Fase 4 · Query con cierre (auto-archivado + curator)

Supercontexto Fase 4 · Query con cierre

Qué es

La Fase 4 del Supercontexto cierra el ciclo de conocimiento en CreaRack Pro: cada llamada a bib_ask que produzca una respuesta rica intenta archivarse automáticamente como concept_page en la wiki Supercontexto, pasando un filtro de calidad Haiku antes de escribir. Adicionalmente, incorpora un Curator automático (cron diario + skill interactiva) que revisa los drafts acumulados y decide promote / delete / keep-draft.

El objetivo es que el conocimiento generado en consultas ad-hoc no se pierda: si alguien pregunta “¿cómo funciona el sistema de billing?”, la respuesta meritoria queda guardada sin acción manual.

Componentes introducidos

1. Auto-archivado en `bib_ask` (`archivo.ts`)

Tras sintetizar la respuesta, handleAsk evalúa un pre-filtro barato (sin LLM) antes de invocar Haiku:

Condición	Umbral
Longitud de respuesta	≥ 500 chars
Número de fuentes	≥ 2
Palabras en la pregunta	≥ 4
`ANTHROPIC_API_KEY` configurada	requerida

Si pasa el pre-filtro, se llama a wikiArchiveAnswer (exportada desde wiki.ts). El resultado se añade al JSON de respuesta en el campo archive: { attempted, archived, slug?, reason? }, de modo que el caller puede inspeccionar qué ocurrió sin bloquear.

Fallo silencioso: cualquier error en el archivado no tumba bib_ask. La respuesta al usuario siempre se entrega.

2. `wiki_archive_answer` (tool MCP)

Archiva una respuesta bib_ask como concept_page status:draft.

Flujo interno:

pregunta + respuesta + fuentes
        ↓
  Haiku triage gate  ←  skip_triage=true omite esto
  (archive: true|false)
        ↓ (si archive=true)
  slug derivation  ← concept--<area>--<topic>
        ↓
  idempotency check (SELECT slug from D1)
        ↓
  render front-matter + markdown
        ↓
  ghPutFile  →  D1 INSERT  →  bib_wiki_log

Idempotencia: si el slug ya existe en D1, devuelve { archived: false, skipped_reason: "duplicate_slug" } sin error.

Parámetros clave:

question / answer — requeridos
area — se usa para el prefijo del slug (concept--<area>--…)
suggested_slug / suggested_title — override manual
skip_triage — true para uso desde la skill /bib-archive-last-answer (confirmación humana ya obtenida)
actor — quién archiva; default agent-query-closure

3. `wiki_curator_review` (tool MCP)

Revisa concept_pages en status:draft más antiguas que max_age_days (default: 2) con Haiku y emite veredictos:

Veredicto	Acción en `dry_run=false`
`promote`	`UPDATE status='active'` en D1
`delete`	`DELETE` fila de D1 (el `.md` queda en repo como audit trail)
`keep-draft`	Sin cambios

En dry_run=true (default) solo genera el reporte sin escribir nada. El cron GHA (wiki-curator.yml) invoca en dry_run=true diariamente; se aplica manualmente desde la skill /wiki-review-drafts.

4. Cron GitHub Actions (`.github/workflows/wiki-curator.yml`)

Ejecución diaria a 05:00 UTC (07:00 Madrid en verano).
dry_run=true por defecto — solo reporta.
Disparo manual (workflow_dispatch) con inputs apply, max_age_days, limit.
Guarda el reporte JSON como artifact (retención 30 días).
Requiere secreto MCP_TOKEN en el repositorio.

5. Skills de Claude

Skill	Propósito
`/bib-archive-last-answer`	Override manual: archiva la última respuesta `bib_ask` de la conversación con confirmación humana
`/wiki-promote <slug>`	Promueve un draft a `active` vía `wiki_update_page`
`/wiki-delete <slug>`	Archiva (→ `status:archived`) un draft; confirma antes
`/wiki-review-drafts`	Presentación interactiva del reporte del Curator y opción de aplicar

Variables de entorno nuevas

Variable	Descripción
`ANTHROPIC_API_KEY`	Requerida para triage Haiku y Curator. Sin ella, `wiki_archive_answer` devuelve `skipped_reason: "ANTHROPIC_API_KEY not configured"`
`CURATOR_CRON_TOKEN`	Token para el cron GHA (añadido a `functions/types.ts`)

Flujo completo end-to-end

Usuario/agente → bib_ask("¿cómo funciona X?")
                    ↓
              synthesizeAnswer (Gemini)
                    ↓
         pre-filter (500 chars, 2 fuentes, 4 palabras)
                    ↓ pasa
         wikiArchiveAnswer
           → Haiku triage → ¿archive: true?
                    ↓ sí
           → ghPutFile + D1 INSERT (status: draft)
                    ↓
         bib_ask responde con archive.slug en el JSON
                    ↓
         (al día siguiente) wiki-curator.yml cron
           → wiki_curator_review (dry_run=true)
           → reporte artifact
                    ↓
         Edu/Dani revisan con /wiki-review-drafts
           → aplican promote / delete

Comportamiento del triage Haiku

El prompt del triage instruye a Haiku a no archivar si:

Pregunta trivial (<10 palabras, conversacional, saludo)
Respuesta <200 chars
Respuesta dice “no encontré”, “no existe”, “no hay información”
Respuesta genérica sin datos específicos
Pregunta sobre estado efímero (“¿qué pasó ayer?”)

Y sí archivar si:

Pregunta técnica concreta (patrón, decisión, arquitectura, cómo-funciona-X)
Respuesta con 2+ fuentes concretas
Respuesta con síntesis no-trivial (>500 chars con especificidad)

En caso de duda, el prompt instruye archive: false (preferimos wiki frugal sobre wiki contaminada).

Limitaciones conocidas (v1)

wiki_curator_review aplica todos los veredictos o ninguno — no hay exclusión granular de slugs individuales.
wiki_delete real (borrado de fila + .md) no implementado como tool; se hace vía wiki_archive_page → status:archived + SQL manual si se desea.
El campo area en el auto-archivado se toma de args.app o args.source_type del bib_ask; si no vienen, cae a general.
El .md de páginas borradas por el Curator queda en el repo como audit trail (no hay git rm automático).

Véase también

[[entity—mcp—tool—wiki-archive-answer]]
[[entity—mcp—tool—wiki-curator-review]]
[[feature—supercontext—fase-6-metricas-utility]] — Fase 6 · Métricas + Utility Score (cierre del roadmap)