KB vs Graph Fase 2 · Tripwires + Drift Check MCP handlers
KB vs Graph Fase 2 · Tripwires + Drift Check MCP handlers
Fase 2 de la iniciativa Knowledge Base vs Knowledge Graph + lifecycle + tripwires (ADR decision--20260514--knowledge-base-vs-graph). Introduce los mecanismos automáticos que mantienen la wiki sincronizada con el código fuente: el tripwire trigger y el drift check.
Contexto
La Fase 1 (no documentada en esta página) añadió las columnas kind y lifecycle a bib_wiki_pages y estableció el ADR de ciclo de vida KB vs Graph. La Fase 2 conecta ese modelo con el pipeline de ingest real:
- Cada vez que el Bibliotecario-Ingest procesa un commit mergeado, llama al tripwire para marcar páginas cuyas
sources[type=code]coincidan con los paths tocados. - Un cron futuro (Fase 3) invocará
bib_check_drift_for_docpor cada página marcada para que Haiku decida si la documentación ha quedado desfasada.
Cambios incluidos en PR#37
1. FrontMatter interface extendida (wiki.ts)
Añade kind?: 'knowledge_base' | 'knowledge_graph' y lifecycle?: string. wikiCreatePage persiste ambos campos en D1 con defaults kind='knowledge_base' / lifecycle=null.
2. callAnthropicHaiku — tokens desglosados
La función ahora devuelve { text, tokens, inputTokens, outputTokens }. Se añade haikuCostUsd(in, out) con pricing mid-2026 ($0.0008/1K input, $0.004/1K output) para trazabilidad de costes en bib_drift_checks.
3. Handler bib_mark_verification_pending (tripwire trigger)
Ver [[entity—biblioteca—handler—bib-mark-verification-pending]].
4. Handler bib_check_drift_for_doc (drift check)
Ver [[entity—biblioteca—handler—bib-check-drift-for-doc]].
5. trigger_tripwires() en bib_ingest.py
Nueva función Python que:
- Filtra paths excluidos (wiki
.md, scriptsbib_*, harness,public/supercontext/). - Llama a
bib_mark_verification_pendingvia MCP con los paths restantes. - Se ejecuta siempre antes del flujo Tier 1/2/3, independientemente de si el ingest decide saltar el commit.
- Es tolerante a fallos: si el MCP devuelve error, lo loguea sin abortar el ingest.
Invariantes
| Propiedad | Valor |
|---|---|
| Idempotencia | Sí — verification_pending=0 como precondición en UPDATE |
| Tolerancia a fallos | Tripwire no falla el ingest si MCP da error |
| D1 bind limit | Chunks de 90 slugs (límite 100 params D1) |
| Cobertura de repos | Heurística por prefijo: functions/ src/ migrations/ scripts/ → workspace; resto → CreaRack-Pro |
Lo que NO incluye esta fase
- Cron drift check (Fase 3): el handler
bib_check_drift_for_docexiste y es funcional, pero el workflow cron que lo invoca periódicamente se implementa en Fase 3. - Semantic contradiction check: diferido a Fase 5 (ya aparecía en
wikiLintCheck).
Véase también
- [[entity—biblioteca—handler—bib-mark-verification-pending]]
- [[entity—biblioteca—handler—bib-check-drift-for-doc]]
- [[decision—20260514—knowledge-base-vs-graph]]