[Eslopes]

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

Requisitos

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

Cuestiones:

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

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

Requisitos

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

Cuestiones:

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

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

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

Requisitos

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

Cuestiones:

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