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.