[Eslopes]

WASM-015 — Pruebas, herramientas para agentes y System KB para los tipos web
Estado: borrador. Depende de WASM-001, 004, 008 y 010. Reúne los requisitos de pruebas que citan las demás especificaciones para que el harness se construya una sola vez.

Requisitos

El harness

R1 — Module runner: instancia un módulo generado en un motor WebAssembly sin interfaz gráfica con un host simulado (la API del host de WASM-010 R12 implementada por la prueba). Introduce eventos y lee escrituras de propiedades, salida, errores y memoria. Determinista y suficientemente rápido para el subconjunto NIST (WASM-010 R16).
R2 — Browser runner: construye y sirve un paquete y lo maneja en un motor de navegador real sin interfaz gráfica (hacer clic, escribir, esperar, leer DOM y estilos calculados, imagen). Se utiliza en las comprobaciones indicadas por WASM-002 AC1–AC2, WASM-004 AC2–AC3 y AC6–AC7, WASM-006, WASM-007, WASM-009, WASM-011 y las pruebas de políticas de WASM-013. No puede exigir que el desarrollador instale un navegador para las pruebas comunes.
R3 — Backend runner: inicia el binario del backend en un puerto loopback con un emisor local de identidades de prueba (WASM-009 R12), conecta un cliente y ejercita llamadas (WASM-003, 005, 014), incluidos los escenarios de desfase de versiones de WASM-014 AC10.
Familias de pruebas

R4 — Todo control de clase A y B (WASM-004) tiene una prueba web de ida y vuelta de propiedades, como tests/controls/ en desktop. Se enumeran los 27 controles que las familias desktop todavía no cubren, con una decisión para cada uno: cubrir ahora o registrar como carencia.
R5 — Control de paridad ampliado a la web: un formulario de referencia con un control de cada clase se renderiza mediante el motor desktop y un navegador; se comparan la geometría y, donde el plan fije una tolerancia, el color. Solo se permiten las diferencias documentadas por WASM-004.
R6 — Registro de conformidad ampliado, al estilo NIST (dos cifras por módulo: compila; se ejecuta con 0 fallos), con una segunda columna para el módulo generado. NC, IF e IC son las primeras filas (WASM-010 R16). Una regresión se ejecuta con un comando.
R7 — Los archivos de referencia del generador cubren la salida web: COBOL generado para formularios web, descripción de interfaz, hoja de estilos, página anfitriona y CSP generada. Regeneración al estilo UPDATE_GOLDEN.
R8 — La línea de base de cobolt-bench incorpora las cifras de WASM-010 R15 y de la especificación de rendimiento: tamaño del módulo, arranque y una carga fija de aritmética y cadenas en el módulo y en el intérprete.
R8b — Pruebas de ciclo de vida, memoria y frontera de WASM-017 R20, ejecutadas para cada combinación de variante del módulo (multi-memory, single), variante del player (threaded, plain) y modo de ejecución (Worker, hilo principal). Cubren: carga (traza de red); liberación (abrir y cerrar formularios muchas veces, volviendo a la línea de base); memoria fija; aislamiento; procesamiento por lotes; cadenas; vistas después del crecimiento de memoria; base mínima y matriz de navegadores; cesión (un bucle largo mantiene los frames). Incluye el informe de tamaño de WASM-016 R13 y WASM-017 R16 para que una regresión en la huella de recursos haga fallar una prueba.
R9 — Cada prueba informa de resultados cuantificados y legibles (qué se ejercitó y cómo se comportó), no solo del número de pruebas superadas, como exige la regla de pruebas del proyecto.
Herramientas para agentes

R10 — Las herramientas MCP entienden los tipos de proyecto: create_project acepta un kind (WASM-001 R10); check informa del subconjunto portable y de los controles de clase D (WASM-002 R3, WASM-004 R5) en el formato form-control-event-line; regenerate y validate cubren los nuevos artefactos; build construye el paquete Web, el paquete Mobile y el binario Backend e informa de los tamaños y del resultado del análisis de secretos; list_files muestra las entradas nuevas.
R11 — render_form y run_form funcionan para formularios web con el mismo formato de respuesta que los formularios desktop (WASM-008 R9), y declaran qué motor produjo la imagen.
R12 — El servidor del IDE y rcrun mcp ofrecen el mismo comportamiento web. Una herramienta que no puede hacer algo en un tipo (compilar iOS fuera de macOS) lo indica y explica por qué.
R13 — APPLICATION_RULES del plugin incorpora las reglas de los tipos web: qué no puede contener un formulario web; que los secretos residen solo en el backend; que las llamadas remotas utilizan CALL … WITH WEBSOCKET LINKAGE; que un formulario web es adaptable y utiliza la apariencia Spatial. Se añaden habilidades para aplicaciones Web o Mobile y para Backend. El agente revisor pasa a comprobar estas reglas.
Conocimiento

R14 — System KB declara, en las tablas de documentación del compilador: la clase de cada control en la web (WASM-004 R12), los miembros exclusivos de la web, los built-ins utilizables en el navegador (WASM-010 R7), la frase CALL … WITH WEBSOCKET LINKAGE y su mapeo, los estilos de aplicación (WASM-011) y los controles Authentication y WebLink. chunked.data regenerado, con la prueba de actualización superada.
R15 — Los especialistas de Grace no proponen construcciones que el tipo rechaza: planner y pedantic reviewer leen el tipo del proyecto, y las reglas de política (no heurísticas de palabras) indican lo que puede utilizar cada tipo.
R16 — Los ejemplos distribuidos incluyen al menos una aplicación Web y un Backend, construidos y ejecutados por la suite. No contienen claves ni contraseñas (WASM-013 R7).
Objetivos: harness sin interfaz gráfica que ejecuta el módulo generado y el paquete construido, reproducible, en la suite y en CI; equivalentes web de las familias de pruebas actuales; herramientas MCP y plugin que entienden los proyectos web; System KB, Grace y reglas del plugin que conocen lo que existe en la web; ejemplos que también son pruebas.
Fuera del alcance: automatizar la ventana del propio IDE (nunca); probar los detalles internos de proveedores de identidad y navegadores; pruebas de carga y de larga duración de backends desplegados (propuestas en WASM-019).
Familias de pruebas actuales (§1): tests/controls/ (35 archivos frente a 62 tipos), el control de paridad engine_reference_form_parity_static_vs_faces (solo geometría), los archivos de referencia de codegen (crates/cobolt-codegen/tests/golden), el harness NIST CCVS85 con NIST/progress.json y la línea de base de cobolt-bench.

Cuestiones:

Q1 — Motor de navegador para los runners — abierto: Chromium o Firefox sin interfaz gráfica mediante WebDriver o DevTools, o un harness sobre la vista web de WASM-008. El harness no puede convertir un navegador en prerrequisito de cargo test.
Q2 — Motor WebAssembly del module runner — abierto: intérprete de Rust puro (pequeño, lento) o JIT (rápido, mayor). Remite a WASM-010 Q2.
Q3 — Dónde se guardan los datos de referencia y el registro web — abierto: ampliar NIST/progress.json o un registro paralelo.
Q4 — Tolerancia visual (R5) — abierto: solo geometría (económico) o píxeles (estricto, inestable entre motores). Decidir después de las mediciones.
Q5 — Especialista Grace que conozca la web (WebFormsDesigner) — recomendado: mantener tres especialistas (FormsDesigner, CodeGenerator, EventBinder) que lean el tipo. Alternativa: crear el nuevo.
Estado: borrador. Parte de System KB y de las reglas del plugin ya está implementada para los tipos de proyecto y Preview, según WASM-001 y WASM-008 (véase la sección 7).

WASM-016 — El player: motor de formularios precompilado para el navegador
Estado: borrador. Origen: decisión del operador (2026-10-19) sobre WASM-002 Q7 y WASM-010 Q10: dos .wasm. Depende de WASM-002 y WASM-010. Se encarga de la implementación de WASM-004, 005, 006, 007, 009, 011, 013 y 018.

Requisitos

El artefacto

R1 — El player es un módulo WebAssembly precompilado, con cargador, desarrollado en Rust + Leptos al construir el producto, distribuido con el IDE y copiado (nunca compilado) en cada paquete Web y Mobile. Build Web no exige una cadena de herramientas de Rust, el destino wasm32 ni un empaquetador en la máquina del desarrollador.
R2 — Paquete = player (variantes plain y threaded, R13c) + módulo de programa (uno por proyecto, multi-memory y single-memory) + página anfitriona, descripciones de los formularios, hoja de estilos y recursos. No se ejecuta nada más.
La descripción del formulario

R3 — Build escribe, para cada formulario, una descripción versionada y serializada (controles, propiedades, diseño y puntos de ruptura, eventos vinculados a handlers, bindings de datos, referencia a la hoja de estilos), derivada del .cfrm. El player dibuja cualquier formulario a partir de ella. La misma descripción alimenta Preview (WASM-008) y Build.
R4 — La descripción no contiene secretos ni código de programa; el código de los handlers reside en el módulo, referenciado por id.
Qué hace el player

R5 — Cada control de las clases A y B (WASM-004) se implementa una vez, con las propiedades, eventos y métodos del modelo, la tabla de propiedad → CSS (WASM-007 R1), CssClass, Style, la hoja de estilos del formulario y accesibilidad (WASM-004 R10). También implementa los controles Authentication (WASM-009) y WebLink (WASM-006).
R6 — El player ofrece en el navegador lo que ofrece el host de formularios desktop: propiedades de ventana y fondo, efectos de entrada y salida, eventos del ciclo de vida, despacho de eventos y cadencia de temporizadores y animaciones. Según lo definen las especificaciones 037, 038 y 042, o con una diferencia documentada.
R7 — Acción del usuario en un control: el player entrega el evento (id, control, parámetros) al módulo (WASM-010 R10) y, mientras el módulo se ejecuta, realiza lo que este solicita mediante la API del host: leer y escribir propiedades, llamar a métodos, escribir DISPLAY, proporcionar la hora y números aleatorios, realizar llamadas remotas.
R8 — Cuando el módulo se detiene en una espera (WASM-010 R9), el player realiza la espera (llamada remota, diálogo, temporizador) y reanuda con la respuesta. Los eventos de ese intervalo permanecen en una cola ordenada (WASM-005 R9).
R9 — El player es responsable de la conexión con el backend: abre el WebSocket, incorpora el bearer token (WASM-009 R5), realiza el framing y la correlación (WASM-003 R6, WASM-014), reconecta con espera progresiva, renueva el token y aplica los tiempos de espera. El módulo solo ve “envía este JSON, devuelve la respuesta” (WASM-005 R8). Solo se conecta a las direcciones configuradas.
R10 — El player implementa el enrutamiento y los dos estilos (WASM-011): shell, rutas e historial de la SPA; páginas, ventanas y mensajes super de los formularios standalone.
Coherencia y versiones

R11 — El player, el formato de la descripción del formulario y la API del host tienen cada uno una versión. Build copia el player que corresponde al compilador. El módulo se niega a iniciar con un player que no tenga la entrada de la API del host que necesita. Una discrepancia entre player y módulo es un error de compilación.
Construir y entregar

R12 — El player se construye mediante un paso de la compilación del producto (un ejemplo del workspace, como build_chunked_kb), con la salida incorporada al repositorio o generada en release (Q2) y una prueba de actualización. El IDE encuentra el player como encuentra sus otros recursos. El perfil de compilación que prioriza el tamaño, las herramientas con versiones fijadas y la regla contra wasm-pack corresponden a WASM-017 R16–R17.
R13 — Build informa del tamaño del player y de las partes bajo demanda (Q3). Los gráficos, mapas y Viewer se cargan en el primer uso para que un formulario sin ellos no asuma su coste. Los controles Canvas2D, Canvas3D y los objetos gráficos (WASM-018) son partes de ese tipo.
R13c — Dos variantes a partir de un único código fuente: plain (Rust estable, sin memoria compartida) y threaded (nightly fijado, std reconstruida, atomics, memoria compartida, wasm-bindgen-rayon; WASM-017 R16). Rayon en el trabajo paralelo (imagen, gráficos, ordenación y filtrado de DataGrid, física, rasterización de canvas), con el mismo resultado en la variante plain. La página anfitriona elige según crossOriginIsolated.
R13b — Todo objeto Rust expuesto a JavaScript mediante wasm-bindgen tiene liberación explícita, llamada por unmount() y durante el desmontaje. Los objetos expuestos son pocos y se enumeran. Un panic termina la instancia con un error legible y una acción de recarga. El player nunca entrega a JavaScript una vista de su memoria que sobreviva a una llamada.
Garantía

R14 — El player se mantiene igual al host de formularios desktop mediante mediciones: el formulario de referencia de WASM-004 R11 y las comprobaciones de ciclo de vida, efectos y orden de eventos se ejecutan en ambos. Las diferencias se documentan o se corrigen (la desviación de la especificación 042 es el fallo que esto previene).
R15 — El player cumple WASM-013: ninguna API que inserte HTML (Viewer construye nodos DOM, WASM-013 R5), demostrado mediante búsqueda en el código; ningún eval; CSP estricta; ninguna red aparte del backend y del propio paquete; ningún secreto en el player, las descripciones o la hoja de estilos.
R16 — Con Preview (WASM-008) abierto, el player acepta un módulo, una descripción de formulario o una hoja de estilos nuevos sin recargar, y Preview se actualiza in situ.
R17 — El proyecto Desktop no cambia; el host de formularios desktop sigue siendo el host de las aplicaciones desktop.
Objetivos: player precompilado único que dibuja cualquier formulario, sin Rust por proyecto; implementación única de todos los controles web y los comportamientos del host de formularios; descripción de formulario, API del host y terna de versiones definidas; el player es responsable de la conexión, por lo que el módulo no tiene red; distribuido con el IDE.
Fuera del alcance: código Leptos por proyecto y componentes escritos por el desarrollador; Custom { plugin_id } en la web en la v1; SSR; sustituir el canvas egui de Form Designer; biblioteca pública de componentes.
Estado del player (§1): el host de formularios desktop (cobolt-form-host) no es reutilizable en el navegador (depende de rfd, pollster y eframe). No existen Leptos, wasm-bindgen, web-sys ni trunk en el workspace. Precedente de recurso incorporado al repositorio con prueba de actualización: assets/knowledge/chunked.data.
Los textos fijos del player (cargando, error, volver a intentarlo) pertenecen a la página anfitriona (WASM-002 R15) y son traducibles por el desarrollador.
Criterios que añaden detalles: AC5 (con el backend detenido, el player reconecta con espera progresiva y el programa solo ve ON EXCEPTION para la llamada en curso); AC8 (un formulario sin gráficos, mapas o Viewer no descarga sus partes).

Cuestiones:

Q1 — Formato de la descripción del formulario — recomendado: JSON versionado, con binario compacto más adelante si el tamaño importa.
Q2 — Player incorporado al repositorio o construido en release — recomendado: incorporado al repositorio, con prueba de actualización (como chunked.data).
Q3 — Un archivo o partes bajo demanda — recomendado: partes desde el principio, debido a los controles de clase B.
Q4 — Cuánto del host de formularios llega al navegador en la v1 (efectos, estados y posiciones de ventana) — abierto: decidir por comportamiento en /plan; mantener, mapear o descartar.
Q5 — Extensibilidad (Custom, crates externos en la web) — abierto, fuera del alcance.
Q6 — Player en dos compilaciones del IDE — abierto: confirmar que la recompilación utiliza siempre el player actual y si un proyecto puede fijar un player antiguo.
Estado: borrador. Decisión pendiente del operador: el uso de Leptos en el player (PROG-44). Véase la sección 7.