[Compilador] Web y Mobile

[Eslopes]

Comparto la especificación que se utilizará para implementar la versión 2.0 de PowerRustCOBOL AI para que puedan hacer sus comentarios. El momento de incorporar funcionalidades es ahora, ya que estoy congelando los requisitos.

Tendremos nuevos componentes:
RAD para aplicaciones Web (WebASM 3.0)
RAD para aplicaciones Mobile (Android/iOS)
Backend para aplicaciones (frontend web/mobile)
Compatibilidad con Co-Pilot, Open Codex, Cursor y OpenCodex (diversas opciones de Codex, además de Anthropic Claude Code).
El IDE seguirá siendo el mismo, pero incorporará funcionalidades para cada tipo de proyecto, así como para el backend.

La ventana de creación de nuevos proyectos se ampliará para crear proyectos Web, Mobile y Desktop (el tipo actual).


Lista completa de funcionalidades:

Lista de funcionalidades previstas — serie WASM (2.x.x)
Fecha: 2026-10-20
Fuente: specs/WASM-* de la rama features-2x (worktree .claude/worktrees/features-2x, HEAD c19bcee5), además de WASM-INDEX.md, WASM-PLAN.md, WASM-ABI-v1.md, WASM-PROGRESS.md y WASM-PARITY.md.

1. Cifras
Elemento Cantidad
Especificaciones escritas (WASM-001 a WASM-018) 18
Requisitos R (EARS) sumados en las 18 especificaciones 300
Especificaciones propuestas, sin archivo (WASM-019 a WASM-035) 17
Decisiones D1 a D19 (WASM-INDEX §3) 19
Elementos de WASM-PLAN.md 85
Elementos de WASM-ABI-v1.md 152
Elementos de WASM-PROGRESS.md 86 (2 de ellos son referencias)
Discrepancias de WASM-PARITY.md 10
Requisitos R por especificación:

Especificación R Especificación R
WASM-001 18 WASM-010 18
WASM-002 20 WASM-011 15
WASM-003 23 WASM-012 14
WASM-004 12 WASM-013 17 (incluye R15b)
WASM-005 18 (incluye R5b) WASM-014 17
WASM-006 15 WASM-015 17 (incluye R8b)
WASM-007 14 WASM-016 19 (incluye R13b, R13c)
WASM-008 10 WASM-017 20
WASM-009 13 (incluye R8b) WASM-018 20
2. Índice temático
Para encontrar una funcionalidad por tema. Los detalles se encuentran en la sección 3.

Tema Especificaciones
Tipos de proyecto, selector New Project, árbol del IDE, manifiesto 001
Build Web y Mobile, página anfitriona, subconjunto portable, análisis de secretos 002
Backend (binario, WebSocket, JWT, límites, logs, estructura inicial) 003, 014
Reutilización del catálogo de controles, clases A a E 004
CALL … WITH WEBSOCKET LINKAGE, mapeo JSON, controles de datos remotos 005
Control WebLink 006
CSS3, CssClass, Style, hoja de estilos del formulario 007
Preview en una vista web 008
Control Authentication, proveedores de identidad, reCAPTCHA 009
Generador WebAssembly (disposición de datos, aritmética, flujo, API del host, suspensión) 010
Navegación SPA y standalone, rutas, super, pila móvil 011
Shell móvil Tauri 2 (Android, iOS, firma, permisos, funcionalidades del dispositivo) 012
Seguridad (modelo de amenazas, CSP, XSS, CSRF, cadena de suministro, logs) 013
Contrato del backend (versiones, errores, idempotencia, streams, archivos) 014
Pruebas, herramientas MCP, plugin, System KB, Grace, ejemplos 015
Player precompilado, descripción del formulario, reconexión, versiones 016
Arquitectura del módulo (uno por proyecto, regiones, multi-memory, hilos, frontera JS) 017
Canvas2D, Canvas3D, ImageBuffer, Plot, Scene3D, Physics2D, Physics3D 018
Contratos de bajo nivel (imports, exports, procesamiento por lotes, manifiesto, verbos COBOL: WASM-ABI-v1
Orden de trabajo, crates, riesgos, definición de terminado WASM-PLAN
Discrepancias entre el generador y el intérprete WASM-PARITY
3. Inventario por especificación
Convenciones: R es un requisito de la especificación. Q es una cuestión abierta; cuando crea o selecciona una funcionalidad, se incluye su estado (decidido, abierto o recomendado). Fuera del alcance recoge los objetivos excluidos, y Estado indica lo que la propia especificación o el plan registra sobre la implementación.

WASM-001 — Tipos de proyecto web y móvil, selector New Project y entradas del IDE
Estado de la especificación: borrador, necesita /clarify. No depende de nada y es un prerrequisito de las demás.

Requisitos

R1 — Diálogo New Project con la lista de plantillas a la izquierda y, a la derecha, Project Properties y Template-Specific Options de la plantilla seleccionada, como en la maqueta. Cambiar de plantilla modifica el título del diálogo y las opciones.
R2 — La lista de plantillas es un conjunto de datos, no código de dibujo: cada plantilla es un descriptor (id, nombre, plataformas, project kind, opciones con valores predeterminados, si se puede crear). Añadir una plantilla no modifica el código del diálogo.
R3 — Para todas las plantillas, el diálogo recopila project name, version, main/entry file, project location, description, UI style/theme y default language/locale. Los valores se guardan en el manifiesto y en [ide] y [forms].
R4 — Cada plantilla tiene sus propias opciones, y las opciones que no se aplican no aparecen. Ejemplos: Desktop tiene window style y UI framework; Mobile tiene default orientation y minimum OS version; High DPI y GPU acceleration solo existen en Desktop; Web y Mobile tienen application style (SPA o standalone, WASM-011 R1).
R5 — Mientras no existan las funcionalidades de una plantilla, la entrada aparece marcada como no disponible y Create queda deshabilitado. Se pueden crear en la versión 2.0: Desktop, Web (WebAssembly), Android (Cellphone), Android (Tablet), iPhone y iPad. Los demás no están disponibles.
R6 — Create crea las carpetas y los archivos iniciales del tipo y abre el proyecto. En Web y Mobile también crea la estructura inicial del backend (WASM-003 R22), salvo que el desarrollador desmarque la opción (Q5).
R7 — Opcional: Recent Projects y Create from Template…. Ninguno de los dos es necesario para crear un proyecto.
R8 — El project kind (desktop, web, mobile) se guarda en el manifiesto y se vuelve a cargar con el proyecto. En Mobile también se guardan la plataforma y la device class. Un manifiesto sin kind se carga como desktop.
R9 — El IDE, el lector de manifiestos del compilador y el lector de manifiestos de la CLI coinciden en los campos nuevos. project_upgrade actualiza los manifiestos antiguos sin perder ningún campo.
R10 — La herramienta MCP create_project acepta el tipo y sus opciones. El IDE y la herramienta producen archivos idénticos con las mismas entradas, y la prueba de identidad byte a byte cubre los tipos nuevos.
R11 — Con un proyecto desktop abierto: el árbol muestra exactamente las entradas actuales.
R12 — Con un proyecto web abierto: el árbol muestra WebForms y Backend en lugar de Forms. Proyecto móvil: MobileForms y Backend. Se mantienen Indexed Files, SQL Connections, Common Code, Generated, External Crates, Assets y Documentation (Q1).
R13 — Cada entrada nueva se comporta como Forms: [+] crea un elemento de ese tipo, hay una carpeta en disco, un icono, una etiqueta en los seis idiomas y un lugar en la desambiguación de Grace, en el recorrido guiado y en el listado del agent kit.
R14 — Con un proyecto web o móvil abierto, la caja de herramientas ofrece solo los controles de ese tipo (WASM-004 R5). Run, Build y Preview de la barra de herramientas hacen lo que definen WASM-002 y WASM-008.
R15 — El IDE sigue siendo una única aplicación: sin un nuevo ejecutable, sin un nuevo modo de ventana y sin una nueva licencia.
R16 — Toda cadena del diálogo y de las entradas nuevas es un campo Tr con seis idiomas, incluidos los nombres y descripciones de las plantillas, las etiquetas de las opciones y las notas de no disponibilidad.
R17 — El diálogo tiene un tamaño explícito y no se redimensiona por sí solo. Un único tirador controla ese tamaño.
R18 — Los proyectos que ya están en disco se abren como antes. Ningún archivo se reescribe por el mero hecho de abrirlo.
Objetivos: tipo guardado en el manifiesto y respetado por todo el IDE (desktop, web, mobile); Backend no es un tipo, es la carpeta backend/ de todo proyecto Web o Mobile (operador, 2026-10-20); diálogo guiado por datos; resultado idéntico en el IDE, en rcrun y en MCP.

Fuera del alcance: compilación y ejecución web/móvil (WASM-002, WASM-008); el backend en sí (WASM-003); el catálogo de controles (WASM-004); destinos watch (Android Smartwatch, Apple Watch) y las plantillas Agentic AI Chatbot (Web) y UserControl (Web), que aparecen como no disponibles; cambiar el tipo después de la creación (Q7); marketplace de plantillas.

Maqueta del operador (fija el diseño y los campos, no el texto): diálogo New Desktop Project; lista con All Templates, Desktop (macOS, Windows, Linux), Agentic AI Chatbot (tres SO y Web), Web (WebAssembly), UserControl (Desktop y Web), Android (Cellphone y Tablet), Android (Smartwatch), iPhone, iPad, Apple SmartWatch y Recent Projects; pestañas Project Properties y Template-Specific Options; pie con Create from Template…, Recent Projects, Cancel y Create. Observación: R5 indica que solo se pueden crear las seis entradas de Q3, por lo que Chatbot (desktop) y UserControl (Desktop) tampoco están disponibles.

Cuestiones:

Q1 — Entradas del árbol por tipo — recomendado: Web = WebForms + Backend; Mobile = MobileForms + Backend; Desktop = Forms. Alternativa: mostrar las tres y deshabilitar las que no correspondan.
Q2 — Formato de archivo — recomendado: los formularios web y móviles siguen siendo .cfrm, diferenciados por la carpeta. Alternativa: una extensión nueva.
Q3 — Plantillas no disponibles y conjunto que se puede crear en la versión 2.0 — decidido (operador, 2026-10-19): Web + Android + iOS, sin watch, con la lista de R5.
Q4 — “Target platform” de Desktop — recomendado: mostrar el host, deshabilitado, hasta que exista compilación cruzada.
Q5 — ¿Se crea siempre la estructura inicial del backend? — recomendado: se crea de forma predeterminada, con opción de desmarcarla.
Q6 — Recent Projects y Create from Template… — abierto: si Recent Projects ya existe en otro lugar, y si Create from Template… consiste en copiar un proyecto guardado o en la misma lista de la columna izquierda.
Q7 — ¿Tipo inmutable? — recomendado: fijo en la versión 2.0; conversión en una especificación posterior.
Q8 — Nombres de carpetas — recomendado: webforms/, mobileforms/, backend/.
Estado (plan): registrado como implementado en la rama worktree-agent-a97ba65c65571c2df, posteriormente fusionado (PROGRESS PROG-81, 2.0.20). Modelo en cobolt-compiler/src/project_kind.rs; creación en cobolt-project-tools (create::plan, utilizado por el IDE y por la herramienta); diálogo en cobolt-ide/src/panels/new_project.rs; [desktop] se guarda, pero todavía no tiene efecto en la ejecución. Sin terminar: filtro de la caja de herramientas por tipo (R14, a la espera de WASM-004); la estructura inicial del backend solo crea HEALTH (R6); Target platform de Desktop muestra el host y no permite elegir (Q4).

WASM-002 — Destino WebAssembly (Leptos y Tauri 2) y página anfitriona
Estado: borrador. La ejecución quedó decidida (operador, 2026-10-19): el compilador genera WebAssembly directamente (WASM-010), sin intérprete ni runtime en el navegador.

Requisitos

R1 — Build de un proyecto Web produce un paquete estático en dist (las especificaciones 100/101 rigen la carpeta y la caché): index.html del host; el módulo de programa generado, uno para todo el proyecto, en variantes multi-memory y single-memory (WASM-010, WASM-017 R1 y R9); el player precompilado (WASM-016), plain y threaded, copiado y nunca compilado; el cargador JS; las descripciones de los formularios; la hoja de estilos (WASM-007); los recursos. Nombres con hash del contenido. En standalone, cada formulario tiene una página de entrada.
R2 — Build de un proyecto Mobile produce un paquete Android y/o un paquete iOS que envuelven el mismo frontend en un shell Tauri 2 (WASM-012).
R3 — Check o Build de un proyecto Web/Mobile valida el COBOL frente al subconjunto portable. Cada construcción que no se ejecuta en el navegador genera un error en su línea, indicando la construcción y la alternativa. Mientras haya errores, no se produce ningún paquete. No portables: cualquier organización de archivos (incluidos indexed y redb), procesos secundarios, hilos del SO, sockets nativos, SQL, EXEC RUST y secretos incrustados. El generador se encarga del rechazo (WASM-010 R8).
R4 — Para cada construcción del subconjunto, el programa se comporta como en desktop: mismos resultados, mismos desenlaces de ON SIZE ERROR y ON EXCEPTION, mismo orden de eventos. Todas las diferencias se enumeran en un único lugar y se mide la igualdad (WASM-010 R16).
R5 — La interfaz de usuario utiliza DOM con CSS3, no <canvas> (funcionan la selección de texto, el zoom, la accesibilidad y la búsqueda en la página). Excepción: los controles de dibujo de clase B (gráficos, mapas, indicadores) pueden utilizar SVG o canvas dentro de su propio elemento.
R6 — Cadena de herramientas ausente: el IDE identifica la herramienta, indica si puede instalarla y solo instala lo que sea seguro, con consentimiento (rustup target add sí; Xcode y Android SDK no). Build Web no necesita la cadena de herramientas de Rust. Build Mobile necesita Tauri 2 CLI, Android SDK/NDK, Xcode y la cadena de herramientas de Rust (un shell por aplicación).
R7 — El paquete no contiene ningún secreto (clave, token, contraseña, cadena de conexión, secreto de cliente). Build analiza los archivos, formularios y hojas de estilos, y falla indicando el archivo y el patrón.
R8 — Build informa del tamaño de cada parte (módulo, cargador, hoja de estilos, recursos).
R9 — Un proyecto Desktop se compila como antes. No cambia nada en bin/, eframe ni en el host triple.
R10 — Opcional, modo ventana: la página hace que la aplicación ocupe todo el viewport (incluido el viewport dinámico del teléfono), sin barras de desplazamiento propias, y recalcula el diseño cuando cambia la ventana.
R11 — Opcional, modo dentro de un diseño existente: la página monta la aplicación en un elemento elegido por el host (atributo o selector), la dimensiona según ese elemento y recalcula el diseño cuando el elemento cambia de tamaño. Los puntos de ruptura de los formularios se evalúan según el ancho del elemento.
R12 — Opcional, modo integrado: el CSS de la página no se propaga a la aplicación ni el de la aplicación al exterior. El host puede pasar valores del tema mediante propiedades CSS personalizadas.
R13 — Superficie JS para el host, pequeña y documentada: mount, unmount; parámetros iniciales (locale, theme, backend address); eventos de salida (ready, error, navigated, signed in/out). No ofrece ningún medio para evaluar scripts arbitrarios.
R14 — La aplicación se ejecuta bajo CSP con 'wasm-unsafe-eval' y sin 'unsafe-eval'. Build imprime la política necesaria (script, style, font, image y connect).
R15 — Durante la carga, la página muestra el progreso. Si no hay WebAssembly o falla la carga, muestra un mensaje legible y un botón para volver a intentarlo; nunca una página en blanco.
R16 — Cada módulo de programa es autocontenido (WASM-010 R1–R2) e importa solo la API del host. El paquete no tiene intérprete, AST ni runtime.
R17 — La página anfitriona admite los dos estilos de WASM-011: SPA (una página de entrada y un router) y standalone (una página de entrada por formulario). El modo integrado admite SPA; la compatibilidad con standalone se decide en WASM-011.
R18 — Build declara una base mínima de funcionalidades WebAssembly y una matriz de navegadores (Chrome y Edge, Firefox, Safari, vista web de iOS, Android WebView). El cargador comprueba el navegador frente a esa base y muestra el mensaje de R15 si no la cumple. Módulo multi-memory de forma predeterminada y single-memory para iOS y matrices con Safari. Player threaded y plain. La base mínima es el módulo single-memory con el player plain.
R19 — El cargador obtiene el módulo mediante fetch e instanciación en streaming; integración ES-module solo mediante detección de funcionalidades (WASM-017 R3). Obtiene las partes pesadas del player en el primer uso. Crea la región de datos de cada formulario al crearlo y la libera al destruirlo (WASM-017 R2–R5). Selecciona la variante del módulo, la del player y el modo de ejecución (Worker o hilo principal) mediante comprobaciones.
R20 — Hilos solo cuando la página tiene aislamiento entre orígenes, y la aplicación funciona sin ellos. Build genera, para cada host estático documentado y para el servidor standalone del IDE, las cabeceras Cross-Origin-Opener-Policy: same-origin y Cross-Origin-Embedder-Policy (require-corp o credentialless), e imprime las implicaciones. Puede ofrecer un shim de service worker que establece las cabeceras (desactivado de forma predeterminada). En el modo integrado, la aplicación solo está aislada si la página anfitriona también lo está.
Objetivos: Build Web como paquete estático; Build Mobile como paquete Android e iOS; mismo comportamiento para lo que permite el subconjunto; comprobación del subconjunto en Check y Build, por línea; página anfitriona con modo ventana y modo integrado y una superficie JS pequeña; detección de la cadena de herramientas que refleje la situación real.

Fuera del alcance: runtime, intérprete y redb, disco o hilos en el navegador (el backend los conserva); SSR, PWA y funcionamiento sin conexión; alojamiento o despliegue; depurador web dentro del IDE; modificar la compilación desktop; el backend (WASM-003).

Cuestiones:

Q1 — Modelo de ejecución — decidido (operador, 2026-10-19): generador directo, sin intérprete ni runtime en el navegador.
Q2 — Empaquetador y framework — recomendado: Leptos con renderizado del lado del cliente y trunk. Alternativa: cargo-leptos.
Q3 — ¿Tauri 2 también para Desktop? — recomendado: no, Desktop sigue con egui en la versión 2.0.
Q4 — EXEC RUST en un proyecto web — decidido por el modelo: rechazado; más adelante se permitirá solo mediante el backend o una especificación de crates externos.
Q5 — Presupuesto de tamaño y tiempo de arranque — abierto: se definirá en /clarify, después de medir la fase A de WASM-010.
Q6 — JavaScript de la página anfitriona — recomendado: escrito a mano y entregado como archivo fijo. Alternativa: generado.
Q7 — El player — decidido (operador, 2026-10-19): dos .wasm, un player Leptos precompilado y el módulo COBOL. Coste aceptado: sin código Leptos por proyecto, sin controles Custom en la web en la v1.
Estado: borrador. Elementos de ejecución en WASM-010, WASM-016 y WASM-017.

WASM-003 — Proyecto Backend y canal seguro frontend–backend
Estado: borrador. Depende de WASM-001. Es un prerrequisito de WASM-005 y WASM-009.

Requisitos

Proyecto y compilación

R1 — El Backend (la carpeta backend/ de un proyecto Web o Mobile) almacena programas COBOL, copybooks, definiciones de archivos indexados, conexiones SQL y una lista de programas exportados. Solo estos son accesibles de forma remota, cualquiera que sea el nombre del programa.
R2 — Build del Backend produce un ejecutable autocontenido por plataforma host (macOS, Windows, Linux), con runtime, programas y servidor WebSocket, ampliando la compilación de binario único.
R3 — Los programas se ejecutan en el runtime nativo actual: intérprete, std::fs, hilos, todos los motores de archivos indexados, incluido redb, con archivos, indexed, SQL y HTTP, además de WebSocket, validación de JWT y el mapeo JSON de WASM-005. El backend no se compila mediante el generador de WebAssembly.
R4 — Al compilar, el backend guarda una descripción de la interfaz de cada programa exportado (nombre, grupos de parámetros, grupo RETURNING, roles requeridos) que el proyecto frontend importa (WASM-005 R7).
Canal

R5 — Canal WebSocket sobre TLS (wss). ws sin cifrar solo para direcciones loopback durante la ejecución de desarrollo.
R6 — Cada solicitud tiene un id, el nombre del programa exportado y un payload; cada respuesta tiene el mismo id y el resultado o un error con su clase (WASM-005 R10). Se permiten solicitudes simultáneas y respuestas fuera de orden.
R7 — Caída de conexión: se avisa al llamador (la llamada falla). Nada se pierde silenciosamente y nada se ejecuta dos veces por una reconexión, salvo los programas declarados seguros para repetir (Q4).
R8 — Keep-alive periódico, cierre de conexiones inactivas y reconexión con espera progresiva en el cliente.
Autenticación y autorización

R9 — Se exige un Bearer JWT válido antes de ejecutar cualquier programa exportado, excepto los declarados public (un conjunto pequeño: los programas de inicio de sesión de WASM-009 y una comprobación de estado).
R10 — Validación de la firma con las claves publicadas por el emisor. Lista de algoritmos permitidos (nunca none). Comprueba issuer, audience, expiry y not-before con una tolerancia limitada al desfase de reloj. Acepta solo tokens de acceso, no tokens de identidad.
R11 — El token nunca aparece en la URL, la cadena de consulta ni los logs. El mecanismo para entregarlo por WebSocket se decidirá en /plan.
R12 — El programa lee las claims validadas (subject, roles, tenant) mediante el built-in inline COBOL::"…", de solo lectura. Un programa exportado puede declarar los roles requeridos, y el backend rechaza los demás antes de que el programa comience.
R13 — Si el token caduca con la conexión abierta, la siguiente solicitud recibe authentication expired, y el frontend lo renueva (WASM-009 R5) y repite la solicitud.
Refuerzo de seguridad

R14 — Comprobación del Origin del WebSocket frente a una lista configurada de orígenes permitidos (contra el secuestro de WebSocket entre sitios).
R15 — Todo payload se valida frente a la disposición de datos del programa de destino (nombres, tipos, longitudes, límites de tabla) antes de ejecutarlo. Se rechazan los campos desconocidos, los tipos incorrectos o los valores demasiado largos, sin truncamiento silencioso.
R16 — Tamaño máximo de frame, tiempo de espera por llamada, límite de solicitudes por conexión y por usuario, y límite de llamadas concurrentes. Configurables, con valores predeterminados seguros.
R17 — Todos los secretos (contraseñas de bases de datos, claves API, secretos de cliente, claves de firma) permanecen en la configuración del backend o en el almacén de secretos del SO. Nunca en un formulario, copybook o archivo del frontend.
Concurrencia y estado

R18 — El estado del runtime de una llamada está aislado del de otro llamador. Q2 decide si WORKING-STORAGE es nuevo en cada llamada.
R19 — Cuando más de un cliente utiliza los mismos datos indexados o SQL, se aplican las semánticas de bloqueo entre conexiones, no solo dentro de una unidad de ejecución. La carencia de bloqueo entre procesos es un prerrequisito y se considera una corrección según la decisión de 2026-09-14, en 1.x.x y portada a 2.x.x.
Operación

[Eslopes]

R20 — Iniciar, detener y supervisar el backend desde el IDE, con logs en el panel Output. El mismo binario se comporta igual fuera del IDE.
R21 — Logs estructurados (call id, program, caller subject, duration, outcome), nunca con tokens, contraseñas o campos sensibles. Responde a una sonda de estado.
R22 — Todo proyecto Web o Mobile nuevo se crea con una estructura inicial de Backend que contiene los programas de autenticación de WASM-009 (WASM-001 R6).
R23 — El frontend solo se conecta a las direcciones de backend configuradas para él, y la compilación imprime el connect-src que esto implica (WASM-002 R14).
Objetivos: Backend como carpeta de todo proyecto web o móvil, con programas exportados y binario desktop; WSS con un servidor que solo atiende programas exportados; autenticación por llamada con JWT y autorización por rol; canal seguro de forma predeterminada; ciclo de desarrollo desde el IDE.

Fuera del alcance: despliegue en la nube, contenedores, escalado (propuestos en WASM-019); flujos de proveedores de identidad (WASM-009); sintaxis y mapeo JSON (WASM-005); API REST pública, GraphQL o server push; multi-tenant.

Cuestiones:

Q1 — Dónde se declara el backend — decidido (operador, 2026-10-20): carpeta backend/ dentro del proyecto, no un proyecto separado.
Q2 — Estado — recomendado: WORKING-STORAGE nuevo en cada llamada, con la sesión en un archivo o una base de datos. Alternativa: una instancia por conexión.
Q3 — Endpoints HTTPS además del WebSocket (cookie de renovación, estado, redirección del proveedor) — abierto, “probablemente sí”.
Q4 — Idempotencia — recomendado: ningún programa es seguro para repetir de forma predeterminada.
Q5 — Token de desarrollo (JWT local para probar sin proveedor) — abierto, requiere una decisión: ¿solo durante la ejecución de desarrollo, nunca en release?
Q6 — Empaquetado — recomendado: un binario por host en la versión 2.0.
Q7 — TLS — recomendado: terminación en el binario o en un proxy inverso; el binario rechaza ws que no sea loopback en ambos casos.
Estado: borrador. El backend todavía no se ha fusionado (PROGRESS PROG-79).

WASM-004 — Reutilización del catálogo de controles en la web
Estado: borrador. Depende de WASM-001, 002, 010 y 016. Modifica la especificación 017: en la web, el DOM es el renderizador.

Requisitos

Una definición

R1 — Un control de formulario web o móvil es el mismo control .cfrm de desktop: mismos tipos, propiedades, eventos y métodos. Las propiedades exclusivas de la web (CssClass, Style, WASM-007) se incorporan al modelo como las demás.
R2 — Cada control tiene una clase primaria (A a E) en un registro único que leen la caja de herramientas, Check, KB y agent kit. Cuando las operaciones difieren, el registro enumera esas operaciones y la clase que adoptan: Maps es B para la imagen y C para geocode y directions; Viewer es B para páginas, C para open/save y D para print/share; ToolBar es A para la parte visual y D para acciones que inician programas.
Comportamiento

R3 — Un control de clase A se renderiza con el elemento HTML nativo (button, input, select…), CSS de sus propiedades (WASM-007), y dispara los mismos eventos en el mismo orden.
R4 — Un control de clase B se dibuja con SVG o canvas, acepta las mismas propiedades de datos y métodos, y documenta por control en qué difiere la imagen respecto de desktop.
R5 — En un proyecto web o móvil, la caja de herramientas oculta los controles de clase D, y Check informa de un control D en un formulario (por ejemplo, copiado de un formulario desktop), indicando la línea y la alternativa.
R6 — El panel Properties, la caja de herramientas y el editor de vínculos de eventos se mantienen iguales para un control web. Una propiedad sin efecto o solo aproximada en la web (perspectiva RotateX/RotateY, desenfoque del SO) sigue siendo editable, para poder llevar el formulario de un tipo a otro, y se marca como approximate o ignored en el tooltip (Q3).
R7 — Todo miembro exclusivo de la web se incorpora al vocabulario cerrado de métodos (cobolt-ast/src/methods.rs) y a las tablas de System KB, para evitar que se interprete como subíndice.
Diseño y entrada

R8 — Los cuatro modos de diseño y los puntos de ruptura se respetan mediante CSS layout (operador, 2026-10-19): Flex, Grid y Flow se mapean a flex, grid y flow; Absolute a posicionamiento absoluto; los puntos de ruptura a consultas media o de contenedor. La paridad con el solver de desktop se mide en R11.
R9 — La interacción táctil dispara los mismos eventos de clic que el ratón. Se documenta que los eventos dependientes de hover no se disparan con interacción táctil. El modelo completo de interacción móvil corresponde a WASM-021 (propuesto).
R10 — Control operable mediante teclado, con nombre accesible y rol correctos: los del elemento nativo o el patrón ARIA de los compuestos (TreeView, TabControl, DataGrid, SideMenu, MenuBar).
Garantía

R11 — Todo control A y B tiene una prueba web que asigna un valor distinto a cada propiedad y lo vuelve a leer a partir de lo que muestra el navegador. También hay una comprobación de paridad geométrica en un navegador sin interfaz gráfica frente al motor desktop, en un formulario de referencia con al menos un control de cada clase.
R12 — System KB declara la clase de cada control y los miembros exclusivos de la web, y chunked.data regenerado los incluye (su actualización es un criterio de aprobación efectivo).
Contexto: el catálogo tiene actualmente 62 tipos de control y 69 con WASM-018 (Canvas2D, Canvas3D y cinco objetos cliente).

Clasificación propuesta (por confirmar en /clarify):

A — DOM nativo: Button, TextBox, Label, CheckBox, RadioButton, ListBox, ComboBox, GroupBox, Panel, TabControl, ProgressBar, StatusBar, Line, Shape, NumericUpDown, Slider, Switch, Splitter, TreeView, MenuBar, SideMenu, ToolBar (parte visible), DateTimePicker, PictureBox, Timer, Snackbar.
B — redibujados (SVG o canvas): BarChart, LineChart, PieChart, AreaChart, ScatterChart, DonutChart, RadarChart, Knob, Gauge, Animator, Maps (tiles), Viewer (PDF, subconjunto HTML, Mermaid), y los nuevos Canvas2D y Canvas3D (WASM-018).
C — mediante el backend: DataGrid (bindings IndexedFile y SQL), IndexedFile, SqlDatabase, KnowledgeBase, RestClient, AgentObject, WebSearch, FileDropZone, Maps (geocode y directions), Viewer (open y save) y los 16 controles AWS.
D — no disponibles: acciones de ToolBar que inician programas, abren terminales o imprimen mediante el SO; Viewer print y share; controles de plugin Custom (WASM-032).
E — objetos cliente (sin representación visual, se ejecutan en el player o en el host egui): los nuevos ImageBuffer, Plot, Scene3D, Physics2D y Physics3D (WASM-018).
Puntos de integración enumerados para quienes elaboran los planes (§6): model.rs (enum, ALL, as_str, from_str, default_size, primary_event, supported_events, is_non_visual, Control::new, runtime_property_names_for), paint.rs, render.rs, methods.rs, las ramas de métodos del intérprete, la inicialización del host de formularios, runtime_features.rs, las tablas de KB del compilador, toolbox, properties.rs, designer.rs, agent.rs, prop_help_data.rs, ide_text_data.rs e i18n.rs.

Objetivos: una definición por control; todos los controles clasificados y publicados; controles A y B iguales a los de desktop, con las diferencias enumeradas; harness de conformidad web.

Fuera del alcance: controles nuevos (WebLink corresponde a WASM-006, Authentication a WASM-009); rediseño visual; llevar el canvas de Form Designer a la web.

Cuestiones:

Q1 — Diseño en la web — decidido: CSS (R8). Diferencia de un píxel medida en R11.
Q2 — Clase de los controles limítrofes (Animator, Timer, DateTimePicker, TreeView, DataGrid) — abierto, decidir por control en /plan.
Q3 — Propiedad sin efecto en la web — recomendado: mantenerla y marcarla (R6). Alternativa: ocultarla.
Q4 — DataGrid — abierto, con una orientación indicada: mantener Rows (\n y TAB) y Columns (Name:Type) para uso en memoria. Una tabla remota grande necesita paginación en el servidor (controles de datos posteriores a la v1, WASM-023).
Q5 — Fuentes — recomendado: pila de fuentes del sistema, con fuentes del proyecto mediante @font-face desde Assets/.
Q6 — Apariencia “egui-elegance” (Knob, sombras de vidrio, desenfoque del SO, esquinas de la especificación 057) — abierto: reproducir en CSS o aceptar como aproximada.
Estado: borrador. Prerrequisito del player (WASM-016) y de WASM-005, 006, 007 y 008.

WASM-005 — CALL … WITH WEBSOCKET LINKAGE y controles de datos mediante el backend
Estado: borrador. Depende de WASM-002, 003, 004, 010 y 016. Necesario para WASM-009.

Sintaxis solicitada por el operador: CALL "<nombre>"|identificador WITH WEBSOCKET LINKAGE USING BY VALUE|BY REFERENCE <grupo> [RETURNING <grupo>]. Los grupos se convierten en JSON a partir de la estructura de datos. La infraestructura, incluido el token, es invisible para el desarrollador.

Requisitos

x lenguaje

R1 — CALL {literal | identifier} WITH WEBSOCKET LINKAGE USING [BY VALUE | BY REFERENCE] group … [RETURNING group] [ON EXCEPTION …] [NOT ON EXCEPTION …] [END-CALL] se incorpora a la AST como una convención de llamada. Todas las llamadas CALL existentes se mantienen iguales.
R2 — Cada argumento es un elemento de grupo declarado en WORKING-STORAGE (Q1 trata los elementos elementales). Cualquier otra cosa se rechaza con un diagnóstico en la línea.
R3 — Modos: BY VALUE (se envía el grupo, la copia del llamador no cambia); BY REFERENCE (los valores finales del programa llamado se escriben de vuelta); RETURNING (el elemento RETURNING del programa llamado pasa al grupo indicado). Se pueden combinar.
R4 — Se acepta una llamada WEBSOCKET sin ON EXCEPTION si la descripción de interfaz importada declara el nombre; el analizador informa de los nombres que esta no declara.
Mapeo

R5 — El grupo se convierte en un objeto JSON con miembros en la jerarquía y el orden declarados. Reglas fijadas mediante pruebas:
Nombres: la clave es el data-name tal como se declaró. Se omiten FILLER y los nombres de nivel 88 (Q3).
Tablas: OCCURS n se convierte en un array; OCCURS … DEPENDING ON tiene el número actual de ocurrencias.
Números: número JSON escrito a partir del texto decimal con la escala de PICTURE, nunca mediante coma flotante binaria, con signo. Un número que JavaScript no puede almacenar exactamente se escribe completo y se lee como decimal.
Texto: cadena JSON en UTF-8; se eliminan los espacios finales en la salida (Q4).
USAGE: COMP, COMP-3 y similares se envían como valor numérico, nunca como bytes.
REDEFINES: solo se escribe el elemento redefinido (Q5).
R5b — El mapeo se implementa dos veces, con las mismas reglas: en el código que el generador incrusta en el módulo (WASM-010 R6) y en el runtime nativo del backend. Una tabla normativa y un conjunto de vectores de referencia (grupo, texto JSON, grupo leído de vuelta) se ejecutan en ambas implementaciones.
R6 — El JSON se lee por nombre, no por posición. Una clave ausente deja el elemento como está. Una clave desconocida, un tipo incorrecto, un número que no cabe en PICTURE, una cadena mayor que PIC o una tabla mayor que OCCURS generan un error, nunca truncamiento. El recorrido de ida y vuelta es idéntico.
Contrato remoto

R7 — Las disposiciones de datos de los argumentos se comparten mediante copybooks (COPY). El proyecto frontend puede importar la descripción de interfaz del backend, y la comprobación de R4 y de compatibilidad de las disposiciones se ejecuta en Check.
R8 — El desarrollador no escribe la conexión, el token, la serialización, el framing, la correlación, el keep-alive, la reconexión ni la renovación. Un token caducado se renueva y la llamada se repite una vez antes de fallar.
R9 — Con una llamada WEBSOCKET pendiente, el formulario sigue respondiendo, pero la instrucción posterior a CALL no se ejecuta. Los eventos nuevos entran en una cola ordenada (Q6). En el navegador, esto corresponde a la pausa y reanudación del módulo (WASM-010 R9).
R10 — Fallos (sin conexión, tiempo de espera agotado, fallo o caducidad de autenticación, validación, error remoto, función desconocida): se ejecuta ON EXCEPTION, y la clase y el mensaje se leen mediante el built-in inline COBOL::"…" (Q7).
R11 — Tiempo de espera y payload máximo con valores predeterminados seguros, configurables por proyecto. El backend impone sus límites (WASM-003 R16).
Los controles

R12 — Todos los controles de clase C (WASM-004) mantienen su API COBOL en la web. Diferencias visibles: latencia y los modos de fallo de R10.
R13 — DataGrid con binding IndexedFile o SQL realiza refresh, edit, save y auto-commit mediante el backend. El binding CobolTable permanece en el navegador. Los tipos de binding RestApi y AgentAi, modelados pero nunca ejecutados, se implementan mediante el backend o se retiran de la web (Q8).
R14 — Los controles con conector o secreto (SqlDatabase, RestClient, AgentObject, KnowledgeBase, WebSearch, controles AWS, Maps geocode y directions) se ejecutan en el backend. El frontend almacena solo el nombre de la configuración, nunca cadenas de conexión, claves o contraseñas. Build falla si encuentra alguno de estos datos.
R15 — FileDropZone y Viewer transfieren archivos con un límite de tamaño y una lista de tipos permitidos. El backend nunca acepta una ruta elegida por el navegador.
R16 — Para cada control de clase C, la compilación genera ambos extremos: las llamadas del frontend y los programas exportados del backend, a partir de la configuración del control. Los endpoints exigen autenticación y pueden restringirse por rol (valor predeterminado: solo autenticados).
R17 — El backend solo ejecuta sentencias y operaciones declaradas en tiempo de diseño (consulta con nombre, operación de archivo con parámetros vinculados). Nunca ejecuta SQL, comandos, rutas o URL procedentes del navegador.
Objetivos: CALL … WITH WEBSOCKET LINKAGE con grupos en USING, BY VALUE/BY REFERENCE y RETURNING; mapeo de grupo ⇄ JSON sin pérdidas; infraestructura invisible; controles de clase C funcionando en el navegador con sus API sin cambios; ningún texto SQL, secreto o ruta del navegador se ejecuta en el backend.

Fuera del alcance: JSON GENERATE y JSON PARSE generales (posible especificación posterior); streaming, server push, payload binario y protocolo de archivos grandes (WASM-014, propuestos); modificar la semántica del CALL local; un transporte distinto del de WASM-003.

Cuestiones:

Q1 — Elementos elementales como argumento — recomendado: permitir 01/77 elemental.
Q2 — RETURNING en una llamada local — decidido e implementado: corrección en 1.x.x portada a 2.x.x (8a15f00d y afe22c51).
Q3 — Escritura de las claves JSON — recomendado: tal como se declararon. Sobrescritura por elemento mediante la cláusula NAME.
Q4 — Eliminación de espacios — recomendado: eliminar los espacios finales en la salida y rellenar en la entrada. Los espacios iniciales y los valores compuestos solo por espacios necesitan una regla.
Q5 — REDEFINES — recomendado: escribir solo el primer elemento. Abierto: ¿rechazar un grupo REDEFINES como argumento?
Q6 — Eventos con una llamada pendiente — recomendado: encolar.
Q7 — Cómo se lee el fallo — abierto (requiere la preferencia del operador): built-in como COBOL::"WS-LAST-ERROR"( class message ), registro especial o RETURN-CODE.
Q8 — Bindings RestApi y AgentAi — abierto: implementar mediante el backend u ocultar en la web.
Q9 — Formato de transmisión — recomendado: un frame de texto JSON por llamada.
Estado: borrador. El CALL … RETURNING local ya está corregido en 1.x.x y 2.x.x. La parte WEBSOCKET depende del backend, que no se ha fusionado (PROGRESS PROG-79).

WASM-006 — Control WebLink
Estado: borrador. Origen: elemento 6 del operador. Depende de WASM-004 y WASM-007.

Requisitos

R1 — Control WebLink en la caja de herramientas de los proyectos web y móviles, con icono, tamaño y caption predeterminados. Es un tipo propio que hereda las propiedades, eventos y métodos de Label (Q1 trata el nombre y los formularios desktop).
R2 — Muestra Caption como texto de enlace. Color y subrayado (siempre, al pasar el cursor o nunca, mediante una propiedad). Cursor de mano de forma predeterminada.
R3 — Propiedades además de las de Label:
Url;
Target: Self, NewTab, NewWindow, Parent, Top (equivalentes a _self, _blank, etc.); NewWindow tiene las características de la ventana (ancho, alto, posición, como window.open);
Rel, lista (noopener, noreferrer, nofollow, external…);
Download, desactivado o con el nombre de archivo ofrecido;
HrefLang; MimeType (atributo type); ReferrerPolicy;
colores de los estados Link, Hover, Active y Visited (Visited solo mediante CSS: la página no lee si se ha visitado el enlace);
ping no se ofrece en la v1 (operador, 2026-10-20): hace que el navegador envíe una solicitud que la página no realiza, que la CSP de WASM-013 bloquearía, y vulnera la privacidad. Una especificación futura puede añadirlo, limitado al origen del backend.
R4 — El nombre accesible es Caption; una propiedad opcional de etiqueta accesible lo sustituye. El Tooltip existente se convierte en title.
R5 — Al hacer clic, primero dispara el evento de clic y después navega según Target. Ctrl/Cmd-clic y clic central abren una pestaña nueva; Shift-clic abre una ventana nueva; Alt-clic sigue la convención de descarga del navegador. El evento informa de las teclas modificadoras.
R6 — Si el handler activa Cancel durante el clic, la navegación no se produce. Cancel se lee después de que el handler retorna (Q3).
R7 — Esquemas aceptados: http, https, mailto (con subject, body, cc, bcc), tel, sms, URL relativas y fragmentos (#name). Rechaza javascript:, vbscript: y data: (excepto Download de un archivo generado), en el diseñador y durante la ejecución. Los esquemas aceptados son configurables por proyecto y nunca se amplían de forma predeterminada.
R8 — Con Target NewTab o NewWindow y Rel vacío, abre con noopener noreferrer. El desarrollador puede relajar esta protección explícitamente.
R9 — Recibe el foco y se activa con Enter. Indicador de foco visible. En la web, conserva el menú contextual del navegador (abrir en una pestaña nueva, copiar dirección).
R10 — Un enlace de fragmento que identifica un control o ancla del formulario desplaza la vista hasta él y mueve el foco.
R11 — En el shell móvil, una dirección fuera del origen se abre en el navegador del sistema, no en la vista web. mailto:, tel: y sms: se envían al sistema operativo.
R12 — Métodos: SetUrl, GetUrl, Open (clic simple, respetando Target), OpenIn(target), además de SetCaption y GetCaption de Label. Todos en el vocabulario cerrado (methods.rs) y en System KB.
R13 — Eventos de Label más: before-navigate (donde se aplica Cancel) y after-navigate para navegación en el mismo contexto.
R14 — En Form Designer, se dibuja como texto de enlace. Caption se puede editar directamente; Url en el panel Properties, con validación del esquema e indicación de los esquemas rechazados. El clic se prueba en Preview (WASM-008).
R15 — Recorrido de ida y vuelta mediante .cfrm; prueba en tests/controls/; ejercitado por las pruebas que recorren ControlType::ALL; documentado en System KB; icono; cadenas en seis idiomas.
Objetivos: WebLink con texto de enlace y navegación como <a>; todas las capacidades de <a> como propiedad, método o evento, excepto ping; seguro de forma predeterminada.
Fuera del alcance: texto enriquecido o enlaces inline dentro de un Label; navegación entre formularios de la aplicación (shell de WASM-011 y router propuesto); vista previa, comprobación o analítica de enlaces.
Aplazado o fuera del alcance: el control en formularios desktop (exigiría una capacidad del runtime que no existe); ping; estilo :visited (limitado por los navegadores).

Cuestiones:

Q1 — Nombre y alcance — abierto, con recomendación: nombre WebLink y solo web y móvil en la versión 2.0.
Q2 — Alt-clic y los modificadores varían según el navegador y el SO — abierto: fijar la tabla en /plan.
Q3 — Cómo cancela el handler — recomendado: propiedad booleana (SET LINK-1::Cancel TO TRUE).
Q4 — Navegación del mismo origen dentro de una SPA — abierto; el router decide.
Q5 — Estilo de visitado restringido por privacidad — abierto: declarar el subconjunto compatible.
Q6 — Codificación porcentual e IDN — recomendado: utilizar el analizador de URL de la plataforma y mostrar la forma analizada.
Estado: borrador.

[Eslopes]

WASM-007 — CSS3 para la apariencia y hoja de estilos predeterminada del formulario
Estado: borrador. Precedencia decidida (2026-10-19): prevalece CSS. Depende de WASM-002 y WASM-004. Necesario para WASM-006, 008 y 009.

Requisitos

R1 — Una tabla mapea cada propiedad de apariencia a CSS3. Ejemplos: Shadow* → box-shadow; gradiente → linear-gradient; Transparency → opacity o alfa; Padding* → padding; CornerRadius → border-radius; BorderStyle/Color/Width → border; propiedades de fuente → font-* y text-decoration. Cada entrada se marca como exact, approximate o not on the web (candidatos a approximate: perspectiva RotateX/RotateY y desenfoque del SO). La marca aparece en el tooltip (WASM-004 R6).
R2 — Todo control web o móvil tiene CssClass (nombres de clase separados por espacios) y Style (declaraciones inline), en el modelo y en el panel Properties. El nombre del control se convierte en id/data-name para que un selector pueda acceder a él.
R3 — El elemento lleva una clase de su tipo (p. ej., pr-button). Las pseudoclases (:hover, :focus-visible, :disabled, :checked) se pueden utilizar en los selectores.
R4 — Todo formulario web o móvil tiene una hoja de estilos predeterminada, guardada con el formulario y con un recorrido de ida y vuelta idéntico byte a byte (incluidos comentarios y formato). Al crearlo, se genera a partir del tema, con el CSS equivalente a la apariencia actual.
R5 — El botón de hoja de estilos del panel Properties del formulario abre una ventana modal con editor, resaltado de sintaxis CSS y diagnósticos como advertencias: error de sintaxis, propiedad desconocida, valor que no se puede analizar, funcionalidad que el destino no admite. Botones: Apply, Cancel, Revert to theme default.
R6 — Revert to theme default pide confirmación y se puede deshacer. El IDE nunca descarta el texto del desarrollador sin ello (“el código del usuario es sagrado”).
R7 — La ventana modal tiene un tamaño explícito y un único tirador que lo controla (referencia: panels/leaderboard_modal.rs).
R8 — Cascada, de menor a mayor prioridad: (1) valores predeterminados del tema; (2) propiedades del panel Properties; (3) hoja de estilos del formulario; (4) reglas de CssClass; (5) Style del control. Dentro de CSS se aplica la cascada habitual (especificidad, orden, !important). El plan puede utilizar una capa de cascada inferior.
R9 — La hoja de estilos se aplica solo dentro de la raíz del formulario y no afecta a la página anfitriona (WASM-002 R12). Define propiedades CSS personalizadas para los colores del tema (accent, surface, texto, radius), de modo que la página anfitriona pueda establecerlas.
R10 — CSS compatible: navegadores evergreen y vistas web de las plataformas (WKWebView, WebView de Android). Incluye @media, consultas de contenedor, @font-face para fuentes de Assets/ y env(safe-area-inset-*) en móvil.
R11 — Los cambios en una propiedad, CssClass, Style o la hoja de estilos aparecen en Preview sin recompilar (WASM-008).
R12 — Una sobrescritura CSS que el diseñador no puede dibujar (regla de clase o Style) se marca en Form Designer, sin simular el resultado. El panel Properties marca las propiedades sobrescritas por una regla CSS.
R13 — La hoja de estilos no carga recursos remotos sin permiso del proyecto. url() se limita a recursos del proyecto, URI de datos y orígenes permitidos. Se rechazan los scripts en CSS. Build imprime los orígenes de estilos y fuentes que CSP debe permitir (WASM-002 R14).
R14 — El formulario desktop no cambia: no tiene hoja de estilos y las propiedades nuevas solo existen en web y móvil.
Objetivos: tabla de propiedad → CSS3 con indicación de exactitud; CssClass y Style por control; hoja de estilos por formulario con editor modal; precedencia declarada; vista previa en vivo; hoja de estilos que no sale del formulario.
Fuera del alcance: preprocesador, framework de clases utilitarias, diseñador visual de CSS; renderizar CSS arbitrario en Form Designer de egui; modificar el sistema de estilos desktop.
Propiedades actualmente ausentes: LineHeight, LetterSpacing y FontWeight no existen, y ningún R las añade.

Cuestiones:

Q1 — Precedencia — decidido: CSS prevalece sobre el panel Properties (R8). El panel muestra cuándo se sobrescribe un valor (R12).
Q2 — Dónde se almacena la hoja de estilos — recomendado: archivo forms/<Form>.css junto al formulario. Alternativa: dentro del .cfrm (con la salvedad de CDATA).
Q3 — Hoja de estilos de todo el proyecto (capa de aplicación) — recomendado: dejarla para una especificación futura, reservando su lugar en la cascada.
Q4 — Nombres de clase (pr-button) y propiedades personalizadas como contrato público — abierto: fijarlos en /plan y protegerlos con una prueba.
Q5 — Efectos visuales sin un equivalente CSS exacto (sombras de vidrio, perspectiva, esquinas de la especificación 057) — abierto, sin recomendación: aceptar approximate por propiedad o exigir paridad en los tres temas incorporados.
Estado: borrador.

WASM-008 — Preview como vista web
Estado: borrador. Origen: elemento 9 del operador. Depende de WASM-001, 002, 004 y 007. Relacionado con WASM-003 (backend de desarrollo) y WASM-009 (inicio de sesión de desarrollo).

Requisitos

R1 — Preview de un formulario web o móvil compila el frontend mediante el pipeline de WASM-002 (módulo, descripciones de los formularios y player precompilado), sin compilar Rust, y muestra todo en una vista web del sistema: WKWebView en macOS, WebView2 en Windows, WebKitGTK en Linux. No es una aproximación dibujada por egui.
R2 — La vista web reside en su propia ventana. Si se bloquea o falla, no provoca la caída del IDE (Q1: proceso separado).
R3 — Los cambios en el formulario, una propiedad, CssClass, Style o la hoja de estilos actualizan Preview in situ, conservando el estado cuando sea posible y recargando cuando no lo sea, dentro de un plazo fijado en el plan. Mecanismo: actualización in situ del player (WASM-016 R16).
R4 — Controles de Preview: ajustes predefinidos de dispositivo (teléfono, tablet, ancho desktop); orientación; relación de píxeles del dispositivo; márgenes del área segura; esquema de color (claro/oscuro) y configuración regional; tamaño libre mediante un tirador. La ventana nunca se redimensiona por sí sola.
R5 — La vista web expone las herramientas de desarrollador (inspector, consola) en modo debug. La consola de la página y los errores no capturados se envían al panel Output, con el formulario y, cuando el motor lo proporcione, la línea COBOL.
R6 — Si el formulario llama a un backend (WASM-005), Preview utiliza el backend del proyecto en modo de desarrollo (WASM-003 R20) y lo inicia cuando se solicita. Si no hay un backend en ejecución, avisa en lugar de fallar silenciosamente.
R7 — Si la compilación falla, Preview conserva la última versión válida y muestra los errores. Los errores también se envían a Output.
R8 — La vista web carga solo el origen de desarrollo del propio proyecto. Cualquier otra navegación se bloquea o se entrega al navegador del sistema. La página no accede al IDE.
R9 — Renderizado sin interfaz gráfica de un formulario web a una imagen, y ejecución mediante script (escribir, hacer clic, esperar, leer una propiedad, devolver el texto mostrado, errores e imagen). Sirven para las pruebas y las herramientas MCP render_form y run_form, con el mismo formato de los formularios desktop.
R10 — Con un proyecto desktop, Preview y Run Form se mantienen como están hoy.
Objetivos: Preview en una vista web a partir del mismo pipeline de Build; actualización al guardar y al cambiar el estilo; emulación de dispositivos sin redimensionamiento automático; herramientas de desarrollador y consola en Output; equivalente sin interfaz gráfica para pruebas y agentes.
Fuera del alcance: emuladores Android, simuladores iOS, ejecución en dispositivos; sustituir el canvas de Form Designer por una vista web; depuración remota.
Restricciones: WebKitGTK y WebView2 pasan a ser dependencias de ejecución del IDE; los instaladores y la comprobación de la cadena de herramientas deben indicarlo; licencias del crate de vista web; i18n de ajustes predefinidos y errores.

Cuestiones:

Q1 — Proceso separado o integrado — recomendado y decidido en el plan: proceso y ventana separados, como Run Form.
Q2 — Biblioteca del motor — decidido en el plan: wry 0.57 + tao 0.35.
Q3 — Backend durante Preview — recomendado: backend real iniciado localmente. El plan dice que el IDE no inicia el Backend y que Preview avisa.
Q4 — Inicio de sesión durante Preview — abierto: proveedor real o token de desarrollo (WASM-003 Q5).
Q5 — Presupuesto de actualización (R3, “N ms”) — abierto: medir un prototipo antes de fijarlo.
Q6 — ¿Preview sustituye a Run Form en los tipos web? — decidido en el plan: no. Dos acciones: Preview (vista web con controles de dispositivo), Run (el mismo servidor en el navegador del sistema), Build (paquete e informe).
Plan (plan.md): estado "implementado en worktree-agent-a97ba65c…" con seis entregas. Enfoque en tres pasos: compilar → servir → mostrar. Servidor de desarrollo en loopback (std::net, sin dependencias nuevas; comprobación de la cabecera Host, ruta canonicalizada, solo GET/HEAD). Helper prc-web-preview (wry + tao, proceso propio; probado en macOS). Monitor de formularios, src, Assets, backend y manifiesto, con recompilación y notify_changed. Ajustes predefinidos: 7 ajustes × 2 orientaciones, relación de píxeles 1/1.5/2/3 y área segura que gira con la pantalla. Protocolo JSON fijado: IDE→helper open, size, reload, scheme, devtools, close, emulate; helper→IDE ready, console, error, blocked, failed, closed. Política de navegación restringida al origen de Preview.

Tareas (tasks.md): T1–T10 realizadas, T11–T13 abiertas. Abiertas: T11 abrir una ventana real una vez (operador); T12 conectar el generador real y medir AC1–AC2; T13 backend iniciado cuando se solicita (R6) y renderizado sin interfaz gráfica/ejecución de formularios web (R9, depende de WASM-015 R1–R2). Sin terminar según el plan: R3 es una recarga, no una actualización in situ; los errores no se dibujan sobre la página; @media (resolution) y env(safe-area-inset-*) no cambian con la emulación; Windows y Linux no se han probado.

WASM-009 — Control Authentication y backend de proveedores de identidad
Estado: borrador. El flujo se elige por proveedor (2026-10-19); todavía hay que comprobar las capacidades de cada proveedor. Depende de WASM-003, 005 y 007. Relacionado con el control AwsCognito.

Requisitos

R1 — Control Authentication en la caja de herramientas de web y móvil, con las pantallas: Sign in, Create account, Confirm account (código por correo electrónico o teléfono), Forgot password (solicitud, después código y contraseña nueva), MFA challenge (opcional) y la acción Sign out. El desarrollador elige qué pantallas existen; los textos son traducibles.
R2 — Se estiliza como cualquier control (propiedades, CssClass, Style, hoja de estilos). Define el autocomplete correcto (username, current-password, new-password, one-time-code) para los gestores de contraseñas. Operable mediante teclado y lector de pantalla.
R3 — Expuesto a COBOL:
eventos onSignedIn, onSignedOut, onSignUpCompleted, onPasswordResetRequested, onMfaRequired, onError;
propiedades State, UserName y Email del usuario, y Mode;
métodos SignOut, Refresh, GetClaim.
Los nombres se fijan en /plan y se registran en el vocabulario cerrado y en System KB.
R4 — (Opcional) reCAPTCHA v3: el control obtiene un token por acción protegida (sign-in, sign-up, forgot-password), sin desafío visible, y lo envía. El backend lo verifica con el proveedor utilizando un secreto que solo existe en el backend, comprueba el nombre de la acción y el hostname, y rechaza una puntuación inferior al umbral (0.5 de forma predeterminada) con el mismo mensaje genérico de contraseña incorrecta. La site key es pública; el secreto nunca está en el frontend.
R5 — Token de acceso solo en memoria (nunca en localStorage ni sessionStorage). La renovación no es legible por script: cookie HttpOnly, Secure, SameSite, establecida por el backend en la web; almacenamiento seguro del SO en móvil. Renovación silenciosa antes de caducar. Si falla la renovación, dispara onSignedOut.
R6 — Los tokens nunca se envían a logs, URL o texto visible. GetClaim devuelve el valor de una claim, nunca el token.
R7 — Backend de identidad = conjunto de programas públicos generados del Backend (WASM-003 R9, R22): sign-in, sign-up, confirm, forgot-password, reset-password, MFA challenge/verify, refresh y sign-out.
R8 — Compatibilidad con proveedores mediante una interfaz de adaptador: un cuarto proveedor es un adaptador, no un cambio en el control. Tres adaptadores (AWS Cognito, Keycloak, Microsoft Entra), cada uno con: autenticación, registro, confirmación, recuperación de contraseña, desafío MFA, renovación, cierre de sesión/revocación y atributos básicos, dentro de lo que ofrece cada proveedor. Una tabla en el plan enumera lo que no se admite y lo que hace el control en su lugar.
R8b — Flujo elegido por proveedor (operador, 2026-10-19). Cada adaptador declara in-app (pantallas del control, el backend intercambia credenciales con el proveedor) o alojado (el navegador o la vista web accede a la página de inicio de sesión del proveedor, con intermediación del backend mediante authorization code y PKCE). Los eventos de R3 son los mismos en ambos flujos.
R9 — Ajustes del proveedor en la configuración del Backend, mediante una página de configuración del IDE con la acción Test connection: issuer, o region/realm/tenant; client id; client secret, si corresponde; secreto de reCAPTCHA. Nunca en un formulario, copybook o archivo del frontend.
R10 — Los fallos no revelan si la cuenta existe (misma respuesta para un usuario desconocido y una contraseña incorrecta, y para el restablecimiento con una dirección conocida o no). Límite de solicitudes de sign-in, sign-up y reset por origen y por cuenta, sumado al bloqueo del proveedor. Las contraseñas nunca se envían a los logs.
R11 — Cuando la aplicación exige iniciar sesión para acceder a un formulario (Q4), muestra el formulario Authentication a quien no haya iniciado sesión y el formulario solicitado después del inicio de sesión.
R12 — Las pruebas automatizadas ejecutan los flujos completos frente a un proveedor local (Keycloak en un contenedor y mocks para los demás). Las pruebas con tenants reales de Cognito y Entra corresponden al operador, y la aceptación registra cuáles se ejecutaron.
Objetivos: control Authentication con las pantallas; reCAPTCHA v3 verificado en el backend; backend neutral con adaptadores para Cognito, Keycloak y Entra; gestión de tokens que impida que el script de la página robe la credencial de larga duración; eventos y propiedades útiles para el formulario.
Fuera del alcance: inicio de sesión social y federación (Google, Apple); passkeys/WebAuthn; autorización por roles; consola de administración; sustituir el control AwsCognito; alojar un proveedor. Cada uno se propone en WASM-031.
Aplazado: token de sesión emitido por el backend; hCaptcha y Cloudflare Turnstile (adaptadores posteriores); “Sign in with Apple” en iOS.

Cuestiones:

Q1 — Riesgo de introducir la contraseña en nuestro formulario — decidido: flujo por proveedor (R8b). Para /clarify: capacidades de cada producto y flujo predeterminado de cada adaptador. Recomendado: Cognito in-app; Entra y Keycloak alojados, salvo que el tenant esté configurado para in-app.
Q2 — Token del proveedor o del backend — recomendado: el del proveedor, validado por el backend (WASM-003 R10). El token del backend es una opción posterior.
Q3 — La cookie de renovación exige HTTP, y la serie utiliza WebSocket (WASM-003 Q3) — abierto: confirmar la pequeña superficie HTTPS.
Q4 — Protección de rutas — recomendado: propiedad “requires sign-in” en el nivel del formulario.
Q5 — Tipos de MFA en la versión 2.0 — abierto: solo TOTP o también SMS y correo electrónico.
Q6 — reCAPTCHA v3 y privacidad — abierto: ¿el control ofrece un hook de consentimiento?
Q7 — Móvil: almacenamiento seguro y biometría — abierto, por confirmar con la especificación de la plataforma móvil (WASM-012).
Estado: borrador.

[Eslopes]

WASM-010 — Generación de código WebAssembly
Estado: borrador. Resuelve WASM-002 Q1. Necesario para WASM-004, 005, 008 y 015. Depende de WASM-002.

Requisitos

R1 — Build de un proyecto Web o Mobile emite un módulo WebAssembly para todo el proyecto a partir del COBOL del lado del navegador: formularios generados, handlers de eventos, procedimientos y el Common Code que estos llaman mediante CALL. Cada formulario lleva una copia del Common Code que llama (WASM-017 R1). Hay variantes multi-memory y single-memory (WASM-017 R9). Emisión directa desde la AST, sin compilar Rust y sin intérprete, AST ni paquete de runtime en la salida.
R2 — Módulo autocontenido: importa solo la API del host (R12) y carga únicamente las rutinas que necesita. Exports: los puntos de entrada de R10, los de R9 y la memoria.
R3 — Cada elemento de WORKING-STORAGE, LOCAL-STORAGE y LINKAGE reside en un lugar fijo de la memoria lineal, con disposición byte a byte: PICTURE y USAGE (DISPLAY, COMP/COMP-5, COMP-3, COMP-1/COMP-2, national); posición del signo (overpunch final, SEPARATE, LEADING); OCCURS, incluido DEPENDING ON; grupos como bytes contiguos; REDEFINES sobre los mismos bytes; FILLER, VALUE e INITIALIZE. El tamaño se fija en tiempo de compilación: el código nunca llama a memory.grow. Cada instancia de formulario tiene su propia región (WASM-017 R2). La arena de transporte es la memoria 1 (multi-memory) o una región reservada de la memoria 0 (single-memory).
R4 — Aritmética decimal exacta de punto fijo: como mínimo, los 18 dígitos del estándar y hasta la amplitud que admite el intérprete (mantisa i128, aproximadamente 38 dígitos). ADD, SUBTRACT, MULTIPLY, DIVIDE y COMPUTE, con GIVING, REMAINDER, todos los modos ROUNDED y SIZE ERROR, con los resultados del intérprete (R16).
R5 — Control de flujo completo: párrafos y secciones; PERFORM en todas sus formas (simple, THRU, TIMES, UNTIL, VARYING, inline, TEST BEFORE/AFTER, EXIT PERFORM/CYCLE); GO TO (con DEPENDING) y ALTER; EVALUATE, IF y NEXT SENTENCE; programas anidados; CALL, CANCEL, GOBACK, EXIT PROGRAM y STOP RUN. Ningún programa que compile se rechaza por utilizar GO TO o ALTER.
R6 — Rutinas emitidas en el módulo: aritmética decimal, incluidas operaciones de 128 bits que WebAssembly no tiene; numeric-edited; cadenas para STRING, UNSTRING, INSPECT y modificación por referencia; funciones intrínsecas; aritmética de fecha y hora. Deben tener una única fuente de verdad compartida con el intérprete (Q3). Sin código de archivos, hilos, procesos, redb o std::fs.
R7 — Subconjunto: todas las sentencias COBOL-85 que no necesitan archivos, además de las extensiones PowerRustCOBOL que no necesitan la máquina host: propiedad de control leída y escrita como un elemento de datos (CTRL::Property); llamadas a métodos y valores de métodos; métodos de valor de elementos (Trim, UpperCase, Replace, Len…); expresiones en MOVE/SET/STRING; built-ins inline COBOL::"…" que sirven para el navegador. Cada built-in de BUILTINS se clasifica como browser, backend only o unsupported en una tabla.
R8 — Construcción fuera del subconjunto: error en la línea, indicando la construcción y la alternativa (WASM-002 R3). Una prueba falla cuando una variante de Stmt o un built-in no tiene una entrada en la tabla.
R9 — Suspensión: mientras una llamada espera (CALL remoto, diálogo, espera temporizada), el módulo se detiene, devuelve el control y se reanuda en el mismo punto. La posición, la pila de PERFORM y los datos permanecen en la memoria lineal (Q4). Un handler que supera un presupuesto de tiempo cede al host en una arista de retorno y se reanuda en el siguiente turno. Con la página aislada, el módulo se ejecuta en un Worker (WASM-017 R19). El resultado no depende de dónde haya cedido.
R10 — Evento del host (id del evento, id del control, parámetros): el módulo ejecuta el handler vinculado hasta el final o la siguiente suspensión, aplicando al host los cambios, y avisa cuando termina.
R11 — Error de ejecución (subíndice fuera de la tabla, división por cero sin SIZE ERROR, dato numérico inválido, CALL sin resolver): ON SIZE ERROR y ON EXCEPTION se comportan como en el intérprete. Un error no tratado termina el handler, se notifica con la línea COBOL (R14) y la aplicación continúa.
R12 — API del host breve y versionada, cada entrada con su significado documentado: leer y establecer propiedades de controles; llamar a métodos de controles; escribir DISPLAY en la consola; leer el reloj y números aleatorios; realizar llamadas remotas. La página la implementa (WASM-002). Un módulo para la API n se niega a iniciar en un host que no la ofrezca. La API es de granularidad gruesa: las escrituras de propiedades de un handler se agrupan y se entregan en una llamada al finalizar o al suspenderse, y las lecturas reflejan las escrituras anteriores (WASM-017 R11, R12).
R13 — Aparte de las llamadas al host, el módulo es determinista: los mismos eventos y respuestas producen los mismos resultados. El harness de conformidad depende de ello.
R14 — Name section y line table mapean instrucciones a líneas COBOL, con formulario y evento. Suficiente para los mensajes de R11 y para el depurador propuesto (WASM-024).
R15 — Build informa del tamaño del módulo y del tiempo de arranque. Aquí no se fija ningún límite (Q6).
R16 — Paridad medida entre el módulo y el intérprete:
(a) los programas NIST CCVS85 de los módulos NC, IF e IC incluidos en el subconjunto se compilan y ejecutan en un motor WebAssembly sin interfaz gráfica con 0 fallos en los informes CCVS; fuera del subconjunto, cada programa se enumera con la construcción que lo excluye;
(b) los programas de tests/cobol/ incluidos en el subconjunto imprimen la misma salida en ambos motores;
© cuando difieren, uno de los lados tiene un defecto: se corrige en 1.x.x si es el intérprete (y se porta), y aquí si es el generador. Nunca “documentar la diferencia para que desaparezca”.
R17 — La regla de paridad intérprete/binario incluye el generador y las rutinas emitidas como un consumidor adicional, e identifica las rutinas que constituyen una fuente compartida.
R18 — Fases, cada una utilizable: A — disposición de datos, MOVE, aritmética, IF, PERFORM, GO TO, EVALUATE, API del host para propiedades, métodos y eventos; B — tablas, STRING/UNSTRING/INSPECT, numeric-edited, funciones intrínsecas, programas anidados y CALL local; C — suspensión y CALL remoto con mapeo JSON (WASM-005); D — el resto del subconjunto. Cada fase registra qué se compila y qué supera las pruebas, al estilo del registro NIST. Según GOLDEN RULE #9, NC termina antes que IF e IC.
Objetivos: backend que transforma el COBOL del navegador en un único módulo autocontenido; disposición exacta a nivel de bytes y aritmética exacta con los resultados del intérprete; todo el control de flujo COBOL-85, incluidos GO TO y ALTER; módulo que se pausa y se reanuda; API del host breve como único import; criterio de conformidad: NIST del subconjunto y corpus de referencia con 0 fallos.

Fuera del alcance: E/S de archivos de cualquier organización, redb, std::fs, procesos secundarios, sockets, SQL, EXEC SQL y EXEC RUST (en el navegador, los datos residen en el backend); hilos dentro de la semántica COBOL; runtime, intérprete o AST en el módulo; compilar el backend; GC, modelo de componentes, hilos o SIMD en la v1; optimización más allá de una transformación directa.

Cuestiones:

Q1 — “Directamente” — decidido y confirmado (operador, 2026-10-20): mantener la generación directa, frente al transpilador COBOL → Rust y al intérprete compilado para wasm32.
Q2 — Emisor y motor de pruebas — abierto: wasm-encoder o escritor propio; motor wasmi o wasmtime. Examinar licencia, MSRV y peso en /plan.
Q3 — Cómo se escriben las rutinas — recomendado: opción (a), escritas una vez en Rust, compiladas al construir el producto, almacenadas como un blob y enlazadas estáticamente en cada módulo, descartando las funciones no utilizadas. Una única fuente de verdad con el intérprete.
Q4 — Técnica de suspensión — recomendado: estado explícito mantenido por el código generado (funciona en todos los navegadores). Alternativas rechazadas: JSPI y Asyncify.
Q5 — Paridad del modelo de datos (bytes reales × valores) — abierto, por confirmar. Una diferencia encontrada es un defecto del intérprete (R16c).
Q6 — Presupuestos de tamaño y tiempo de arranque — abierto: medir primero la fase A.
Q7 — Qué built-ins sirven para el navegador — abierto, se decide entrada por entrada en /plan.
Q8 — Archivos indexados y SORT en memoria en el navegador — abierto, por confirmar; fuera de la v1.
Q9 — DISPLAY y ACCEPT — abierto: DISPLAY se envía a la consola del host; ¿ACCEPT se rechaza o se mapea a un diálogo?
Q10 — Uno o dos módulos — decidido (2026-10-19): dos .wasm (módulo y player, WASM-016).
Estado: borrador. Cobertura NIST citada en el estado actual: NC, IF, IC, SM, ST, SQ, IX y RL terminados; DB solo compila; SG fuera del alcance (para el intérprete). Para el generador, PROGRESS registra NC, IF e IC terminados (sección 7).

WASM-011 — Navegación y estilos de aplicación: SPA de forma predeterminada, formularios standalone como alternativa
Estado: borrador. Depende de WASM-001, 002 y 010. Parte de la especificación 049 (shell, FormFormat, super) y de la especificación 037 (ciclo de vida).

Requisitos

Estilo de la aplicación

R1 — El estilo es una configuración del proyecto, elegida en New Project (WASM-001 R4) y modificable antes de Build. Valores: SPA (predeterminado) o Standalone.
R2 — Comportamiento por estilo. SPA: OpenFormSync es un diálogo modal dentro de la página, con el llamador suspendido hasta que se cierre (WASM-010 R9); OpenFormAsync es un panel no modal dentro de la página; la carga por menú (shell) carga en ContentPane (especificación 049). Standalone: OpenFormSync abre una pestaña o ventana nueva (en móvil, una pantalla apilada), con el llamador suspendido; OpenFormAsync abre una pestaña o ventana nueva y el llamador continúa; no se utiliza la carga por menú (no hay shell).
R3 — FormFormat (Standalone, Embedded, Both, especificación 049) conserva su significado y la comprobación durante la compilación: un formulario Embedded no puede ser destino de una apertura standalone, y un formulario Standalone no puede cargarse en un panel. En SPA, un formulario Standalone o Both abierto mediante OpenFormSync/OpenFormAsync aparece como diálogo o panel dentro de la página; no es una carga en ContentPane.
SPA

R4 — Al mostrar un formulario, la dirección pasa a ser la ruta del formulario (nombre más parámetros de apertura). Atrás y Adelante recorren la navegación. Recargar o pegar una dirección abre la aplicación en ese formulario (lo que se restaura depende de Q1). La región de datos del formulario se crea con él y se libera al destruirlo, no mientras permanezca residente o se conserve mediante PreservePreviousForm (WASM-017 R2, R5). El módulo se carga una vez, al iniciar.
R5 — La ruta funciona en cualquier host estático sin configuración de servidor (Q2) y no se apropia de la dirección de la página cuando la aplicación está integrada (WASM-002 R11).
R6 — Dirección sin formulario o con un formulario que el usuario no puede abrir: la aplicación muestra un desenlace definido de not-found o sign-in (WASM-009 R11) y dispara un evento que el desarrollador puede gestionar.
R7 — En cada navegación: foco en el título del nuevo formulario, anuncio a la tecnología de asistencia y reinicio del desplazamiento.
R8 — (Opcional) Formulario con cambios sin guardar: salir mediante Atrás, el menú o cerrando la pestaña pide confirmación, dentro de lo que permita el navegador.
Standalone

R9 — Cada formulario standalone tiene su propia dirección y página, que se pueden abrir directamente (marcador, enlace), sujetas al inicio de sesión, y se ejecuta en su propia instancia, con sus propios datos, como en desktop.
R10 — La apertura standalone a partir de un gesto del usuario abre la ventana. Si el bloqueador de ventanas emergentes la rechaza (llamada mediante temporizador o después de una espera), la aplicación indica cómo permitirla, dispara un evento y libera al llamador suspendido con un fallo.
R11 — super en standalone es el formulario que lo abrió: leer y escribir propiedades y llamar a métodos mediante mensajes entre ventanas del mismo origen. Asíncrono para la plataforma, síncrono para el programa. Falla con ON EXCEPTION si se ha cerrado el opener (Q3).
R12 — Al cerrar una ventana standalone, los eventos del ciclo de vida (especificación 037) se ejecutan hasta donde permita el navegador, y se libera a un llamador suspendido en OpenFormSync.
Móvil

R13 — En el shell móvil (WASM-012) no hay pestañas ni ventanas: los standalone son pantallas apiladas en una pila de navegación. El gesto o botón Atrás del sistema desapila; un enlace profundo abre un formulario como en R4 y R9.
General

R14 — Los diálogos modales retienen el foco, se cierran mediante el teclado cuando el formulario lo permite, se apilan en el orden de apertura y bloquean lo que está detrás.
R15 — El proyecto Desktop permanece sin cambios.
Objetivos: estilo en el nivel del proyecto, SPA de forma predeterminada; comportamiento definido para cada combinación de estilo × verbo en web y móvil; URL, Atrás/Adelante y recarga para SPA, además de enlaces profundos; super, eventos del ciclo de vida y FormFormat con su significado actual.
Fuera del alcance: compartir datos entre formularios (unidad de ejecución compartida, EXTERNAL, USING en OpenFormSync), que queda para una especificación propia como en la 049; router en el servidor o SSR; animaciones entre rutas; modificar el modelo de ventanas de desktop.
Previsto por la especificación: nuevos eventos (not-found, popup-blocked, leave-confirmation); textos de i18n en seis idiomas; rutas y páginas de entrada generadas a partir de la lista de formularios, nunca editadas a mano; la ventana emergente utiliza el tamaño de diseño del formulario.

Cuestiones:

Q1 — Qué restaura una recarga o un enlace profundo — recomendado (A): el formulario y sus parámetros, no los datos. Opción B: instantánea de los datos en sessionStorage (nunca tokens, WASM-009 R5).
Q2 — Sintaxis de la ruta — recomendado: hash #/customer/42 (funciona en cualquier host estático). Alternativa: path /customer/42 (exige un servidor que sirva la aplicación para rutas desconocidas).
Q3 — super entre ventanas — abierto: el canal solo existe en el mismo origen y en el mismo perfil. Confirmar el límite y que el cierre del opener sea un ON EXCEPTION normal.
Q4 — Navegación de varias páginas en la misma ventana (cada OpenForm sustituye la página) — abierto: ¿fuera del alcance o parte de “standalone”?
Q5 — Estilo predeterminado en móvil — abierto, con recomendación: SPA con pila.
Q6 — Módulo de programa de una página standalone — decidido (2026-10-20, WASM-017 Q1): cada página carga el módulo único y el player único, instanciados con el formulario inicial; el navegador almacena ambos en caché.
Q7 — Varias instancias de la aplicación en la misma página — abierto: permitido o rechazado.
Estado: borrador.

WASM-012 — Shell móvil (Tauri 2): compilaciones Android e iOS, dispositivos, firma y permisos
Estado: borrador. Depende de WASM-001, 002 y 010. Relacionado con WASM-009 y WASM-013. La propia especificación declara que las afirmaciones sobre Tauri se basan en conocimientos generales y deben verificarse en /plan.

Requisitos

Compilación y cadena de herramientas

R1 — Build de un proyecto Mobile produce, para cada plataforma elegida, un paquete Android (instalable y en formato de tienda) y un archive iOS. Ambos envuelven el paquete de WASM-002 en el shell Tauri, con la identidad del proyecto (R6).
R2 — Herramienta ausente (Android SDK, NDK o JDK; destinos Rust de Android o iOS; Xcode y herramientas de línea de comandos; Tauri CLI en la versión fijada): el IDE indica cuál es, para qué sirve y cómo obtenerla. Solo instala lo que sea seguro (rustup target add), nunca Xcode ni Android SDK. Una plataforma que la máquina no puede compilar (iOS fuera de macOS) aparece como no disponible con el motivo.
R3 — Ejecutar en un dispositivo: enumera emuladores, simuladores y dispositivos conectados; inicia el elegido; instala y lanza; recarga el frontend con cada cambio; muestra el log del dispositivo en el panel Output; se detiene cuando se solicita.
Identidad y firma

R4 — Firma de release con las credenciales del propio desarrollador (keystore Android; certificado y provisioning profile Apple), referenciadas por nombre. Las contraseñas y claves permanecen en el almacén de secretos del SO y nunca en un archivo del proyecto. Si el almacén no está disponible, el IDE se niega a continuar, en lugar de recurrir al texto sin cifrar. Las compilaciones de debug se firman automáticamente.
R5 — Build rechaza un paquete de release sin firmar o firmado con una clave de debug, e informa de ello.
R6 — Identidad del proyecto: application id en DNS inverso; nombre (traducible a los seis idiomas); versión y build number derivados de la versión del proyecto; iconos y pantalla de inicio. Iconos generados en todos los tamaños exigidos a partir de una imagen en Assets/.
Permisos y funcionalidades del dispositivo

R7 — El programa declara cada funcionalidad del dispositivo utilizada (capability que el compilador encuentra en llamadas y controles). Build escribe los permisos de la plataforma (Android, descripciones de uso de iOS) y falla, indicando la funcionalidad y la línea, si el programa utiliza una funcionalidad no declarada.
R8 — Cuando se necesita por primera vez, la aplicación solicita el permiso en ese momento, con el texto de justificación del desarrollador (traducible). La denegación llega al programa como un fallo normal que puede gestionar.
R9 — Funcionalidades del dispositivo utilizables en COBOL: conjunto breve y versionado, cada una con una entrada de la API del host (WASM-010 R12), con permiso, significado y entrada en KB. Primer conjunto (Q1): almacenamiento seguro (WASM-009 R5), abrir una dirección en el navegador o marcador telefónico (WASM-006 R11) y enlaces profundos. Después, una por una: cámara, ubicación, notificaciones, biometría, respuesta háptica, panel para compartir, portapapeles, lector de códigos de barras.
Comportamiento en el dispositivo

R10 — El shell pasa a la página las áreas seguras y el tamaño del teclado como variables CSS (WASM-007 R10), respeta la orientación fijada y entrega el gesto Atrás a la navegación de WASM-011 R13.
R11 — El paso a segundo plano, el retorno y el cierre disparan los eventos del ciclo de vida (especificación 037) hasta donde permita la plataforma. Al volver, restablece la conexión con el backend (WASM-003 R8) y, si la sesión ha caducado, solicita un nuevo inicio de sesión.
R12 — La página procede del paquete, nunca de la red. Solo el frontend empaquetado llama a comandos nativos (lista de capacidades con los comandos permitidos). Las direcciones fuera del origen se abren en el navegador del sistema. La vista web se ejecuta bajo la CSP de WASM-013.
R13 — Build imprime una lista de lo que exigirán las tiendas (declaraciones de privacidad de iOS, seguridad de los datos de Android), derivada de las funcionalidades declaradas.
R14 — Los proyectos Desktop o Web no cambian. Se respetan las opciones del tipo Mobile en New Project (orientación predeterminada, SO mínimo).
Objetivos: paquete Android e iOS del mismo frontend desde el IDE; detección de la cadena de herramientas que refleje la situación real e indique el siguiente paso exacto; ejecución en emulador, simulador o dispositivo con logs en el IDE; firma con las credenciales del desarrollador fuera de los archivos; permisos declarados y solicitados en el momento adecuado; conjunto pequeño de funcionalidades del dispositivo.
Fuera del alcance: watch y TV (WASM-034); envío a las tiendas (manual); compilación de iOS en Windows o Linux; actualización automática fuera de las tiendas; interfaz nativa (las pantallas son las del player web).
Previsto por la especificación: la CLI de Tauri tiene subcomandos android e ios (init, dev, build); el IDE ya almacena secretos en el almacén del SO con una alternativa en texto sin cifrar, y el caso móvil no hereda esa alternativa; el shell es un artefacto generado, nunca editado a mano; una compilación Rust por aplicación es inevitable en móvil, a diferencia de Web; las dependencias de Tauri pasan por los controles de dependencias (sin aws-lc-rs ni ring, MSRV 1.92).

Cuestiones:

Q1 — Primeras funcionalidades del dispositivo — abierto: decidir entre cámara, ubicación, notificaciones, biometría y lector de códigos de barras para la versión 2.0.
Q2 — Compilación en la nube o remota para iOS — abierto: fuera del alcance o especificación posterior.
Q3 — Niveles mínimos de SO (API Android, versión iOS) — abierto.
Q4 — Tablets — recomendado: Android Tablet e iPad son plantillas separadas que difieren de los teléfonos solo en los puntos de ruptura. Alternativa: shell separado.
Q5 — Fijación de versiones de Tauri y plugins — abierto: por proyecto con una vía de actualización, o siguiendo al IDE.
Q6 — Fijación de certificados y refuerzo de seguridad de la conexión con el backend — abierto.
Estado: borrador. No iniciado según PROGRESS (PROG-82).

[Eslopes]

WASM-013 — Arquitectura de seguridad y modelo de amenazas de la línea WebAssembly
Estado: borrador. Depende de WASM-002, 003, 005, 009, 010 y 012. Es responsable de las reglas que estos citan (WASM-002 R7, R14; WASM-003 R14–R17; WASM-005 R14, R17; WASM-006 R7–R8; WASM-007 R13; WASM-008 R8).

Requisitos

El modelo

R1 — Modelo de amenazas de la serie: activos (cuentas, tokens, datos, secretos, código fuente del desarrollador); actores (anónimo, autenticado, página maliciosa que integra o abre la aplicación, cliente de backend malicioso, dependencia maliciosa, archivo de proyecto malicioso abierto en el IDE); fronteras de confianza (navegador ⇄ backend, página anfitriona ⇄ módulo, módulo ⇄ player, IDE ⇄ vista web de Preview, shell móvil ⇄ frontend, backend ⇄ proveedor y datos). Para cada amenaza: control y prueba que lo demuestra. Se revisa en /analyze de cada fase.
Políticas que genera la compilación

R2 — Página anfitriona con CSP de denegación predeterminada: scripts del origen y 'wasm-unsafe-eval', sin 'unsafe-eval' ni 'unsafe-inline' (nonce o hash donde sea inevitable); estilos del origen y hashes; imágenes y fuentes del origen; connect-src limitado a las direcciones del backend; base-uri y form-action restringidos; frame-ancestors según el modo de integración. Se exige Trusted Types donde se admita.
R3 — Los hosts estáticos pueden no permitir definir cabeceras. Build entrega la política como <meta> (lo que meta puede expresar) y como conjunto de cabeceras listo para hosts comunes (lo que meta no puede expresar: frame-ancestors, report-only, HSTS), e imprime cuál es cuál.
R4 — El backend envía Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy restrictiva y Permissions-Policy; la configuración TLS rechaza versiones y cifrados por debajo de un mínimo declarado.
XSS

R5 — Todo valor que llega a la página (caption, elemento, celda, tooltip, mensaje) se inserta como texto, nunca se analiza como markup. El player no tiene ninguna API que inserte cadenas HTML (innerHTML, outerHTML, insertAdjacentHTML, document.write), y una prueba busca esos puntos de inserción en el código. El único control que renderiza markup, el subconjunto HTML de Viewer, construye nodos DOM (createElement, setAttribute, textContent) a partir de un árbol analizado y filtrado mediante una lista de elementos, atributos y esquemas de URL permitidos.
CSRF, CORS y origen

R6 — Las llamadas que modifican el estado se autorizan mediante un bearer token añadido por la página, nunca solo mediante una cookie. Una solicitud que depende de cookies (renovación de WASM-009 R5) utiliza SameSite, un token CSRF o una cabecera que el navegador no añade entre sitios. Se verifica Origin del WebSocket (WASM-003 R14). Superficie HTTPS con lista explícita de orígenes permitidos, nunca un comodín con credenciales.
Secretos

R7 — Análisis de secretos que bloquea Build web o móvil (WASM-002 R7), con los patrones de esta especificación: claves y tokens de nube, bloques de claves privadas, JSON Web Tokens, cadenas de conexión, formatos de claves API, cadenas de alta entropía por encima de una longitud configurable. Se ejecuta sobre el paquete, formularios, copybooks y hojas de estilos. Falla indicando el archivo y el patrón, nunca el valor.
R8 — Una clave de backend o de firma nunca recurre al texto sin cifrar: sin el almacén del SO, el producto se detiene y lo comunica (WASM-012 R4).
Cadena de suministro

R9 — Todo crate de frontend, player, backend y shell pasa por una lista de permitidos protegida por dependency-guard (ampliado de la especificación 063 AC8 / 103), con archivo de bloqueo, auditoría de vulnerabilidades, comprobación de licencias y ningún script de compilación que descargue de la red, salvo los declarados. El JavaScript de la página anfitriona se escribe a mano y es pequeño (WASM-002 Q6), sin árbol de gestor de paquetes.
R10 — Cada Build escribe un SBOM en un formato estándar, y los recursos de la página anfitriona incluyen hashes de integridad.
Seguro de forma predeterminada

R11 — Toda relajación (token de desarrollo, ws:// para una dirección que no sea loopback, origen comodín, CSP debilitada, omitir el análisis de secretos) es una configuración explícita cuyo nombre incluye unsafe, muestra una advertencia en el IDE y hace fallar Build de release.
R12 — El backend de desarrollo se vincula a loopback salvo instrucción en contrario, y la vista web de Preview carga solo su origen (WASM-008 R8).
Logs y privacidad

R13 — Los logs, informes de fallos y telemetría del backend, del frontend y del IDE nunca contienen tokens, contraseñas, secretos o campos marcados como sensibles. El plan enumera los datos personales tratados y adónde se envían.
Móvil

R14 — La lista de capacidades del shell da a cada ventana el acceso nativo mínimo, ninguno al origen remoto, y se genera a partir de las funcionalidades declaradas (WASM-012 R7, R12).
Garantía

R15 — La suite incluye: auditoría de dependencias y licencias; análisis de secretos frente a secretos introducidos deliberadamente; prueba de que la CSP y las cabeceras generadas coinciden con el texto esperado y de que una página bajo ellas no ejecuta scripts inline ni eval; búsqueda de puntos de inserción XSS; fuzzing del tratamiento de frames WebSocket, del mapeo JSON (WASM-005) y de la validación de tokens (WASM-003 R10), con un presupuesto de ejecución declarado.
R15b — (restricción) La aplicación utiliza aislamiento entre orígenes e hilos cuando la página los ofrece, y funciona sin ellos (operador, 2026-10-20; WASM-017 R19). Con aislamiento (COOP: same-origin, COEP: require-corp o credentialless), la página dispone de SharedArrayBuffer. Coste: todo recurso entre orígenes debe enviar CORS o CORP, o cargarse bajo credentialless. La vía plain es una alternativa probada como vía completa. La memoria del módulo nunca crece, la arena es fija, la memoria compartida tiene un máximo declarado y el cargador libera por completo las regiones, el módulo y los Workers de los formularios y aplicaciones destruidos (WASM-017 R2, R5, R7, R8).
R16 — Cuando la serie llega a release candidate, se registra antes del lanzamiento una revisión por alguien distinto del autor y, si el operador lo decide (Q1), una prueba de penetración externa.
Objetivos: modelo de amenazas con fronteras de confianza identificadas y un control por amenaza; CSP estricta y conjunto de cabeceras generado y probado; reglas de XSS, CSRF, CORS, tokens, secretos, cadena de suministro y logs, cada una verificable; valores predeterminados seguros con relajación explícita y rechazada en release; comprobaciones automatizadas (dependencias, análisis de secretos, política, puntos de inserción, fuzzing).
Fuera del alcance: refuerzo de seguridad del SO, protección contra manipulación, detección de root o jailbreak; WAF; detalles internos de proveedores de identidad; certificación de cumplimiento (propuesta en WASM-030).

Cuestiones:

Q1 — Prueba de penetración externa — abierto: obligatoria antes de la versión 2.0 o revisión por un segundo lector; el presupuesto y el proveedor corresponden al operador.
Q2 — Trusted Types — abierto: se exigen solo donde se admiten y requieren que el código del player los cumpla.
Q3 — Rigor del análisis de secretos — recomendado: alta entropía como advertencia; formatos conocidos como error.
Q4 — Contacto de seguridad y política de divulgación (archivo SECURITY) — abierto; necesario antes de la versión 2.0.
Q5 — Fijación de certificados para el backend del shell móvil — abierto: opción, exigencia o elección del desarrollador.
Estado: borrador. No iniciado según PROGRESS (PROG-83).

WASM-014 — Contrato del backend y su evolución
Estado: borrador. Depende de WASM-003 y WASM-005. Relacionado con WASM-009, 012 y 013.

Requisitos

Versiones y handshake

R1 — Toda compilación del backend tiene una versión de contrato y una versión de protocolo de transmisión. Toda compilación del frontend lleva la versión de contrato contra la que se compiló. Ambas se incluyen en la descripción de interfaz (WASM-003 R4).
R2 — Al abrir la conexión, ambos lados intercambian versiones y el backend responde accepted, accepted with a warning (cliente más antiguo, compatible) o refused, con el motivo y, cuando sea posible, la versión a la que debe actualizarse. El frontend dispara un evento definido; en caso de rechazo, la aplicación puede solicitar una actualización (enlace de la tienda en móvil).
R3 — La versión del protocolo permite servir más de una versión a la vez, dentro de una ventana declarada. Un cliente fuera de la ventana se rechaza con un mensaje de actualización, nunca con un error de protocolo.
Compatibilidad

R4 — Reglas de cambios compatibles e incompatibles en un programa exportado, escritas y comprobadas durante la compilación. Compatible: campo final opcional, nuevo programa exportado, ampliación de OCCURS, nueva clase de error. Incompatible: eliminar o renombrar un campo, cambiar PICTURE o USAGE de forma incompatible, reducir OCCURS, cambiar los roles requeridos, eliminar un programa.
R5 — Durante la compilación del backend, la nueva descripción de interfaz se compara con la última publicada (guardada en el proyecto). Cada cambio incompatible se notifica con el programa, el elemento y la regla. Release Build falla, salvo que el desarrollador incremente deliberadamente la versión mayor del contrato.
R6 — Un programa puede marcarse como deprecated, con un mensaje y una versión de eliminación. Llamarlo tiene éxito y dispara un evento de advertencia en el frontend.
Errores

R7 — Todo fallo tiene una clase de una lista cerrada: transport (sin conexión, cerrada, tiempo de espera agotado), authentication (ausente, inválida, caducada), authorisation (rol rechazado), validation (el payload no cabe en la disposición de datos), not found, version (R2), rate or size limit, application (el programa notificó un fallo), server. Tiene un código numérico estable, un mensaje en inglés para los logs y un campo para detalles del programa. Una clase desconocida se interpreta como server.
R8 — Clase application: un programa de backend notifica un fallo de negocio (pedido rechazado, clave duplicada) con un código y datos que el frontend lee en ON EXCEPTION, distinto de las clases de la plataforma. El mecanismo se decide en /plan (Q1).
Repetición y orden

R9 — El programa declara si es seguro repetirlo (idempotente). Tras una pérdida de conexión, el runtime solo repite si el programa se ha declarado seguro. En caso contrario, notifica transport e indica si la llamada puede haberse recibido (Q2).
R10 — Una llamada no idempotente puede llevar una idempotency key generada por el runtime; una repetición elegida por el desarrollador se responde con el resultado almacenado, durante un plazo declarado, sin ejecutar dos veces.
R11 — Las llamadas de una conexión se ejecutan en el orden en que se hicieron, salvo que el programa se declare independiente. Varias llamadas en curso (WASM-003 R6) no modifican el orden.
Tamaño, duración y streams

R12 — Un payload por encima del tamaño configurado se rechaza con size limit. Un resultado legítimamente grande utiliza fragmentación (reensamblada por el runtime, R13) o transferencia de archivos (R15).
R13 — (Opcional) Llamada de larga duración: el backend envía mensajes de progreso y una respuesta final. El frontend dispara un evento de progreso; el usuario o el programa puede cancelar, y el backend respeta la cancelación en el siguiente punto seguro.
R14 — (Opcional) Programa stream (feed, contador, log): el frontend recibe eventos, realiza subscribe y unsubscribe explícitos y se vuelve a suscribir tras una reconexión. Un cliente sin suscripción no supone ningún coste para el servidor (Q3).
Archivos

R15 — La carga y descarga forman parte del contrato: transferencia por fragmentos con tamaño declarado, lista de tipos permitidos y checksum, reanudable tras una caída, sujeta a límites de tamaño y tasa, con evento de progreso. El backend rechaza las rutas o nombres elegidos por el navegador (WASM-005 R15) y asigna los nombres a los archivos. La dirección de descarga se emite por solicitud, es de corta duración y está vinculada al llamador (Q4).
Evolución del contrato

R16 — Las reglas del propio contrato tienen una versión: cambiar el handshake, la lista de errores o el protocolo de archivos implica un cambio de versión del protocolo, con la ventana de R3.
R17 — El proyecto Desktop no se ve afectado.
Objetivos: versión de contrato en cada compilación y handshake en la conexión; regla de compatibilidad impuesta por una herramienta; modelo de errores con clases; comportamiento definido para reintentos, llamadas grandes y largas, streams y archivos.
Fuera del alcance: segundo protocolo (REST, GraphQL, gRPC); refuerzo de seguridad del transporte (WASM-003, WASM-013); el mapeo JSON en sí (WASM-005); servidores multiversión más allá de lo permitido por la compatibilidad.
Base existente: dos precedentes de formato de transmisión versionado (bincode FormIpcMessage, JSON lines RemoteDebugCmd) y la versión de manifiesto CURRENT_STRUCTURE.

Cuestiones:

Q1 — Cómo notifica un programa un fallo application — recomendado: built-in COBOL::"…" que el programa llama para que la plataforma distinga un fallo deliberado de un fallo real.
Q2 — “Puede haberse recibido” — abierto: declarar la garantía (at-most-once de forma predeterminada, at-least-once para programas seguros) y decidir si la clase application puede consultar el backend después.
Q3 — Streams — abierto: exigen estado de servidor por suscriptor, en tensión con WASM-003 Q2. Entran en la versión 2.0 o quedan para una especificación posterior.
Q4 — Desde dónde descargar un archivo — recomendado: dirección HTTPS de corta duración para la descarga; fragmentos por WebSocket para la carga.
Q5 — Retención de resultados de idempotencia y de descripciones de interfaz anteriores — abierto, junto con la especificación de operaciones.
Estado: borrador. No iniciado según PROGRESS (el contrato de WebSocket depende del backend, PROG-79).

[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.

[Eslopes]

WASM-017 — Arquitectura del módulo, modelo de memoria, hilos y frontera JavaScript
Estado: borrador, con las decisiones del operador de 2026-10-20 incorporadas. Depende de WASM-002, 010 y 016. Ajusta WASM-002, 010, 011, 013, 015 y 016.

Requisitos

Carga y vida del formulario

R1 — Build emite un módulo de programa para todo el proyecto, con el Common Code de cada formulario copiado, autocontenido (WASM-010 R2). El cargador lo obtiene mediante compilación en streaming e inicia el formulario principal en cuanto está listo.
R2 — Cada instancia de formulario tiene su WORKING-STORAGE en una región de la memoria de datos, asignada al crearla y liberada al destruirla (especificación 049: no residente y no conservada). Tamaño fijo durante la compilación (R7): datos estáticos más, para cada formulario, Instances × su tamaño. Instances es una propiedad del formulario (valor predeterminado: 4 para formularios que OpenFormSync/OpenFormAsync puedan abrir; 1 en los demás). Crear una instancia por encima de Instances provoca el error de ejecución de WASM-010 R11 con el nombre del formulario.
R3 — Cargador mediante fetch + instanciación en streaming. La integración ES-module es opcional y solo se utiliza mediante detección de funcionalidades (R6, R18). Las partes pesadas del player (WASM-016 R13) se obtienen en el primer uso mediante el mismo cargador.
R4 — El tiempo de vida sigue a COBOL, no a la pila: WORKING-STORAGE de un programa vive desde el primer CALL hasta CANCEL o hasta que se destruye la instancia del formulario. Excepción: programa INITIAL, que comienza limpio en cada llamada y cuyo estado se descarta al retornar.
R5 — Al destruir una instancia, el módulo libera y reinicializa su región, y el cargador libera todas las referencias (listeners, temporizadores, llamadas pendientes, entradas de la tabla del host). Al desmontar la aplicación, el cargador libera el módulo y las memorias y termina los Workers. La compilación de debug demuestra ambos casos (R20).
R6 — No se utiliza Component Model en la v1 (compatibilidad de Chrome no establecida). La API del host sigue utilizando imports y exports simples. Se reconsiderará cuando los tres motores tengan compatibilidad nativa (Q7).
Modelo de memoria

R7 — Memoria de datos de tamaño fijo durante la compilación (R2). Código generado sin memory.grow. Un dato que no se pueda dimensionar provoca un error de compilación que identifica el elemento.
R8 — Frames de texto y JSON en la arena de transporte de tamaño fijo, obtenido del límite de payload del proyecto (WASM-005 R11). Multi-memory: la arena es la memoria 1, separada de los datos (memoria 0). Single-memory: región reservada de la memoria 0. La API del host es la misma: offset, length y selector de memoria.
R9 — Multi-memory es el valor predeterminado del módulo (operador, 2026-10-20). Build también produce la variante single-memory (sin ninguna instrucción multi-memory), utilizada siempre para iOS (multi-memory desactivado de forma predeterminada) y siempre que la matriz de navegadores incluya Safari o la vista web de iOS (predeterminado). El paquete Web incluye ambas y el cargador comprueba WebAssembly.validate y carga la adecuada. Un proyecto sin Safari puede elegir “multi-memory only”; Build lo rechaza si la matriz incluye Safari (AC7). Solo el módulo emitido utiliza una segunda memoria; el player (Rust) no.
R10 — El host nunca conserva TypedArray o DataView sobre la memoria del módulo entre llamadas: obtiene la vista en cada uso. El player no entrega a JavaScript vistas que sobrevivan a una llamada; también se aplica a la memoria compartida.
La frontera

R11 — API del host de granularidad gruesa: las escrituras de propiedades de un handler se acumulan y se entregan en una llamada al finalizar o al suspenderse, y las lecturas reflejan las escrituras anteriores; un evento es una llamada; una llamada remota es una solicitud y una respuesta; ninguna llamada al host por iteración de bucle. Un programa de dibujo sigue la misma regla: los comandos se envían a un buffer en la arena y se ejecutan en una llamada (WASM-018 R6).
R12 — El texto cruza la frontera una vez en cada dirección: UTF-8 en la arena frente a cadenas JavaScript mediante TextEncoder/TextDecoder. Cuando el navegador ofrece JS String Builtins, el cargador puede utilizarlos (mediante detección de funcionalidades).
R13 — Los datos que no necesitan el programa (bytes de un archivo arrastrado, imagen, buffers de píxeles de los objetos gráficos) no pasan por el módulo: el player los mueve (WASM-014 R15, WASM-018).
R14 — Todo objeto Rust expuesto a JavaScript mediante wasm-bindgen tiene una liberación explícita (free() o dispose), llamada por unmount() y por el cargador durante el desmontaje. Pocos objetos y enumerados; ninguno queda solo a cargo del GC de JavaScript. Se aplica a los handles de los objetos gráficos (WASM-018).
R15 — Un panic termina esa instancia de forma limpia: la página anfitriona muestra un error legible con una acción de recarga y dispara un evento de error. Un error de ejecución COBOL no es un panic (WASM-010 R11). En la variante threaded, un panic en un worker también termina la instancia.
Compilación y base mínima

R16 — Player con perfil de release que prioriza el tamaño: lto, codegen-units = 1, panic = "abort", símbolos eliminados, opt-level según mediciones ("z" frente a "s") y un paso de wasm-opt; tamaños notificados (WASM-016 R13). Dos variantes del mismo código fuente: plain (Rust estable, base mínima) y threaded (nightly fijado, std reconstruida, atomics, bulk memory, memoria compartida, --target web, wasm-bindgen-rayon). El resto del workspace permanece en Rust estable, MSRV 1.92; nightly queda limitado al paso del player.
R17 — La compilación del producto ejecuta wasm-bindgen CLI con versión fijada, Binaryen wasm-opt con versión fijada y el empaquetador (WASM-002 Q2), nunca wasm-pack. Estas herramientas y nightly existen solo en la compilación del producto; se aplican las reglas de cadena de suministro (WASM-013 R9); la fecha de nightly se registra en cada compilación.
R18 — Base mínima de funcionalidades WebAssembly y matriz de navegadores (Chrome y Edge, Firefox, Safari, vista web de iOS, Android WebView), a partir de MDN y Can I Use en /plan. El cargador comprueba y selecciona de forma independiente: variante del módulo (R9), variante del player (R19) y aceleración opcional (JS String Builtins, ES-module). Si no se cumple la base mínima, muestra el mensaje de WASM-002 R15.
Concurrencia

R19 — Los hilos y Rayon están incluidos en la v1 (operador, 2026-10-20):
(a) Rayon se ejecuta en el player y en los objetos gráficos (filtros y remuestreo de imágenes, rasterización de gráficos y canvas, física, ordenación y filtrado de DataGrid), en un pool dimensionado según navigator.hardwareConcurrency (limitado, configurable), en el player threaded;
(b) el módulo se ejecuta en un Worker dedicado cuando la página tiene aislamiento entre orígenes; las llamadas al host se redirigen al hilo principal (escrituras por lotes, lecturas mediante espera en memoria compartida) para que un bucle largo no congele la página. Sin aislamiento, el módulo se ejecuta en el hilo principal con cesión cooperativa (WASM-010 R9). Los resultados no dependen del modo;
© el aislamiento (COOP: same-origin con COEP: require-corp o credentialless) se exige para los hilos y es una propiedad del despliegue: Build imprime las cabeceras y ofrece un shim de service worker opcional (desactivado de forma predeterminada); los recursos de otros orígenes deben permitirlo (CORS o CORP);
(d) una página que integra la aplicación solo está aislada si la página anfitriona lo está; en caso contrario, utiliza el player plain y el hilo principal;
(e) nada exige hilos para garantizar la corrección: todas las funcionalidades funcionan en el player plain y en el hilo principal, y una prueba ejecuta los mismos casos en cada uno (R20);
(f) resultados deterministas: una reducción Rayon no puede depender del número de hilos (WASM-018 R20).
R20 — Suite de pruebas para cada combinación de variante del módulo, variante del player y modo (Worker, hilo principal): carga (módulo obtenido al inicio; parte pesada solo en el primer uso); liberación (abrir y cerrar un formulario muchas veces vuelve a la línea de base; unmount termina los Workers); memoria fija; procesamiento por lotes (un handler con 1000 propiedades realiza como máximo un número declarado de llamadas); cadenas (ida y vuelta UTF-8 con multibyte); vista (una llamada que hace crecer la memoria del player mantiene las lecturas correctas); base mínima y matriz (un navegador por debajo de la base mínima recibe el mensaje); aislamiento (con y sin COOP/COEP, se elige la variante correcta y los resultados son los mismos); cesión (un bucle largo mantiene los frames dentro de un plazo en el hilo principal).
Objetivos: módulo que utiliza streaming, se compila mientras se descarga e inicia rápidamente, con partes pesadas bajo demanda; memoria del formulario devuelta al destruirlo, demostrado mediante una prueba; modelo de memoria sin crecimiento y sin vistas desconectadas; multi-memory de forma predeterminada y single-memory donde falte; API del host con bajo coste al cruzarla; concurrencia real donde la plataforma lo permite, nunca exigida para la corrección; compilación compacta y reproducible, con base mínima y matriz impuestas por Build.
Fuera del alcance: hilos en la semántica de COBOL; Component Model, WebAssembly GC y memorias de 64 bits en la v1; cifras de rendimiento (la especificación solo las hace medibles).

Tabla de decisiones de tratamiento (§1): 1a carga bajo demanda (un módulo; partes pesadas del player: gráficos, mapas, Viewer, motor 3D); 1b Component Model no adoptado; 1c ES-module opcional y detectado; 1d “destruir al retornar” adaptado a COBOL (región por formulario, INITIAL descartado); 2a JS String Builtins opcionales; 2b multi-memory predeterminado con la arena como memoria 1; 3 .free() para el player y los objetos gráficos; 4 sin memory.grow en el módulo; 5a llamadas de granularidad gruesa como regla; 5b hilos y Rayon adoptados; 6 perfil que prioriza el tamaño y wasm-opt para el player, nightly fijado para la variante threaded.

Cuestiones:

Q1 — Un módulo por proyecto — decidido (2026-10-20). Coste: primera descarga mayor, mitigada mediante streaming, compresión y partes bajo demanda.
Q2 — Presupuesto de cesión (ms) y número predeterminado de Workers — abierto: sugerencia hardwareConcurrency menos uno, limitado a 8.
Q3 — Variantes single/multi-memory — decidido (R9).
Q4 — Matriz de navegadores y versiones mínimas (en especial, la versión de iOS más antigua) — abierto, a partir de /plan.
Q5 — Aislamiento en el shell móvil (cabeceras del protocolo de recursos de Tauri; si la vista web de iOS aísla) — abierto. Si no hay aislamiento, se ejecutan el player plain y el hilo principal.
Q6 — wasm-opt — abierto, recomendado: solo en la compilación del player.
Q7 — Reconsiderar Component Model y ES-module — abierto; desencadenante: compatibilidad nativa en Chrome, Firefox y Safari.
Q8 — opt-level — abierto: "z" o "s" según mediciones.
Q9 — Nightly: fecha fijada y si build-std sigue siendo necesario — abierto.
Q10 — Shim de service worker para cabeceras — abierto: ofrecerlo, solo documentarlo o dejarlo fuera.
Estado: borrador. Los hilos, multi-memory y el player threaded se incorporan al player (PROG-45 a PROG-50).

Post añadido a las 01:55. Post anterior a las 01:54

WASM-018 — Canvas 2D, Canvas 3D y objetos gráficos, en todas las plataformas
Estado: borrador (parte 1 del plan implementada; véase la sección 7). Origen: operador, 2026-10-20: controles Canvas2D y Canvas3D y objetos para generar gráficos (juegos, gráficos de datos, manipulación de imágenes), en todas las plataformas, con crates populares y 100 % Rust. Depende de WASM-004, 010, 016 y 017.

Requisitos

El catálogo

R1 — Todas las cajas de herramientas ofrecen dos controles visuales, Canvas2D y Canvas3D, cada uno con propiedades, eventos, métodos, tamaño e icono predeterminados, secciones de Properties, recorrido de ida y vuelta .cfrm, documentación en System KB, prueba en tests/controls/, etiquetas en seis idiomas y nombres de métodos en el vocabulario cerrado.
Canvas2D: Width, Height (píxeles lógicos), PixelRatio, Smoothing, BackgroundColor, TargetFps (0 = redibujado bajo demanda), AutoPresent, AccessibleLabel; eventos onFrame (con milisegundos transcurridos), onPointerDown/Move/Up/Enter/Leave, onWheel, onKeyDown/Up, onTouchStart/Move/End, onResize.
Canvas3D: las mismas propiedades y eventos, más ClearColor, Msaa y Backend de solo lectura (WebGPU, WebGL2, Vulkan, Metal, Dx12, Software).
R2 — Cinco objetos no visuales, colocados en un formulario como Timer o RestClient: ImageBuffer (R11), Plot (R12), Scene3D (R9), Physics2D y Physics3D (R10). Lo que crean (serie, nodo, luz, cuerpo) son handles: enteros que RETURNING devuelve a un elemento de datos y que los métodos reciben. Un handle se libera mediante Release, al eliminar aquello que identifica y al destruir el objeto o formulario (WASM-017 R14).
R3 — Todo en un crate de Rust puro, cobolt-graphics, sin egui, web-sys ni sistema de archivos. Se compila para los destinos del host y para wasm32 en ambas variantes del player. El host desktop y el player solo proporcionan la superficie, los eventos de entrada, el reloj de frames y los bytes de los recursos.
100 % Rust

R4 — Un crate solo se incorpora si: es Rust; ningún script de compilación del conjunto predeterminado de funcionalidades compila C/C++ o enlaza bibliotecas del sistema (cc, cmake, bindgen, pkg-config), excepto las API gráficas del navegador y del SO a las que wgpu accede mediante bindings Rust; licencia permisiva compatible con Apache-2.0; release en los últimos doce meses; compatibilidad con wasm32; MSRV ≤ 1.92 (excepto el nightly del player threaded); supera los controles de dependencias de WASM-013 R9 (sin ring, sin aws-lc-rs). Lista de exclusión de pruebas: font-kit, freetype-sys, harfbuzz-sys, skia-safe, cairo-sys-rs, libwebp-sys, mozjpeg-sys y similares.
R5 — Crates elegidos (salvo que el plan demuestre que alguno incumple R4):
Rasterizador 2D: tiny-skia (CPU, trazados, trazos, líneas discontinuas, gradientes, patrones, máscaras de recorte, modos de mezcla; determinista);
Curvas: kurbo;
Texto: skrifa + rustybuzz + fontdb (contornos, conformación de texto latino, CJK, árabe e índico, búsqueda de fuentes), con unicode-bidi y unicode-linebreak;
Imágenes: image + imageproc + fast_image_resize (códecs de Rust puro, filtros, morfología, remuestreo);
Gráficos de datos: plotters con la funcionalidad de texto ab_glyph y un DrawingBackend propio sobre tiny-skia;
3D: wgpu + naga + glam + bytemuck + gltf (WebGPU y WebGL2 en el navegador; Vulkan, Metal y Dx12 en los demás); la capa de escena es propia;
Física: rapier2d y rapier3d (con parry), con parallel mediante Rayon y enhanced-determinism;
Paralelismo: rayon (en el navegador mediante wasm-bindgen-rayon);
Gamepad: gilrs en desktop; la Gamepad API del navegador mediante el player.
Rechazados, con su motivo: bevy (framework de aplicación, decenas de MB de Wasm, requiere controlar el bucle); three-d (segunda pila gráfica junto a wgpu); macroquad/miniquad (controlan la ventana y el bucle); charming (renderiza con JavaScript); skia-safe y cairo-rs (C o C++); vello (GPU todavía no estable, sustituible después detrás de la misma API).
Lista de visualización y paridad

R6 — Los métodos de dibujo registran comandos en una lista de visualización binaria versionada, definida una vez en cobolt-graphics, que el control ejecuta en una llamada: en Present/Flush, al final de onFrame con AutoPresent y antes de cualquier método que lea la imagen (ToImage, GetPixel, MeasureText, IsPointInPath). En el módulo generado, la lista reside en la arena de transporte y una llamada al host la entrega (WASM-017 R11); en el intérprete, reside en la memoria del host. Todos los hosts decodifican con el mismo Rust.
Canvas2D

R7 — Canvas2D con la semántica de HTML Canvas 2D API donde exista un equivalente (tabla de diferencias en KB):
Estado: Save, Restore, Clear.
Trazados: BeginPath, MoveTo, LineTo, QuadTo, CubicTo, ArcTo, Arc, Ellipse, Rect, RoundRect, ClosePath, Fill, Stroke, Clip.
Formas: FillRect, StrokeRect, ClearRect, DrawLine, DrawCircle, DrawPolygon.
Estilo: SetFillColor, SetStrokeColor, SetLineWidth, SetLineCap, SetLineJoin, SetDash, SetAlpha, SetBlendMode, SetLinearGradient, SetRadialGradient, SetPattern, SetShadow.
Transformaciones: Translate, Rotate, Scale, SetTransform, ResetTransform.
Texto: SetFont, SetTextAlign, DrawText, MeasureText.
Imágenes: DrawImage de un ImageBuffer (completo o rectángulo de origen, con o sin escala); DrawSprite para un frame de una hoja de sprites.
Lectura de vuelta: ToImage, GetPixel, IsPointInPath.
Presentación: Present.
Rasterización en CPU, con antialiasing y determinista (tiny-skia); un canvas grande puede rasterizarse por bloques en paralelo (R20).
R8 — Texto conformado (shaped), bidireccional y con saltos de línea correctos en los seis idiomas, incluidos japonés y chino, con fuentes del conjunto base incorporado o de Assets/. MeasureText devuelve exactamente el espacio que ocupa DrawText.
Canvas3D y Scene3D

R9 — Canvas3D renderiza una Scene3D con wgpu: SetScene, SetCamera, Render, Resize, Screenshot (a un ImageBuffer) y Pick (nodo bajo un píxel, mediante ray casting con parry3d). Scene3D ofrece:
Primitivas: AddBox, AddSphere, AddPlane, AddCylinder, AddCone, AddTorus;
LoadModel de glTF 2.0 o GLB, con mallas, materiales, transformaciones y animaciones esqueléticas y de nodos;
Transformaciones: SetPosition, SetRotation, SetScale, LookAt;
Materiales: color, metallic, roughness, emissive, ImageBuffer como textura, PBR metallic-roughness;
Luces: AddDirectionalLight, AddPointLight, AddSpotLight, SetAmbient, con mapas de sombras para luces direccionales y spot;
SetBackground, SetFog; cámaras AddCamera (perspectiva y ortográfica); SetAnimation/PlayAnimation; Remove; instancing; frustum culling.
Backend identifica lo que se ejecuta (WebGPU, después WebGL2 en la web; Vulkan, Metal o Dx12 nativo; software en las pruebas). Sin backend, muestra un mensaje legible y dispara un evento.
R10 — Physics2D y Physics3D: mundo (CreateWorld con gravedad); cuerpos estáticos, dinámicos y cinemáticos con formas (ball, box, capsule, convex hull, trimesh en 3D); SetPosition, SetVelocity, ApplyForce, ApplyImpulse; articulaciones (fixed, revolute, prismatic); RayCast; Step con paso de tiempo fijo opcional; GetPosition, GetRotation; eventos de colisión; Bind de un cuerpo a un sprite o nodo de Scene3D.
Objetos de imagen y gráficos de datos

R11 — ImageBuffer: Create, LoadAsset, LoadFromBytes, Encode (PNG, JPEG, GIF, WebP, BMP, QOI), Save (desktop escribe un archivo; web lo entrega al navegador o al backend), Resize (nearest, bilinear, Catmull-Rom, Lanczos), Crop, Rotate, Flip, Fill, GetPixel, SetPixel, DrawOnto un Canvas2D, Composite con modos de mezcla, y filtros: grayscale, invert, brightness, contrast, hue, saturation, threshold, blur (Gaussian, box), sharpen, edge detection, Convolve con kernel, dilate, erode, histogram. Decodifica solo con códecs de Rust puro, con límite de píxeles.
R12 — Plot con plotters: line, bar, scatter, area, pie, histogram, candlestick, heatmap, polar, error bars, superficie y dispersión 3D. Datos de AddPoint o de una tabla COBOL (SetSeriesFromTable: recuento, stride y tipo numérico descritos una vez, valores leídos en una pasada, WASM-017 R11). Títulos, ejes, leyendas, cuadrículas y estilos. Render en un Canvas2D, en un ImageBuffer o como texto SVG.
Entrada, frames y accesibilidad

R13 — Los controles canvas pueden recibir el foco y entregan teclado, puntero, rueda, tacto y gamepad como eventos y como estado consultable (IsKeyDown, PointerX, PointerY, GamepadAxis, GamepadButton); exponen AccessibleLabel y una descripción para la tecnología de asistencia; el programa puede definir una alternativa de texto.
R14 — Con TargetFps por encima de cero, el canvas dispara onFrame a esa frecuencia con el tiempo transcurrido, sincronizado con la pantalla (requestAnimationFrame en el navegador, repaint de egui en desktop). Se pausa cuando la página o ventana está oculta y limita la frecuencia con batería baja. El modo fixed-step proporciona a un juego un onFrame estable para la física.
Seguridad y límites

R15 — Límites (tamaño del canvas, píxeles decodificados, tamaño del modelo y la textura, nodos y cuerpos, longitud de la lista de visualización), definidos por el proyecto con valores predeterminados seguros; al superarlos, error legible. No leen archivos ni abren conexiones (recursos incorporados; el acceso remoto pasa por el backend). Decodificación de imágenes y modelos no confiables con códecs de Rust puro, sometidos a fuzzing (WASM-013 R15). Un shader o modelo no provoca la caída de la página; la pérdida del dispositivo gráfico se gestiona y se notifica.
Plataformas

R16 — Todo host que ejecuta formularios implementa los controles y objetos: el host de formularios egui (Preview del IDE, Run Form, aplicaciones compiladas), donde Canvas2D envía píxeles como textura y Canvas3D renderiza en una textura; y el player (Web y Mobile). El intérprete y el módulo generado implementan los métodos y construyen la lista de visualización (WASM-010 R7). La paridad intérprete/binario se aplica a todos.
R17 — Form Designer muestra los canvas como marcadores de posición etiquetados con el tamaño y el backend. Preview, Run Form y la aplicación construida muestran el dibujo en vivo.
R18 — El player carga el motor 3D, el código de gráficos de datos y los filtros de imagen como partes en el primer uso (WASM-016 R13, WASM-017 R3). Build informa de los tamaños.
R19 — El proyecto de ejemplo examples/PowerGraphics acompaña al producto con un juego (sprites, física, entrada), galería de gráficos, laboratorio de imágenes y visor 3D, construido y ejecutado en Desktop y Web en la suite. El capítulo del Developer’s Guide se escribe en release.
Determinismo y paralelismo

R20 — El trabajo con Rayon (filtros y remuestreo, renderizado de gráficos, división del canvas en bloques, fase amplia de física) produce el mismo resultado con cualquier número de hilos, incluido uno: el trabajo por píxel es independiente, las reducciones siguen un orden fijo y la física utiliza enhanced-determinism. Las pruebas comparan un hilo frente a varios y plain frente a threaded; las imágenes de referencia son exactas para el rasterizador CPU y están dentro de una tolerancia declarada para la GPU.
Objetivos: Canvas2D y Canvas3D más ImageBuffer, Plot, Scene3D, Physics2D y Physics3D en Desktop, Web y Mobile, con la misma API y los mismos resultados; implementaciones 100 % Rust de crates populares; lista de visualización que mantiene la granularidad gruesa de la frontera; todos los núcleos cuando la plataforma los ofrece, con resultados idénticos cuando no; proyecto de ejemplo que ejercita todo.
Fuera del alcance: audio (desktop ya reproduce sonido mediante Animator); motor de juegos general (ECS, planificador, pipeline de recursos); renderizador 2D por GPU (la vía GPU sería un cambio interno); sustituir los siete controles de gráficos, PictureBox o Animator; ray tracing, compute shaders para el desarrollador, VR y AR.
Estado actual (§1): 62 tipos en ControlType::ALL; methods.rs exige el nombre en el vocabulario cerrado, o se interpreta como subíndice; CALL … RETURNING devuelve un valor desde 2026-10-19 (así es como un handle vuelve a COBOL). Crates ya presentes en el árbol: tiny-skia, kurbo, ab_glyph, skrifa, image, wgpu, naga, glow. Ausentes: imageproc, glam, lyon, plotters, rapier, gltf, rustybuzz, cosmic-text.

[Eslopes]

Cuestiones:

Q1 — Rasterizador — decidido (reconsiderable): tiny-skia en CPU. Alternativa: vello (GPU) cuando sea estable.
Q2 — Capa de escena — decidido: propia sobre wgpu.
Q3 — Animación esquelética y sombras — decidido (están en R9).
Q4 — Renderizador desktop — abierto: eframe tiene glow y wgpu; compartir el dispositivo con Canvas3D exige wgpu. (El texto de la especificación llama a esto “Q7” en R16 y “Q4” en §7; registro ambas referencias tal como están).
Q5 — Adaptador de software para CI — abierto: para que las referencias 3D se ejecuten sin GPU.
Q6 — Nombres — decidido: ImageBuffer y Plot (evitando los controles Image y Chart).
Q7 — Fuentes — abierto: cuáles se incorporan al conjunto base para CJK y RTL, y si se cargan bajo demanda.
Q8 — Audio — abierto, fuera de esta especificación: un objeto de sonido sobre kira sería una especificación separada.
Plan (plan.md y tasks.md): tareas T1–T22.

Parte 1 (el crate), realizada: T1 base (lista de visualización v1, rasterizador, límites, handles); T2 motor de texto; T3 ImageBuffer; T4 Plot; T5 Physics2D/3D; T6 Scene3D y Canvas3D; T7 API orientada a COBOL, registro y handles con propietario; T8 control de dependencias; T9 mediciones y comprobaciones de tamaño; T10 plan y tareas.
Parte 2 (hosts), no iniciada: T11 adaptador del host egui; T12 bindings del intérprete (objetos como controles, vocabulario en methods.rs, RETURNING para handles); T13 generador y módulo generado (lista de visualización en la arena, una llamada al host); T14 partes del player (cargar motor 3D, gráficos y filtros en el primer uso).
Parte 3 (superficie del producto), no iniciada: T15 controles Canvas2D y Canvas3D (propiedades, eventos, .cfrm, Properties, caja de herramientas, tests/controls/); T16 marcador de posición del Designer; T17 System KB y chunked.data; T18 etiquetas en seis idiomas; T19 gamepad (gilrs y Gamepad API); T20 examples/PowerGraphics; T21 verificación en navegador y entre plataformas; T22 documentación y finalización.
Discrepancias registradas en el plan (respecto de la especificación): harfrust 0.12 en lugar de rustybuzz (archivado en upstream); icu_segmenter en lugar de unicode-linebreak (último release de 2023); tiny-skia 0.12 en lugar de 0.11.4 (el gradiente cónico de dos puntos es el de createRadialGradient); plotters con backends propios y motor de texto propio en lugar de ab_glyph; glam 0.33; gltf 1.4.1 sin la funcionalidad de lectura de archivos; naga solo como dev-dependency; hilos de rapier limitados a 256.

Pendientes del plan: no se ha verificado la regla de antigüedad del release de R4 (fechas no disponibles sin conexión). Las referencias de GPU difieren entre adaptadores (solo se ejecutó Metal).

Criterios de aceptación (AC1–AC14): AC1 (dibujo idéntico píxel a píxel en los tres destinos, texto en los seis idiomas); AC2 (diez mil formas en una sola llamada al host); AC3 (MeasureText igual a la extensión de DrawText en texto latino, japonés, chino y RTL); AC4 (glTF animado con luces, sombras y pick); AC5 (Backend informa de WebGPU, WebGL2 o ninguno); AC6 (mismas posiciones con 1 o N hilos y en plain frente a threaded); AC7 (desenfoque de 24 MP más rápido en threaded, medido); AC8 (una tabla COBOL de 100.000 valores se convierte en una serie en una pasada); AC9 (abrir y cerrar 100 veces un formulario con canvas, imagen y escena vuelve a la línea de base); AC11 (control de dependencias, plan T8); AC10, AC12 y AC13 no se describen en el resumen de lectura, véase la especificación; AC14 (el ejemplo web carga el motor 3D solo cuando aparece el formulario 3D).

4. Especificaciones propuestas, todavía sin archivo (WASM-019 a WASM-035)
Fuente: WASM-INDEX §5. “P2” se necesita inmediatamente después o junto con la serie; “P3” es posterior. Los números son provisionales. Ninguna tiene un archivo de especificación.

Propuesta Especificación Por qué falta actualmente P
WASM-019 Despliegue y operación del backend Contenedores, nube (PowerCloud ya conoce AWS), proxy inverso y TLS, escalado y afinidad de sesión, secretos, métricas y trazas (ampliando el documento de observabilidad), estado, actualizaciones graduales, migraciones y copias de seguridad P2
WASM-020 Accesibilidad e internacionalización de las aplicaciones generadas ARIA, orden del foco, contraste, RTL, formatos de configuración regional frente a PICTURE editado y DECIMAL-POINT IS COMMA, IME, UTF-8 en PIC X/PIC N y JSON, cambio de idioma durante la ejecución P2
WASM-021 Modelo de interacción táctil y móvil Gestos, pulsación prolongada como menú contextual, sin hover, comprobación de tamaño mínimo del objetivo táctil, comportamiento del teclado virtual, modos de entrada según PICTURE (teclado numérico), orientación, pull-to-refresh P2
WASM-022 Funcionamiento sin conexión, PWA y caché Service worker, cola de llamadas sin conexión, política de IndexedDB, flujo de actualización del paquete e invalidación de caché, posibilidad de instalación P2
WASM-023 Controles de datos posteriores a la v1 Paginación, ordenación y filtrado en el servidor para DataGrid; control optimista en Save; transacciones entre llamadas (COMMIT/ROLLBACK por el canal); bloqueo de registros con clientes remotos (depende de la corrección del bloqueo entre procesos) P2
WASM-024 Depuración y diagnóstico Puntos de interrupción COBOL durante la ejecución en el navegador (el crate DAP sobre WebSocket hasta el IDE), mapas de código fuente más allá de line table, telemetría de consola y errores, informes de fallos, identificadores de correlación entre los logs del frontend y del backend P2
WASM-025 Distribución y actualizaciones Alojamiento y CDN, cabeceras de caché, URL versionadas, actualizador de Tauri, listas de comprobación para el envío a las tiendas, qué hace update_check del IDE cuando existe 2.0.0 (lo ofrecería a todos los IDE 1.x.x), reversión P2
WASM-026 Conversión de proyectos y código compartido Asistente de conversión desktop → web que señala los controles y verbos no compatibles, pasos de project_upgrade, Common Code y copybooks compartidos entre desktop y web P2
WASM-027 Plantillas y ejemplos Plantilla Agentic AI Chatbot (Web) (la clave del modelo reside en el backend), UserControl (Web), versiones web de PowerChat, PowerAnalytics, PowerDemo3 y PowerSpatial, Create from Template… P2
WASM-028 Documentación, localización y plan de lanzamiento Capítulos del Developer’s Guide 2.0 (retenidos por la decisión de 2026-10-19), README, regeneración de las cinco traducciones en la versión menor, anuncios en el foro agrupados en el RC, pasos de release candidate a partir de 2.0.0 P2
WASM-029 Presupuestos de rendimiento Cifras que WASM-017 hace medibles: tamaño y arranque del módulo, rendimiento del módulo frente al intérprete (cobolt-bench), virtualización de DataGrid, memoria, tamaño de payloads P2
WASM-030 Licencias y cumplimiento Licencias de Leptos, Tauri, crate de vista web, emisor y empaquetador; políticas de uso de teselas de mapas; términos y consentimiento de reCAPTCHA; formularios de seguridad de los datos de las tiendas; leyes de protección de datos P2
WASM-031 Funcionalidades adicionales de identidad Inicio de sesión social y federación, passkeys/WebAuthn, modelo de autorización (roles y permisos), gestión de sesiones y dispositivos, log de auditoría P3
WASM-032 Plugins, controles personalizados y crates externos en wasm32 Custom { plugin_id } sin painter ni runtime; EXEC RUST rechazado en el navegador (WASM-002 Q4) y necesita una vía mediante el backend P3
WASM-033 Más controles nativos de la web Vídeo y audio integrados, imagen desde URL, IFrame, editor de texto enriquecido, cámara y lector de QR (móvil) P3
WASM-034 Otros factores de forma Smartwatch Android, Apple Watch, TV P3
WASM-035 Evolución del diseñador Diseñador basado en una vista web, diseñador que entiende CSS, marcos de dispositivo, vista previa del estado de componentes P3
Carencias estratégicas que señala el propio índice (afectan a todas las especificaciones):

El principio de “un renderizador para todo” (especificación 017) termina en la web: Form Designer dibuja con egui y la web con DOM. La paridad de píxeles es un objetivo medido (WASM-004 R11), y el operador decide cuánta diferencia es aceptable (WASM-004 Q6, WASM-007 Q5).
Un lenguaje, dos motores: el navegador ejecuta WebAssembly generado; el backend y desktop ejecutan el intérprete. Mantener ambos iguales es un criterio de aprobación medido (WASM-010 R16, WASM-015 R6).
El generador es la ruta crítica: la fase A de WASM-010 debe existir antes de la mayoría de los criterios de aceptación de las demás especificaciones.
Claves en formularios: AgentAPIKey y ConnectionString aceptan texto. Los ejemplos de 2026-10-19 dejan las claves vacías, y el control de análisis de secretos (WASM-002 R7, WASM-013 R7) es lo que lo garantiza.

5. Contrato de bajo nivel — WASM-ABI-v1 (152 elementos)
Estado: borrador 1, modificado el 2026-10-20. Es normativo para cobolt-wasm (productor), cobolt-web-player y el cargador de la página anfitriona (consumidores). Modificar el archivo implica modificar los tres. El campo abi del manifiesto aumenta cuando una regla cambia de forma incompatible. Actualmente abi: 1.

Convenciones (ABI-03 a ABI-06): enteros little-endian; varint es LEB128 sin signo, hasta 5 bytes; text es varint length seguido de bytes UTF-8; los offsets son bytes dentro de la arena.

Artefactos (§1):

program.wasm — variante multi-memory; memoria 0 = datos COBOL, memoria 1 = arena (ABI-07);
program.single.wasm — variante single-memory; la arena es una región de la memoria 0; sin instrucciones multi-memory (ABI-08);
player.wasm, player.js — construidos por el producto; plain y threaded (ABI-09);
manifest.json — también incrustado como custom section prmanifest (ABI-10);
formularios, hoja de estilos y recursos (ABI-11);
regla de imports: solo los de §3 (ABI-12); regla de exports: solo los de §4, además de las memorias y los pr_dbg_* opcionales (ABI-13).
Memoria (§2):

Memoria de datos 0 con tamaño fijo, mínimo y máximo iguales (ABI-14); sin memory.grow (ABI-15);
disposición: [constants][descriptors][form templates][instance regions: Instances × size per form][task stacks][scratch registers] (ABI-16);
arena: arena_size bytes, procedente del límite de payload (ABI-17, 1 MiB de forma predeterminada);
región batch (offset 0, 64 KiB de forma predeterminada, escrita por el módulo) (ABI-18);
región answer (offset batch_size, 64 KiB de forma predeterminada, escrita por el host) (ABI-19);
región frame-out (escrita por el módulo, una solicitud remota) (ABI-20) y frame-in (escrita por el host, una respuesta) (ABI-21);
en multi-memory, la arena es la memoria 1, con offsets absolutos (ABI-22); en single, una región de la memoria 0 a partir de pr_arena_base() (ABI-23);
el host determina la variante mediante pr_variant() y el export arena, nunca por suposición (ABI-24);
el host obtiene una vista de la memoria en cada uso y no la conserva entre llamadas (ABI-25).
Imports (§3), namespace "pr":

Post añadido a las 01:55. Post anterior a las 01:55

flush(len) — aplica los comandos de batch en orden; se llama al finalizar, al suspenderse, al ceder, cuando batch se llena y antes de cada query (ABI-27);
query(len) -> i32 — batch con comandos y una query; el host aplica, evalúa, escribe la respuesta en answer y devuelve el tamaño o un error negativo (ABI-28);
remote(len) -> i32 — envía frame-out y devuelve un request id (≥ 0) o un error; la tarea retorna entonces SUSPENDED (ABI-29);
now() -> f64 (ms desde la época Unix, UTC) (ABI-30); random() -> f64 en [0, 1) (ABI-31);
abort(len) — fatal, con comando ERROR; el host notifica, termina la tarea y mantiene la aplicación; no retorna (ABI-32);
imports exclusivos de conformidad: file_open, file_read, file_write, file_close (ABI-33, detalles en §8);
un host que no proporciona un import declarado se niega a iniciar, con el mensaje de WASM-002 R15 (ABI-34).
Exports (§4):

memory y arena (ABI-35); pr_abi() -> i32 (valor 1, ABI-36); pr_variant() -> i32 (bit 0 = multi-memory, bit 1 = conformance) (ABI-37); pr_arena_base() -> i32 (ABI-38); pr_init() -> i32 (se ejecuta una vez; 0 = ok) (ABI-39);
pr_open_form(form, opener) -> i32 — crea una instancia, devuelve el id de instancia o un error (-3 = sin instancia libre, error de WASM-017 R2 con el nombre del formulario) (ABI-40);
pr_close_form(inst) -> i32 — handlers de cierre, libera y reinicializa la región cuando la tarea está DONE (ABI-41);
pr_event(inst, ctrl, event, argc) -> i32 — ejecuta el handler vinculado a (ctrl, event) con argc textos leídos de answer (ABI-42);
pr_resume(task, len) -> i32 — continúa la tarea después de SUSPENDED o YIELDED (ABI-43);
pr_cancel(task) — abandona la tarea suspendida (ABI-44);
pr_tick() -> i32 — tarea actual o -1 (ABI-45);
pr_status() -> i32 — estado de la ejecución más reciente (ABI-46);
pr_dbg_live() y pr_dbg_region_used() — opcionales, para la prueba de liberación (ABI-47, ABI-48);
estados: 0 DONE (ABI-49), 1 SUSPENDED (ABI-50), 2 YIELDED (ABI-51), 3 STOPPED — STOP RUN o GOBACK del programa principal (ABI-52); negativo = error (ABI-53);
regla “uno a la vez” (ABI-54), sustituida por la enmienda A5.
Batch, módulo → host (§5):

op 0x01 SET (path, text) — asigna un valor a una propiedad o miembro (ABI-55);
op 0x02 CALL (path) — invoca un método y descarta el resultado (ABI-56);
op 0x03 DISPLAY (text) — consola del host (ABI-57);
op 0x04 ERROR (varint code, text message, varint unit, varint line, varint form, varint event) — error con posición COBOL (ABI-58);
op 0x05 LOG (varint level, text) — diagnóstico (ABI-59);
gramática de path: varint inst, varint ctrl, varint nseg, seg*, donde seg es varint name, varint nargs, text* (ABI-60);
ids de control: 0 = el propio formulario (ABI-61); 1 = el formulario que abrió este, super:: (ABI-62); 2 = el objeto de la aplicación, COBOL:: (ABI-63); controles numerados a partir de 3, en el orden de forms[i].controls (ABI-64);
tabla names del manifiesto, compartida por el módulo (ABI-65).
Queries, módulo → host, síncronas (§6):

la región batch termina con una query, op en 0x10…0x1F (ABI-66);
0x10 GET (path), 0x11 CALLR (path), 0x12 COUNT (path) (ABI-67, ABI-68, ABI-69);
el host aplica los comandos antes de la query para que la lectura refleje las escrituras del propio handler (ABI-70);
el código generado no emite una query por iteración de bucle, salvo que haya una lectura de control en el bucle (ABI-71).
Eventos, host → módulo (§7):

pr_event identifica el control y el evento por su índice en la tabla events del manifiesto, con los nombres de desktop (ABI-72);
argc textos al comienzo de answer (ABI-73);
los eventos sin handler no se entregan: el manifiesto enumera los pares con handler (ABI-74).
Conformidad (§8), solo hosts de prueba:

file_open(name_len, mode) con modo 0 input, 1 output, 2 extend, 3 input/output (ABI-75); file_read(handle, cap), -1 = fin de archivo (ABI-76); file_write(handle, len) (ABI-77); file_close(handle) (ABI-78); bit 1 de pr_variant activado (ABI-79);
el cargador rechaza un módulo de conformidad en una página, en el shell Tauri y en Preview (ABI-80).
Códigos de error (§9): -1 genérico (ABI-81); -2 argumento inválido (ABI-82); -3 sin instancia libre (ABI-83); -4 formulario, control, evento o verbo desconocido (ABI-84); -5 payload demasiado grande para la arena (ABI-85); -6 el host rechazó por permiso o política (ABI-86); -7 sin conexión o fallo de transporte (ABI-87); -8 cancelado (ABI-88); -9 tiempo de espera agotado (ABI-89); -10 el módulo produjo un trap (ABI-90). Un error de ejecución COBOL no es un trap: llega como ERROR y estado negativo (ABI-91). Un trap es un defecto del generador y se convierte en -10 con la última línea conocida, mediante la global $line (ABI-92).

Manifiesto (§10, JSON en prmanifest): campos abi (ABI-93), generator (ABI-94), project (ABI-95), variant con multi_memory y conformance (ABI-96), limits con arena_size 1048576, batch_size 65536, answer_size 65536, frame_size 393216, budget_blocks 20000 y data_pages 17 (ABI-97), names (ABI-98), events (ABI-99), forms con {id, name, main, instances, region_size, controls[{id,name,type}], handlers[{ctrl,event,entry}]} (ABI-100), builtins (ABI-101), imports (ABI-102), sizes con module, rt_functions y rt_bytes (ABI-103). Custom sections prmanifest (ABI-104) y prlines, que vincula un line id con unidad, línea y columna (ABI-105). Global $line exportada para diagnóstico (ABI-106). Name section con form.paragraph.block (ABI-107).

Lista de comprobación del host (§11): ABI-108 (streaming, comprobación de variante, verificación de pr_abi); ABI-109 (imports exactos, manifiesto, pr_init, pr_open_form del formulario principal); ABI-110 (aplicar batch en orden, nunca retener una vista, encolar eventos, reanudar después de YIELDED); ABI-111 (pr_close_form al destruir y liberar referencias); ABI-112 (UTF-8 en ambas direcciones, una conversión por dirección).

Enmiendas de 2026-10-20 (§12), cada una es una regla que la implementación demostró incompleta:

A1 — pr_status enumerado como export (ABI-114). Afecta al generador: sí.
A2 — pr_close_form devuelve el estado; la región se libera cuando está DONE (ABI-115). Afecta al generador solo si el handler de cierre se suspende.
A3 — exports opcionales pr_dbg_* para la prueba de liberación (ABI-116). No afecta al generador.
A4 — ERROR.code es la magnitud (3 para -3) o un número COBOL a partir de 1000 (ABI-117). Afecta: sí.
A5 — varias tareas suspendidas al mismo tiempo, una por instancia de formulario; las tareas de distintas instancias se intercalan (un OpenFormSync suspende al que abre mientras se ejecuta el hijo); los eventos de una misma instancia permanecen en serie; pr_resume(task, len) identifica la tarea; pr_cancel(-1) descarta la ejecución que produjo un trap (ABI-118). Afecta: sí, tabla de tareas y estado por tarea. El fixture tiene 4 tareas: el que abre, el hijo modal y dos reservas.
A6 — frame de error para una llamada remota que falla: {"id":N,"error":{"class","code","message","may_hav e_been_received"}}, con clases transport, authentication, limit y client. Una llamada enviada cuando cayó el enlace tiene may_have_been_received: true y nunca se repite. Frame de éxito: {"id":N,"result":…} (ABI-119). Afecta: sí.
A7 — verbos de COBOL:: y me:: que implementa el player, cuáles se suspenden y el texto de argumento de cada evento (ABI-120). Un verbo desconocido responde -4 y un ERROR. Afecta: sí.
A8 — sobre de mensajes en la conexión entre player y backend (ABI-121): primer mensaje {"type":"auth","token":…}; llamada {"type":"call","id":N,"frame":{…}}; respuesta {"id":N,"result":…} o {"id":N,"error":{…}}; ping y pong; un error de autenticación con expired hace renovar el token y repetir una vez. Los ids inferiores a 0x80000000 son del módulo; los superiores, del player (control Authentication). Es una propuesta del player hasta que WASM-014 la sustituya. No afecta al generador; el backend debe utilizar este formato.
Verbos COBOL:: (objeto de la aplicación, ctrl 2) — §12.1:

MessageBox, Alert (texto, título, botones; se suspende hasta cerrar; botón en DialogResult) (ABI-122);
Confirm (como el anterior, con botones de pregunta; se suspende) (ABI-123);
InputBox (texto, título, valor predeterminado; texto introducido en DialogResult; se suspende) (ABI-124);
Sleep, Wait (milisegundos; se suspende) (ABI-125);
OpenFormSync, OpenFormAsync (nombre del formulario; handle; Sync se suspende hasta que se cierra el hijo) (ABI-126);
Navigate, OpenUrl (dirección y destino, según la política de WebLink; no se suspende) (ABI-127);
Download (nombre y texto; no se suspende) (ABI-128); CopyToClipboard (ABI-129); SetTitle (ABI-130);
GetProperty, SetProperty (propiedades de la aplicación: DialogResult, Locale, Standalone, Title…) (ABI-131);
StopRun, Exit (la aplicación termina; STOPPED) (ABI-132).
Verbos me:: (formulario, ctrl 0) — §12.1:

OpenFormSync, OpenFormAsync — solo Sync se suspende (ABI-133);
Close — cierra después de que termina el handler (ABI-134);
SetTitle, SetFullscreen, SetFocus, GetFormState… (la lista termina en puntos suspensivos, no es exhaustiva) (ABI-135).
Authentication (ctrl del control) — §12.1: SignOut, Refresh, GetClaim (valor de una claim, nunca el token) (ABI-136).

Argumento de cada evento — §12.2 (todos los argumentos son text):

teclado (onKeyDown, onKeyPress, onKeyUp): la tecla (ABI-137);
onMouseWheel: delta vertical (ABI-138); onCheckedChanged: true o false (ABI-139); onItemChecked: elementos marcados separados por salto de línea (ABI-140); onItemDoubleClick: texto del elemento (ABI-141); onTabClick y onTabChanged: número de página, a partir de 1 (ABI-142);
onNodeClick, onNodeSelect, onNodeDblClick, onNodeCheck: text⇥index⇥level⇥checked (ABI-143);
onMenuClick, onMenuItemClick: id del elemento (ABI-144); onClick de un botón de ToolBar: id; de WebLink: modificadores (ABI-145);
onCellClick, onCellDoubleClick: row,column a partir de 0 (ABI-146); onRowDoubleClick: fila; onColumnClick: columna (a partir de 0);
onMapClick: latitud y longitud con seis decimales (ABI-147); onMarkerClick: id del marcador (ABI-148);
onFilesDropped, onFilesRejected: nombres separados por salto de línea (ABI-149);
onButtonClick de Snackbar: id del botón (ABI-150);
onSignedIn, onSignedOut, onSignUpCompleted, onPasswordResetRequested, onMfaRequired: sin argumento (ABI-151);
onError de Authentication: clase y código de la respuesta del backend, nunca el mensaje (ABI-152).

[Eslopes]

6. Plan de ejecución — WASM-PLAN (85 elementos)
Documento de orden, crates y riesgos. Cada especificación tiene su propio plan.md y tasks.md, escritos cuando se retome la especificación. No indica el estado por elemento: el estado real está en PROGRESS (sección 7).

Artefactos y responsables (§1):

Módulo de programa — cobolt-wasm (generador y minienlazador), cobolt-wasm-rt (rutinas en Rust para wasm32, distribuidas como un blob), cobolt-decimal (núcleo decimal exacto compartido con el intérprete). Producido por Build del IDE, en segundos, sin cadena de herramientas de Rust (especificaciones 010, 017, 005);
Player — cobolt-web-player (Leptos) y cobolt-graphics; construido una vez por el producto (especificaciones 016, 004, 006, 007, 011, 018);
Página anfitriona y cargador — plantillas de cobolt-compiler (HTML, JS, CSS) (especificaciones 002, 011, 013);
Backend — cobolt-server, nativo (especificaciones 003, 005, 014, 009);
Integración del IDE — cobolt-ide, cobolt-codegen, cobolt-project-tools (especificaciones 001, 008, 015, 012).
Decisiones de ejecución (P1–P8):

P1 — cobolt-wasm-rt es #![no_std], compilado para wasm32-unknown-unknown; rutinas escritas una vez en Rust y enlazadas estáticamente (WASM-010 Q3 (a)); blob versionado en crates/cobolt-wasm/assets/rt.wasm con hash en un archivo adjunto y prueba de actualización; el minienlazador copia solo las funciones alcanzables (tree-shaking), renumera y fusiona los datos estáticos.
P2 — extracción del núcleo decimal a cobolt-decimal (sin std, sin alloc), solo en 2.x.x. Coste declarado: una corrección 1.x.x en value.rs se porta a mano, no mediante cherry-pick.
P3 — el programa se transforma en un grafo de bloques; cada bloque es una función que devuelve el siguiente id o un código reservado (SUSPEND, END, ERROR). Ninguna transferencia de control COBOL utiliza la pila de WebAssembly. Estado de la tarea (pc, pila de PERFORM, pila de CALL) en la memoria lineal. Alternativas rechazadas: función única con loop/br_table, Asyncify y JSPI.
P4 — descriptor por elemento (offset, usage, digits, scale, sign, length); aritmética como secuencia de rt_ld, rt_add, rt_st sobre una pequeña pila de registros en un área temporal que nunca atraviesa una suspensión.
P5 — oráculo: el intérprete, después el estándar; la suite NIST y el estándar deciden cuando discrepan. Cada diferencia se clasifica en WASM-PARITY.md (defecto del generador, defecto del intérprete como corrección 1.x.x, o discrepancia aceptada, con registro del texto del estándar). Harness diferencial cobolt-wasm/tests/parity.rs. El criterio de aprobación es la ejecución NIST.
P6 — flag --conformance del generador, para verbos de archivos secuenciales y line-sequential, solo en el control NIST; esos verbos se convierten en imports file_*; el flag se incluye en el manifiesto; el player y el cargador rechazan los módulos de conformidad; Build de un proyecto web nunca lo activa.
P7 — motores de pruebas: wasmi (Rust puro) para pruebas unitarias y de conformidad; node con V8 para multi-memory fiel al navegador; Chrome y Safari mediante las herramientas de WASM-015 para el player.
P8 — orden: GOLDEN RULE #9 se aplica al generador (NC termina en ambos ejes antes de IF e IC); el resto avanza en paralelo donde los archivos son disjuntos.
Frentes de trabajo (W0–W8):

W0 — documento ABI v1 y este plan (realizado);
W1 — cobolt-graphics: lista de visualización, texto, ImageBuffer, Plot, Scene3D, Physics, handles, límites, control de dependencias (especificación 018; agente G, fusionado);
W2 — CALL … WITH WEBSOCKET LINKAGE, mapeo de grupo ⇄ JSON con vectores de referencia, cobolt-server, contrato y backend de identidad (especificaciones 005, 003, 014, 009; agente B, en curso);
W3 — cobolt-decimal, cobolt-wasm-rt, cobolt-wasm (disposición de datos, transformación, enlazador, código de integración de la API del host), harness de paridad, NC → IF → IC (especificaciones 010, 017; realizado en gran parte);
W4 — player: cobolt-web-player, JS del cargador, página anfitriona, variantes, Viewer mediante construcción de nodos, controles de clases A a E, CSS, navegación, WebLink, control Authentication (lado frontend), controles Canvas conectados a W1 (especificaciones 016, 002, 004, 006, 007, 011, 009, 018; agente P, fusionado en 2.0.24);
W5 — IDE: tipos de proyecto y selector, entradas del árbol, claves Tr, conexión de Build, Run y Preview, vista previa en una vista web (especificaciones 001, 008, 015; fusionado en 2.0.20);
W6 — controles de seguridad y matriz de pruebas, herramientas para agentes, System KB y chunked.data (especificaciones 013, 015; pendiente);
W7 — shell móvil Tauri 2 (especificación 012; pendiente);
W8 — registro de paridad y correcciones portadas a 1.x.x donde el intérprete se equivoca (especificación 010 R16; WASM-PARITY.md; pendiente).
Riesgos (1–7):

El generador es la ruta más larga (NC = 95 programas, 4614 aserciones). Mitigación: primero el harness diferencial, fase A pequeña, registro por fase.
Disposición fiel a los bytes frente a un intérprete basado en valores (REDEFINES, movimientos de grupo sobre COMP-3, MOVE superpuesto). El estándar y NIST son el árbitro.
El minienlazador para un módulo de Rust es infraestructura nueva (puntero de pila global, segmentos de datos, tabla de llamadas indirectas, name section). Mitigación: -C panic=abort, sin alloc, inventario de tree-shaking y wasm-tools validate en cada salida.
Cadena de herramientas: trunk 0.22 requiere rustc 1.96.1 (instalado: 1.95). Utilizar trunk 0.21.14 o wasm-bindgen directamente; nightly fijado para threaded, instalado cuando W4 llegue a ese punto.
lopdf impide que cobolt-forms se compile para wasm32 (código PDF de Viewer). Desactivar PDF en wasm32 mediante una funcionalidad de cargo, algo que W4 realiza y prueba en ambos destinos.
Disco: cada worktree tiene su target/; los agentes clonan con cp -cRp; ningún cargo clean del compartido.
Agentes en paralelo realizando fusiones: cada agente es responsable de crates disjuntos; la integración se realiza mediante merge en features-2x, resolviendo Cargo.toml, Cargo.lock, versión y CHANGELOG a mano.
Definición de terminado de la serie (PLAN §5): cada especificación en V en el registro, con evidencia identificada, y cinco hechos verdaderos, cada uno con una ejecución registrada:

un proyecto web construido mediante Build del IDE se abre en el navegador y en Preview del IDE; los handlers se ejecutan en el módulo generado; el player dibuja los controles;
un CALL remoto llega a un backend autenticado por wss, suspende el módulo y se reanuda con la respuesta;
NC, IF e IC se ejecutan en el módulo generado con 0 fallos;
los players threaded y plain y las dos variantes del módulo superan la matriz de WASM-017 R20;
los shells Android e iOS ejecutan el mismo paquete según la cadena de herramientas de la máquina; lo que no pueda ejecutarse queda en el registro con el comando exacto, “nunca declarado como realizado”.
7. Estado de implementación (WASM-PROGRESS.md, 2026-10-20)
Leyenda del registro: S especificado · P planificado (plan.md) · T con tareas (tasks.md) · I en implementación · V verificado. Una fila solo queda como done cuando sus criterios de aceptación se han ejecutado y superado, con evidencia identificada.

7.1 Estado en el registro: las 18 especificaciones están marcadas solo como S. Las columnas P, T, I y V están vacías. El texto del propio registro documenta un trabajo mucho más avanzado (véase 7.2), por lo que la tabla está desactualizada.

7.2 Ya realizado

NC (NIST Nucleus) en un módulo generado — 2.0.19: compila 95/95 y ejecuta 95/95 con 0 fallos. Módulo: 4612 PASS / 0 FAIL / 5 DELETED; intérprete: 4614 / 0 / 5. La diferencia de 2 se debe al recuento del harness (cuenta los marcadores PASS del archivo de impresión), y la línea de resumen de cada programa es idéntica en los 95. Doce cambios del intérprete aplicados y probados (comparación de números con caracteres, BLANK WHEN ZERO, VALUE en editado, movimiento de grupo alfanumérico editado, desedición con inserciones, INSPECT en numérico con signo, OCCURS DEPENDING ON, nivel 66 y RENAMES, PERFORM VARYING AFTER, WHEN apilados, DIVIDE GIVING editado, claves externas mediante el host).
IF (funciones intrínsecas) en un módulo generado — 2.0.20: 45/45 compilan y se ejecutan; 841 PASS / 0 FAIL.
IC (programas anidados y llamadas) — 2.0.22: 25/25 compilan y se ejecutan; 309 PASS / 0 FAIL / 4 DELETED. Cubre unidades de programa, CALL/CANCEL, LINKAGE, GLOBAL/EXTERNAL, archivos OPTIONAL y declarativas USE.
cobolt-decimal — V. Suite del intérprete: 1527 superadas, 0 fallidas.
cobolt-numedit — V. 199.233 casos aleatorios, 0 diferencias frente al original.
cobolt-wasm-rt — I. 15 pruebas nativas (códecs, MOVE, aritmética, condiciones, DISPLAY, pictures editadas, INSPECT, STRING, UNSTRING, INITIALIZE, archivos de conformidad).
cobolt-wasm (generador), fases A y B de WASM-010 — I. Programas iguales al intérprete, byte a byte, en ambas variantes de memoria. Los módulos se validan. “Hello” tiene 15,8 KB.
Player, cargador, página anfitriona y paquete — fusionados en 2.0.24 (7 commits). Verificados en Chrome y node frente a un módulo fixture, no frente a un módulo generado.
ABI A5 a A7 — vinculan al generador: los exports de formulario en compile_project se escriben conforme a ellas (PROG-43, vinculante).
IDE: tipos de proyecto, selector, árbol, Preview y herramientas — fusionados en 2.0.20.
cobolt-graphics, parte 1 (el crate) — fusionado en 2.0.21. Según el plan: 330 pruebas superadas en macOS; compila para wasm32 en 20 de 20 combinaciones de funcionalidades.
CALL … RETURNING local — corrección 8a15f00d (1.91.219) en main, portada como afe22c51 (2.0.1) en 2.x.x.
7.3 Pendiente