Resumen
PR #72 (s82, 2026-05-24) cierra dos gaps que quedaban en el pipeline Sync Cascade tras los fixes anti-destructivos de s80:
| Bug | Componente | Síntoma | Severidad |
|---|---|---|---|
| #64 | bib_ingest.py → run_ingest() | reconcile_wiki_to_d1 no corría en TIER 3 → drift silencioso repo↔D1 | Alta (silencioso) |
| #65 residual | wiki.ts → wikiProposeMirrorUpdate | MAX_BODY=32000 insuficiente para onboardings (~42 KB) → Haiku proponía body truncado | Alta (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ón | Valor MAX_BODY | Contexto |
|---|---|---|
| Inicial | 8 000 chars | Default conservador |
| s80 (post-incidente PR #66+#67) | 32 000 chars | Fix tras incidente con docs 20-60 KB |
| s82 (este PR) | 120 000 chars | Fix 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_tokensoutput = 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
| Fecha | Evento |
|---|---|
| 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 Z | PR #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]]