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