Construyendo en público. Esto es lo nuevo.

La ruta anterior pasaba el output del LLM por cinco capas determinísticas — normalización, plan semántico, documento de autoría, compilador y validador — cada una con sus propios nombres de campos. Un detalle tan sutil como que el modelo dijera "connectorId" mientras una capa intermedia esperaba "ropeId" hacía que un resorte se renderizara desconectado de su anclaje al techo. Acumulamos varios bugs de ese estilo. La capa intermedia existía porque originalmente los LLMs eran más débiles y emitían descripciones parciales que requerían inferencia. Con los modelos actuales y un spec bien diseñado, el LLM puede emitir la estructura final directamente — el mismo patrón que ya usaba la página de funciones cartesianas. El resultado es un pipeline que se entiende leyendo dos archivos en lugar de cinco, donde los bugs se ven a la primera, y donde añadir comportamientos nuevos (como las reglas de posicionamiento para resortes y cuerdas, o el anclaje arbitrario en los tres lados del plano inclinado) toca un solo punto en lugar de coordinar cinco.

La IA generalista de entrada agregaba una capa de "adivinanza" que fallaba sutilmente: una "trayectoria parabólica" solicitada desde el dashboard a veces se enrutaba a math2D y se dibujaba como parábola algebraica en lugar de un tiro parabólico físico; un "diagrama de cuerpo libre" pedido desde el editor de math2D intentaba reescribirse como gráfica. El usuario sentía que el AI Assistant a veces "no entendía". El problema no era el modelo sino la falta de contexto explícito de dominio. Resolverlo desde la UX es honesto: para hacer mecánica se entra a Física, para graficar se entra a Funciones — y la IA recibe ese contexto desde el primer prompt. Como subproducto se eliminó toda una capa de heurísticas de clasificación de dominio que era fuente recurrente de bugs, y el dashboard quedó más limpio: tres tarjetas con un ícono y un click, sin un input de texto al frente que invitaba a escribir prompts ambiguos.

Una clase manipula objetos: el bloque se mueve, el plano cambia de ángulo, la masa se ajusta. Antes, las etiquetas eran estáticas y los números quedaban desactualizados al instante. Ahora cada etiqueta es una expresión que se reevalúa cada render — al rotar el plano, la fórmula que dice "el ángulo es {{plano.profile.angleDeg}}°" se actualiza sola. El buscador resuelve el problema de descubribilidad: el docente no necesita conocer el JSON interno para saber qué propiedades existen.

Hasta ahora no había forma simple de dibujar un sistema de ejes locales en una escena de mecánica — útil para mostrar un frame de referencia rotado, etiquetar componentes de una fuerza o dar contexto geométrico a un diagrama. Es la primitiva foundational sobre la que se construirán las próximas mejoras: anclaje a otros objetos con orientación reactiva (los ejes rotan junto al plano inclinado cuando cambia el ángulo, o siguen la tangente de una trayectoria parabólica) y descomposición automática de vectores cercanos al origen del sistema.

El FBD original era todo o nada: o se mostraban todas las fuerzas, o ninguna. Para enseñar es necesario poder destacar una fuerza específica, atenuar las que no estamos analizando ahora, o esconder la fricción para mostrar el caso ideal. El estilo editable per fuerza también permite personalizar diagramas para presentaciones — pintar una fuerza más larga, mover su rótulo si se superpone con otro, cambiar el tipo de cabeza para diferenciar visualmente fuerzas de contacto vs. a distancia.

Antes solo se podía representar planos inclinados con el ángulo recto a la derecha — para problemas con bloques deslizando hacia la izquierda había que rotar el diagrama entero. Ahora un solo checkbox alterna la orientación; la física, el FBD y los anclajes block-on-surface se compensan automáticamente.

El usuario en una clase de geometría no quiere "armar una curva con 2 puntos para hacer una recta" — quiere una recta. Y necesita que sus vértices se peguen a otros objetos para que el diagrama no se rompa al editar. Reorganizamos el panel de propiedades en secciones (Geometría / Estilo / Nodos) y reemplazamos los dropdowns separados de markers por una grilla visual de presets, estilo PowerPoint.

El TextLabel original era una primitiva pensada para etiquetas cortas, pero los docentes mezclan prosa y fórmulas constantemente — frases como "la energía cinética es $E_k = \frac{1}{2}mv^2$" son cotidianas en una clase. Reescribimos el render de texto con math: ahora el container es un único bloque HTML embebido en el SVG (foreignObject), lo que permite a KaTeX alinearse al baseline correcto y respetar el spacing entre tokens. También agregamos un área de selección generosa alrededor del texto para que el clic directo lo capture sin fricción.

Al enseñar coordenadas, valores de funciones o intersecciones, las "guías" hacia los ejes son el estándar visual del libro de texto. Antes había que dibujarlas a mano como segmentos. Ahora son una propiedad declarativa del punto y se actualizan con él.

A diferencia de herramientas como PhET donde cada simulación es un módulo aislado, las zonas de simulación de QuickFigen conviven con anotaciones, fórmulas y otros diagramas en el mismo lienzo. La fórmula que ve el alumno (x(t) = A·cos(ωt)) es la misma que estudia en clase.

Antes, marcar una intersección era congelar coordenadas estáticas: cualquier edit de la curva dejaba el punto desfasado. Con el resolver de bisección y el campo attachedTo, los puntos quedan declarativos — basta con declarar "intersección de f y g" y el render se encarga del resto, igual que GeoGebra.

El parser determinista anterior tropezaba con frases ambiguas y rompía el contexto entre prompts. Pasamos todo a Gemini con el spec de CartesianPlotParams + reglas explícitas de semántica (above/below/between, smart points, x_range del viewport). Resultado: prompts encadenables sin perder la escena.