vipink1203/cumplimiento-app

Cumplimiento de la aplicación

Cada aplicación pasa estas puertas antes de llegar a usuarios reales, y sigue pasándolas a medida que cambia. Una puerta es una obligación con una regla, qué construir y una verificación de "hecho cuando". El estado de cada puerta se registra en el expediente de cumplimiento del proyecto, para que nada se pase por alto confiando en la memoria o en buenas intenciones.

Esto es ingeniería basada en leyes investigadas, no asesoramiento legal. Las reglas provienen de las notas con fuentes en research/, con fecha 2026-10-31: 01 privacidad y consentimiento, 02 comercio y afirmaciones y 03 accesibilidad, PI e IA. Cuando una nota tenga más de 6 meses de antigüedad en el momento de la ejecución, verifica nuevamente las fuentes primarias citadas en las secciones que estés utilizando (con una habilidad de investigación, si la tienes) antes de considerar sus fechas y umbrales como actuales.

Principios

• Una misma compilación para todos. Compila según el estándar común más estricto (GDPR para privacidad, California para suscripciones y precios, WCAG 2.2 AA para accesibilidad) para cada usuario, en lugar de bifurcar por país.
• El mapa de datos es la verdad. Las páginas legales, los avisos de consentimiento y la lista de proveedores describen lo que el código y la app en vivo realmente hacen, encontrado leyendo el código y capturando tráfico, nunca lo que una plantilla supone. Cuando la aplicación cambia, las páginas cambian en el mismo commit.
• Evidencia o nada. Cada afirmación, sello, logotipo, reseña y número en la aplicación apunta a una entrada de evidencia en el expediente.
• El propietario decide, el agente redacta. El agente escribe páginas, código y pruebas; las firmas, registros, permisos y juicios legales son acciones del propietario, y el agente nunca marca una como completada en nombre del propietario.

Pasos

1. Mapea los datos. Construye el mapa de datos en el expediente de cumplimiento a partir del código y una ejecución en vivo: cada campo de formulario y entrada de API con datos personales, cada columna de base de datos o almacenamiento que los contenga, cada cookie y clave de localStorage/sessionStorage/IndexedDB, cada dominio al que llama la aplicación (captura un HAR de Playwright de cada ruta, y una captura con proxy como mitmproxy de una instalación móvil limpia), cada SDK en el árbol de dependencias y cada correo electrónico que la aplicación envía. Para cada elemento: propósito, base legal, dónde se almacena, período de retención y qué proveedor lo recibe. Hecho cuando la búsqueda en el código y el HAR no muestren nada ausente del mapa.
2. Establece el alcance. Responde en el expediente: ¿Quiénes son los usuarios (consumidores, empresas, ¿niños posible?)? ¿Dónde (EE.UU., UE/Reino Unido, otros lugares)? ¿Qué tan grande es el negocio (personal, facturación)? ¿Acepta pagos o suscripciones? ¿Envía correos electrónicos de marketing? ¿Almacena contenido proporcionado por los usuarios (publicaciones, comentarios, archivos, perfiles, avatares)? ¿Muestra resultados de IA o un chat de IA? ¿Maneja datos de salud, financieros, biométricos o de ubicación precisa? Un "sí" en datos sensibles o niños agrega una revisión legal a las acciones del propietario.
3. Recorre cada puerta. Lee cada archivo de puerta a continuación y asigna a cada puerta un estado: pass (aprobado), fail (fallo), n/a (no aplica, con la respuesta de alcance que lo descarta) o owner (esperando una acción del propietario).
   • gates/privacy.md: aviso de privacidad, minimización, retención, solicitudes de acceso y eliminación, niños, entrenamiento de IA con datos de usuario, proveedores, DPA y subprocesadores (PRIV).
   • gates/consent-and-tracking.md: banner de cookies, bloqueo de rastreadores antes del consentimiento, señales de exclusión, consentimiento de marketing separado (CONSENT).
   • gates/terms-and-payments.md: aceptación de términos y su registro, precios completos, reembolsos, renovación automática, cancelación, desistimiento en la UE (TERMS, PAY).
   • gates/marketing-and-claims.md: afirmaciones, sellos de seguridad, reseñas, logotipos, tiempo de actividad, urgencia, patrones oscuros, datos de la empresa, correo electrónico de marketing (CLAIM, UX, BIZ, EMAIL).
   • gates/accessibility.md: escaneo WCAG 2.2 AA, contraste, texto alternativo, teclado, enfoque, tiempos y objetivos, declaración de accesibilidad de la UE (A11Y).
   • gates/licenses-and-content.md: licencias de código, fuentes, imágenes e iconos, notificación y eliminación de contenido de usuario (LIC, UGC).
   • gates/ai.md: divulgación de chat de IA, etiquetado y marcado de contenido generado (AI).
4. Corrige y demuestra. Construye lo que necesita cada fail, luego ejecuta su verificación de "hecho cuando": comprobaciones automatizadas como pruebas en el conjunto de pruebas del proyecto para que sigan ejecutándose, comprobaciones manuales registradas con fecha y resultado. Hecho cuando cada puerta sea pass, n/a o owner, sin ningún fail restante.
5. Entrega. Escribe la lista de acciones del propietario al inicio del expediente e informa al propietario en la sesión, una línea cada una: qué hacer, por qué y dónde.

En un cambio posterior, repite los pasos 1 y 3 a 5 para los archivos de puerta que toque el cambio, y actualiza el expediente en el mismo commit.

El expediente de cumplimiento

Cada aplicación mantiene un expediente en docs/compliance.md en su repositorio, actualizado en el mismo lugar, construido a partir de record-template.md. Contiene las respuestas de alcance, el mapa de datos, el estado y la prueba de cada puerta, las entradas de evidencia, el registro de activos y las acciones del propietario. Una aplicación se lanza solo cuando su expediente no muestra ningún fail y el propietario ha aprobado o aceptado explícitamente cada acción de propietario abierta.