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