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:

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:

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

Variables de entorno nuevas

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)