CreaRack-SL

Incident s82 — Cierre de gaps Sync Cascade: reconcile TIER 3 + MAX_BODY onboardings

Resumen

PR #72 (s82, 2026-05-24) cierra dos gaps que quedaban en el pipeline Sync Cascade tras los fixes anti-destructivos de s80:

BugComponenteSíntomaSeveridad
#64bib_ingest.py → run_ingest()reconcile_wiki_to_d1 no corría en TIER 3 → drift silencioso repo↔D1Alta (silencioso)
#65 residualwiki.ts → wikiProposeMirrorUpdateMAX_BODY=32000 insuficiente para onboardings (~42 KB) → Haiku proponía body truncadoAlta (destructivo potencial)

Bug #64 — reconcile_wiki_to_d1 ausente en TIER 3

Causa raíz

run_ingest() en bib_ingest.py tiene tres caminos de ejecución según el tier del commit:

  • Pre-LLM skip → reconciliación ✅
  • Haiku skip → reconciliación ✅
  • TIER 3 (proceso profundo Sonnet) → reconciliación ausente ❌ (hasta este PR)

Un commit wiki clasificado como TIER 3 escribía los cambios de frontmatter (campos related, tags, mirrors) en el .md del repo pero no los propagaba a D1, causando drift silencioso entre el repositorio y la base de datos.

Fix aplicado

# Bug #64 (s82): reconciliación al final del camino TIER 3
recon = reconcile_wiki_to_d1(changed_files, trigger_ref, mcp_token)
if any(recon[k] for k in ("reconciled", "indexed_new", "skipped_not_in_d1", "failed")):
    log(
        f"[Reconcile] D1 sync (TIER 3): {recon['reconciled']} updated, "
        f"{recon['indexed_new']} newly indexed, "
        f"{recon['skipped_not_in_d1']} skipped, {recon['failed']} failed"
    )

Mismo patrón que ya usaban los dos skips. Añadido al final de run_ingest() antes del return 0.


Bug #65 residual — MAX_BODY insuficiente para onboardings

Historial de la constante

SesiónValor MAX_BODYContexto
Inicial8 000 charsDefault conservador
s80 (post-incidente PR #66+#67)32 000 charsFix tras incidente con docs 20-60 KB
s82 (este PR)120 000 charsFix para mirrors reales de Sync Cascade (~42 KB)

Causa raíz

Con MAX_BODY=32 000, Haiku 4.5 recibía los primeros 32 KB de un mirror de 42 KB. El safety-check de 0,5× no lo detectaba porque 32 000 / 42 000 = 76 % > 50 %. Haiku devolvía un proposed_body que omitía los últimos ~10 KB del documento.

Fix aplicado

const MAX_BODY = 120000;   // antes 32000 (s80) → antes aún 8000
const ABORT_BODY = 180000; // antes 50000
// max_tokens en llamada Anthropic: 24000 (antes 8000 s80)
  • Haiku 4.5 admite 200 K tokens de input: el body completo de cualquier doc del corpus cabe.
  • max_tokens output = 24 000 (~84 KB) evita truncado en la respuesta para mirrors de 42 KB.
  • El safety-check 0,5× se mantiene como última defensa.

Validación en vivo

Llamada real wiki_propose_mirror_update par profile-biz → profile-dev tras deploy:

  • should_propose: true
  • Body completo devuelto con cambio quirúrgico (no fragmento)
  • Coste: $0,005
  • Pipeline confirmado no destructivo para docs normales

Cambio adicional

src/content/wiki/workspace--perfiles--profile-dev.md: corregida referencia residual introducida en #70:

- Al terminar una sesión: commit con descripción clara + actualizar `NOTAS.md`
+ Al terminar una sesión: commit con descripción clara + actualizar `WORKLOG.md` (NOTAS.md fue retirado — la doc vive en la Wiki)

Timeline

FechaEvento
2026-05-22 (s80)Fix anti-destructivo inicial: MAX_BODY 8 000 → 32 000; safety-check 0,5× introducido
2026-05-24 (s82)Bug #64 detectado: reconcile TIER 3 ausente. Bug #65 residual: MAX_BODY=32 000 aún insuficiente
2026-05-24 08:48 ZPR #72 mergeado. Gaps cerrados. Pipeline Sync Cascade validado end-to-end

Estado

Resuelto — ambos gaps cerrados. Pipeline Sync Cascade (Bloque 5) operativo con reconciliación completa en todos los tiers y límites de body correctos para el corpus real.

Véase también

  • [[feature—biblioteca—sync-cascade]]
  • [[entity—biblioteca—handler—wiki-propose-mirror-update]]
  • [[entity—biblioteca—script—bib-ingest]]
  • [[incident—20260522—sync-cascade-destructivo-s80]]