Incident: PRs destructivos en mirrors wiki por MAX_BODY insuficiente (s80, 22-05-2026)
Incident: PRs destructivos en mirrors wiki por MAX_BODY insuficiente
Estado: Resuelto (cerrado en s82, 24-05-2026) Severidad: Alta — datos borrados en mirrors wiki de producción vía PRs automáticos Sesiones afectadas: s80 (descubierto), s82 (hardening final)
Resumen
wikiProposeMirrorUpdate (handler CF Workers, wiki.ts) usaba MAX_BODY=8000 chars para truncar el cuerpo del mirror antes de enviarlo a Haiku. Los mirrors reales de Sync Cascade (onboardings, team-processes) pesan entre 20 KB y 60 KB. Al ver solo los primeros 8 KB, Haiku interpretaba ese fragmento como el documento completo y devolvía un proposed_body que contenía únicamente esos ~8 KB → los PRs generados automáticamente borraban el 80-90% del contenido de cada mirror.
Los PRs #66 y #67 materializaron este bug: +20 / -600 LOC en mirrors de onboarding.
Cronología
| Fecha | Evento |
|---|---|
| ~2026-05-22 (s80) | Detectado en revisión de PR #66 y #67: mirrors con pérdida masiva de contenido |
| s80 | Primera mitigación: MAX_BODY 8 000 → 32 000, ABORT_BODY introducido a 50 000, max_tokens output 8 000 |
| 2026-05-24 (s82) | Gap residual detectado: docs reales (~42 KB) seguían superando 32 000. Safety-check 0.5× los dejaba pasar (32/42 = 76%) |
| s82 | Fix definitivo: MAX_BODY 32 000 → 120 000, ABORT_BODY 50 000 → 180 000, max_tokens 8 000 → 24 000 |
| s82 | Validación en vivo par profile-biz → profile-dev: body completo, cambio quirúrgico, should_propose=true, $0.005 |
Causa raíz
MAX_BODY=8000 (y después 32000) demasiado bajo para el corpus real de mirrors. El modelo (Haiku) no tenía visibilidad del documento completo y producía output que parecía válido (estructura correcta, sin errores) pero era solo un fragmento.
El safety-check de 0.5× (proposed_body.length < mirror_body.length × 0.5) actuaba como última defensa, pero fallaba cuando el recorte superaba el 50 % del body referenciado (el body truncado, no el real):
- Body real del mirror: 42 KB
- Body que veía Haiku: 32 KB (MAX_BODY)
proposed_bodydevuelto: ~32 KB → ratio 32/42 = 76 % → pasaba el check
Medidas correctivas aplicadas
MAX_BODY= 120 000 — cubre cualquier documento del corpus actual (máx ~42 KB conocido). Haiku 4.5 admite 200 K tokens de input.ABORT_BODY= 180 000 — umbral de abort para documentos anómalos; por encima se escala a revisión manual sin propuesta.max_tokensoutput = 24 000 (≈ 84 KB) — evita que la respuesta se trunque al devolver bodies de 42 KB.- Safety-check 0.5× — mantenido como invariante final. Ahora opera sobre el body real (no truncado).
Lecciones aprendidas
- Los umbrales de longitud en handlers LLM deben calibrarse contra los percentiles P95/P99 del corpus real, no contra estimaciones teóricas.
- Un safety-check de ratio solo es efectivo si el denominador es el tamaño real del documento, no el tamaño del prompt enviado al modelo.
- La validación en vivo (par real, coste medido) es necesaria para confirmar que el fix no introduce regresiones.
Archivos afectados
functions/api/mcp/handlers/wiki.ts— funciónwikiProposeMirrorUpdate
Véase también
- [[feature—biblioteca—sync-cascade]]