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