Actualización semanal 6 de junio de 2026

Highlights

• WatDis refuerza la navegación de redes densas con vista general, dibujo por viewport y previews de pan/zoom más fluidos.

• En redes grandes, Diagnósticos deja de disparar QA automático por defecto y separa mejor Zoom de Open Props.

• watdis-next suma una política de scripts más estricta y deja mejores señales para validar el comportamiento del canvas en seguimientos posteriores.

Novedades (Por Categoria)

Interfaz y experiencia de usuario

• El canvas ahora combina una vista general con niveles de detalle adaptativos para no dibujar todo igual en cada zoom.
• Durante pan y zoom, la previsualización usa rutas más livianas y el viewport se actualiza de forma más atómica cuando termina el gesto.
• El resultado buscado es simple: que explorar una red grande se sienta menos pesado antes de entrar al análisis más profundo.

QA y diagnóstico

• En redes grandes, los checks quedan disponibles bajo demanda y antes de corridas hidráulicas, en vez de ejecutarse automáticamente durante importación o browsing.
• Los hallazgos de Diagnósticos ahora separan Zoom de Open Props: una acción navega; la otra abre propiedades sin mover el viewport.
• Las acciones solo de vista ya no contaminan el historial de undo, evitando costo extra al inspeccionar modelos grandes.

Rendimiento y observabilidad

• Se añadieron culling por viewport, coalescing por requestAnimationFrame y exposición local de stats del canvas para medir nodos visibles, enlaces visibles y tiempos de dibujo.
• La mejora publicada esta semana es trabajo real de respuesta y observabilidad, no un benchmark final de producción ya cerrado.

Seguridad y hardening

• watdis-next suma una CSP mínima que limita orígenes de scripts a fuentes permitidas y mantiene compatibilidad con el runtime actual.
• Es una mejora de endurecimiento, no una promesa de aislamiento absoluto: el runtime actual todavía requiere unsafe-eval.

Proximo

• Revalidar Barranquilla después del redeploy para confirmar el impacto real en browsing y tiempos percibidos.
• Perfilar hover y hit-testing solo si el modelo sigue pesado después de esta tanda de optimizaciones.
• Mantener el trabajo de solver y planificación interna fuera de los claims públicos hasta que haya cambios de runtime medidos.