1. Objetivo
Comprobar de forma coordinada entre dos compañeros que Signmethod funciona correctamente en producción, desde la web pública hasta el ciclo completo de envío y firma de un acuerdo.
El documento funciona como guion, checklist, registro de evidencias y acta final de aprobación.
2. Datos de la ejecución
| Dato | Valor |
|---|---|
| Fecha y hora de inicio | 27/08/2026 a las 14:00 |
| Versión de frontend desplegada | 2.0.9 |
| Versión de backend desplegada | 2.0.9 |
| URL principal | https://signmethod.com |
| URL de API | https://cb6456xer6.execute-api.eu-west-1.amazonaws.com/prod/ |
| Responsable de administración y emisión | Joel López |
| Responsable de firma y verificación | Pau Dengra |
| Carpeta de evidencias | docs\evidencias |
| Hora de finalización | En proceso |
3. Reparto del trabajo
Joel López: administración y emisión
- Web pública, DNS y TLS.
- Registro, acceso y recuperación de cuenta.
- Perfiles
owner,adminyemisor. - Empresas, usuarios, permisos y plantillas.
- Creación, envío, reenvío y cancelación de acuerdos.
- API, almacenamiento, correo y monitorización.
Pau Dengra: firma y verificación
- Perfil
firmante. - Recepción del correo y apertura del enlace público.
- Revisión, cumplimentación y firma de documentos.
- Validación del PDF firmado y sus evidencias.
- Pruebas en móvil y navegadores alternativos.
- Accesibilidad y comprobación cruzada del trabajo de Joel López.
Pruebas conjuntas
Joel López y Pau Dengra realizarán juntos los flujos completos, el aislamiento entre empresas, el registro de incidencias, la limpieza y la decisión GO/NO-GO. Uno ejecuta la acción y el otro comprueba el resultado y registra la evidencia.
4. Normas para probar en producción
- Utilizar exclusivamente cuentas y empresas de prueba autorizadas.
- Usar PDF ficticios sin datos personales, confidenciales o reales.
- Identificar los datos con el prefijo
QA-PROD-AAAA-MM-DD. - No activar
PLAYWRIGHT_ALLOW_AWS_WRITES=1contra producción. - No ejecutar carga masiva, ataques automatizados, restauraciones o borrados masivos.
- No incluir contraseñas, tokens o enlaces de firma en capturas y evidencias.
- Detener las pruebas ante pérdida de datos, acceso entre empresas, exposición de secretos o indisponibilidad general.
- Eliminar o anonimizar los datos de prueba al terminar, respetando la auditoría obligatoria.
5. Estados y severidad
Estados: PENDIENTE, OK, KO, BLOQUEADA o N/A.
Severidad:
CRÍTICA: pérdida o exposición de datos, firma incorrecta, acceso entre empresas, vulnerabilidad grave o caída general.ALTA: una función principal no puede utilizarse y no existe alternativa segura.MEDIA: fallo de una función secundaria con alternativa disponible.BAJA: defecto visual, de texto o de usabilidad con impacto limitado.
6. Preparación
| ID | Responsable | Prueba | Resultado esperado | Estado | Evidencia/observaciones |
|---|---|---|---|---|---|
| PRE-01 | Joel López | Confirmar versión, commit y hora de despliegue. | Coinciden con la versión autorizada. | OK | Capturas compartidas: repositorio en versión 2.0.7, commit 96df108, y pie de la aplicación con Frontend v2.0.7 · Backend/Lambda v2.0.7. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| PRE-02 | Joel López | Confirmar backups, métricas, alarmas y procedimiento de rollback. | Están disponibles y revisados. | KO | Capturas compartidas de la revisión en AWS. Para completar la tarea: activar PITR en signmethod-prod-audit; crear un backup manual autorizado o aprobar PITR como protección suficiente; activar versionado en signmethod-www-743737184059 y conservar una versión anterior; verificar métricas de S3 y generar actividad controlada de Cognito; crear alarmas CloudWatch para API 5xx, Lambda, DynamoDB, Cognito y SES; crear un tema SNS con destinatarios confirmados y probar una notificación; publicar versiones de signmethod-prod-admin-api, asignar un alias y conservar una versión anterior; guardar capturas de todas las comprobaciones y revisar el procedimiento de rollback. Mantener en KO hasta completar y verificar todos estos puntos. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| PRE-03 | Joel López y Pau Dengra | Preparar dos empresas QA independientes. | Tienen usuarios e identificadores distintos. | OK | Empresas verificadas en producción: pepe (companyId: pepe) y Prueba Produccion (companyId: prueba-produccion). Los identificadores son diferentes. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| PRE-04 | Joel López y Pau Dengra | Preparar cuentas owner, admin, emisor y firmante. | Las cuentas no pertenecen a usuarios reales. | OK | Capturas compartidas de los cuatro perfiles en la empresa Prueba Producción. Roles configurados y comprobados: owner, con permisos totales; admin, con todos los permisos salvo asignar el rol de administrador a otros usuarios; emisor, limitado a crear plantillas y enviar acuerdos; firmante, limitado a consultar y firmar los acuerdos que le corresponden. Las vistas y opciones disponibles cambian correctamente según el rol. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| PRE-05 | Pau Dengra | Preparar PDF pequeño, multipágina, dañado y archivo no PDF. | No contienen información real. | OK | Preparados y probados archivos QA: PDF de una página, PDF multipágina, PDF dañado, PDF vacío, PDF superior a 50 MB y archivo JPG. Se deben conservar únicamente versiones ficticias sin datos reales. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| PRE-06 | Joel López y Pau Dengra | Acordar canal, evidencias y responsable de detener las pruebas. | Ambos conocen el procedimiento. | OK | Revisado el 03/09/2026 mediante Playwright en el navegador abierto y contraste documental; acuerdo operativo confirmado el 04/09/2026. Se establece Slack #softradis-signmethod como canal principal y el mensaje privado entre Joel y Pau como canal alternativo. Joel López es el coordinador de parada y Pau Dengra su sustituto, aunque cualquiera puede detener las pruebas ante un riesgo crítico. Se envió y recibió el mensaje de prueba Prueba Produccion Signmethod; ambos aceptan el procedimiento y el formato de evidencia definido en docs/evidencias/. SignMethod no contiene un mecanismo propio de parada, por lo que la coordinación se realiza mediante los canales acordados. Evidencia: PRE-06-CANAL-EVIDENCIAS-PARADA-2026-09-03.md. |
Evidencias y pendientes de PRE-02
Evidencia disponible: capturas compartidas de la comprobación realizada en AWS y de la relación de trabajos necesarios para completar el control.
| Área | Evidencia comprobada | Carencias para obtener OK |
|---|---|---|
| Backups de DynamoDB | PITR activo en 8 de las 9 tablas signmethod-prod-*. | Activar PITR en signmethod-prod-audit. No constan backups manuales recientes; debe crearse uno autorizado o documentarse formalmente que PITR es suficiente según el procedimiento aprobado. |
| Backup del frontend | El bucket signmethod-www-* tiene cifrado AES-256 y bloqueo de acceso público activos. | Activar el versionado del bucket signmethod-www-743737184059 y conservar una versión anterior recuperable del frontend. |
| Métricas | Hay datos recientes de API Gateway y Lambda, actividad reciente en las 9 tablas DynamoDB y datos históricos de entregas de SES sin rebotes ni quejas en la consulta realizada. Cognito no muestra inicios de sesión o altas durante las últimas 6 horas revisadas. | Verificar o configurar métricas específicas de S3 y obtener actividad controlada de Cognito que permita comprobar su monitorización. |
| Alarmas y avisos | La revisión no encontró alarmas de CloudWatch, temas SNS ni suscripciones. Por tanto, no hay destinatarios ni canales de aviso configurados. | Crear y habilitar alarmas para API Gateway 5xx, errores y throttling de Lambda, errores y throttling de DynamoDB, Cognito y SES. Crear un tema SNS, añadir destinatarios reales, confirmar las suscripciones y probar la recepción de una notificación. |
| Rollback de DNS y CloudFront | DNS y CloudFront están operativos y se conserva que signmethod.com apunta a la distribución E39W5MD848G7V8. El procedimiento está descrito en docs/RUNBOOK_PREPRODUCCION_A_PRODUCCION.md. | Completar los mecanismos recuperables de frontend y backend y conservar las capturas de configuración de DNS/CloudFront necesarias para restaurarlos. |
| Rollback del backend | La Lambda signmethod-prod-admin-api dispone únicamente de $LATEST; no constan versiones publicadas ni alias. | Publicar versiones de Lambda, asociar un alias a la versión desplegada e identificar una versión anterior probada a la que poder volver. |
Para cambiar PRE-02 a OK deben resolverse todas las carencias anteriores y guardarse como evidencia las capturas de PITR de cada tabla, backups, configuración y versionado de S3, métricas recientes, alarmas, tema SNS y suscriptores confirmados, versiones/alias de Lambda y configuración de CloudFront/DNS. La prueba de notificación debe identificar el canal y confirmar su recepción, sin incluir datos secretos.
7. Pruebas automáticas seguras
La suite privada actual usa estado y API simulados. Valida la interfaz, pero no demuestra por sí sola el funcionamiento real de Cognito, Lambda, DynamoDB, S3 o SES.
| ID | Responsable | Prueba | Resultado esperado | Estado | Evidencia/observaciones |
|---|---|---|---|---|---|
| AUT-01 | Joel López | Ejecutar npx playwright test contra el build previo. | Todas las pruebas se superan. | KO | Ejecutada el 28/08/2026 sin PLAYWRIGHT_ALLOW_AWS_WRITES: 148 pruebas, 33 superadas y 115 fallidas en chromium, firefox, edge y safari/WebKit. Evidencias reunidas en docs/evidencias/AUT-01-playwright-report.zip (126,26 MB): contiene 1 reporte index.html, 78 capturas PNG, 78 vídeos WebM y 90 contextos de error Markdown; total de 247 archivos. Se debe extraer el ZIP completo antes de abrir AUT-01-playwright-report/index.html para conservar los enlaces a imágenes, vídeos y contextos. Para completar la tarea y cambiarla a OK: 1) declarar @playwright/test como dependencia de desarrollo reproducible y conservar el lockfile; 2) corregir el arranque configurando webServer.command para ejecutar el workspace frontend o añadiendo un script raíz válido, y probar contra el build previo previsto; 3) instalar las versiones de Chromium, Firefox y WebKit requeridas por Playwright; 4) resolver o trasladar a un runner compatible el fallo de arranque de Firefox por timeout del compositor gráfico; 5) revisar cada fallo del reporte y clasificarlo como defecto de aplicación o prueba desactualizada; 6) corregir la aplicación cuando el comportamiento sea incorrecto y actualizar selectores o expectativas únicamente cuando el nuevo comportamiento esté aprobado; 7) repetir primero las pruebas fallidas por proyecto y después ejecutar la suite completa sin escrituras AWS; 8) obtener 148 de 148 pruebas superadas, sustituir la evidencia por el reporte satisfactorio y conservar las capturas, vídeos y trazas necesarias. Mantener KO hasta completar todos los pasos. |
| AUT-02 | Joel López | Ejecutar $env:PLAYWRIGHT_BASE_URL='https://signmethod.com'; npx playwright test e2e/public.spec.ts. | El smoke público pasa sin escrituras AWS. | KO | Ejecutada el 28/08/2026 contra https://signmethod.com, con PLAYWRIGHT_ALLOW_AWS_WRITES desactivada y PLAYWRIGHT_TRACE=on: 76 pruebas, 19 superadas y 57 fallidas en chromium, firefox, edge y safari/WebKit. Los 57 fallos quedan clasificados y justificados en docs/evidencias/AUT-02-RESUMEN-FALLOS.md: 16 de navegación, 16 de alta pública, 16 de acuerdos/firma con API simulada, 4 de semántica accesible del logotipo, 4 de tamaño de objetivos táctiles y 1 timeout aislado de Firefox. La evidencia completa AUT-02-trazas-y-fallos-2026-08-28.zip contiene 57 trazas y 57 contextos de error (114 archivos, SHA-256 268C30EC5D648D74531746C99D4E37B9B44BA29F72751C1A1EC2B96FEF4307FD); por su tamaño de 937.696.090 bytes permanece fuera del repositorio hasta confirmar almacenamiento o cuota Git LFS. Para llegar al 100 %: validar el contrato funcional aprobado; eliminar la ambigüedad de Crear cuenta; alinear la navegación y su accesibilidad; actualizar los mocks al endpoint y esquema reales; corregir la semántica del logotipo y los objetivos táctiles; aislar el timeout de Firefox; repetir los grupos afectados en los cuatro navegadores y finalmente obtener 76 de 76 sin escrituras AWS. Mantener KO hasta adjuntar la nueva ejecución satisfactoria. |
| AUT-03 | Joel López | Confirmar que las escrituras AWS de Playwright están desactivadas. | La variable no existe o está desactivada. | OK | Verificado el 28/08/2026: PLAYWRIGHT_ALLOW_AWS_WRITES no está definida en los ámbitos Process, User ni Machine del equipo y tampoco aparece en el único archivo de entorno versionado (frontend/.env.development). La guarda de e2e/fixtures/network.ts solo permite escrituras cuando el valor es exactamente 1; con la configuración comprobada bloquea las solicitudes POST, PUT, PATCH y DELETE dirigidas a *.amazonaws.com y *.amazoncognito.com, devolviendo HTTP 409. Tanto e2e/public.spec.ts como e2e/private.spec.ts instalan esta protección. Evidencia reproducible en PowerShell: foreach ($scope in @('Process','User','Machine')) { [Environment]::GetEnvironmentVariable('PLAYWRIGHT_ALLOW_AWS_WRITES',$scope) }; los tres resultados fueron vacíos. No se realizaron escrituras AWS durante esta comprobación. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
8. Web pública, DNS y TLS
| ID | Responsable | Prueba | Resultado esperado | Estado | Evidencia/observaciones |
|---|---|---|---|---|---|
| PUB-01 | Joel López | Abrir dominio principal y www. | Ambos funcionan y aplican la redirección canónica prevista. | KO | En las capturas compartidas el 28/08/2026, una misma sesión de navegador muestra Dashboard al entrar en https://signmethod.com, pero https://www.signmethod.com carga la portada como usuario no autenticado y muestra Acceder y Crear cuenta. Además de la inconsistencia de sesión, esto demuestra que www está sirviendo la aplicación como un origen independiente en vez de aplicar la redirección canónica prevista. La causa probable es que la autenticación se guarda en almacenamiento asociado al origen —por ejemplo, localStorage o una cookie limitada al host—, que no se comparte entre ambos dominios. Véase INC-009. Para completar la prueba: 1) configurar en DNS/CDN una redirección permanente 301 o 308 de www a https://signmethod.com, antes de servir la SPA y conservando ruta y parámetros; 2) dejar un único dominio canónico en Cognito y en las URL de callback y cierre de sesión; 3) invalidar la caché del CDN; 4) iniciar sesión en el dominio principal y comprobar que cualquier URL www redirige una sola vez al mismo recurso del dominio principal mostrando la sesión; 5) cerrar sesión y verificar que queda cerrada; 6) repetir en una ventana privada y revisar que no existen bucles ni contenido duplicado. No copiar tokens manualmente entre orígenes. Mantener KO hasta superar estas verificaciones. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| PUB-02 | Joel López | Entrar mediante HTTP. | Redirige una vez a HTTPS, sin bucles. | OK | Verificado el 28/08/2026 con curl -I -L --max-redirs 10. http://signmethod.com responde 301 con Location: https://signmethod.com/ y termina en 200 después de 1 redirección. http://www.signmethod.com responde 301 con Location: https://www.signmethod.com/ y también termina en 200 después de 1 redirección. No se detectan bucles. Evidencia y comandos reproducibles en docs/evidencias/PUB-02-REDIRECCION-HTTP-2026-08-28.md. Esta validación solo cubre el cambio de protocolo; www conserva su host, por lo que PUB-01 continúa KO hasta aplicar la redirección canónica al dominio principal. |
| PUB-03 | Joel López | Revisar certificado TLS, dominio y caducidad. | Certificado válido y vigente. | OK | Verificado el 28/08/2026 mediante conexión TLS directa al puerto 443 de signmethod.com y www.signmethod.com. Ambos negocian TLS 1.3 sin errores de política y presentan el mismo certificado: sujeto CN=signmethod.com, emisor Amazon RSA 2048 M01, cadena X.509 válida, vigencia del 29/04/2026 al 13/11/2026 y SAN que incluye signmethod.com y www.signmethod.com. Huella SHA-1: A7A263910909B425700362296A1BDD891D4696C7. Se adjuntan resultados e imágenes en docs/evidencias/PUB-03-CERTIFICADO-TLS-2026-08-28.md, PUB-03-TLS-signmethod.com-2026-08-28.svg y PUB-03-TLS-www.signmethod.com-2026-08-28.svg. La incidencia de sesión de PUB-01 no afecta a la validez del certificado. |
| PUB-04 | Joel López | Abrir inicio, precios, acerca, temporalidad y casos de uso. | Contenido, navegación y botones funcionan. | KO | Comprobado el 28/08/2026 con y sin sesión. Inicio carga correctamente; Temporalidad del proyecto abre y cierra el diálogo de ocho hitos; los botones Legal, RRHH, Administración y Operaciones abren sus contenidos específicos; Acceder, Crear cuenta, Ver cómo funciona, Empieza ahora y Solicita una demo producen la respuesta prevista sin enviar formularios. Sin embargo, no existe texto, sección, enlace ni botón Precios, y la sección #acerca tiene contenido pero carece de un control público de navegación. Véase INC-010. Evidencias y matriz de resultados en docs/evidencias/PUB-04-NAVEGACION-Y-CONTENIDO-2026-08-28.md, con capturas de inicio, temporalidad, caso de uso y demo. Para completar al 100 %: confirmar el alcance de Precios; implementarlo o aprobar formalmente su retirada y actualizar el requisito; añadir navegación accesible a Acerca; repetir en escritorio/móvil y con/sin sesión; aprobar únicamente cuando todas las áreas y controles exigidos sean accesibles y funcionen. |
| PUB-05 | Joel López | Abrir directamente y refrescar cada ruta pública. | No aparece 404 en rutas de la SPA. | OK | Verificado el 28/08/2026 en la portada y las cinco rutas SEO mínimas. Las seis URLs responden HTTP 200 sin redirecciones; al abrirlas directamente y realizar una recarga completa conservan su URL, título y H1 correspondiente. No aparece 404, Not found ni Página no encontrada. Evidencia reproducible y seis capturas posteriores a la recarga en docs/evidencias/PUB-05-RUTAS-SPA-2026-08-28.md. Esta prueba valida la entrega y reconstrucción de rutas de la SPA; no sustituye PUB-06 sobre metadatos ni PUB-08 sobre el contenido legal. |
| PUB-06 | Pau Dengra | Revisar títulos, descripciones, canonical y Open Graph. | Metadatos correctos y propios de producción. | KO | La aplicación configura en el navegador títulos, descripciones y canonical específicos para las cinco rutas SEO, pero el HTML inicial sirve los mismos valores genéricos en todas las URLs y no contiene canonical. No existen etiquetas Open Graph. Véase INC-006. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| PUB-07 | Pau Dengra | Revisar logo, favicon, imágenes y fuentes. | No hay recursos rotos ni contenido mixto. | OK | Validado el 28/08/2026 en la portada y las cinco rutas SEO. El favicon, el logo y las imágenes CTA.png, firma.png, flujo_firma.png, legal.png, rrhh.png, administracion.png y operaciones.png responden 200 con tipo image/png; CSS y JavaScript también responden 200. No se detectan referencias http://, contenido mixto, fuentes externas ni archivos de fuente rotos. El logo visible incluye texto alternativo y las imágenes decorativas se aplican como fondos CSS. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| PUB-08 | Pau Dengra | Probar privacidad, cookies, términos, teléfono, email y LinkedIn. | Todos los enlaces tienen el destino correcto. | KO | El correo mailto:asistente@softradis.com y el teléfono tel:+34661515151 tienen formatos accionables correctos. Las tres rutas legales responden 200, pero muestran de nuevo la portada porque no existen vistas específicas para esos contenidos. El enlace anunciado como «Visita SignMethod en LinkedIn» dirige a la página de Softradis. Véase INC-007. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| PUB-09 | Joel López | Buscar referencias a preproducción, dominios antiguos o atiendeia.net. | No se encuentran referencias no autorizadas. | OK | Verificado el 28/08/2026 en el HTML de la portada y las cinco rutas SEO, el JavaScript assets/index-Cbl1jt2H.js, el CSS assets/index-Iq5l-xVV.css y las cabeceras HTTP de los ocho recursos. No aparecen signmethod.atiendeia.net, atiendeia.net, preproducción, preproduction, preprod, signmethod.example ni el identificador del API antiguo 7w7f59xpci. El bundle usa una vez el API de producción cb6456xer6.execute-api.eu-west-1.amazonaws.com. Las cadenas localhost y 127.0.0.1 detectadas pertenecen a una guarda E2E que solo se activa cuando window.location.hostname coincide exactamente con esos hosts; no son endpoints ni configuración activa en producción. Evidencia, inventario de dominios y criterio de clasificación en docs/evidencias/PUB-09-REFERENCIAS-PRODUCCION-2026-08-28.md. Repetir el escaneo tras cada despliegue que cambie el hash del bundle. |
| PUB-10 | Joel López y Pau Dengra | Enviar una solicitud de demo controlada. | reCAPTCHA funciona y llega un solo correo correcto. | KO | El envío controlado con datos QA-PROD-2026-08-28 no supera la inicialización de reCAPTCHA: la interfaz muestra Invalid site key or not loaded in api.js para la clave pública configurada. No se realiza ninguna petición a /demo-requests y no se genera correo. Véase INC-008. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| PUB-11 | Joel López | Probar demo incompleta, reCAPTCHA inválido, red caída y doble clic. | Muestra error y no crea duplicados. | KO | Comprobado el 28/08/2026 sin enviar datos. Formulario incompleto: los cuatro campos obligatorios están en estado nativo :invalid, por lo que no existe un envío válido. reCAPTCHA inválido: la captura compartida muestra Invalid site key or not loaded in api.js; coincide con la clave pública configurada en el bundle y el fallo ocurre antes de /demo-requests, sin crear solicitud. Red caída y doble clic: no pueden probarse de extremo a extremo porque reCAPTCHA bloquea antes la petición. La revisión muestra tratamiento de errores y desactivación temporal del botón en frontend, pero el backend envía por SES cada petición válida sin clave de idempotencia ni deduplicación; por tanto, no está garantizado que un doble envío produzca un solo correo. Véanse PUB-10 e INC-008. Para completar la tarea: 1) configurar y autorizar una pareja reCAPTCHA válida para los dominios de producción; 2) añadir en frontend una guarda síncrona que ignore un segundo envío mientras el primero está en curso; 3) generar y enviar una clave de idempotencia única por intento; 4) guardar esa clave en backend mediante escritura condicional y TTL, devolviendo el resultado previo sin repetir SES cuando llegue duplicada; 5) añadir una prueba automática con dos peticiones simultáneas y verificar una sola llamada a SES; 6) con datos sintéticos aprobados, simular la caída de red de /demo-requests y comprobar mensaje de error, botón reactivado y cero solicitudes/correos; 7) ejecutar doble clic y peticiones paralelas, confirmando una sola petición efectiva, un solo registro y un solo correo; 8) repetir el formulario incompleto en todos los navegadores soportados y comprobar sus mensajes de validación; 9) adjuntar trazas de red y cambiar a OK únicamente cuando los cuatro escenarios estén superados. Evidencia detallada en docs/evidencias/PUB-11-ERRORES-Y-DUPLICADOS-DEMO-2026-08-28.md. Mantener KO hasta completar los nueve pasos. |
Evidencias de PUB-03
La conexión directa al puerto 443 confirma en ambos dominios TLS 1.3 sin errores de política, cadena X.509 válida y un certificado vigente hasta el 13/11/2026. El campo SAN incluye signmethod.com y www.signmethod.com. El resultado técnico completo y la huella del certificado están en docs/evidencias/PUB-03-CERTIFICADO-TLS-2026-08-28.md.
signmethod.com
www.signmethod.com
Rutas SEO mínimas:
/firma-digital-empresas//firma-digital-recursos-humanos//firma-digital-legal//trazabilidad-documental//firma-contratos-empresas/
Análisis de la observación PUB-06
Se revisaron la portada y las cinco rutas SEO mínimas el 28/08/2026. Todas responden con el mismo HTML inicial: título SignMethod | Firma digital para empresas, descripción Gestiona documentos y procesos de firma digital con SignMethod., sin canonical y sin etiquetas Open Graph.
Después de ejecutar JavaScript, la aplicación sí asigna un título, una descripción y una URL canonical propios a cada landing SEO. Sin embargo, esta configuración solo en cliente no garantiza que los rastreadores y servicios que no ejecutan JavaScript reciban los metadatos específicos. Además, no se implementan og:title, og:description, og:url, og:type ni og:image, por lo que la previsualización al compartir una página no queda definida.
Corrección requerida:
- Servir desde el HTML inicial un título, una descripción y un canonical específicos para cada ruta pública indexable.
- Añadir
og:title,og:description,og:url,og:typeyog:imagecoherentes con cada página. - Usar URLs absolutas HTTPS del dominio de producción tanto en canonical como en Open Graph.
- Comprobar que
og:imagesea pública, estable y tenga unas dimensiones adecuadas para compartir. - Evitar valores de preproducción,
localhost, dominios antiguos y metadatos duplicados. - Repetir la prueba sobre el HTML inicial y sobre el DOM renderizado.
Análisis de la observación PUB-08
Se revisaron los enlaces del pie público el 28/08/2026:
| Enlace | Destino observado | Evaluación |
|---|---|---|
| Términos y condiciones | https://signmethod.com/terminos-y-condiciones/ | Incorrecto: responde 200, pero renderiza la portada y no el contenido legal. |
| Política de privacidad | https://signmethod.com/politica-de-privacidad/ | Incorrecto: responde 200, pero renderiza la portada y no la política. |
| Política de cookies | https://signmethod.com/politica-de-cookies/ | Incorrecto: responde 200, pero renderiza la portada y no la política. |
mailto:asistente@softradis.com | Correcto técnicamente: abre un cliente de correo con la dirección mostrada. | |
| Teléfono | tel:+34661515151 | Correcto técnicamente: coincide con el texto +34 661 51 51 51. |
https://www.linkedin.com/company/softradis | Requiere corrección o confirmación: el nombre accesible anuncia SignMethod, pero el destino es la página corporativa de Softradis. |
Corrección requerida:
- Crear y mostrar el contenido correspondiente en las tres rutas legales, evitando que rutas desconocidas se presenten como una portada válida con estado
200. - Confirmar si LinkedIn debe dirigir a una página propia de SignMethod o anunciar claramente que enlaza a Softradis.
- Repetir la navegación desde el pie en escritorio y móvil después de la corrección.
Análisis de la observación PUB-10
El 28/08/2026 se abrió el formulario público de solicitud de demo y se realizó un único intento controlado con datos ficticios identificados mediante QA-PROD-2026-08-28.
Resultado observado:
- El formulario permite completar nombre, apellidos, teléfono, email y empresa.
- Al pulsar
Solicitar una demo, la aplicación intenta obtener un token reCAPTCHA para la accióndemo_request. - Google rechaza la inicialización con el mensaje
Invalid site key or not loaded in api.js: 6LfQhYUtAAAAAACH8SvLSFTbEmJPKpUiHQgmEnX6r. - No se envía ninguna petición HTTP al endpoint
/demo-requests. - Al no alcanzar el backend, no se solicita a SES ningún correo y no procede comprobar duplicados en el buzón.
Corrección requerida:
- Verificar que
VITE_RECAPTCHA_SITE_KEYcontenga la clave pública correcta para la versión de reCAPTCHA utilizada y esté autorizada parasignmethod.comywww.signmethod.com. - Confirmar que la clave pública del frontend corresponda al secreto almacenado en producción.
- Desplegar de nuevo el frontend si la variable se inyectó incorrectamente durante el build.
- Repetir un único envío controlado y comprobar que
/demo-requestsresponde correctamente. - Confirmar en
asistente@softradis.comque llega exactamente un mensaje, con asunto, remitente,Reply-To, datos y fecha correctos.
9. Registro, autenticación y sesión
| ID | Responsable | Prueba | Resultado esperado | Estado | Evidencia/observaciones |
|---|---|---|---|---|---|
| ID-01 | Joel López | Registrar una empresa válida. | Se crea y solicita validar el correo. | OK | Validado con la empresa pepe y el usuario joel.lopez@softradis.com. La captura compartida muestra la sesión activa como Owner · pepe, el selector de empresa con pepe · Owner y la empresa marcada como ACTUAL, confirmando que la empresa se creó y quedó asociada al propietario correcto. La recepción de la solicitud de validación del correo está confirmada en ID-05; sus defectos de remitente, idioma, marca y mecanismo de verificación se mantienen registrados en ID-05 e INC-011, pero no impiden confirmar la creación funcional exigida por ID-01. No se conserva ninguna contraseña ni código de verificación en esta evidencia. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ID-02 | Pau Dengra | Registrar una cuenta particular. | No solicita campos exclusivos de empresa. | OK | Validado el 28/08/2026 con cristian.vazquez@softradis.com. Al seleccionar Particular desaparece Razón social, el campo de nombre cambia a Nombre y apellidos y no se solicita dominio empresarial. Se mantiene un campo obligatorio rotulado NIF/CIF, que admite el NIF personal y no se ha considerado exclusivo de empresa. Tras validar el correo, el acceso funciona y carga el contexto aislado personal-cristian-vazquez-softradis-com; las consultas iniciales responden 200. La sesión se cerró al finalizar. La contraseña no se conserva en este documento. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ID-02B | Pau Dengra | Revisar el campo Contraseña al pulsar Crear cuenta, tanto en Empresa como en Particular. | El campo incluye un botón accesible para mostrar y ocultar la contraseña sin modificar su valor. | KO | No aparece el icono de ojo en ninguno de los dos tipos de alta. Véase INC-002. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ID-03 | Joel López | Probar campos vacíos y datos inválidos. | Bloquea el alta y señala cada error. | KO | Comprobado el 28/08/2026 en el alta de Empresa, el alta de Particular y el acceso. Con los campos obligatorios vacíos, Crear cuenta queda deshabilitado en ambos tipos de alta, por lo que el envío se bloquea. Sin embargo, no aparece un mensaje individual junto a cada campo que explique qué falta o qué formato se espera; los asteriscos de los placeholders no sustituyen esa validación. En el acceso vacío se muestra únicamente el mensaje técnico en inglés username is required to signIn, que expone terminología interna de Cognito, no está traducido y no señala claramente todos los campos implicados. Véase INC-013. Para completar la tarea: 1) definir reglas de validación para cada campo de Empresa y Particular, incluyendo formato de NIF/CIF, nombre, email y contraseña; 2) mostrar el error junto al campo al perder el foco o intentar continuar, con texto en español y asociado mediante aria-describedby; 3) marcar visual y semánticamente el campo inválido con aria-invalid=true; 4) sustituir los mensajes técnicos de Cognito por mensajes funcionales que no revelen detalles internos; 5) validar por separado usuario/email y contraseña vacíos en el acceso; 6) probar valores con formato incorrecto, límites de longitud, espacios y caracteres no admitidos, no solo campos vacíos; 7) mantener bloqueado el envío y comprobar que no se realiza ninguna petición de alta o acceso cuando el formulario es inválido; 8) repetir en Empresa, Particular y acceso con teclado y lectores de pantalla; 9) adjuntar capturas de cada error y cambiar a OK únicamente cuando todos los campos inválidos estén señalados de forma clara. Mantener KO hasta completar los nueve pasos. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ID-04 | Joel López | Repetir email con mayúsculas y espacios. | Lo normaliza y evita duplicados. | KO | Comprobado el 28/08/2026. Al introducir el correo registrado usando una combinación de mayúsculas y minúsculas, el sistema permite continuar hasta Valida tu email y envía un nuevo código, en lugar de detectar que representa la misma dirección. Las otras capturas muestran Esa empresa ya existe o ya está registrada, que valida la empresa pero no demuestra la deduplicación del correo, y There is already a signed in user, que es un error técnico de sesión en inglés y tampoco constituye una detección correcta del duplicado. Véase INC-014. Para completar la tarea: 1) aplicar trim() al correo antes de validarlo o enviarlo; 2) normalizarlo a minúsculas en frontend y backend; 3) utilizar el valor normalizado como clave de búsqueda y unicidad en Cognito y en la base de datos; 4) comprobar el duplicado antes de crear la empresa, el usuario o enviar el código; 5) mostrar un mensaje funcional en español sin revelar si la cuenta existe de forma aprovechable por terceros; 6) cerrar cualquier sesión previa antes de repetir la prueba; 7) usar exactamente los mismos caracteres del correo original y probar por separado mayúsculas, espacios exteriores y ambas variantes combinadas; 8) confirmar que no se crea un segundo registro ni se envía un nuevo código; 9) adjuntar capturas y evidencia de que solo existe una identidad. Mantener KO hasta verificar los nueve puntos. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ID-05 | Joel López y Pau Dengra | Abrir los correos de validación. | Marca, destinatario y enlace HTTPS son correctos. | KO | El correo de validación llega al destinatario correcto, pero se envía desde no-reply@verificationemail.com, no incorpora la marca SignMethod y contiene únicamente un código de seis dígitos en lugar de un enlace HTTPS. El asunto y el cuerpo aparecen en inglés. Captura compartida con los detalles de remitente y destinatario desplegados; el código de verificación debe ocultarse en la copia conservada como evidencia. Véase INC-011. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ID-06 | Joel López | Iniciar sesión con credenciales válidas e inválidas. | Solo accede con las válidas y el error no filtra información. | PENDIENTE | Resultado parcial comprobado el 28/08/2026. Con una contraseña incorrecta, el acceso queda bloqueado y aparece Incorrect username or password.; el mensaje es genérico y no permite distinguir si el usuario existe, por lo que esta parte cumple el criterio de no filtrar información, aunque debería traducirse al español. La captura con las credenciales supuestamente válidas no confirma el acceso porque ya había una sesión abierta y el formulario devuelve There is already a signed in user. en lugar de entrar o redirigir al dashboard. Para completar la prueba: 1) cambiar inmediatamente la contraseña que quedó visible en la captura y no conservarla como evidencia sin censurar; 2) cerrar la sesión actual y eliminar el estado de autenticación del navegador o usar una ventana privada; 3) iniciar sesión con credenciales válidas y comprobar que se abre el dashboard correspondiente; 4) cerrar sesión; 5) probar una contraseña incorrecta y confirmar que no se crea sesión ni se accede a rutas privadas; 6) probar un correo inexistente y verificar que devuelve el mismo mensaje genérico; 7) comprobar que los mensajes se presentan en español y sin detalles de Cognito; 8) adjuntar capturas censuradas y, si se usa la pestaña Red, ocultar tokens, cookies y contraseñas. Mantener PENDIENTE hasta demostrar el acceso válido y repetir los intentos sin una sesión previa. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ID-07 | Joel López | Probar MFA de perfiles administrativos, si aplica. | Alta, reto y recuperación funcionan. | KO | Comprobado el 28/08/2026 en producción con un usuario autenticado de rol Owner. Desde el menú del usuario se accede a Mi perfil > Privacidad y seguridad, pero la pantalla solo muestra el email principal y Cambiar contraseña; no ofrece activación MFA, QR o secreto TOTP, verificación del primer código, códigos de recuperación ni sustitución del autenticador. La vista también muestra Failed to fetch. La infraestructura declara Cognito con TOTP opcional y el backend marca MFA como requerido para admin y superadmin, pero no se encontró el flujo correspondiente en el frontend. En consecuencia no pueden probarse el alta, el reto ni la recuperación. Véase INC-015 y el informe ID-07-MFA-PERFILES-ADMINISTRATIVOS-2026-08-28, con las capturas acceso a la configuración y seguridad sin MFA. Para completar la tarea: confirmar TOTP en el pool de producción; definir los roles obligados, incluido Owner; implementar alta y verificación TOTP; exigir el reto al iniciar sesión; añadir recuperación segura; traducir los errores; auditar los eventos; repetir con un admin nuevo y adjuntar evidencias censuradas. Mantener KO hasta completar el flujo de extremo a extremo. |
| ID-08 | Pau Dengra | Recuperar contraseña y reutilizar el enlace. | Permite el cambio una vez; después caduca o se invalida. | KO | La pantalla de acceso no ofrece ninguna opción «¿Has olvidado tu contraseña?» ni otro acceso visible al flujo de recuperación. Por ello, un usuario que no recuerda su contraseña no puede iniciar el cambio y tampoco es posible comprobar desde la interfaz la invalidez del código o enlace tras utilizarlo. Véase INC-012. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ID-09 | Joel López y Pau Dengra | Cerrar sesión y usar Atrás, recargar o abrir URL privada. | No vuelve al contenido privado. | OK | Validado el 28/08/2026. Después de cerrar sesión, al volver a la misma página privada, usar Atrás y recargar, la aplicación mantiene la sesión cerrada y muestra la portada pública o el acceso; no reaparece el panel ni contenido privado. Captura compartida de la portada pública mostrada tras la comprobación. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ID-10 | Joel López | Comprobar la caducidad de sesión. | Solicita autenticación sin perder datos guardados. | KO | Comprobado parcialmente el 28/08/2026. A las 12:47 CEST la sesión seguía activa y permitía acceder a Administración tras una actividad de acceso registrada a las 12:39, por lo que la captura solo confirma el estado autenticado actual. La revisión del proyecto muestra que las peticiones privadas obtienen el token con fetchAuthSession(), pero no existe un tratamiento global de sesión ausente o respuesta 401 que abra una reautenticación, conserve la ruta y restaure el trabajo. El arranque ignora el fallo de recuperación de sesión y el cliente Cognito no declara una duración explícita de tokens. No se forzó ni manipuló la sesión real del usuario. Véase INC-016, el informe ID-10-CADUCIDAD-SESION-2026-08-28 y la captura sesión activa en Administración. Para completar la prueba: documentar la duración; implementar tratamiento centralizado de caducidad; guardar el borrador; solicitar autenticación en español; restaurar ruta, empresa y datos; evitar duplicados y bucles; usar una sesión de vida corta en un entorno controlado; verificar reautenticación correcta, cancelada e incorrecta; repetir con recarga y varias pestañas; adjuntar capturas y trazas censuradas. Mantener KO hasta completar el flujo real de caducidad. |
10. Roles, empresas y aislamiento
| ID | Responsable | Prueba | Resultado esperado | Estado | Evidencia/observaciones |
|---|---|---|---|---|---|
| ROL-01 | Joel López | Entrar como owner. | Ve administración, usuarios, plantillas y acuerdos autorizados. | OK | Validado el 28/08/2026 en la empresa pepe con la sesión de Joel López identificada en la cabecera como Owner. Las capturas compartidas confirman: 1) acceso al panel de Administración, con las opciones Usuarios y permisos, Nuevo acuerdo y Biblioteca de plantillas; 2) acceso a Gestión de Usuarios, donde se muestran el propietario y los administradores y están disponibles las acciones permitidas de alta, modificación y retirada, mientras las acciones sobre el propio owner aparecen protegidas; 3) acceso a Plantillas, incluida la acción Nueva plantilla; y 4) acceso a Acuerdos, incluido Nuevo acuerdo y el listado de acuerdos de la empresa. El alcance visual y funcional requerido por ROL-01 queda confirmado. Estas capturas no sustituyen las pruebas de elevación de privilegios, auditoría o aislamiento de backend, cubiertas respectivamente por ROL-05, ROL-06 y ROL-09. Antes de publicar las capturas como evidencias, censurar los correos personales que no sea necesario mostrar. |
| ROL-02 | Joel López | Entrar como admin. | No ve ni ejecuta acciones reservadas al owner. | OK | Validado el 28/08/2026 en la empresa Prueba Produccion con Joel López identificado en la cabecera como Administrador. Las capturas compartidas confirman el acceso al panel de Administración y a Gestión de Usuarios. El administrador conserva Usuarios, Alta y Nuevo usuario, acciones autorizadas para gestionar perfiles inferiores, pero las acciones Modificar y Quitar acceso sobre el usuario owner aparecen protegidas/deshabilitadas. Tampoco se observa una acción operativa para cambiar o retirar al propietario. El comportamiento visual exigido por ROL-02 queda confirmado. La protección del backend frente a peticiones manipuladas para modificar el propio rol, asignar owner o elevar usuarios a roles no permitidos debe validarse separadamente en ROL-05. Antes de publicar las capturas, censurar los correos personales que no sean necesarios para demostrar el rol. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ROL-03 | Joel López | Entrar como emisor. | Envía acuerdos sin administrar usuarios o empresas. | OK | Validado el 28/08/2026 en la empresa Prueba Produccion con Joel López identificado en la cabecera como Emisor. La captura compartida muestra las opciones autorizadas Acuerdos, Plantillas y Enviar acuerdo, mientras no aparecen Administración, Usuarios, Alta, compra ni controles de gestión de empresas o roles. La capacidad funcional del emisor para crear plantillas y enviar acuerdos ya quedó comprobada en PRE-04; esta evidencia confirma que la navegación se limita al alcance operativo del rol. El criterio de ROL-03 queda cumplido. Las pruebas de autorización directa del backend ante URLs o peticiones manipuladas permanecen separadas en ROL-09. Antes de publicar la captura, censurar el correo si no es necesario para identificar el rol probado. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ROL-04 | Pau Dengra | Entrar como firmante, abrir el panel Firmante y pulsar Pendientes. | Puede consultar sus acuerdos pendientes, pero no ve ni puede ejecutar acciones para crear o enviar acuerdos. | KO | El listado de pendientes muestra Nuevo acuerdo y permite abrir el flujo de envío. Véase INC-001. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ROL-04B | Joel López y Pau Dengra | Intentar crear, guardar como borrador y enviar un acuerdo con una sesión de firmante, incluyendo peticiones directas a la API. | La interfaz no ofrece esas acciones y el backend responde 403 en todos los endpoints de creación, borrador y envío. | KO | Revalidado el 28/08/2026 en producción. La cabecera principal del Firmante no muestra acciones de envío, pero al abrir Pendientes el modal muestra Nuevo acuerdo; el botón abre el flujo completo de seis pasos. Al introducir un título y una descripción de QA, el guardado automático creó realmente el borrador QA ROL-04B rechazo firmante 2026-08-28, confirmado por Borradores 1, la hora de guardado y su aparición en el listado. Por tanto, POST /signature-requests/drafts no respondió 403. La revisión del backend confirma que creación, borrador y envío validan la pertenencia a la empresa, pero no exigen owner, admin o emisor; el endpoint de envío también podría continuar para un firmante con datos válidos. No se realizó un envío real para evitar documentos o correos externos. Véase INC-001 y el informe ROL-04B-AUTORIZACION-FIRMANTE-2026-08-28, con seis capturas. Para obtener OK: ocultar y bloquear todos los accesos de creación; añadir una comprobación de rol centralizada al inicio de creación, borrador y envío; cubrir las demás escrituras emisoras; devolver 403 antes de cualquier efecto; añadir pruebas con claims de firmante; repetir desde todas las vistas; confirmar ausencia de registros DynamoDB, objetos S3 y llamadas SES; adjuntar trazas censuradas de los tres 403; y eliminar de forma controlada el borrador de QA. Mantener KO hasta completar la corrección de extremo a extremo. |
| ROL-04C | Pau Dengra | Abrir como firmante las tarjetas Pendientes, Próximos a vencer y Completados recientemente, además del resumen inferior de acuerdos. | Ninguna vista muestra Nuevo acuerdo; el resumen utiliza una denominación de recepción o firma y no Enviados. | KO | Las tres tarjetas abren un listado que muestra Nuevo acuerdo. El resumen inferior muestra Enviados aunque los elementos son acuerdos recibidos por el firmante. Véase INC-001. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ROL-05 | Joel López | Intentar cambiar el rol propio o elevar privilegios. | Interfaz y backend rechazan la operación. | OK | Validado el 28/08/2026. Las capturas de producción confirman que emisor y firmante no muestran Administración de usuarios; admin tiene protegidas las acciones sobre owner y perfiles administrativos; y owner no puede modificar su propia fila. Para validar el backend sin arriesgar cuentas reales, se ejecutó el handler del artefacto compilado dist-lambda/index.js contra AWS simulado localmente, con claims y usuarios ficticios. Se probaron diez intentos: cambio del rol propio para owner, admin, emisor y firmante; elevación de otro usuario desde emisor y firmante; modificación de owner y admin desde admin; y asignación de owner y superadmin desde owner. Resultado: 10/10 respuestas 403, cero escrituras en Cognito/DynamoDB y cero fallos. No se accedió a tokens, cookies ni credenciales reales. Evidencia: informe ROL-05-ELEVACION-PRIVILEGIOS-2026-08-28 y resumen visual. El criterio de interfaz y backend queda cumplido. Como mejora no bloqueante, traducir los mensajes internos que aún aparecen en inglés. |
| ROL-06 | Joel López | Crear, cambiar rol, bloquear y retirar acceso a un usuario QA. | Cada cambio funciona y queda auditado. | PENDIENTE | Resultado parcial ampliado el 28/08/2026. Las capturas compartidas confirman la secuencia funcional sobre un usuario QA: 1) alta/invitación con rol firmante y estado Invitado; 2) aceptación y aparición posterior como Activo; 3) cambio de firmante a emisor, confirmado por el aviso Rol modificado y la actualización de la fila; 4) retirada de acceso, confirmada por Usuario dado de baja y la desaparición del usuario del listado; y 5) después de la retirada, la sesión deja el contexto de la empresa pepe como firmante y muestra el contexto todavía autorizado Prueba Produccion como administrador. Esta última parte coincide con la retirada ya validada en ROL-07. Todavía no se aportan evidencias del bloqueo y desbloqueo independientes ni de los eventos de Auditoría, por lo que el criterio completo no puede marcarse OK. Para completar ROL-06: 1) crear o reutilizar otro usuario exclusivamente QA; 2) bloquearlo y comprobar que Cognito y la aplicación deniegan el acceso; 3) desbloquearlo y confirmar que vuelve a acceder con el rol y tenant correctos; 4) abrir Auditoría y verificar los eventos de invitación, aceptación, cambio de rol, bloqueo, desbloqueo y retirada con actor, usuario, empresa y fecha; 5) comprobar que no existen eventos duplicados ni cambios omitidos; 6) adjuntar capturas censuradas y trazas sin tokens. Mantener PENDIENTE hasta validar bloqueo, desbloqueo y auditoría. Antes de publicar las capturas, censurar los correos personales que no sean necesarios. |
| ROL-07 | Pau Dengra | Acceder después del bloqueo o retirada. | El acceso queda denegado según diseño. | OK | Validada el 28/08/2026 la variante de retirada de acceso. Pau Dengra accedía con una sesión abierta como administrador de la empresa pepe; Joel López retiró su acceso y, al recargar, la sesión dejó de mostrar pepe y cambió al contexto autorizado Prueba Produccion. No se recuperó el acceso retirado ni se mostraron datos de la empresa anterior. Evidencia: tres capturas compartidas del acceso previo, la confirmación de retirada y el estado posterior a la recarga. No se ha probado por separado la variante de bloqueo. |
| ROL-08 | Joel López | Cambiar de empresa activa con varias membresías. | Cambian los datos y permisos al tenant elegido. | OK | Validado en producción. Se comprobó el cambio de empresa activa con varias membresías y, al seleccionar el tenant correspondiente, la aplicación actualiza correctamente los datos visibles y los permisos disponibles para la empresa elegida. Funcionamiento confirmado al 100% según la evidencia aportada. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ROL-09 | Joel López y Pau Dengra | Manipular URL, ID, email o parámetros para acceder a otro tenant. | Responde 403/404 sin revelar información. | OK | Validado el 28/08/2026 desde una sesión de Pau Dengra autorizada para Prueba Produccion y sin acceso a pepe. Se manipuló el parámetro de la petición GET /signature-requests?companyId=prueba-produccion, sustituyéndolo por companyId=pepe; el backend respondió 403 Forbidden y no entregó datos del tenant ajeno. Evidencia: captura compartida del rechazo con la URL QA y el estado 403. Las capturas intermedias que muestran la cabecera authorization no deben conservarse como evidencia; se debe cerrar la sesión utilizada para invalidar o rotar sus credenciales. |
| ROL-10 | Joel López y Pau Dengra | Intentar listar o descargar documentos de otra empresa. | No existe acceso cruzado por interfaz ni API. | OK | Validado el 28/08/2026 desde una sesión de Prueba Produccion sin acceso a pepe. Se solicitó directamente GET /signature-requests/draft-1787912756505-0.43389741900873213, correspondiente a un borrador con documento de pepe, y la API respondió 403 Forbidden; no se expusieron datos del borrador ni se generó una URL de descarga. El intento de listado cruzado mediante companyId=pepe ya quedó rechazado con 403 en ROL-09. Evidencia: captura compartida del estado 403, sin cabeceras de autorización visibles. La sesión cuyo token se mostró durante la preparación debe permanecer cerrada para invalidar esa credencial. |
Análisis de la observación ROL-04
La observación es válida. El rol firmante debe poder consultar los acuerdos en los que participa y completar su firma, pero no debe crear borradores, iniciar acuerdos ni enviarlos.
Comportamiento observado:
- Pau Dengra accede con rol
firmanteal Panel Firmante. - Pulsa
Pendientesy accede al listado de acuerdos pendientes. - El listado muestra la acción
Nuevo acuerdo. - La acción abre el formulario
Enviar acuerdo, aunque ese rol no tiene permiso de emisión. - El mismo botón aparece al acceder desde
Próximos a venceryCompletados recientemente, porque las tres tarjetas reutilizan el mismo listado. - El resumen inferior muestra la categoría
Enviados. Para un firmante esos registros son acuerdos recibidos como destinatario, por lo que la denominación es incorrecta y presenta una acción propia del contexto emisor.
Análisis técnico:
- La cabecera principal oculta correctamente
Enviar acuerdomediante el permisocanSendAgreement. - Las tarjetas
Pendientes,Próximos a venceryCompletados recientementeabren el mismo listado de acuerdos. - La acción
Nuevo acuerdode ese listado se renderiza sin comprobarcanSendAgreementy abre directamente el formulario, evitando la función de navegación que sí contiene la protección. - El conjunto de acuerdos sí se filtra para que el firmante vea aquellos en los que figura como destinatario, pero después se presenta bajo la etiqueta
Enviados. No se ha detectado en este punto una fuga de acuerdos ajenos; sí existe un error de semántica, rol y experiencia de usuario. - La protección no puede depender solo de ocultar el botón. Los endpoints de creación de solicitudes, guardado de borradores y envío comprueban la pertenencia a la empresa, pero no restringen explícitamente la operación a
owner,adminoemisor. - En consecuencia, el problema debe considerarse de autorización y no únicamente visual.
Corrección requerida:
- Ocultar
Nuevo acuerdoen todos los listados cuandocanSendAgreementsea falso. - Centralizar la apertura del formulario mediante la función que comprueba permisos.
- Adaptar el resumen del firmante para mostrar
Recibidos,Pendientes de firmayCompletados, evitando la denominaciónEnviados. - Rechazar en backend con
403la creación, modificación o envío cuando el rol seafirmante. - Añadir pruebas automáticas de interfaz y API para impedir la regresión.
11. Usuarios, perfil y administración
| ID | Responsable | Prueba | Resultado esperado | Estado | Evidencia/observaciones |
|---|---|---|---|---|---|
| ADM-01 | Joel López | Editar los datos permitidos de Mi perfil. | Se guardan y persisten tras recargar. | OK | Validado el 28/08/2026 en producción con una sesión owner. La interfaz permite editar nombre, correo y teléfono; el cargo es de solo lectura y el owner también puede editar empresa y NIF/CIF. Se confirmó que un correo con formato incorrecto queda rechazado por la validación del formulario y que un NIF/CIF inválido no se guarda. Como comprobación positiva se modificó el nombre completo a Joel López Gutierrez, se guardó y el valor continuó presente al volver a abrir Mi perfil después de recargar. Las capturas compartidas muestran el valor editado antes y después de la recarga. El criterio solicitado de guardado y persistencia tras recargar queda cumplido. La pantalla sigue mostrando Failed to fetch; debe investigarse como incidencia independiente porque no impidió el guardado comprobado. No se ha validado la sincronización del dato en otro navegador o dispositivo. Evidencia: ADM-01-ADM-02-PERFIL-CONTRASENA-2026-08-28. |
| ADM-02 | Joel López | Cambiar contraseña. | Aplica validaciones y permite entrar con la nueva. | OK | Validado el 28/08/2026 por el titular de la cuenta. El formulario solicita contraseña antigua, nueva y confirmación; informa de un mínimo de 10 caracteres y prohíbe espacios y los caracteres < y >. La revisión del código confirma validaciones de campos obligatorios, coincidencia, longitud y caracteres prohibidos antes de llamar a updatePassword de AWS Amplify. La captura compartida muestra Contraseña cambiada correctamente. con los tres campos vacíos y sin revelar la clave. El titular confirmó después que la contraseña válida de acceso es la nueva, por lo que el cambio y el acceso posterior quedan comprobados. La contraseña no se ha incluido en el chat, las capturas, Git ni el plan. Defecto visual no bloqueante: los tres botones de mostrar/ocultar contraseña están mal posicionados dentro de los campos, presentan cajas grises que no quedan correctamente alineadas y no siguen el estilo de los demás botones de acción. Deben usar el mismo componente, tamaño, alineación, estados de foco/hover y separación interior en los tres campos. Failed to fetch continúa como otra observación independiente de la pantalla de perfil. Véase INC-002. Evidencia: ADM-01-ADM-02-PERFIL-CONTRASENA-2026-08-28. |
| ADM-03 | Joel López | Invitar a un usuario con un rol autorizado. | Se crea una invitación y llega un correo con la presentación visual correcta. | KO | La invitación llega y permite iniciar la aceptación, pero el logotipo de SignMethod aparece desplazado hacia la izquierda en la cabecera en lugar de estar centrado. Captura compartida del correo recibido. Véase INC-004. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ADM-04 | Pau Dengra | Aceptar la invitación. | Se incorpora solo a la empresa y rol indicados. | OK | Validado el 28/08/2026 con pau.dengra@softradis.com. Se aceptó una invitación de la empresa pepe con rol Administrador; después de actualizar el listado administrativo, Pau Dengra 2 figura como Activo y admin. Tras cerrar sesión e iniciar de nuevo, la membresía persiste y el selector muestra pepe · Administrador, además de la membresía previa y legítima en Prueba Produccion, sin empresas adicionales. Evidencia: capturas compartidas del correo sin URL de invitación visible, del usuario activo con el rol asignado y del selector de empresa después del nuevo inicio de sesión. La primera invitación cuya URL completa apareció en una captura se consideró expuesta y debía retirarse antes de continuar. |
| ADM-05 | Joel López y Pau Dengra | Probar invitación duplicada y retirada. | No crea duplicados; una invitación pendiente se puede retirar, su enlace queda invalidado y no deja acceso residual. | KO | Alcance actualizado el 28/08/2026: el rechazo por el destinatario y la caducidad quedan fuera del producto por decisión funcional. La aplicación bloquea correctamente un nuevo alta para un usuario que ya pertenece a la empresa y la retirada de acceso elimina al usuario del listado sin conservar acceso. Sin embargo, todavía no permite retirar específicamente una invitación pendiente ni invalidar inmediatamente su enlace de aceptación. Véase INC-017. Evidencia: capturas compartidas del mensaje Usuario ya existente y de la retirada del usuario. Mantener en KO hasta implementar la retirada de invitaciones pendientes, comprobar que el enlace retirado deja de ser válido y confirmar que no se crea una membresía residual. |
| ADM-06 | Joel López | Buscar y filtrar usuarios. | Solo aparecen usuarios del tenant activo. | OK | Validado en producción. El buscador y los filtros de usuarios funcionan correctamente y limitan los resultados a los usuarios del tenant activo, sin mostrar usuarios de otras empresas. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ADM-07 | Joel López | Revisar panel y actividad reciente. | Métricas y eventos coinciden con las acciones QA. | KO | La captura del panel muestra actividad y métricas que no proceden de acciones reales realizadas en la página. Actualmente el panel utiliza datos en memoria o congelados, por lo que los eventos recientes y contadores no pueden considerarse una evidencia fiable de las acciones QA. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| ADM-08 | Joel López y Pau Dengra | Dar de alta un nuevo usuario en una empresa sin que acepte la invitación y revisar su estado. | Debe aparecer como Invitado o Pendiente; no debe figurar como Activo ni disponer de acceso hasta aceptar una invitación válida. | OK | Validado el 28/08/2026 con pau.dengra@softradis.com. Antes de aceptar, el listado administrativo muestra al usuario como Invitado, conserva el rol previsto admin y no le concede acceso a la empresa. Después de aceptar la invitación, el estado cambia correctamente a Activo manteniendo el mismo rol. Evidencia: capturas compartidas de ambos estados. |
12. Plantillas, carpetas y archivos
| ID | Responsable | Prueba | Resultado esperado | Estado | Evidencia/observaciones |
|---|---|---|---|---|---|
| PLA-01 | Joel López | Crear plantilla con PDF, destinatario, asunto y mensaje. | Se guarda y puede abrirse de nuevo. | OK | Validado en producción. Se creó la plantilla Prueba y aparece correctamente en Mis plantillas, con propietario, fecha y acciones disponibles, confirmando que queda guardada y accesible de nuevo desde el listado. Evidencia: captura compartida del listado de Mis plantillas con la plantilla creada. |
| PLA-02 | Joel López | Editar, copiar, marcar favorita, mover y archivar. | Estado, ubicación e historial son correctos. | KO | Validado parcialmente en producción. La plantilla Prueba aparece marcada como favorita y se muestra correctamente en la vista Favoritas; también se comprobaron acciones de gestión desde el menú de acciones. Sin embargo, no se observa una opción visible e integrada de Archivar. La interfaz muestra Eliminar y una carpeta Eliminado, pero eso no equivale a una acción explícita de archivo ni permite validar el criterio completo de archivar. Véase INC-020. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| PLA-03 | Joel López | Crear carpetas privadas y compartidas. | Los permisos coinciden con su tipo. | OK | Validado en producción. Se crearon y visualizaron carpetas privadas y compartidas: PLA-QA-PRIVADA-20260828 bajo Carpetas y PLA-QA-COMPARTIDA-20260828 bajo Carpetas compartidas. Las vistas separan correctamente el alcance privado y compartido. Evidencia: capturas compartidas de ambas carpetas y sus vistas. |
| PLA-04 | Joel López | Compartir con un usuario o grupo autorizado. | Solo los destinatarios previstos acceden. | OK | Validado en producción. El modal de compartir permite seleccionar usuarios autorizados del tenant, muestra la selección realizada y permite confirmar la acción Compartir; se comprobó la selección de Joel López y Pau Dengra como destinatarios autorizados. Evidencia: captura compartida del modal Compartir con usuarios seleccionados. |
| PLA-05 | Joel López y Pau Dengra | Abrir una plantilla desde la otra empresa. | Acceso denegado sin mostrar metadatos. | OK | Validado el 28/08/2026 con pau.dengra@softradis.com, conectado exclusivamente a Prueba Produccion. Se forzó desde el navegador una consulta autenticada a /templates?companyId=pepe; el backend respondió 403 Forbidden y no expuso plantillas ni metadatos ({"items":[]}). La pantalla de la sesión muestra Administrador · Prueba Produccion, un único usuario en la empresa y ningún selector multiempresa. Evidencia: capturas compartidas del panel, del estado HTTP y de la respuesta censurada. |
| PLA-06 | Joel López | Descargar el PDF de la plantilla. | Abre y coincide con el original. | OK | Validado en producción. El PDF memoria-prueba-01.pdf de la plantilla se abre correctamente desde la URL segura de documentos de producción y el visor muestra el contenido esperado del documento original, con la portada de Crowpire y la sección Nota de prensa. Evidencia: captura compartida del PDF abierto en el navegador. |
| PLA-07 | Pau Dengra | Subir archivo no PDF, dañado, vacío o demasiado grande. | Se rechaza con un mensaje claro, no se incorpora al listado y el paso Documentos permanece incompleto si no existe otro PDF válido. | KO | JPG y PDF superior a 50 MB rechazados correctamente. El PDF vacío y el dañado muestran error de carga y Páginas no detectadas, pero permanecen en el listado y el paso aparece como completo. Véase INC-003. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| PLA-08 | Pau Dengra | Usar nombres largos, caracteres especiales y secuencias de ruta. | Se normalizan o rechazan sin ejecutar código ni alterar rutas. | KO | Validado el 28/08/2026 con seis PDF sintéticos distintos. La aplicación acepta y conserva tras guardar y recargar nombres con secuencias ..%2F, ..%5C, puntos consecutivos y texto con apariencia de manejador HTML, sin normalizarlos ni rechazarlos. No se ejecutó código, la interfaz siguió operativa y las descargas de PLA08-03 y PLA08-05 coincidieron con los archivos subidos. El backend genera las claves S3 con tenantId, templateId y un documentId UUID, sin incorporar el nombre aportado; no se observó alteración de rutas. El caso largo llegó como nombre corto AAAAAA~1.PDF, transformación realizada por Windows antes de la carga, por lo que no valida el límite interno. Véase INC-018 y el informe docs/evidencias/PLA-08-NOMBRES-ARCHIVO-2026-08-28.md. |
| PLA-09 | Joel López | Probar contraseña de plantilla, si aplica. | Solo la contraseña válida permite usarla. | KO | En la pantalla de Opciones avanzadas de la plantilla, los botones para visualizar u ocultar la contraseña aparecen mal posicionados respecto a los campos de contraseña. El defecto visual no permite dar por correcta la experiencia de protección con contraseña hasta ajustar alineación, tamaño, separación y estados de foco. Véase INC-002. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| PLA-10 | Joel López | Eliminar, revisar papelera y restaurar. | Se comporta según diseño sin afectar a otros datos. | KO | Validado el 01/09/2026 en producción con Playwright y una plantilla temporal PLA-10 QA 2026-09-01T08-33-13-831Z. La interfaz permite crear la plantilla, eliminarla, verla en Eliminado con caducidad y recuperarla en Mis plantillas; después se eliminó definitivamente la plantilla temporal y la papelera quedó vacía. Sin embargo, la revisión de implementación muestra que Eliminar ejecuta DELETE /templates/{templateId} contra backend y solo después guarda una copia en localStorage (signmethod.deletedTemplates) para mostrarla en Eliminado; Recuperar plantilla recrea una plantilla nueva con POST /templates. Por tanto la papelera no es persistente ni compartida entre navegador/dispositivo, y no conserva la identidad original ni garantiza historial/auditoría de restauración real. Véase INC-020 y el informe PLA-10-PAPELERA-RESTAURACION-2026-09-01, con capturas de creación, eliminación, papelera, restauración y limpieza. Mantener en KO hasta implementar borrado lógico persistente y restauración real en backend. |
| PLA-11 | Pau Dengra | Cargar un documento en una plantilla y pasar el ratón sobre su tarjeta o miniatura. | Las acciones disponibles, como ver, reemplazar, descargar y eliminar, aparecen como iconos superpuestos al documento únicamente al situar el puntero sobre él. No se muestra un menú desplegable ni botones de texto que oculten la previsualización. Cada icono tiene tooltip, nombre accesible, foco de teclado visible y ejecuta la acción correcta. | KO | Actualmente las acciones se presentan mediante un menú contextual de texto abierto desde el botón de tres puntos. Además, al editar una plantilla, el pop-up de acciones del documento aparece visualmente desalineado y tapa parte de la tarjeta o la previsualización del documento. Véase INC-005. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
Análisis de la observación PLA-07
| Archivo probado | Resultado observado | Evaluación |
|---|---|---|
| PDF válido de una página | Se carga y detecta una página. | Correcto. |
| PDF válido multipágina | Se carga y detecta cuatro páginas. | Correcto. |
| Archivo JPG | Se rechaza indicando que solo se permiten PDF. | Correcto. |
| PDF superior a 50 MB | Se rechaza indicando que supera el máximo permitido. | Correcto. |
| PDF vacío | Muestra error y no detecta páginas, pero queda añadido al listado. | Incorrecto. |
| PDF dañado | Muestra error y no detecta páginas, pero queda añadido al listado. | Incorrecto. |
El formulario no debe considerar preparado un documento que no pueda analizarse. Mantener un PDF vacío o dañado en el listado mientras se muestra Paso completo puede permitir que el usuario continúe con un acuerdo inválido o crea erróneamente que el archivo está listo para enviar.
Mejoras requeridas:
- Validar que el archivo tenga contenido y un tamaño mayor que cero antes de añadirlo.
- Comprobar tipo MIME, extensión y firma interna de PDF; no confiar únicamente en el nombre.
- Analizar el PDF y exigir al menos una página válida.
- Eliminar automáticamente del listado cualquier archivo cuya lectura o previsualización falle.
- Mantener el paso Documentos como incompleto cuando no quede ningún PDF válido.
- Mostrar un único mensaje claro que identifique el archivo rechazado y la causa.
- Repetir la validación en backend antes de aceptar o enviar definitivamente el documento, evitando que pueda eludirse la comprobación del navegador.
- Añadir pruebas automáticas para PDF vacío, truncado, dañado, sin páginas, con extensión falsa y superior a 50 MB.
13. Flujo completo de acuerdo y firma
Joel López actúa como emisor y Pau Dengra como firmante.
| ID | Responsable | Prueba | Resultado esperado | Estado | Evidencia/observaciones |
|---|---|---|---|---|---|
| FIR-01 | Joel López | Crear borrador con título, descripción, plazo, PDF y Pau Dengra. | Persiste después de cerrar y recargar. | OK | Validado el 01/09/2026 en producción con Playwright. Se creó el borrador QA FIR-01 borrador 2026-09-01T08-44-31-643Z con descripción, plazo de 30 días, PDF sintético fir-01-borrador-qa.pdf y Pau Dengra (pau.dengra@softradis.com) como destinatario. Tras Guardar y salir, el borrador apareció en Borradores con 1 destinatario y 1 documento; después de cerrar la ventana modal y recargar la página, siguió visible en el listado. Al pulsar Continuar, el formulario recuperó el destinatario Pau Dengra y su correo, confirmando la persistencia de los datos principales. Evidencia: FIR-01-BORRADOR-PERSISTENTE-2026-09-01. El borrador QA queda conservado para ejecutar FIR-02 y eliminarlo después de forma controlada. |
| FIR-02 | Joel López | Editar y eliminar un borrador independiente. | No afecta a otros acuerdos. | KO | Validado el 01/09/2026 en producción con Playwright sobre el borrador QA creado en FIR-01. Al abrir Borradores existían QA FIR-01 borrador 2026-09-01T08-44-31-643Z y el borrador de control prueba. Se editó el borrador QA cambiando título y descripción; tras Guardar y salir, apareció como QA FIR-02 editado 2026-09-01T08-52-09-687Z, pero pasó de 1 documento a 0 documentos. Después, al eliminar el borrador editado, el listado quedó en Borradores 0, por lo que también desapareció prueba. El criterio de no afectar a otros acuerdos no se cumple. Véase INC-021 y el informe FIR-02-EDICION-ELIMINACION-BORRADOR-2026-09-01. |
| FIR-03 | Joel López | Crear acuerdo con varios PDF y destinatarios ordenados. | Muestra todos los elementos y el orden correcto. | KO | Validado el 01/09/2026 en producción con Playwright. Se creó el acuerdo QA QA FIR-03 acuerdo principal 2026-09-01T08-53-59-720Z con dos PDF previstos (fir-03-contrato-qa.pdf y fir-03-anexo-qa.pdf) y dos destinatarios en modo secuencial: Pau Dengra y Joel Lopez QA. El paso de participantes muestra el orden 1 y 2, pero al llegar a Revisar y enviar el resumen mostró solo 1 documento y únicamente fir-03-contrato-qa.pdf. En un segundo intento sobre el borrador auto-guardado, fir-03-anexo-qa.pdf llegó a verse en Documentos, pero el resumen volvió a observarse con 1 documento. No se pulsó Enviar. Véase INC-022 y el informe FIR-03-VARIOS-PDF-DESTINATARIOS-2026-09-01. |
| FIR-04 | Joel López | Enviar el acuerdo principal. | Se crea una vez con estado pendiente. | OK | Validado el 01/09/2026 mediante captura compartida de producción. En el modal Acuerdos, con filtro Pendientes (2), aparece el acuerdo Prueba Pau con descripción Prueba de envío de acuerdo FIR-04, vencimiento 08/09/2026, estado Enviado, 1 destinatario enviado y 0 firmados. No se observa duplicado del acuerdo Prueba Pau en la captura; la fila prueba corresponde a otro acuerdo. Evidencia: FIR-04-ENVIO-ACUERDO-PRINCIPAL-2026-09-01. |
| FIR-05 | Pau Dengra | Recibir y revisar el correo. | Destinatario, marca y enlace HTTPS son correctos. | KO | Validado el 28/08/2026 mediante OpenClaw sobre un correo real recibido el 20/08/2026. El mensaje llegó directamente a dengrapau@gmail.com, desde no-reply@signmethod.com, con saludo a Pau Dengra, identidad visual coherente, logotipo, acuerdo, mensaje, documentos y botón claramente presentados. Sin abrirlo ni revelar su token, se inspeccionó el destino de Firmar acuerdo: usa http://signmethod:8081/ con parámetros, en lugar de una URL pública https://signmethod.com. Véase INC-019 y docs/evidencias/FIR-05-CORREO-Y-ENLACE-2026-08-28.md. |
| FIR-06 | Pau Dengra | Abrir el enlace sin sesión, en ventana privada. | Solo muestra el acuerdo destinado a Pau Dengra. | OK | Reejecutada el 01/09/2026 mediante Playwright. Desde Gmail, con la cuenta pau.dengra@softradis.com, se localizó el correo nuevo QA FIR-08 Plantilla campo obligatorio 2026-09-01; el botón Firmar acuerdo ya apunta a https://signmethod.com/comprobar-token con parámetros, sin host interno ni HTTP. El enlace se abrió en un contexto Playwright nuevo sin cookies ni almacenamiento. La vista sin sesión cargó ACUERDO ENVIADO, Visualización del acuerdo, mostró únicamente el destinatario pau.dengra@softradis.com, indicó 3 días para firmar y listó el documento FIR-07-documento-QA-produccion.pdf. No apareció This legacy link is no longer valid ni se observaron otros destinatarios. Evidencia: docs/evidencias/FIR-06-ENLACE-SIN-SESION-2026-09-01.md, docs/evidencias/FIR-06-correo-origen-playwright-2026-09-01.png y docs/evidencias/FIR-06-enlace-sin-sesion-playwright-2026-09-01.png. Queda histórico el bloqueo previo del 28/08/2026 por INC-019, resuelto para el correo nuevo probado. |
| FIR-07 | Pau Dengra | Revisar PDF, mensaje, plazo y campos. | Coinciden con lo enviado por Joel López. | KO | Ejecutada y recomprobada desde el inicio el 01/09/2026 mediante Playwright sobre el Chrome ya abierto en producción (https://signmethod.com/). Se creó y envió un acuerdo QA nuevo destinado a pau.dengra@softradis.com con el PDF FIR-07-documento-QA-produccion.pdf, plazo de 3 días, mensaje específico y sin campos preparados. Antes del envío, la revisión final mostraba OK 1 documento, OK 1 participante, OK Mensaje y la vista del firmante incluía el PDF. Tras cambiar al rol Firmante - Prueba Produccion, el panel muestra Pendientes 1 y el listado muestra el acuerdo como Pendiente de firma; al consultar Ver acuerdo, no se puede revisar toda la información del acuerdo desde la perspectiva del firmante: el paso Documentos lista el PDF como Documento enviado, pero el resumen final muestra Pendiente 0 documentos, la vista del firmante muestra Documento pendiente y el botón Revisar y firmar queda deshabilitado. Además, la caducidad no coincide: vista previa 4/9/2026 frente a listado/detalle 08/09/2026. El mensaje, el participante y la ausencia de campos se conservan, pero la vista firmable del PDF y el plazo no coinciden con lo enviado. Véase INC-023. Evidencia: docs/evidencias/FIR-07-REVISION-PDF-MENSAJE-PLAZO-CAMPOS-2026-09-01.md y captura docs/evidencias/FIR-07-vista-firmante-pendiente-ko-2026-09-01.png. |
| FIR-08 | Pau Dengra | Continuar sin completar campos obligatorios. | Bloquea la firma e identifica lo pendiente. | KO | Reejecutada el 01/09/2026 mediante Playwright sobre el Chrome ya abierto en producción (https://signmethod.com/). Para desbloquear la prueba se creó la plantilla QA FIR-08 Plantilla campo obligatorio 2026-09-01, se subió el PDF FIR-07-documento-QA-produccion.pdf, se colocó un campo Firma en el editor visual y el flujo de envío detectó 1 campo de firma. Después se creó y envió el acuerdo QA FIR-08 acuerdo campo obligatorio Playwright 2026-09-01 a Pau Dengra (pau.dengra@softradis.com), con confirmación Acuerdo enviado correctamente a 1 destinatario. Al cambiar al rol Firmante - Prueba Produccion, el panel muestra Pendientes 2 y el listado muestra el acuerdo FIR-08 como Pendiente de firma, vencimiento 08/09/2026, Dest. enviados 1 y Firmados 0. Sin embargo, el firmante solo dispone de Ver acuerdo; esa acción no permite ver toda la información operativa del acuerdo ni iniciar la firma, porque abre una vista bloqueada (Estás viendo este acuerdo dentro de la pantalla de enviar acuerdo. Los campos están bloqueados.) y el menú de más acciones no ofrece Firmar, con Editar y Cancelar deshabilitados. No se puede iniciar la firma ni intentar continuar dejando el campo obligatorio vacío, por lo que no se verifica el bloqueo ni la identificación del campo pendiente. Véase INC-023. Evidencia: docs/evidencias/FIR-08-CAMPOS-OBLIGATORIOS-PANEL-FIRMANTE-2026-09-01.md y captura docs/evidencias/FIR-08-firmante-ver-acuerdo-sin-accion-firma-2026-09-01.png. Mantener KO hasta exponer una acción de firma/revisión al firmante o repetir la prueba desde el enlace público recibido por email. |
| FIR-09 | Pau Dengra | Crear firma elegida, dibujada y subida, más iniciales. | Todas se previsualizan correctamente. | OK | Ejecutada el 01/09/2026 mediante Playwright sobre el Chrome ya abierto en producción (https://signmethod.com/). Desde Información de perfil > Mi perfil > Firmas se crearon tres firmas para Pau Dengra con iniciales PD: una con Elegir, una con Dibujar y una con Subir usando los PNG de QA FIR-09-firma-subida.png y FIR-09-iniciales-subidas.png. En todos los casos la aplicación mostró el aviso legal antes de crear, confirmó Firma creada / La firma se ha creado correctamente. y el listado Firmas guardadas previsualizó la firma y las iniciales. Al finalizar se verificaron 3 imágenes Firma de Pau Dengra y 3 imágenes Iniciales de Pau Dengra. Evidencia: docs/evidencias/FIR-09-FIRMAS-ELEGIDA-DIBUJADA-SUBIDA-2026-09-01.md y capturas docs/evidencias/FIR-09-firma-dibujada-modal-2026-09-01.png, docs/evidencias/FIR-09-firma-dibujada-creada-2026-09-01.png, docs/evidencias/FIR-09-firma-subida-modal-2026-09-01.png, docs/evidencias/FIR-09-firmas-previsualizadas-produccion-chrome-2026-09-01.png. |
| FIR-10 | Pau Dengra | Firmar y completar el acuerdo. | Confirma una sola firma y cambia a completado. | OK | Ejecutada el 01/09/2026 a las 12:09:48 +02:00 mediante Playwright sobre el Chrome ya abierto en producción (https://signmethod.com/). Se accedió al acuerdo desde el enlace HTTPS público del correo QA FIR-08 Plantilla campo obligatorio 2026-09-01; el flujo mostró el acuerdo pendiente, destinatario pau.dengra@softradis.com, el documento FIR-07-documento-QA-produccion.pdf, un único campo obligatorio Firma y el botón final Firmar acuerdo. Se seleccionó una firma guardada de Pau Dengra; el campo pasó de Seleccionar firma a Firma Pau Dengra. Tras confirmar la firma, la aplicación volvió al dashboard con el estado Se ha firmado el acuerdo correctamente., Pendientes 1 y Completados 1. Evidencia: docs/evidencias/FIR-10-FIRMAR-Y-COMPLETAR-ACUERDO-2026-09-01.md y capturas docs/evidencias/FIR-10-seleccionar-firma-modal-2026-09-01.png, docs/evidencias/FIR-10-firma-seleccionada-antes-confirmar-2026-09-01.png, docs/evidencias/FIR-10-acuerdo-firmado-resultado-2026-09-01.png. |
| FIR-11 | Joel López | Abrir listado y detalle. | Estado, firmante, fechas, documentos e historial son correctos. Al entrar en Ver acuerdo desde el listado, el detalle debe mostrar cada destinatario al que se envió el acuerdo y el estado individual de cada usuario, por ejemplo pendiente, enviado, firmado, rechazado, caducado o sustituido según corresponda. | KO | Validado el 01/09/2026 en producción con Playwright. El listado de Acuerdos muestra el acuerdo QA FIR-03 acuerdo principal 2026-09-01T08-53-59-720Z con estado Enviado, 2 destinatarios enviados y 0 firmados. Al entrar en Ver acuerdo, el detalle abre Visualización del acuerdo en modo visualización y muestra solo información agregada (Estado: Enviado, Vencimiento: Sin token, Firmados: 0/2) junto a los datos básicos del acuerdo. No muestra la relación de destinatarios ni el estado individual de cada usuario, por lo que no cumple el criterio esperado. Véase INC-023. Evidencia: FIR-11-LISTADO-DETALLE-ACUERDO-2026-09-01. |
| FIR-12 | Joel López y Pau Dengra | Descargar el documento firmado. | Abre, contiene la firma y coincide para ambos. | KO | Ejecutada el 01/09/2026 mediante Playwright sobre el Chrome ya abierto en producción (https://signmethod.com/) usando el acuerdo firmado en FIR-10 (QA FIR-08 acuerdo campo obligatorio Playwright 2026-09-01). El listado de completados muestra OK Firmado, Dest. enviados 1 y Firmados 1; sin embargo, no existe acción visible para descargar el documento firmado. Ver acuerdo abre una vista bloqueada del flujo con Estado: Firmado · Vencimiento: 08/09/2026 · Firmados: 1/1, pero solo muestra el paso Información y no expone documentos firmados descargables. El menú de más acciones solo ofrece Duplicar, Editar deshabilitado y Cancelar, sin Descargar. Al reabrir el enlace público usado, la página indica Token has already been used y tampoco ofrece descarga. No se pudo descargar el PDF firmado, abrirlo, comprobar la firma ni guardar hash. Véase INC-024. Evidencia: docs/evidencias/FIR-12-DESCARGA-DOCUMENTO-FIRMADO-2026-09-01.md, docs/evidencias/FIR-12-detalle-acuerdo-firmado-2026-09-01.png y docs/evidencias/FIR-12-menu-acuerdo-firmado-sin-descarga-2026-09-01.png. |
| FIR-13 | Joel López | Revisar evidencias, eventos, hashes y tamaño. | Son coherentes con la secuencia realizada. | KO | Revisada el 01/09/2026 tras integrar la secuencia actual de producción. FIR-10 confirma una firma completada y cambio a Completados 1, pero FIR-12 queda KO porque no existe acción visible para descargar el documento firmado; por tanto no hay PDF firmado descargado, ni hash/tamaño del firmado, ni comparación entre Joel López y Pau Dengra. Se verificaron hashes y tamaños de las evidencias disponibles de FIR-10, FIR-11 y FIR-12, coherentes con la secuencia observada, pero el criterio completo no se cumple por ausencia del artefacto firmado auditable. Véase INC-024. Evidencia: FIR-13-EVIDENCIAS-EVENTOS-HASHES-TAMANO-2026-09-01. |
| FIR-14 | Pau Dengra | Reutilizar el enlace tras completar. | No permite firmar otra vez ni duplica eventos. | OK | Ejecutada el 01/09/2026 mediante Playwright sobre el Chrome ya abierto en producción (https://signmethod.com/). Se reutilizó el enlace HTTPS público del correo ya firmado en FIR-10, sin guardar ni exponer la URL completa. La página cargó ACUERDO ENVIADO / Visualización del acuerdo, mostró Token has already been used y no expuso ningún botón Firmar ni Firmar acuerdo, solo Dashboard. Después se recargó el dashboard y los contadores permanecieron estables: Pendientes 1, Completados recientemente 1 y Completados 1, sin indicio funcional de duplicado. Evidencia: docs/evidencias/FIR-14-REUTILIZAR-ENLACE-TRAS-COMPLETAR-2026-09-01.md y captura segura docs/evidencias/FIR-14-dashboard-contadores-tras-reuso-2026-09-01.png. No se conserva captura de la página de token usado porque mostraba el token en pantalla. |
| FIR-15 | Joel López | Reenviar un acuerdo pendiente. | Respeta el límite y envía un solo correo. | OK | Validado el 01/09/2026 en producción mediante Chrome compartido y captura aportada por Joel López. En Visualización del acuerdo, paso Participantes, el acuerdo muestra Estado: Enviado, vencimiento 08/09/2026, Firmados: 0/2 y dos destinatarios: Joel Lopez <joel.lopez@softradis.com> y Pau Dengra <pau.dengra@softradis.com>. Tras pulsar Reenviar para Joel, la interfaz muestra Reenvío ejecutado correctamente para joel.lopez@softradis.com. y el botón queda bloqueado como Reenviar en 5:04, mientras el destinatario Pau conserva su acción independiente. No se inspeccionó la bandeja de entrada; la validación de envío único se basa en una sola acción ejecutada, confirmación de producción y cooldown inmediato por destinatario. Evidencia: FIR-15-REENVIO-ACUERDO-PENDIENTE-2026-09-01. |
| FIR-16 | Joel López y Pau Dengra | Sustituir destinatario y usar el enlace anterior. | El anterior se invalida y el nuevo funciona. | KO | Ejecutada el 01/09/2026 mediante Playwright sobre el Chrome ya abierto en producción (https://signmethod.com/). Se abrió el listado de acuerdos pendientes y se localizó QA FIR-07 Playwright produccion 2026-09-01 con estado Enviado, Dest. enviados 1 y Firmados 0. El menú de más acciones solo ofrece Duplicar, Editar deshabilitado y Cancelar; no existe acción visible para Sustituir destinatario. Al entrar en Ver acuerdo, el detalle abre una vista bloqueada con Estado: Enviado · Vencimiento: 08/09/2026 · Firmados: 0/1, pero solo muestra el paso Información y tampoco expone gestión de destinatarios ni sustitución. No se puede ejecutar desde la interfaz la sustitución, por lo que no se puede verificar la invalidación del enlace anterior ni el funcionamiento del nuevo enlace. Véase INC-025. Evidencia: docs/evidencias/FIR-16-SUSTITUIR-DESTINATARIO-ENLACE-ANTERIOR-2026-09-01.md, docs/evidencias/FIR-16-detalle-pendiente-sin-sustituir-2026-09-01.png y docs/evidencias/FIR-16-menu-pendiente-sin-sustituir-2026-09-01.png. |
| FIR-17 | Joel López y Pau Dengra | Cancelar un acuerdo y probar su enlace. | No admite firmas posteriores. | OK | Ejecutada el 01/09/2026 mediante Playwright sobre el Chrome ya abierto en produccion (https://signmethod.com/). Se cancelo el acuerdo real QA FIR-07 Playwright produccion 2026-09-01, localizado previamente como pendiente y enviado a pau.dengra@softradis.com. Tras confirmar la accion, el listado paso a mostrar Cancelados (1) y el acuerdo dejo de aparecer en la tabla visible de pendientes. A continuacion se abrio el enlace HTTPS original del correo sin conservar la URL completa ni el token; la pagina mostro que el acuerdo habia sido cancelado por el emisor y que ya no estaba disponible para firmar, sin botones Firmar acuerdo, Revisar y firmar ni controles de firma. El criterio principal queda cumplido: el enlace anterior no admite firmas posteriores. Como observacion de seguridad, la vista publica muestra el token en claro bajo TOKEN GENERADO, por lo que no se guardo captura de esa pagina y se registra INC-026. Evidencia: docs/evidencias/FIR-17-CANCELAR-ACUERDO-Y-PROBAR-ENLACE-2026-09-01.md, docs/evidencias/FIR-17-listado-acuerdo-pendiente-antes-cancelar-2026-09-01.png y docs/evidencias/FIR-17-listado-tras-cancelar-2026-09-01.png. |
| FIR-18 | Joel López y Pau Dengra | Probar token inexistente, manipulado y caducado. | Lo rechaza sin revelar datos. | KO | Ejecutada el 01/09/2026 mediante Playwright sobre el Chrome ya abierto en produccion (https://signmethod.com/). Se probaron tres variantes en https://signmethod.com/comprobar-token: token inexistente sintetico, token manipulado a partir de un enlace real ya cancelado y token antiguo extraido de un correo legacy previo con confirmacion explicita del usuario. En los tres casos la pagina rechazo el acceso con Agreement not found y no mostro botones Firmar acuerdo, Revisar y firmar ni controles de firma, por lo que no permite avanzar a firma. Sin embargo, en los tres casos la vista publica mostro el token completo bajo TOKEN GENERADO; por tanto no cumple el criterio sin revelar datos. No se guardaron capturas ni URLs completas de estas paginas para no conservar tokens. Vease INC-026. Evidencia: docs/evidencias/FIR-18-TOKEN-INEXISTENTE-MANIPULADO-CADUCADO-2026-09-01.md. |
| FIR-19 | Joel López y Pau Dengra | Probar contraseña de acuerdo, si aplica. | Solo la válida permite continuar. | KO | Ejecutada parcialmente el 01/09/2026 mediante Playwright sobre el Chrome ya abierto en produccion (https://signmethod.com/) y completada con revision del contrato frontend/backend. En el flujo Nuevo acuerdo se comprobo que existe la seccion Proteccion del acuerdo, que al activarla muestra dos campos de contraseña del acuerdo. Se inicio la preparacion del acuerdo QA QA FIR-19 contraseña acuerdo 2026-09-01 con destinatario previsto pau.dengra@softradis.com, pero la automatizacion del selector de archivo en Chrome quedo inestable antes de enviar el acuerdo. La revision de implementacion confirma el defecto funcional: la ruta publica GET /public-agreements/{token}, usada por https://signmethod.com/comprobar-token, llama a findPublicSignatureRequestByToken y devuelve el acuerdo por token sin comprobar passwordProtectionEnabled, agreementPasswordHash ni agreementPasswordSalt; la vista publica tampoco muestra un prompt de contraseña antes de cargar documentos y boton Firmar. Por tanto, para acuerdos protegidos no existe un control verificable donde una contraseña incorrecta bloquee y solo la valida permita continuar. Vease INC-027. Evidencia: docs/evidencias/FIR-19-CONTRASENA-DE-ACUERDO-2026-09-01.md. |
| FIR-20 | Joel López y Pau Dengra | Firmar secuencialmente con dos destinatarios. | Cada uno firma en su turno y se completa al final. | KO | Ejecutada el 01/09/2026 con apoyo de Playwright en el Chrome abierto y revision del contrato frontend/backend antes de crear mas acuerdos reales en produccion. La interfaz contempla el modo Secuencial en participantes y el frontend envia signingOrderEnabled junto con signingOrder cuando se activa. Sin embargo, el backend sendSignatureRequest genera token para todos los destinatarios con recipients.map(...) y envia correos a todos mediante Promise.all(...), sin limitar el envio al primer firmante. La ruta publica por token findPublicSignatureRequestByToken solo valida existencia, cancelacion, invalidacion, uso y caducidad del token, pero no comprueba signingOrder ni si hay firmantes anteriores pendientes. La finalizacion persistCompletedSignatureDocument permite firmar a cualquier destinatario del acuerdo y solo marca el acuerdo como completado cuando todos han firmado, sin bloquear turnos. Por tanto, el sistema no garantiza que cada destinatario firme en su turno: todos pueden recibir enlace y firmar en cualquier orden. Vease INC-028. Evidencia: docs/evidencias/FIR-20-FIRMA-SECUENCIAL-DOS-DESTINATARIOS-2026-09-01.md. |
| FIR-21 | Pau Dengra | Añadir comentarios, si aplica. | Se guardan y son visibles solo para quien corresponda. | KO | Ejecutada el 01/09/2026 con apoyo de Playwright en el Chrome abierto y revision del contrato frontend/backend. La interfaz de firma puede mostrar un campo Comentario cuando commentsEnabled esta activo y el envio de firma incluye comment: linkedSignatureComment.trim(). En backend, persistCompletedSignatureDocument guarda ese comentario dentro del signedArtifact. Sin embargo, el detalle de acuerdo getSignatureRequest construye signedVersions sin devolver el campo comment, y la interfaz no contiene ninguna vista posterior que liste comentarios guardados ni controles de visibilidad por remitente/destinatario. Por tanto, no se puede comprobar desde la aplicacion que los comentarios queden visibles solo para quien corresponda; en la practica el comentario queda persistido como metadato interno del artefacto, pero no consultable en UI. Vease INC-029. Evidencia: docs/evidencias/FIR-21-COMENTARIOS-ACUERDO-2026-09-01.md. |
| FIR-22 | Joel López y Pau Dengra | Verificar que un destinatario no abre el documento de otro. | El backend deniega el acceso. | KO | CRITICA. Ejecutada el 01/09/2026 con apoyo de Playwright en el Chrome abierto y revision del contrato frontend/backend antes de crear nuevos documentos reales. El backend no garantiza el aislamiento por destinatario. En la ruta publica GET /public-agreements/{token}, getPublicAgreementByToken identifica al destinatario del token y devuelve solo ese destinatario en recipients, pero llama a buildPublicAgreementDocuments(request.documents ?? []) y devuelve todos los documentos del acuerdo con URLs prefirmadas de descarga/previsualizacion, sin filtrar por destinatario ni assignedFieldIds. En la ruta autenticada de detalle, assertActorCanOpenSignatureRequest permite abrir el acuerdo a cualquier destinatario incluido; despues getSignatureRequest construye signedVersions recorriendo todos los request.recipients y devuelve downloadUrl de las versiones firmadas de todos ellos, sin filtrar por actor destinatario. Por tanto, un destinatario puede recibir o consultar documentos/versiones que no le corresponden si forman parte del mismo acuerdo. Vease INC-030. Evidencia: docs/evidencias/FIR-22-AISLAMIENTO-DOCUMENTOS-DESTINATARIO-2026-09-01.md. |
| FIR-23 | Pau Dengra | Cargar un documento al crear o editar un acuerdo y pasar el ratón sobre su tarjeta o miniatura. | Las acciones disponibles, como sustituir, ver, descargar y eliminar, aparecen como iconos superpuestos al documento únicamente al situar el puntero sobre él. No se muestran botones de texto permanentes sobre la previsualización. Cada icono tiene tooltip, nombre accesible, foco de teclado visible y ejecuta la acción correcta. | KO | Actualmente las acciones aparecen como botones de texto grandes y permanentes sobre el documento. Véase INC-005. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
14. Persistencia, almacenamiento y correo
Requiere acceso técnico autorizado.
| ID | Responsable | Prueba | Resultado esperado | Estado | Evidencia/observaciones |
|---|---|---|---|---|---|
| TEC-01 | Joel López | Revisar las peticiones de los flujos reales. | No hay 5xx, preproducción ni reintentos anómalos. | KO | AWS confirma producción (signmethod-prod-*), 5XXError=0, Lambda Errors=0 y Throttles=0; Chrome no muestra preproducción, pero observa GET /prod/signatures con net::ERR_FAILED. Falta access logs/correlación para certificar ausencia de reintentos o duplicados anómalos. Véase INC-032. Evidencia: TEC-01-TEC-02-TEC-03-REVISION-TECNICA-PRODUCCION-2026-09-01.md. |
| TEC-02 | Joel López | Revisar objetos, metadatos y checksums. | Original y firmado están en tenant y ubicación correctos. | KO | AWS confirma tabla con PITR, registros con requestId, companyId, status, documentos/destinatarios y un original S3 con PDF, tamaño, ETag y metadatos. KO/parcial: falta SHA-256 explícito, no hay signedArtifacts/firmados completados revisables y 10 documentos revisados no siguen uniformemente documents/{companyId}/{documentId}/.... Evidencia: TEC-01-TEC-02-TEC-03-REVISION-TECNICA-PRODUCCION-2026-09-01.md. |
| TEC-03 | Joel López | Probar URL firmada con método/objeto distinto y tras caducar. | Solo admite la operación, objeto y periodo autorizados. | KO | URL firmada S3 de producción: GET autorizado 200, PUT sobre URL de descarga 403, key alterada 403 y URL caducada 403. KO porque falta repetir con URL emitida por el endpoint real de la aplicación y con artefacto firmado cuando exista. Véase INC-033. Evidencia: TEC-01-TEC-02-TEC-03-REVISION-TECNICA-PRODUCCION-2026-09-01.md. |
| TEC-04 | Joel López | Intentar acceso público y listado del bucket. | Ambos están bloqueados. | KO | No se pudo obtener evidencia concluyente desde el entorno local: Chrome bloquea el endpoint publico S3 con net::ERR_BLOCKED_BY_CLIENT, curl.exe falla por TLS local y Invoke-WebRequest termina con error de recepcion. Para convertirlo en OK: probar el listado publico del bucket y una key real QA sin URL firmada, guardar respuestas 403 AccessDenied en ambos casos y conservar evidencia redaccionada sin keys sensibles completas. Vease INC-034. Evidencia: TEC-04-TEC-06-TEC-07-TEC-08-REVISION-TECNICA-PRODUCCION-2026-09-02.md. |
| TEC-05 | Joel López | Cerrar sesión y volver a consultar los datos. | Usuarios, plantillas, acuerdos y estados persisten. | OK | Chrome confirma cierre de sesión, login posterior y persistencia de usuario joel.lopez@softradis.com, empresa pepe - Owner, acuerdos y contadores (Pendientes 3, Enviados 5, Completados 0). Evidencia: TEC-05-PERSISTENCIA-SESION-DATOS-2026-09-01.md. |
| TEC-06 | Joel López | Revisar envíos, entregas, rebotes y duplicados. | Cada acción genera los mensajes previstos. | KO | Con autorizacion del usuario se creo y envio el acuerdo QA QA TEC-06 envio Joel 2026-09-02 a joel.lopez@softradis.com. SignMethod mostro Acuerdo enviado correctamente a 1 destinatario; Gmail recibio un unico correo de no-reply@signmethod.com, asunto Prueba, a las 09:42. AWS 02/09 09:42 CEST confirma actividad Lambda, Errors=0, Throttles=0 y API Gateway 5XXError=0, pero los access logs no estan configurados (accessLog: null), SES no tiene configuration sets en eu-west-1 y CloudTrail no devuelve eventos email.amazonaws.com. Para convertirlo en OK: activar access logs/correlation id, configurar eventos SES de envio/entrega/rebote/queja, repetir envio QA y demostrar 1 envio, 1 entrega, 0 rebotes, 0 quejas, 0 duplicados tecnicos, 5XXError=0, Lambda Errors=0 y Throttles=0. Vease INC-032. Evidencia: TEC-04-TEC-06-TEC-07-TEC-08-REVISION-TECNICA-PRODUCCION-2026-09-02.md. |
| TEC-07 | Joel López | Revisar logs de las pruebas. | No contienen contraseñas, tokens completos ni documentos. | KO | La consola de Chrome no mostro entradas capturadas ni secretos visibles, pero falta revisar CloudWatch/API Gateway del periodo exacto y no hay access logs completos por peticion. Para convertirlo en OK: exportar logs censurados de Lambda/API Gateway del periodo de pruebas, buscar patrones sensibles (password, token, Authorization, Cookie, X-Amz-Signature, URLs firmadas completas y contenido PDF), confirmar cero secretos/documentos o corregir el logging y repetir con evidencia limpia. Vease INC-032. Evidencia: TEC-04-TEC-06-TEC-07-TEC-08-REVISION-TECNICA-PRODUCCION-2026-09-02.md. |
| TEC-08 | Joel López | Repetir una operación tras un corte de red controlado. | No duplica usuarios, documentos, acuerdos o firmas. | KO | Prueba parcial sin efectos reales: se corto red en Chrome, se actualizo el listado y tras recuperar red los contadores siguieron Todos (5), Pendientes (3), Borradores (0), Completado (0), sin duplicados visibles. Para convertirlo en OK: elegir una escritura QA controlada, registrar conteos antes, cortar red durante la operacion, reintentar tras recuperar conexion y verificar en UI/backend/logs que no se duplican usuarios, documentos, acuerdos ni firmas; pedir confirmacion previa si implica envio o firma. Vease INC-035. Evidencia: TEC-04-TEC-06-TEC-07-TEC-08-REVISION-TECNICA-PRODUCCION-2026-09-02.md. |
| TEC-09 | Joel López | Comprobar consistencia entre Cognito, usuarios y empresa. | Identidad, membresía y estado coinciden. | OK | Desde Chrome se valida coherencia visible entre sesión joel.lopez@softradis.com, empresa activa pepe y rol Owner. No incluye contraste directo con Cognito/DynamoDB por requerir AWS. Evidencia: TEC-09-CONSISTENCIA-IDENTIDAD-USUARIO-EMPRESA-2026-09-01.md. |
15. Seguridad funcional
No ejecutar escaneos agresivos o denegación de servicio en producción.
| ID | Responsable | Prueba | Resultado esperado | Estado | Evidencia/observaciones |
|---|---|---|---|---|---|
| SEG-01 | Joel López | Realizar petición desde un origen no autorizado. | CORS rechaza el origen. | KO | Comprobado desde Chrome con origen https://example.com: GET /prod/health responde HTTP 200, type: cors y cuerpo legible de signmethod-admin-api, por lo que un origen no autorizado puede leer al menos un endpoint. Ademas, API Gateway usa Cors.ALL_ORIGINS/Cors.ALL_METHODS, Lambda responde access-control-allow-origin: * y el bucket S3 permite allowedOrigins: ['*'] con GET, PUT y HEAD. Para convertirlo en OK: definir allowlist cerrada de origenes autorizados, retirar * de API/Lambda/S3, probar origen autorizado con preflight valido y origen no autorizado con rechazo/sin cabecera Access-Control-Allow-Origin, y guardar cabeceras/capturas. Vease INC-036. Evidencia: SEG-01-SEG-03-SEG-07-REVISION-SEGURIDAD-2026-09-02.md. |
| SEG-02 | Joel López | Revisar CSP y cabeceras de seguridad. | Son correctas y no rompen login, reCAPTCHA o PDF. | KO | Chrome/CDP muestra que la respuesta HTML principal no incluye Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy ni Permissions-Policy. Evidencia: SEG-02-CSP-CABECERAS-SEGURIDAD-2026-09-01.md. |
| SEG-03 | Joel López | Modificar o usar un JWT caducado. | El backend rechaza la petición. | PENDIENTE | Confirmado en AWS: la API real signmethod-prod-admin-api (cb6456xer6, stage prod, eu-west-1) usa Cognito User Pools en rutas protegidas, por ejemplo /users/{userId}, y la validacion JWT se realiza en API Gateway antes de invocar la Lambda. No se creo User Pool, app client, usuario QA ni se guardo/expuso ningun JWT. Desde Chrome en https://signmethod.com, GET /prod/companies sin Authorization y con JWT falso/caducado no devuelven datos y quedan como Failed to fetch. Falta una prueba con JWT QA real caducado y codigo HTTP exacto; lo esperado con Cognito ante expiracion es 401 Unauthorized, pero no se ha ejecutado esa prueba concreta y no hay access logs del stage prod. Para convertirlo en OK: usar token QA real caducado o manipulado contra una ruta privada, confirmar 401/403 sin datos ni efectos, probar tambien sin Authorization, revisar que CloudWatch no registra el token completo y guardar solo codigos HTTP/token redaccionado. Vease INC-037. Evidencia: SEG-01-SEG-03-SEG-07-REVISION-SEGURIDAD-2026-09-02.md. |
| SEG-04 | Joel López y Pau Dengra | Introducir HTML/JS inocuo en campos QA. | Se muestra como texto o se sanitiza; nunca se ejecuta. | OK | Validado el 01/09/2026 en produccion mediante Playwright sobre el Chrome abierto. Se introdujeron payloads inocuos de HTML/JS en titulo, descripcion, asunto y mensaje de un borrador QA. En titulo/listado React escapo las etiquetas (<b>, <img...>); en el editor Quill el HTML se mantuvo como texto escapado; los marcadores data-seg04* no se activaron en ningun momento. La revision de codigo confirma sanitizacion adicional de HTML enriquecido antes de previsualizar/enviar. Evidencia: docs/evidencias/SEG-04-XSS-CAMPOS-QA-2026-09-01.md. |
| SEG-05 | Pau Dengra | Probar nombres de archivo con secuencias de ruta. | Se normalizan o rechazan. | KO | Validado el 01/09/2026 en produccion mediante Playwright sobre el Chrome abierto. Se creo el borrador QA QA SEG-05 nombres ruta 2026-09-01 y se subieron cuatro PDF con nombres problematicos: ..%2F..%2Fsecreto.pdf, ..%5C..%5Csecreto.pdf, ....secreto.pdf y contrato_'onerror=alert(1)'.pdf. El flujo de acuerdos los acepto, los mostro en tarjetas de documento y, tras guardar y reabrir el borrador, persistieron literalmente sin rechazo ni normalizacion. No se observo ejecucion de codigo ni alteracion visible de rutas; el backend usa documentId/UUID para claves internas, pero conserva document.name sin politica de limpieza. Vease INC-018. Evidencia: docs/evidencias/SEG-05-NOMBRES-RUTA-ACUERDOS-2026-09-01.md. |
| SEG-06 | Joel López | Repetir manualmente varios accesos o registros fallidos. | Actúa la protección prevista sin bloqueo indefinido. | PENDIENTE | No automatizar volumen. Evidencia anexa: OBSERVACIONES-HISTORICAS-SIN-ARCHIVO-DEDICADO-2026-09-01.md. |
| SEG-07 | Joel López | Revisar secretos y permisos IAM autorizados. | No hay secretos en frontend y se aplica privilegio mínimo. | KO | NO OK. Auditoria AWS solo lectura: no hay secretos literales en variables Lambda, codigo Lambda ni bundle frontend; signmethod-prod-admin-api usa rol exclusivo con confianza limitada a lambda.amazonaws.com; Cognito esta limitado al User Pool de produccion; DynamoDB no usa dynamodb:* y apunta a ARNs signmethod-prod-*; S3 esta limitado al bucket real y este tiene bloqueo publico, SSE-S3, versionado, propietario forzado y denegacion HTTP; SSM esta limitado a dos ARNs y no hay Secrets Manager; validate-policy no devuelve errores/avisos. Brechas: ses:SendEmail mantiene Resource:*, SES esta en sandbox y sin configuration sets/event destinations; S3 no restringe prefijo/tenant y permite GetObject*, List*, DeleteObject* y escritura sobre bucket/*; DynamoDB no tiene condicion tenant e incluye Scan/DeleteItem; /signmethod/prod/recaptcha-secret no existe y demo-request-recipient es String; no hay permissions boundary, analyzer en eu-west-1 ni CloudTrail regional; varias acciones Cognito admin no tienen uso reciente verificable. Para convertirlo en OK: crear/corregir secreto reCAPTCHA como SecureString, limitar SES/S3/DynamoDB/Cognito a identidades, prefijos, acciones y recursos necesarios, configurar SES events, Access Analyzer y CloudTrail, justificar o retirar acciones no usadas y repetir flujos criticos tras el recorte. Vease INC-038. Evidencia: SEG-01-SEG-03-SEG-07-REVISION-SEGURIDAD-2026-09-02.md. |
| SEG-08 | Joel López y Pau Dengra | Manipular IDs en operaciones de lectura y escritura. | La autorización se valida siempre en backend. | KO | CRITICA. Ejecutada el 01/09/2026 mediante Playwright sobre el Chrome abierto y revision dirigida del backend. La sesion visible estaba en Administrador · Prueba Produccion. No se realizaron escrituras destructivas reales. Se detecto que POST /users/{userId}/block y POST /users/{userId}/unblock llaman a setUserBlocked(userId, blocked, actorFrom(event)), pero setUserBlocked no recibe event ni valida assertActorCanAccessCompany, rol de administrador, pertenencia a empresa, ni autoproteccion antes de ejecutar AdminDisableUserCommand/AdminEnableUserCommand y actualizar DynamoDB. Ademas, las rutas publicas de firma permiten operar por documentId dentro del acuerdo asociado al token sin comprobar asignacion de documento/campo al destinatario, coherente con INC-030. Por tanto no puede afirmarse que la autorizacion se valide siempre en backend ante manipulacion de IDs. Vease INC-031. Evidencia: docs/evidencias/SEG-08-MANIPULACION-IDS-LECTURA-ESCRITURA-2026-09-01.md. |
17. Rendimiento y resiliencia
| ID | Responsable | Prueba | Resultado esperado | Estado | Evidencia/observaciones |
|---|---|---|---|---|---|
| REN-01 | Joel López | Ejecutar Lighthouse en home, login y panel. | Cumple los límites acordados o se acepta la desviación. | KO | Evidencia Lighthouse completa para las tres superficies: panel https://signmethod.com/#dashboard con 95/100/96/92, FCP 0.9 s, LCP 1.4 s, TBT 0 ms, CLS 0.03, Speed Index 1.0 s; login/modal en incognito sin sesion, prueba de las 12:02, con 93/98/100/92, FCP 0.7 s, LCP 1.7 s, TBT 0 ms, CLS 0, Speed Index 0.7 s; home publica con 88/98/100/92, FCP 0.8 s, LCP 1.8 s, TBT 0 ms, CLS 0, Speed Index 2.0 s. KO porque home Performance 88 queda por debajo del rango verde habitual y no hay aceptacion formal de la desviacion. Para convertirlo en OK: guardar/exportar los reportes, aceptar formalmente esa desviacion o corregir optimizaciones y repetir. Vease INC-042. Evidencia: REN-01-REN-02-RENDIMIENTO-CACHE-RECURSOS-2026-09-02.md. |
| REN-02 | Joel López | Revisar caché, compresión y tamaño de recursos. | Assets versionados usan caché sin cachear datos sensibles. | KO | Recarga sin cache en Chrome/DevTools sobre signmethod.com/#dashboard: 31 respuestas observadas, transferencia total aprox. 17.23 MB, de los cuales 17.22 MB son recursos estaticos y unos 10 KB API. Positivo: HTML con cache-control: no-cache,no-store,must-revalidate; assets versionados index-Cbl1jt2H.js (476 KB) e index-Iq5l-xVV.css (68 KB) con public,max-age=31536000,immutable, content-encoding: br y Hit from cloudfront; API no se sirve desde cache. Lighthouse confirma payload alto en panel (16,825 KiB), login/modal incognito (16,815 KiB) y home publica (16,817 KiB), con Improve image delivery de hasta 14,323 KiB, imagenes de 1.8-2.3 MB, CSS bloqueante, LCP no descubrible de inicio, imagenes sin width/height, JS no usado (240-447 KiB segun superficie, con parte atribuible a extension) y CSS no usado (64 KiB). Para convertirlo en OK: optimizar imagenes (webp/avif), variantes responsive, lazy loading, width/height, fetchpriority=high para LCP, reducir JS/CSS no usado, definir presupuesto de peso y repetir medicion conservando cabeceras. Vease INC-042. Evidencia: REN-01-REN-02-RENDIMIENTO-CACHE-RECURSOS-2026-09-02.md. |
| REN-03 | Pau Dengra | Probar red lenta desde el navegador. | Muestra carga/error y no duplica acciones. | KO | Simulada red lenta desde Chrome/DevTools sobre signmethod.com/#dashboard (400 ms, descarga aprox. 50 Kbps, subida aprox. 20 Kbps). La recarga de solo lectura quedo estable en unos 7.9 s; contadores antes y despues iguales (Enviados 6, Pendientes 3, Completados 1), sin duplicados visibles. Las respuestas principales devolvieron 200/204, pero se observo un net::ERR_FAILED y no se probo una accion de escritura/reintento, por lo que no se demuestra ausencia de duplicados ante acciones. Para convertirlo en OK: probar una escritura QA segura con red lenta/corte controlado, mostrar carga/error, bloquear doble accion o demostrar idempotencia, recuperar red/reintentar y verificar en UI/backend/logs que no se duplican acuerdos, documentos, usuarios, correos ni firmas. Vease INC-035. Evidencia: REN-01-REN-02-RENDIMIENTO-CACHE-RECURSOS-2026-09-02.md. |
| REN-04 | Joel López | Simular 4xx/5xx solo localmente o en un entorno controlado. | Informa y permite reintentar con seguridad. | KO | Repetido dos veces en Chrome real de produccion con tokens inexistentes no sensibles: GET /prod/public-agreements/TOKEN-INEXISTENTE-REN-04-2026-09-02 y GET /prod/public-agreements/TOKEN-INEXISTENTE-REN-04-RETEST-2026-09-02 devuelven 404, pero la UI muestra Agreement not found y no se observa accion clara de reintento. La prueba local controlada con Playwright tambien falla: esperaba No se ha encontrado un acuerdo para este token., pero la UI mostro Acuerdo no encontrado. No se han simulado todavia 500, timeout ni fallo de red con reintento seguro; el intento de simular 500 por CDP fue rechazado por Chrome y no se fuerza en produccion. Para convertirlo en OK: completar mocks 404/500/timeout/network abort, mensajes claros en castellano, accion de reintento y demostrar que no hay duplicados tras reintentar. Vease INC-043. Evidencia: REN-04-REN-05-RESILIENCIA-LATENCIA-2026-09-02.md, capturas docs/evidencias/REN-04-token-inexistente-produccion-2026-09-02.png y docs/evidencias/REN-04-token-inexistente-produccion-retest-2026-09-02.png. |
| REN-05 | Joel López | Revisar latencia, timeouts y cold starts observados. | Están dentro de los límites acordados. | KO | Ventana ampliada 02/09/2026 07:47-03/09/2026 07:47 UTC. API Gateway/X-Ray p95/p99 1,163/1,344 ms, dentro de los umbrales recomendados <=1,500/2,000 ms. Lambda p95/p99 de referencia 571/647 ms, dentro de <=750/1,000 ms; maximo 801.37 ms, memoria 124/256 MB, timeouts 0, fallos de runtime 0 y throttles 0. DynamoDB: nueve tablas sin SystemErrors, UserErrors ni throttling; peor latencia Query p99=20.83 ms. KO porque los cold starts son 24/128 (18.75 %) y superan el objetivo <=10 %, aunque Init Duration p95/max 624.76/724.70 ms cumple <=800/1,000 ms. Ademas, Lambda esta en PassThrough, S3 no tiene metricas detalladas ni access logging, no hay alarmas y API Gateway carece de access logging/CORS en respuestas de error; esto es compatible con que /prod/signatures aparezca como net::ERR_FAILED antes de invocar Lambda. Para convertirlo en OK: reducir o aceptar formalmente la tasa de cold starts, repetir contra los umbrales, instrumentar dependencias, habilitar observabilidad/alarmas y corregir/verificar CORS y /prod/signatures. Vease INC-044. Evidencia: REN-04-REN-05-RESILIENCIA-LATENCIA-2026-09-02.md y captura docs/evidencias/REN-05-panel-timings-produccion-2026-09-02.png. |
| REN-06 | Joel López | Revisar cuotas de Cognito, API Gateway, Lambda, DynamoDB, S3 y SES. | Hay margen suficiente y no existe throttling anómalo. | KO | Revision AWS de produccion comunicada el 03/09/2026. Cognito queda OK: pico de autenticacion 0,033 req/s (0,028 % de 120 req/s) y sin TooManyRequests. Lambda queda OK: 2.325 invocaciones en 7 dias, 0 errores, 0 throttles, 0 timeouts y concurrencia maxima 5/10. SES queda OK para el sandbox previsto: 5/200 mensajes en 24 h (2,5 %), margen de 195, 50 envios/49 entregas/1 rebote en 7 dias y prueba con 1 envio/1 entrega. El resultado global es KO: aunque API Gateway solo alcanzo 0,533 req/s frente a 10.000 req/s y no tuvo 429/5XX durante la prueba, CloudTrail registro 701 TooManyRequestsException el 27/08 en el plano de control del despliegue; DynamoDB, con 9 tablas y 4 indices bajo demanda y picos de solo 3,5 RCU/3 WCU, registro una ThrottlingException en CreateTable; S3, con unos 50 objetos/5,37 MiB y sin SlowDown/503 localizados, carece de metricas suficientes de solicitudes, errores y latencia. Para convertirlo en OK: aplicar backoff exponencial con jitter, reducir paralelismo y esperar estabilizacion en los despliegues; repetirlos sin throttling y observar una ventana limpia; habilitar access logs de API Gateway y Request Metrics/Data Events o access logging en S3; configurar las alarmas indicadas y repetir REN-06. Vease INC-045. Evidencia: REN-06-CUOTAS-THROTTLING-AWS-2026-09-03.md. |
18. Monitorización durante las primeras dos horas
Joel López y Pau Dengra alternarán un control cada 15 minutos.
| Hora | Responsable | Home | Login | Rechazo no autorizado | Listado | Firma pública | API/Lambda | Cognito | DynamoDB | S3/SES | Observaciones |
|---|---|---|---|---|---|---|---|---|---|---|---|
| +00 | Joel López | OK | OK | OK | OK | OK | OK | KO | KO | PARCIAL | Ejecutado el 03/09/2026, 09:53-10:00 CEST, mediante Playwright en Chrome y revisión AWS. Home y panel disponibles; listado con 6 acuerdos y respuestas 200; token ficticio rechazado con 404. Lambda: 23 invocaciones y 23 REPORT, Errors=0, Throttles=0, máximo 568,71 ms, memoria 122/256 MB y 3 cold starts. API Gateway recibió 3 OPTIONS /signatures, pero ningún GET: Chrome lo bloqueó porque el preflight no admite cache-control; Lambda no fue invocada. Cognito queda KO de observabilidad por falta de métricas de autenticación y alarmas durante la ventana, aunque el login funcional fue OK. No existe ninguna alarma para la función. S3 no tiene Request Metrics, FilterId, registros de acceso ni CloudTrail Data Events; CloudFront tampoco tiene logs. Las lecturas directas autorizadas devolvieron 200/206 sin cambios y CloudFront sirvió la portada con 200, pero el origen no puede reconstruirse. No existen alarmas S3 o CloudFront ni acciones SNS. El objeto privado era JSON, no un PDF abierto desde Signmethod; SES sigue sin verificar. No se cerró sesión ni se usó un token real. El paquete final contiene 17 archivos, supera la lectura integral y verifica 16 de 16 hashes del manifiesto; SHA-256 del ZIP 8bdeba69c7cea8d738f49023b04e3570bbc20834f7dd076514c9a57a334b5ed0. Evidencias: MON-00-CONTROL-PRIMERAS-DOS-HORAS-2026-09-03.md y observation-plus00-evidence-2026-09-03.zip. |
| +15 | Pau Dengra | OK | OK | OK | OK | OK | OK | KO | KO | PARCIAL | Ventana evaluada: 03/09/2026, 08:28-08:54 UTC; consulta retrospectiva AWS a las 10:22 UTC en modo de solo lectura y contraste funcional posterior con Playwright. Home: 10/10 200, media 81 ms, máxima 155 ms; CloudFront registró 42 solicitudes y 0 % de errores totales, 4xx y 5xx. API health: 10/10 200, CORS 204 y máxima 193 ms. Lambda: 18 invocaciones, 0 errores, 0 throttles, duración media 69,48 ms, máxima 145,3 ms y concurrencia máxima 2; sus 60 eventos de log incluyen tres registros ERROR correspondientes a respuestas 410 esperadas de enlaces inválidos, no a fallos internos. Login, segundo factor, rechazo no autorizado, listado y firma completa quedaron funcionalmente OK; el acuerdo QA MON-15 firma completa 2026-09-03 figura como Firmado. Cognito queda KO en su columna de observabilidad porque no tuvo puntos de autenticación ni alarmas durante la ventana, aunque el login funcional fue OK. DynamoDB queda KO: las nueve tablas signmethod-prod-* estaban ACTIVE y PAY_PER_REQUEST, pero no tuvieron tráfico ni emitieron métricas que permitan acreditar retrospectivamente latencia, errores o throttling; tampoco existen alarmas. S3/SES queda PARCIAL: CloudFront acredita la entrega web, pero los tres buckets revisados no tenían Request Metrics; SES no registró actividad y carece de configuration sets, event destinations y alarmas. Resultado global KO de monitorización porque no existen alarmas asociadas a Lambda, DynamoDB, S3, SES o Cognito. La revalidación funcional quedó desplazada respecto al intervalo nominal posterior a +00. Evidencia: MON-15-CONTROL-PRIMERAS-DOS-HORAS-2026-09-03.md. |
| +30 | Joel López | OK | OK | OK | OK | OK | OK | KO | KO | PARCIAL | Estados copiados de +15 por indicación expresa, utilizando la evidencia de Pau Dengra; no acredita una ejecución independiente de Joel en +30. Se mantienen Cognito=KO, DynamoDB=KO y S3/SES=PARCIAL. Evidencias: MON-15-CONTROL-PRIMERAS-DOS-HORAS-2026-09-03.md y MON-30-OBSERVACIONES-JOEL-LOPEZ-2026-09-03.txt. |
| +45 | Pau Dengra | OK | OK | OK | OK | OK | OK | KO | KO | PARCIAL | Estados y evidencia funcional reutilizados de +15 por indicación expresa; no constituye una ejecución independiente en el intervalo nominal +45. Se mantienen Cognito=KO y DynamoDB=KO por falta de observabilidad, y S3/SES=PARCIAL por ausencia de Request Metrics S3 y eventos SES acreditados. Evidencias: MON-15-CONTROL-PRIMERAS-DOS-HORAS-2026-09-03.md y MON-45-OBSERVACIONES-PAU-DENGRA-2026-09-03.txt. |
| +60 | Joel López | OK | OK | OK | OK | OK | OK | KO | KO | PARCIAL | Réplica documental de las respuestas de +15, sin una nueva medición atribuible a Joel en +60. La evidencia funcional es la misma y las brechas de Cognito, DynamoDB y S3/SES no cambian. Evidencias: MON-15-CONTROL-PRIMERAS-DOS-HORAS-2026-09-03.md y MON-60-OBSERVACIONES-JOEL-LOPEZ-2026-09-03.txt. |
| +75 | Pau Dengra | OK | OK | OK | OK | OK | OK | KO | KO | PARCIAL | Se replican las respuestas de +15 con la misma evidencia base y una observación propia para +75; no se añade una medición nueva ni se acredita continuidad temporal. Persisten los KO de Cognito y DynamoDB y el resultado PARCIAL de S3/SES. Evidencias: MON-15-CONTROL-PRIMERAS-DOS-HORAS-2026-09-03.md y MON-75-OBSERVACIONES-PAU-DENGRA-2026-09-03.txt. |
| +90 | Joel López | OK | OK | OK | OK | OK | OK | KO | KO | PARCIAL | Se reutilizan estados y evidencia de +15 con observación específica para +90; no representa una comprobación autónoma de Joel. Persisten Cognito=KO, DynamoDB=KO y S3/SES=PARCIAL. Evidencias: MON-15-CONTROL-PRIMERAS-DOS-HORAS-2026-09-03.md y MON-90-OBSERVACIONES-JOEL-LOPEZ-2026-09-03.txt. |
| +105 | Pau Dengra | OK | OK | OK | OK | OK | OK | KO | KO | PARCIAL | Cierre documental basado en los mismos resultados de +15, acompañado de un TXT de observaciones distinto. No representa una comprobación autónoma en +105. Las brechas de Cognito, DynamoDB y S3/SES permanecen sin cambios. Evidencias: MON-15-CONTROL-PRIMERAS-DOS-HORAS-2026-09-03.md y MON-105-OBSERVACIONES-PAU-DENGRA-2026-09-03.txt. |
| +120 | Joel López y Pau Dengra | OK | OK | OK | OK | OK | OK | KO | KO | PARCIAL | Cierre conjunto copiado de +15 por indicación expresa. No acredita una ejecución independiente en +120 ni continuidad durante las dos horas. Se conservan las brechas de Cognito, DynamoDB y S3/SES. Evidencias: MON-15-CONTROL-PRIMERAS-DOS-HORAS-2026-09-03.md y MON-120-OBSERVACIONES-JOEL-PAU-2026-09-03.txt. |
Revisar en cada control:
4xx/5xxde CloudFront y API Gateway;- errores, duración y throttling de Lambda;
- fallos de registro, login y MFA en Cognito;
- errores y throttling de DynamoDB;
- errores de acceso a S3;
- entregas y rebotes de SES;
- alarmas activas y cambios anómalos de latencia.
Las carencias de observabilidad que impiden que el control quede completamente en OK se registran en INC-046.
19. Registro de incidencias
Las incidencias repetidas o con la misma causa se han consolidado. La numeración actual es correlativa y todas las referencias del plan apuntan al ID vigente.
| ID | Prueba | Severidad | Descripción | Hora | Detectada por | Evidencia | Responsable | Estado/solución |
|---|---|---|---|---|---|---|---|---|
| INC-001 | ROL-04 / ROL-04B / ROL-04C | CRÍTICA | Un firmante ve Nuevo acuerdo desde el listado, puede abrir el flujo completo y ha creado correctamente un borrador en producción mediante el guardado automático. El backend no exige un rol emisor en creación, borrador o envío: la pertenencia a la empresa permite superar el control actual. El resumen también denomina Enviados a acuerdos recibidos por el firmante. | Reproducido el 27/08/2026 y confirmado con creación efectiva de borrador el 28/08/2026 | Joel López y Pau Dengra | Informe docs/evidencias/ROL-04B-AUTORIZACION-FIRMANTE-2026-08-28.md, seis capturas del panel, acceso al flujo y borrador creado, y revisión de los controladores del backend. | Equipo de desarrollo | Abierta: ocultar todas las acciones emisoras para firmante; exigir owner, admin o emisor antes de cualquier escritura o envío; devolver 403 sin efectos en DynamoDB, S3 o SES; añadir pruebas automáticas negativas; eliminar el borrador de QA con autorización y repetir ROL-04, ROL-04B y ROL-04C. |
| INC-002 | ID-02B / ADM-02 / PLA-09 | BAJA | El control para mostrar u ocultar contraseñas no está implementado de forma común y consistente: falta en el alta de Empresa y Particular, y aparece desalineado o con estilos discordantes en Cambiar contraseña y en Opciones avanzadas de plantillas. | Detectada entre el 27/08/2026 y el 28/08/2026 | Pau Dengra y Joel López | Observación reproducida en los tres flujos; capturas de alta, cambio de contraseña y opciones avanzadas, sin conservar ninguna contraseña. | Equipo de frontend | Abierta: crear un único componente accesible de campo de contraseña; incorporarlo en el alta y reutilizarlo en perfil y plantillas; conservar el valor al alternar; unificar alineación, espaciado, tamaño, estados de foco/hover y objetivo táctil; repetir ID-02B, ADM-02 y PLA-09. |
| INC-003 | PLA-07 | MEDIA | Los PDF vacíos o dañados muestran un error de carga y Páginas no detectadas, pero permanecen incorporados y el paso Documentos aparece como completo. | Durante la ejecución del 27/08/2026 | Pau Dengra | Pruebas realizadas con los archivos QA generados en docs/; JPG y PDF superior a 50 MB sí fueron rechazados correctamente. | Equipo de desarrollo | Abierta: rechazar y retirar archivos no analizables, mantener el paso incompleto, validar también en backend y repetir PLA-07. |
| INC-004 | ADM-03 | BAJA | En el correo de invitación a una empresa, el logotipo de SignMethod no aparece centrado horizontalmente en la cabecera; queda desplazado hacia la izquierda. El contenido y el botón de aceptación siguen siendo utilizables. | Durante la ejecución del 28/08/2026 | Joel López | Captura compartida del correo de invitación recibido. | Equipo de desarrollo | ABIERTA. Corregir la plantilla HTML del correo, comprobarla en los clientes soportados y repetir ADM-03. |
| INC-005 | PLA-11 / FIR-23 | BAJA | Las acciones de documento no siguen un componente ni una disposición coherentes. En plantillas se abren en un menú de texto mal posicionado que tapa parte de la tarjeta; en acuerdos aparecen como botones de texto grandes y permanentes sobre la previsualización. | Detectada entre el 28/08/2026 y el 01/09/2026 | Pau Dengra y Joel López | Capturas de nueva plantilla, edición de memoria-prueba-01.pdf y paso Documentos de un acuerdo. | Equipo de frontend | Abierta: unificar las acciones como iconos superpuestos con tooltips y nombres accesibles; añadir alternativa equivalente para teclado y táctil; corregir posición, capas, espaciado y tratamiento de la acción destructiva; comprobar escritorio, móvil y zoom; repetir PLA-11 y FIR-23. |
| INC-006 | PUB-06 | MEDIA | La portada y las cinco rutas SEO sirven el mismo título y descripción genéricos en el HTML inicial, sin canonical. La aplicación cambia título, descripción y canonical después de ejecutar JavaScript, pero no implementa ninguna etiqueta Open Graph. Los rastreadores sin renderizado JavaScript y las plataformas sociales no reciben metadatos completos y propios de cada página. | Durante la ejecución del 28/08/2026 | Pau Dengra | Consulta directa del HTML público de las seis URLs y revisión de la configuración SEO del frontend. | Equipo de desarrollo | Abierta: generar metadatos específicos en el HTML inicial, incorporar Open Graph, validar la imagen social y repetir PUB-06. |
| INC-007 | PUB-08 | MEDIA | Los enlaces de términos, privacidad y cookies cambian la URL, pero la aplicación vuelve a renderizar la portada en lugar del contenido legal. Además, el enlace cuyo nombre accesible anuncia SignMethod abre la página de Softradis en LinkedIn, por lo que la marca anunciada y el destino no coinciden. | Durante la ejecución del 28/08/2026 | Pau Dengra | Navegación y consulta directa de las tres rutas legales; revisión de los destinos href del pie y comprobación pública de la página de LinkedIn. | Equipo de desarrollo | Abierta: implementar las tres páginas legales y confirmar o corregir el destino/nombre del enlace de LinkedIn; repetir PUB-08. |
| INC-008 | PUB-10 / PUB-11 | MEDIA | El formulario público de demo no completa un envío fiable. La clave reCAPTCHA de producción es rechazada con Invalid site key or not loaded in api.js, por lo que no se llama a /demo-requests; además, el endpoint carece de idempotencia y deduplicación, de modo que, una vez desbloqueado reCAPTCHA, peticiones simultáneas podrían provocar varios envíos SES. | Durante la ejecución del 28/08/2026 | Pau Dengra y Joel López | Intento QA-PROD-2026-08-28, mensaje del formulario, tráfico sin petición a /demo-requests y revisión de submitDemoRequest y requestDemo. | Equipo de desarrollo | Abierta: configurar y autorizar las claves reCAPTCHA de producción; añadir guarda de doble envío en frontend y clave de idempotencia con escritura condicional y TTL en backend; probar error de red, doble clic y dos peticiones simultáneas; confirmar una sola solicitud y un solo correo; repetir PUB-10 y PUB-11. |
| INC-009 | PUB-01 | MEDIA | signmethod.com y www.signmethod.com sirven la aplicación como orígenes distintos: con la sesión iniciada, el dominio principal muestra Dashboard, mientras que www muestra Acceder y Crear cuenta. La ausencia de redirección canónica divide el estado de autenticación y puede generar contenido duplicado y una experiencia incoherente. | Durante la ejecución del 28/08/2026 | Joel López | Capturas compartidas de ambos dominios en la misma sesión de navegador. | Equipo de infraestructura y desarrollo | Abierta: redirigir permanentemente www al dominio principal preservando ruta y parámetros, unificar las URL de autenticación, invalidar la caché y repetir PUB-01 verificando inicio y cierre de sesión sin bucles. |
| INC-010 | PUB-04 | MEDIA | La web pública no contiene una sección, enlace ni botón Precios. La sección #acerca sí existe, pero no dispone de un enlace o botón visible para navegar hasta ella. El resto de secciones y CTA comprobados responden correctamente. | Durante la ejecución del 28/08/2026 | Joel López | Navegación real con y sin sesión, inventario del DOM y capturas guardadas en docs/evidencias/PUB-04-NAVEGACION-Y-CONTENIDO-2026-08-28.md. | Equipo de producto y desarrollo | Abierta: confirmar el alcance de Precios, implementar el contenido/navegación o aprobar su retirada actualizando el requisito; añadir navegación accesible a Acerca y repetir PUB-04 en escritorio y móvil. |
| INC-011 | ID-05 | MEDIA | El correo de validación de una cuenta nueva no utiliza la identidad de SignMethod: se recibe desde no-reply@verificationemail.com, sin marca visual, y presenta el asunto y el cuerpo en inglés. Además, proporciona un código de seis dígitos en vez del enlace HTTPS previsto por la prueba. El destinatario sí es correcto. | Durante la ejecución del 27/08/2026 | Pau Dengra | Captura compartida del correo de validación con los detalles de remitente y destinatario desplegados. La copia definitiva debe conservarse con el código de verificación oculto. | Equipo de desarrollo | Abierta: adaptar la configuración y la plantilla del correo a la identidad e idioma de SignMethod, incluir el mecanismo HTTPS previsto o actualizar formalmente el criterio si la validación por código es el diseño aprobado, y repetir ID-05. |
| INC-012 | ID-08 | MEDIA | La pantalla de acceso no incluye la opción «¿Has olvidado tu contraseña?» ni otro mecanismo visible para iniciar la recuperación. Un usuario que ha olvidado sus credenciales no puede solicitar el cambio, por lo que el flujo de recuperación y la invalidación del código o enlace después del primer uso quedan bloqueados. | Durante la ejecución del 28/08/2026 | Pau Dengra | Observación directa de la pantalla de acceso; pendiente conservar una captura sin credenciales introducidas. | Equipo de desarrollo | Abierta: añadir un acceso visible y accesible al flujo de recuperación, implementar la solicitud y confirmación del cambio, invalidar el código o enlace tras el primer uso y repetir ID-08 de extremo a extremo. |
| INC-013 | ID-03 | MEDIA | Los formularios de alta de Empresa y Particular bloquean el envío cuando están vacíos, pero no muestran errores individuales asociados a cada campo. En el acceso vacío aparece username is required to signIn, un mensaje técnico de Cognito en inglés que no explica de forma adecuada todos los datos requeridos. | Durante la ejecución del 28/08/2026 | Joel López | Capturas compartidas del alta vacía de Empresa, alta vacía de Particular y acceso vacío. | Equipo de desarrollo | Abierta: implementar validación por campo accesible y en español, traducir/mapear los errores de autenticación, probar formatos inválidos y repetir ID-03 verificando que no sale ninguna petición con datos incorrectos. |
| INC-014 | ID-04 | ALTA | Una variante del correo registrado que combina mayúsculas y minúsculas alcanza la pantalla de validación y provoca el envío de otro código. El flujo no demuestra una comparación canónica del email y puede permitir identidades duplicadas o estados de alta inconsistentes. Además, durante las repeticiones aparecen mensajes relacionados con la empresa y con una sesión activa que no explican correctamente el conflicto del correo. | Durante la ejecución del 28/08/2026 | Joel López | Capturas compartidas del alta con el correo en mayúsculas, la variante combinada, la pantalla Valida tu email y el mensaje técnico de sesión activa. | Equipo de desarrollo | Abierta: normalizar el email con espacios exteriores eliminados y minúsculas en todas las capas, imponer unicidad sobre el valor canónico, evitar crear recursos o enviar códigos ante duplicados y repetir ID-04 sin una sesión previa. |
| INC-015 | ID-07 | ALTA | Los perfiles administrativos no disponen de un flujo utilizable de MFA en la interfaz. Privacidad y seguridad solo permite cambiar la contraseña, muestra Failed to fetch y no ofrece alta TOTP, reto ni recuperación, aunque la infraestructura declara TOTP opcional y el backend marca MFA como requerido para admin y superadmin. | Durante la ejecución del 28/08/2026 | Joel López | Informe docs/evidencias/ID-07-MFA-PERFILES-ADMINISTRATIVOS-2026-08-28.md y capturas de acceso al perfil y seguridad sin MFA. | Equipo de desarrollo | Abierta: verificar la configuración efectiva de Cognito, definir los roles obligados, implementar asociación y verificación TOTP, reto de acceso, recuperación segura, mensajes en español y auditoría; repetir ID-07 de extremo a extremo con un usuario admin. |
| INC-016 | ID-10 | ALTA | No existe un flujo explícito para la caducidad de sesión: las peticiones privadas pueden fallar al no disponer de token o recibir una respuesta no autorizada, pero la aplicación no abre una reautenticación ni conserva y restaura de forma verificable la ruta, la empresa activa y el trabajo guardado. La duración efectiva de la sesión tampoco está declarada en el cliente Cognito del proyecto. | Durante la ejecución del 28/08/2026 | Joel López | Informe docs/evidencias/ID-10-CADUCIDAD-SESION-2026-08-28.md, captura de la sesión activa en Administración y revisión de authHeaders, apiFetch y el arranque de autenticación. | Equipo de desarrollo | Abierta: definir la política de sesión, manejar globalmente la ausencia de sesión y los 401, guardar borradores seguros, reautenticar y restaurar el contexto; repetir ID-10 con caducidad corta controlada y trazas censuradas. |
| INC-017 | ADM-05 | ALTA | No existe una operación específica para retirar una invitación pendiente y revocar inmediatamente su enlace de aceptación. La protección frente al alta duplicada y la retirada de un acceso ya concedido funcionan, pero no cubren la revocación previa a la aceptación. | Durante la ejecución del 28/08/2026 | Pau Dengra | Capturas compartidas del bloqueo de un usuario ya existente y de la retirada de acceso; decisión funcional de excluir rechazo y caducidad del alcance del producto. | Equipo de desarrollo | Abierta: añadir la retirada de invitaciones pendientes, cambiar su estado de forma atómica, invalidar el token o enlace asociado, impedir que cree una membresía y repetir ADM-05 desde el enlace retirado. |
| INC-018 | PLA-08 / SEG-05 | MEDIA | Los nombres de documentos no se normalizan ni se rechazan de forma uniforme en plantillas y acuerdos: se aceptan y persisten secuencias de traversal codificadas (..%2F y ..%5C), puntos consecutivos y texto con apariencia de manejador HTML. No se observó ejecución de código ni alteración de rutas porque las claves internas usan identificadores generados, pero el nombre inseguro permanece expuesto en UI, descargas y potencialmente en Content-Disposition. | Detectada entre el 28/08/2026 y el 01/09/2026 | Pau Dengra | Informes docs/evidencias/PLA-08-NOMBRES-ARCHIVO-2026-08-28.md y docs/evidencias/SEG-05-NOMBRES-RUTA-ACUERDOS-2026-09-01.md, archivos QA y capturas de carga, persistencia y descarga. | Equipo de desarrollo | Abierta: definir una política única de nombres para plantillas y acuerdos; decodificar de forma controlada antes de validar; rechazar o normalizar separadores, traversal, puntos consecutivos, controles y texto potencialmente peligroso; limitar longitud; generar un Content-Disposition seguro; mantener el nombre fuera de las claves; añadir pruebas de frontend/backend y repetir PLA-08 y SEG-05. |
| INC-019 | FIR-05 | ALTA | El botón Firmar acuerdo del correo real de solicitud de firma apunta a http://signmethod:8081/ con parámetros, un origen interno y sin TLS, en lugar de una URL pública HTTPS de producción. El destinatario, remitente y presentación visual son correctos, pero el enlace impide considerar seguro y utilizable el correo. | Correo recibido el 20/08/2026; inspeccionado el 28/08/2026 | Pau Dengra | Informe docs/evidencias/FIR-05-CORREO-Y-ENLACE-2026-08-28.md y captura local censurada del mensaje abierto en Gmail. El token y la URL completa no se conservaron. | Equipo de desarrollo e infraestructura | Abierta: configurar el origen público de firma como https://signmethod.com, generar enlaces absolutos exclusivamente HTTPS, impedir hosts internos en producción, añadir una validación de despliegue y repetir FIR-05 con un correo nuevo antes de continuar con FIR-06. |
| INC-020 | PLA-02 / PLA-10 | ALTA | El ciclo de vida de plantillas no distingue ni persiste correctamente archivar, eliminar y restaurar. No existe una acción visible de Archivar; Eliminar borra el registro original en S3/DynamoDB y la papelera se simula en localStorage; Recuperar plantilla crea otra mediante POST /templates, por lo que no funciona entre navegadores y se pierde identidad e historial. | Detectada en producción y confirmada el 01/09/2026 | Joel López | Capturas de gestión de plantillas e informe docs/evidencias/PLA-10-PAPELERA-RESTAURACION-2026-09-01.md, con flujo Playwright y revisión de frontend/backend. | Equipo de desarrollo | Abierta: definir estados y acciones separados para archivar, enviar a papelera, restaurar y eliminar definitivamente; implementar borrado lógico persistente en backend; listar la papelera desde API; restaurar conservando templateId; registrar auditoría; repetir PLA-02 y PLA-10 desde dos navegadores o una sesión limpia. |
| INC-021 | FIR-02 | ALTA | La edición y eliminación de borradores no queda aislada. Al editar el borrador QA de FIR-01, el borrador guardado perdió su documento y pasó de 1 documento a 0 documentos. Después, al eliminar el borrador editado, el listado de borradores quedó vacío y desapareció también el borrador de control prueba. | Durante la ejecución del 01/09/2026 | Joel López | Informe docs/evidencias/FIR-02-EDICION-ELIMINACION-BORRADOR-2026-09-01.html con las capturas incrustadas del listado inicial, edición, guardado y estado final Borradores 0. | Equipo de desarrollo | Abierta: revisar la identificación usada al continuar, guardar y eliminar borradores; asegurar que las operaciones se aplican solo al draftId seleccionado; conservar documentos al editar si no se reemplazan; confirmar en backend que DELETE /signature-requests/drafts/{draftId} solo marca como eliminado el borrador indicado; repetir FIR-02 con al menos dos borradores de control. |
| INC-022 | FIR-03 | ALTA | El flujo de creación de acuerdo no conserva o no muestra todos los PDF en el resumen final. Aunque se intentan cargar dos documentos y el segundo puede verse en el paso Documentos, Revisar y enviar muestra solo 1 documento y no presenta el conjunto completo esperado. La validación de orden de destinatarios queda incompleta porque el caso completo falla por pérdida de documentos. | Durante la ejecución del 01/09/2026 | Joel López | Informe docs/evidencias/FIR-03-VARIOS-PDF-DESTINATARIOS-2026-09-01.html con las capturas incrustadas de información, documentos, destinatarios ordenados, mensaje y segundo PDF añadido; salida de Playwright con resumen 1 documento. | Equipo de desarrollo | Abierta: corregir la carga/acumulación de múltiples PDF, evitar que un nuevo setInputFiles reemplace silenciosamente la lista cuando debe añadir, persistir todos los documentos en borrador y resumen, mantener numeración secuencial visible y repetir FIR-03 antes de enviar el acuerdo principal. |
| INC-023 | FIR-07 / FIR-08 / FIR-11 / UX-01 / UX-03 | ALTA | El panel de firmante no permite localizar, revisar e iniciar la firma de forma fiable. El listado puede indicar acuerdos pendientes y no mostrar filas; Ver acuerdo abre una vista bloqueada o incoherente, sin acción de firma, con estados contradictorios de documentos y sin el detalle individual de destinatarios. Este mismo bloqueo impide validar de extremo a extremo el flujo en todos los navegadores y en orientación vertical/horizontal. | Durante la ejecución del 01/09/2026 | Pau Dengra y Joel López | Informes de FIR-07, FIR-08, FIR-11, UX-01 y UX-03; capturas de listado vacío, vista bloqueada y recorridos Playwright en Chrome con viewports 390x844 y 844x390; resultados multi-navegador de AUT-02. | Equipo de desarrollo | Abierta: corregir el listado de pendientes; rediseñar Ver acuerdo para mostrar PDF, mensaje, plazo, campos y estado individual de destinatarios; ofrecer Firmar o Revisar y firmar cuando corresponda; cargar los campos obligatorios; repetir FIR-07, FIR-08, FIR-11 y UX-03, y después ejecutar el flujo completo de UX-01 en Chrome, Edge, Firefox, WebKit/Safari y móvil real. la descarga posterior del PDF firmado permanece separada en INC-024. |
| INC-024 | FIR-12 | ALTA | No hay una acción visible para descargar el documento firmado de un acuerdo completado. Tras firmar el acuerdo FIR-10, el listado muestra Firmado y Firmados 1/1, pero Ver acuerdo solo abre el modo visualización bloqueado y el menú de acciones no incluye Descargar ni acceso al PDF firmado. Al reabrir el enlace público usado tampoco se ofrece descarga; solo se informa de que el token ya fue utilizado. Además, el detalle mostrado en UI carga el original.pdf, no una versión firmada. En acuerdos con varios destinatarios, debe poder descargarse el documento firmado correspondiente a cada usuario concreto, eligiendo el firmante/destinatario deseado y no solo un PDF genérico del acuerdo. | Durante la ejecución del 01/09/2026 | Pau Dengra | Evidencia docs/evidencias/FIR-12-DESCARGA-DOCUMENTO-FIRMADO-2026-09-01.md, capturas docs/evidencias/FIR-12-detalle-acuerdo-firmado-2026-09-01.png y docs/evidencias/FIR-12-menu-acuerdo-firmado-sin-descarga-2026-09-01.png; comprobación de interfaz mediante Playwright. | Equipo de desarrollo | Abierta: exponer en el listado y/o detalle de acuerdos completados una acción clara para descargar el PDF firmado; usar las versiones firmadas del backend (signedVersions) en lugar del original.pdf; permitir descarga por emisor y firmante autorizado; mostrar un selector/listado de destinatarios firmantes para descargar la versión firmada de cada usuario concreto; mostrar hash/tamaño por versión firmada y repetir FIR-12 para ambos usuarios. |
| INC-025 | FIR-16 | ALTA | No existe una acción visible en la interfaz para sustituir un destinatario de un acuerdo pendiente. En el listado de acuerdos pendientes, el menú de acciones del acuerdo QA FIR-07 Playwright produccion 2026-09-01 solo ofrece Duplicar, Editar deshabilitado y Cancelar. En Ver acuerdo, la vista queda en modo visualización bloqueado y solo muestra información agregada, sin gestión de destinatarios ni sustitución. Aunque el backend contiene un endpoint de sustitución de destinatario (POST /signature-requests/{requestId}/recipients/{recipientEmail}/replace), el flujo no está disponible desde la UI, por lo que FIR-16 no puede ejecutar la sustitución ni comprobar la invalidación del enlace anterior y el funcionamiento del nuevo enlace. | Durante la ejecución del 01/09/2026 | Joel López / Pau Dengra | Evidencia docs/evidencias/FIR-16-SUSTITUIR-DESTINATARIO-ENLACE-ANTERIOR-2026-09-01.md, capturas docs/evidencias/FIR-16-detalle-pendiente-sin-sustituir-2026-09-01.png y docs/evidencias/FIR-16-menu-pendiente-sin-sustituir-2026-09-01.png; revisión de frontend/src/App.tsx y backend/src/admin-api.ts. | Equipo de desarrollo | Abierta: añadir en el listado o detalle del acuerdo una acción Sustituir destinatario para destinatarios pendientes/no firmados; pedir nuevo nombre y email; llamar al endpoint replace; invalidar el token anterior; enviar o previsualizar el nuevo enlace; mostrar historial/estado del destinatario sustituido; repetir FIR-16 comprobando que el enlace anterior responde Token has been invalidated o equivalente y que el nuevo enlace abre el acuerdo correcto. |
| INC-026 | FIR-14 / FIR-17 / FIR-18 | MEDIA | La vista publica de enlace de firma muestra el token en claro dentro de la pagina bajo el texto TOKEN GENERADO, tanto cuando el token ya ha sido usado, cuando el acuerdo ha sido cancelado y cuando se prueba un token inexistente, manipulado o antiguo. Aunque no se observa posibilidad de firmar de nuevo en FIR-14 ni FIR-17 y FIR-18 rechaza los tokens no validos, exponer el token en UI aumenta el riesgo de filtracion en capturas, soporte, logs visuales o comparticiones de pantalla. | Durante la ejecucion del 01/09/2026 | Pau Dengra | Observacion mediante Playwright al reabrir enlaces publicos ya usados/cancelados y al probar tokens inexistente, manipulado y antiguo. No se conservan capturas ni URLs completas de las paginas que contienen token; las evidencias guardan solo el resultado funcional con valores censurados. | Equipo de desarrollo | Abierta: eliminar el token completo de la interfaz publica, sustituirlo por un identificador truncado o referencia interna no sensible si hace falta soporte, revisar que errores de token usado, invalidado, cancelado, caducado o manipulado no revelan secretos y repetir FIR-14, FIR-17 y FIR-18 sin capturar tokens. |
| INC-027 | FIR-19 | ALTA | La contraseña de acuerdo no se exige en la ruta publica de firma. Aunque el flujo de creacion permite activar Proteccion del acuerdo y guardar agreementPasswordHash/agreementPasswordSalt, GET /public-agreements/{token} devuelve el acuerdo tras validar solo el token de firma y no comprueba la contraseña del acuerdo. La vista publica de https://signmethod.com/comprobar-token tampoco muestra un prompt de contraseña antes de enseñar documentos o permitir abrir la firma. En consecuencia, no puede cumplirse el criterio de FIR-19: una contraseña incorrecta no queda bloqueada y la valida no es el unico camino para continuar. | Durante la ejecucion del 01/09/2026 | Pau Dengra | Comprobacion con Playwright del flujo de creacion protegido hasta la seccion Proteccion del acuerdo y revision de frontend/src/App.tsx y backend/src/admin-api.ts. No se conserva ninguna contraseña temporal. | Equipo de desarrollo | Abierta: aplicar la proteccion tambien al acceso publico por token; devolver inicialmente solo metadatos minimos y passwordRequired; añadir endpoint seguro de verificacion o incluir una prueba de contraseña en la carga publica; no revelar documentos, campos ni accion de firma hasta validar la contraseña; limitar intentos; registrar auditoria; repetir FIR-19 con contraseña incorrecta y correcta. |
| INC-028 | FIR-20 | ALTA | El modo de firma secuencial no se aplica en backend. El frontend puede enviar signingOrderEnabled y signingOrder, pero sendSignatureRequest genera tokens para todos los destinatarios y envia todos los correos a la vez. Ademas, el acceso publico por token y la finalizacion de firma no comprueban si el destinatario actual es el siguiente en turno ni bloquean a firmantes posteriores cuando hay anteriores pendientes. | Durante la ejecucion del 01/09/2026 | Pau Dengra | Revision de frontend/src/App.tsx y backend/src/admin-api.ts tras comprobar con Playwright el flujo de acuerdos. No se envio un nuevo acuerdo QA porque la logica publicada ya demuestra que no existe enforcement secuencial. | Equipo de desarrollo | Abierta: persistir signingOrderEnabled y signingOrder como parte del acuerdo; emitir inicialmente token/correo solo al primer destinatario; tras cada firma, generar y enviar el token del siguiente; bloquear en GET /public-agreements/{token} y en los endpoints de firma si hay firmantes anteriores pendientes; mostrar estados por destinatario; auditar cada cambio de turno y repetir FIR-20 con dos destinatarios reales. |
| INC-029 | FIR-21 | MEDIA | Los comentarios de firma no son consultables ni tienen controles de visibilidad. El frontend permite escribir Comentario durante la firma cuando commentsEnabled esta activo y el backend lo persiste en signedArtifacts[].comment, pero getSignatureRequest no devuelve ese campo dentro de signedVersions y la interfaz no muestra ningun historial/listado de comentarios por documento, destinatario o acuerdo. No existe una politica visible que determine si lo ve el remitente, el firmante, todos los destinatarios o solo perfiles autorizados. | Durante la ejecucion del 01/09/2026 | Pau Dengra | Revision de la vista de firma mediante Playwright y de frontend/src/App.tsx / backend/src/admin-api.ts. No se creo un comentario real adicional en produccion al no existir una vista donde validarlo posteriormente. | Equipo de desarrollo | Abierta: devolver los comentarios autorizados en el detalle del acuerdo, mostrar historial por documento y destinatario, definir alcance de visibilidad, ocultar comentarios a usuarios no autorizados, auditar creacion/lectura si aplica y repetir FIR-21 con comentario de firmante y comprobacion desde emisor y destinatario. |
| INC-030 | FIR-22 | CRITICA | El backend no aísla documentos ni versiones firmadas por destinatario. GET /public-agreements/{token} valida el token y reduce la lista de recipients al destinatario del token, pero devuelve todos los documentos del acuerdo mediante buildPublicAgreementDocuments(request.documents ?? []), incluyendo URLs prefirmadas de descarga/previsualizacion. En el detalle autenticado, cualquier destinatario del acuerdo supera assertActorCanOpenSignatureRequest; despues getSignatureRequest devuelve signedVersions de todos los destinatarios con downloadUrl, sin filtrar por el actor. Esto puede permitir que un destinatario abra documentos o versiones firmadas de otro destinatario cuando conviven en el mismo acuerdo. | Durante la ejecucion del 01/09/2026 | Pau Dengra | Revision de backend/src/admin-api.ts y del flujo de acuerdos mediante Playwright. No se creo un nuevo acuerdo real porque la logica publicada ya demuestra la ausencia de denegacion por destinatario. | Equipo de desarrollo | Abierta: modelar la relacion documento-destinatario; filtrar documentos publicos por destinatario/token; filtrar signedVersions segun actor y rol; permitir acceso completo solo a emisor/admin autorizados; devolver 403 al intentar descargar un documento/version firmada de otro destinatario; añadir pruebas negativas con dos destinatarios y repetir FIR-22. |
| INC-031 | SEG-08 | CRÍTICA | Las operaciones POST /users/{userId}/block y /unblock no validan autorización completa en backend. setUserBlocked actúa sobre el usuario indicado sin recibir el evento ni comprobar empresa, rol, pertenencia, jerarquía o autobloqueo, por lo que un actor autenticado podría manipular el userId y alcanzar una escritura sensible. El aislamiento de documentos por destinatario se gestiona por separado en INC-030. | Durante la ejecución del 01/09/2026 | Pau Dengra | Informe docs/evidencias/SEG-08-MANIPULACION-IDS-LECTURA-ESCRITURA-2026-09-01.md, comprobación no destructiva con Playwright y revisión de backend/src/admin-api.ts; no se ejecutó un bloqueo real. | Equipo de desarrollo | Abierta: pasar event a setUserBlocked; cargar el usuario objetivo; validar empresa y rol con su jerarquía; impedir autobloqueo y proteger owner/admin; devolver 403/404 sin detalles ante IDs ajenos; añadir pruebas negativas con usuario externo, firmante y admin de otra empresa; repetir SEG-08. |
| INC-032 | TEC-01 / TEC-06 / TEC-07 | ALTA | Producción no dispone de trazabilidad correlacionable y verificablemente segura para certificar los flujos críticos ni la entrega de correos. Faltan access logs de API Gateway y eventos SES; por ello no se pueden demostrar por petición la ausencia de reintentos/duplicados, el resultado técnico de cada correo ni que los logs omitan contraseñas, tokens, URLs firmadas y documentos, aunque las métricas agregadas, Gmail y la consola del navegador no muestran fallos, duplicados o secretos visibles. | Detectada entre el 01/09/2026 y el 02/09/2026 | Joel López | Informes técnicos TEC-01, TEC-06 y TEC-07; métricas AWS; captura de GET /prod/signatures con net::ERR_FAILED; capturas de recepción única en Gmail y consola del navegador sin entradas sensibles. | Equipo de infraestructura y desarrollo | Abierta: activar access logs de API Gateway con request/correlation ID, ruta, método, estados y latencia; registrar eventos funcionales y configurar eventos SES de envío, entrega, rebote y queja; excluir o truncar datos sensibles; correlacionar los sistemas; revisar CloudWatch con búsquedas censuradas; repetir TEC-01, TEC-06 y TEC-07 demostrando trazabilidad completa, ausencia de duplicados y cero secretos o documentos en logs. |
| INC-033 | TEC-03 | MEDIA | La prueba de URL firmada solo se ha podido validar contra una URL S3 de produccion generada sobre un objeto real: GET autorizado responde 200 y metodo incorrecto, key alterada y URL caducada responden 403. Falta ejecutar la misma bateria con una URL emitida por el endpoint real de la aplicacion y con un artefacto firmado, por lo que no se demuestra de extremo a extremo que el flujo aplicado por SignMethod limite correctamente operacion, objeto y periodo autorizado. | Durante la ejecucion del 01/09/2026 | Joel López | Evidencia docs/evidencias/TEC-01-TEC-02-TEC-03-REVISION-TECNICA-PRODUCCION-2026-09-01.md; pruebas AWS sobre URL S3 redaccionada y tentativa desde Chrome sin conservar tokens. | Equipo de desarrollo | Abierta: exponer o capturar de forma segura una URL emitida por la aplicacion sin divulgar query params sensibles; repetir GET autorizado, metodo no autorizado, key alterada y caducidad; repetir sobre un PDF firmado cuando exista un signedArtifact; guardar solo codigos HTTP y URL redaccionada. |
| INC-034 | TEC-04 | MEDIA | No se ha podido demostrar de forma concluyente que el bucket de documentos de produccion bloquee tanto el listado publico como el acceso publico a objetos. El endpoint S3 inferido fue bloqueado por Chrome con net::ERR_BLOCKED_BY_CLIENT y las comprobaciones por terminal fallaron por problemas TLS/conexion del entorno local. Ademas, no se dispone de una key real de objeto QA para probar acceso directo sin URL firmada. | Durante la ejecucion del 02/09/2026 | Joel López | Informe docs/evidencias/TEC-04-TEC-06-TEC-07-TEC-08-REVISION-TECNICA-PRODUCCION-2026-09-02.md; intento Chrome contra endpoint publico S3 y comprobaciones locales sin codigo HTTP fiable. | Equipo de infraestructura | Abierta: aportar o ejecutar prueba del listado publico del bucket con respuesta 403 AccessDenied; probar una key QA real sin URL firmada y confirmar 403 AccessDenied; conservar evidencia redaccionada y repetir TEC-04. |
| INC-035 | TEC-08 / REN-03 | MEDIA | Las pruebas de corte y degradación de red solo se ejecutaron sobre lecturas del listado. La interfaz se recuperó y los contadores permanecieron estables, aunque apareció un net::ERR_FAILED; al no probarse una escritura y su reintento, no se puede acreditar el comportamiento de carga/error ni la idempotencia de usuarios, documentos, acuerdos, correos o firmas. | Durante la ejecución del 02/09/2026 | Joel López y Pau Dengra | Informes de TEC-08 y REN-03; capturas del listado tras el corte y del dashboard bajo red lenta (400 ms, 50 Kbps de descarga y 20 Kbps de subida). | Equipo de frontend/backend | Abierta: elegir una escritura QA segura; registrar el estado previo; ejecutarla con red lenta y con corte controlado; mostrar carga/error y bloquear doble acción o aplicar idempotencia; recuperar la conexión, reintentar y verificar en UI/backend/logs que no hay duplicados; repetir TEC-08 y REN-03. |
| INC-036 | SEG-01 | ALTA | CORS esta configurado de forma abierta para API Gateway, Lambda y S3. Desde Chrome con origen https://example.com, GET /prod/health devuelve HTTP 200 legible por CORS. API Gateway usa Cors.ALL_ORIGINS y Cors.ALL_METHODS; la respuesta Lambda anade access-control-allow-origin: *; y el bucket de documentos permite allowedOrigins: ['*'] con metodos GET, PUT y HEAD. Esta configuracion no permite demostrar que un origen no autorizado sea rechazado. | Durante la revision del 02/09/2026 | Joel López | Informe docs/evidencias/SEG-01-SEG-03-SEG-07-REVISION-SEGURIDAD-2026-09-02.md; prueba en navegador desde https://example.com; revision de backend/infra/lib/signmethod-backend-stack.mjs y backend/src/admin-api.ts. | Equipo de infraestructura y desarrollo | Abierta: sustituir * por allowlist de origenes autorizados, restringir metodos/headers, probar origen autorizado y no autorizado, guardar cabeceras y repetir SEG-01. |
| INC-037 | SEG-03 | MEDIA | La proteccion Cognito/JWT esta configurada en la API real signmethod-prod-admin-api (cb6456xer6, stage prod, eu-west-1) y se aplica en API Gateway antes de invocar la Lambda para rutas protegidas como /users/{userId}. Desde Chrome en https://signmethod.com, una llamada privada sin Authorization y otra con JWT falso/caducado no devuelven datos y quedan como Failed to fetch. Falta evidencia runtime completa con JWT QA real caducado, codigo HTTP exacto 401/403 y trazabilidad por peticion; el stage prod no tiene access logs configurados. | Durante la revision del 02/09/2026 | Joel López | Informe docs/evidencias/SEG-01-SEG-03-SEG-07-REVISION-SEGURIDAD-2026-09-02.md; prueba en navegador, revision AWS comunicada por Joel y revision de rutas protegidas en backend/infra/lib/signmethod-backend-stack.mjs. | Equipo de QA y desarrollo | Abierta: usar token QA caducado/manipulado contra rutas privadas, confirmar 401/403, probar sin Authorization, verificar que logs no registran tokens completos y repetir SEG-03 con evidencia redaccionada. |
| INC-038 | SEG-07 | ALTA | No hay evidencia de secretos expuestos en variables Lambda, codigo Lambda o bundle frontend, y varios alcances estan correctamente limitados: rol exclusivo de Lambda con confianza lambda.amazonaws.com, Cognito limitado al User Pool de produccion, DynamoDB sin dynamodb:* y tablas signmethod-prod-*, S3 limitado al bucket real con bloqueo publico/SSE-S3/versionado/SSL, y SSM sin GetParameter sobre *. Sin embargo, no se cumple privilegio minimo ni trazabilidad completa: ses:SendEmail usa Resource:*, SES esta en sandbox y sin configuration sets/event destinations, S3 no restringe prefijo/tenant, DynamoDB no aplica condicion tenant e incluye Scan/DeleteItem, /signmethod/prod/recaptcha-secret no existe como SecureString, no hay permissions boundary, no hay analyzer en eu-west-1, no hay CloudTrail regional y varias acciones Cognito admin no tienen uso reciente justificable. | Durante la revision del 02/09/2026 | Joel López | Informe docs/evidencias/SEG-01-SEG-03-SEG-07-REVISION-SEGURIDAD-2026-09-02.md; escaneo de /assets/index-Cbl1jt2H.js desde navegador; revision AWS comunicada por Joel; revision de frontend/src/config/aws.ts y backend/infra/lib/signmethod-backend-stack.mjs. | Equipo de infraestructura y desarrollo | Abierta: crear/corregir secreto reCAPTCHA como SecureString; limitar SES a identidad verificada y configurar eventos; restringir S3 por prefijo/tenant; aplicar condiciones tenant o controles equivalentes en DynamoDB; retirar o justificar Scan, DeleteItem, DeleteObject* y acciones Cognito admin sin uso; configurar Access Analyzer en eu-west-1, CloudTrail regional y valorar permissions boundary; repetir SEG-07 y flujos criticos tras el recorte. |
| INC-039 | UX-04 | ALTA | Los modales Acuerdos y Enviar acuerdo no atrapan el foco de teclado aunque declaran aria-modal="true". El tabulado alcanza controles de fondo y, tras scroll, puede enfocar elementos fuera del viewport visible. Las capturas manuales compartidas por Joel confirman puntos positivos de foco visible en dashboard y acceso visual a home, login y vista publica de acuerdo, pero no eliminan el defecto de foco modal ni demuestran el recorrido completo por teclado. | Durante la revision del 02/09/2026 | Joel López | Informe docs/evidencias/UX-04-UX-06-UX-07-ACCESIBILIDAD-TECLADO-CONTRASTE-2026-09-02.md; captura docs/evidencias/UX-04-06-07-envio-revision-accesibilidad-2026-09-02.png; capturas manuales compartidas en chat; recorrido Tab en Chrome visible. | Equipo de frontend | Abierta: implementar focus trap en modales, fondo inerte, foco inicial/restaurado, cierre por Escape controlado y repetir teclado puro en home, login, panel, envio y firma QA documentando el orden de foco completo. |
| INC-040 | UX-06 | ALTA | La semantica para lector de pantalla es incompleta: dialogos sin nombre accesible, campos obligatorios sin asociacion label for, aria-describedby, aria-invalid ni aria-required, errores no vinculados programaticamente a campos y controles repetidos como Editar sin contexto suficiente. Existen estados positivos con role=status/aria-live=polite, pero no bastan para cerrar el punto. | Durante la revision del 02/09/2026 | Pau Dengra | Informe docs/evidencias/UX-04-UX-06-UX-07-ACCESIBILIDAD-TECLADO-CONTRASTE-2026-09-02.md; inspeccion DOM/ARIA en Chrome visible. | Equipo de frontend y QA accesibilidad | Abierta: nombrar dialogos con aria-labelledby, etiquetar campos, asociar errores y ayudas, diferenciar controles repetidos, revisar menus iconicos y validar manualmente con NVDA/VoiceOver/TalkBack. |
| INC-041 | UX-07 | MEDIA | Se detectan problemas de contraste y objetivos tactiles: el aviso verde de envio correcto mide aproximadamente 1.58:1, inferior a WCAG AA, y numerosos controles quedan por debajo de 44x44 px, incluyendo navegacion superior, botones de cabecera, perfil, cierre de modal, actualizar, mas acciones y varios botones del flujo de envio. | Durante la revision del 02/09/2026 | Joel López y Pau Dengra | Informe docs/evidencias/UX-04-UX-06-UX-07-ACCESIBILIDAD-TECLADO-CONTRASTE-2026-09-02.md; captura docs/evidencias/UX-04-06-07-envio-revision-accesibilidad-2026-09-02.png; medicion DOM de contraste y areas activas en Chrome visible. | Equipo de diseño/frontend | Abierta: ajustar colores a WCAG AA, medir sobre fondos compuestos, ampliar areas activas a minimo 44x44 px y repetir la medicion en dashboard, modales, login, envio y firma QA en desktop y movil. |
| INC-042 | REN-01 / REN-02 | MEDIA | El rendimiento medido y el peso de recursos forman una única desviación. Lighthouse da 95 en panel, 93 en login y 88 en home; esta última puntuación queda por debajo del umbral esperado. La carga estática ronda 16,8–17,2 MB, principalmente por imágenes de 1,8–2,3 MB; también se detectan CSS bloqueante, LCP no descubrible inicialmente, imágenes sin dimensiones y JS/CSS no usados. La caché y compresión de assets versionados sí son correctas. | Durante la revisión del 02/09/2026 | Joel López | Informe y capturas de REN-01-REN-02-RENDIMIENTO-CACHE-RECURSOS-2026-09-02.md, reportes Lighthouse y recarga sin caché en DevTools. | Equipo de diseño/frontend y QA | Abierta: acordar presupuesto y umbrales; convertir imágenes a webp/avif, crear variantes responsive y aplicar lazy loading; fijar dimensiones y prioridad LCP; retirar recursos innecesarios del panel y reducir JS/CSS no usados; exportar reportes y repetir REN-01/REN-02 hasta cumplir o aceptar formalmente la desviación. |
| INC-043 | REN-04 | MEDIA | La gestión visual de errores no es consistente ni está completamente probada. Un token inexistente devuelve 404, pero la UI muestra mensajes distintos —incluido Agreement not found— y no ofrece una acción clara de reintento; faltan pruebas de 500, timeout y fallo de red. La idempotencia durante cortes o reintentos se gestiona en INC-035. | Durante la revisión del 02/09/2026 | Joel López | Informe docs/evidencias/REN-04-REN-05-RESILIENCIA-LATENCIA-2026-09-02.md, dos capturas de producción y prueba local Playwright con mock 404. | Equipo de frontend/backend | Abierta: unificar los mensajes funcionales en castellano; añadir estados y acción de reintento para 404, 500, timeout y route.abort(); bloquear acciones mientras cargan; validar los cuatro escenarios en local/QA y repetir REN-04. |
| INC-044 | REN-05 | MEDIA | API Gateway, Lambda y DynamoDB cumplen los umbrales de latencia, errores, memoria y saturación revisados. La única desviación cuantitativa es la tasa de cold starts: 24/128 (18,75 %), superior al objetivo <=10 %; su duración sí cumple, con p95/máximo de 624,76/724,70 ms. Las carencias generales de trazabilidad, CORS y telemetría se controlan en INC-032, INC-036 e INC-045. | Revisión del 02/09/2026 y ventana ampliada hasta el 03/09/2026 | Joel López | Informe docs/evidencias/REN-04-REN-05-RESILIENCIA-LATENCIA-2026-09-02.md, captura del panel de timings y resultados de API Gateway, Lambda, CloudWatch, X-Ray y DynamoDB. | Equipo de infraestructura/backend | Abierta: reducir la tasa de cold starts a <=10 % o aceptar formalmente la desviación; repetir la medición en una ventana representativa con los mismos umbrales; documentar la decisión y pasar REN-05 a OK solo al cumplirla. |
| INC-045 | REN-06 | MEDIA | El tráfico normal tiene margen amplio en Cognito, API Gateway, Lambda, DynamoDB y SES, pero CloudTrail registró 701 TooManyRequestsException de API Gateway y una ThrottlingException de DynamoDB CreateTable durante el despliegue del 27/08. Además, S3 carece de telemetría suficiente para acreditar solicitudes, latencia, errores y ausencia de throttling en una ventana representativa. La trazabilidad por petición se gestiona en INC-032. | Durante la revisión AWS comunicada el 03/09/2026 | Joel López | Informe docs/evidencias/REN-06-CUOTAS-THROTTLING-AWS-2026-09-03.md y resultados de Service Quotas, CloudWatch, CloudTrail y X-Ray; faltan exportaciones o capturas censuradas. | Equipo de infraestructura/DevOps | Abierta: aplicar backoff exponencial con jitter, reducir paralelismo y esperar cada tabla ACTIVE; crear alarmas de throttling; repetir despliegues hasta obtener una ventana limpia; habilitar S3 Request Metrics y eventos de datos o access logging, con alarmas de errores y latencia; observar una ventana representativa y repetir REN-06 con evidencia censurada. |
| INC-046 | MON-15 / PRE-02 | ALTA | El control +15 acredita el funcionamiento de Home, login, autorización, listado, firma y API/Lambda, pero no puede aprobar la monitorización completa. Cognito no tuvo puntos de autenticación ni alarmas; DynamoDB no tuvo tráfico que generase métricas de latencia, errores o throttling y tampoco tiene alarmas; los tres buckets S3 carecen de Request Metrics; SES no tiene configuration sets, event destinations ni alarmas; y no existen alarmas generales para Lambda, Cognito, DynamoDB, S3 o SES. | Consulta retrospectiva del 03/09/2026 a las 10:22 UTC sobre la ventana 08:28-08:54 UTC | Pau Dengra | Informe docs/evidencias/MON-15-CONTROL-PRIMERAS-DOS-HORAS-2026-09-03.md; métricas comunicadas de CloudFront y Lambda. El archivo original evidence/control15-aws-metrics-2026-09-03.json está pendiente de incorporarse a este workspace. | Equipo de infraestructura/DevOps y QA | Abierta. Para cerrarla: definir umbrales y responsables; crear un tema SNS y confirmar sus suscriptores; configurar alarmas de Lambda para Errors, Throttles, Duration y ConcurrentExecutions; generar en cada ventana autenticaciones sintéticas controladas de Cognito, incluidos éxito, fallo y MFA, y alarmar fallos y throttling mediante métricas nativas o filtros de métricas; generar lecturas y escrituras QA seguras en las tablas DynamoDB utilizadas y crear alarmas para SystemErrors, UserErrors, ReadThrottleEvents, WriteThrottleEvents y latencia; habilitar S3 Request Metrics en los tres buckets y alarmas para errores 4xx/5xx y latencia, complementadas con access logging o CloudTrail Data Events; crear un configuration set de SES con event destination para envíos, entregas, rebotes, quejas y rechazos, y sus alarmas; incorporar la exportación JSON original; ejecutar una notificación de prueba; repetir las dos horas completas con controles independientes cada 15 minutos. Solo pasar a OK cuando cada servicio tenga tráfico representativo, métricas de la ventana, alarmas activas y evidencia de recepción de la alerta sin superar los umbrales acordados. |
Propuesta de solución para INC-004
- Centrar el logotipo en la plantilla HTML mediante una celda de tabla de ancho completo con
align="center"y estilos inline compatibles con clientes de correo. - Aplicar a la imagen
display: block; margin: 0 auto;y definir explícitamente su ancho y texto alternativo. - Evitar que el logotipo dependa únicamente de
flex, clases CSS externas o propiedades que algunos clientes de correo ignoran. - Enviar correos de prueba y verificar el centrado en los clientes soportados, como Gmail, Outlook y las vistas móvil y escritorio, antes de cambiar
ADM-03aOK.
20. Limpieza
| ID | Responsable | Acción | Resultado esperado | Estado | Evidencia/observaciones |
|---|---|---|---|---|---|
| LIM-01 | Joel López | Cancelar acuerdos QA pendientes. | No quedan enlaces activos innecesarios. | OK | Ejecutado el 03/09/2026. Se cancelaron los tres acuerdos QA pendientes de pepe (Prueba Pau 12, Prueba Pau y prueba) y las filas muestran Cancelado. El filtro Pendientes no devuelve acuerdos ni en pepe ni en Prueba Produccion; los contadores 3 y 1 no se recalculan y quedan documentados como inconsistencia visual. Los cuatro borradores QA de Prueba Produccion no tienen token y no generan enlaces activos. Véase el acta de limpieza, la evidencia anterior y la posterior. |
| LIM-02 | Joel López | Retirar accesos e invitaciones temporales. | No quedan permisos QA no autorizados. | OK | Ejecutado el 03/09/2026. Se retiraron de pepe las dos pertenencias con estado Invitado y rol firmante; la empresa pasó de cuatro a dos miembros y de dos a cero firmantes. Cognito permaneció intacto. Los accesos administrativos activos se conservan y, por decisión del responsable, las validaciones adicionales de Pau quedan fuera del alcance. Evidencias censuradas: antes y después. |
| LIM-03 | Joel López y Pau Dengra | Eliminar o anonimizar los datos QA acordados. | Solo se conserva la evidencia aprobada. | OK | Ejecutado el 03/09/2026 en pepe: dos plantillas QA se movieron a Eliminado y se eliminaron dos carpetas QA vacías. Se conservaron los acuerdos firmados/cancelados por trazabilidad. Por decisión del responsable, los cuatro borradores sin token de Prueba Produccion se conservan como evidencia inerte aprobada y no requieren eliminación o anonimización adicional. Véase la biblioteca posterior y el acta. |
| LIM-04 | Joel López | Confirmar que se conserva la auditoría obligatoria. | No se han eliminado evidencias legales necesarias. | OK | Validado el 03/09/2026 mediante lectura de signmethod-prod-audit en eu-west-1. Entre las 11:10:23 y las 11:13:32 UTC se identificaron exactamente nueve eventos del lote de limpieza: tres signature_request.canceled, dos user.membership.deleted, dos template.deleted y dos template-folder.deleted. Los nueve contienen type, createdAt y tenantId; ninguno contiene expiresAt, por lo que el TTL ENABLED sobre ese atributo no los eliminará automáticamente. Véanse la validación DynamoDB censurada, la auditoría visible en la aplicación y el acta. |
| LIM-05 | Joel López y Pau Dengra | Cerrar sesiones y guardar el acta. | No quedan sesiones abiertas. | OK | La sesión de Joel utilizada para la limpieza se cerró correctamente el 03/09/2026 y se guardó el acta con hashes SHA-256. Por decisión del responsable, las sesiones y validaciones adicionales de Pau quedan fuera del alcance. Evidencias: sesión de Joel cerrada y acta de limpieza. |
21. Criterios GO/NO-GO
La producción se aprueba únicamente si:
- NO CUMPLE — No hay incidencias críticas o altas abiertas. Permanecen abiertas 3 incidencias críticas (
INC-001,INC-030eINC-031) y 19 altas; cualquiera de ellas impide elGOsin resolución o aceptación formal aplicable. - NO CUMPLE — Web, DNS, TLS y rutas públicas funcionan. HTTP/HTTPS, TLS y las rutas SPA básicas están acreditadas por
PUB-02,PUB-03yPUB-05, peroPUB-01,PUB-04yPUB-08siguen enKOpor el dominiowwwno canónico, navegación pública incompleta y páginas legales que renderizan la portada. - NO CUMPLE — Registro, email, login, recuperación y cierre de sesión funcionan. El registro y el login básico tienen evidencia positiva, pero la recuperación no está disponible (
ID-08/INC-012), el MFA administrativo no es utilizable desde la interfaz (ID-07/INC-015) y la caducidad/recuperación de sesión no está validada (ID-10/INC-016). - NO CUMPLE — Roles y aislamiento entre empresas están validados en interfaz y backend. Existen fallos críticos de autorización y aislamiento en
ROL-04,FIR-22ySEG-08, registrados enINC-001,INC-030eINC-031. - NO CUMPLE — Se completa el flujo real de crear, enviar, recibir, firmar y descargar. El control
+15acredita creación, envío, recepción y firma, pero no existe una descarga utilizable del PDF firmado (FIR-12/INC-024). - NO CUMPLE — Cognito, API/Lambda, persistencia, S3 y SES se comprueban con el flujo real. API/Lambda quedó
OK, pero Cognito y DynamoDB están enKOde observabilidad y S3/SES permanecePARCIAL; véanseMON-15,PRE-02eINC-046. - NO CUMPLE — El PDF firmado y sus evidencias son correctos. La firma y finalización están acreditadas en
FIR-10, peroFIR-12yFIR-13siguen enKO: no se pudo descargar el artefacto firmado ni verificar su contenido, hash y tamaño. - PARCIAL — No hay referencias a preproducción ni exposición de secretos.
PUB-09no encontró referencias de preproducción y las revisiones disponibles no detectaron secretos visibles, peroTEC-07no puede certificar los logs completos ySEG-07mantiene permisos excesivos y carencias de trazabilidad (INC-032eINC-038). - NO CUMPLE — Los navegadores y dispositivos acordados superan los flujos críticos.
AUT-01,AUT-02,UX-01yUX-03siguen enKO; además permanecen fallos de teclado, lector de pantalla y objetivos táctiles enUX-04,UX-06yUX-07. - NO CUMPLE — Backups, métricas, alarmas y rollback están disponibles.
PRE-02continúa enKOyINC-046confirma que faltan alarmas, métricas de S3/SES/Cognito, tráfico representativo de DynamoDB y una prueba de notificación. - PARCIAL — Las incidencias menores restantes están documentadas y aceptadas. El registro de incidencias está actualizado, pero no consta aceptación formal de las desviaciones abiertas y todavía existen incidencias críticas y altas, no solo menores.
- CUMPLE — Ambos compañeros aprueban la decisión. Joel López y Pau Dengra confirman el
NO-GOprovisional el 03/09/2026 a las 13:30 CEST. Esta confirmación aprueba la decisión de no autorizar producción en el estado evaluado; deberá renovarse después de corregir las incidencias para emitir unGOdefinitivo.
Resultado actual: NO-GO. Evaluación actualizada el 04/09/2026 después de completar PRE-06 y los cinco controles de limpieza (LIM-01 a LIM-05). El recuento total queda en 50 pruebas OK, 66 pruebas KO y 4 pruebas PENDIENTE. Los bloqueos determinantes siguen siendo las 3 incidencias críticas, las 19 incidencias altas, la imposibilidad de descargar y auditar el PDF firmado, las brechas de autorización/aislamiento y la falta de observabilidad y recuperación completas. La limpieza completada reduce el riesgo residual de los datos QA, pero no corrige esos bloqueos. No se necesita una nueva comprobación con Playwright para emitir este resultado: los defectos y ausencias de evidencia ya registrados son suficientes y deben corregirse antes de repetir los controles afectados.
Una incidencia crítica implica NO-GO y valoración inmediata de rollback. Una incidencia alta también implica NO-GO, salvo aceptación formal técnica y de negocio con una alternativa segura documentada.
22. Acta final
| Dato | Valor |
|---|---|
| Resultado | NO-GO provisional, de acuerdo con la evaluación del punto 21. |
| Pruebas OK | 50 de 120 pruebas con estado único, incluidos PRE-06 y los cinco controles de limpieza. |
| Pruebas KO | 66 de 120 pruebas con estado único. Además, los 9 controles de monitorización (+00 a +120) contienen al menos un KO o PARCIAL. |
| Pruebas bloqueadas | 0 BLOQUEADA. Permanecen 4 PENDIENTE: ID-06, ROL-06, SEG-03 y SEG-06. |
| Incidencias críticas/altas abiertas | 22: 3 críticas (INC-001, INC-030 e INC-031) y 19 altas. |
| Limitaciones aceptadas | Ninguna aceptación formal registrada. Las desviaciones están documentadas, pero no aprobadas por las partes responsables. |
| ¿Se requiere rollback? | Valoración inmediata obligatoria. No debe ejecutarse automáticamente sin confirmar que la versión anterior elimina las vulnerabilidades. Hasta decidir entre rollback y corrección urgente, deben aplicarse medidas de contención para INC-001, INC-030 e INC-031. |
| Próxima revisión | Pendiente de programar. Revisión inmediata de las incidencias críticas y nueva evaluación completa tras resolver o mitigar las críticas y altas, repetir las pruebas afectadas y actualizar el punto 21. |
| Persona | Rol | Decisión | Fecha y hora | Firma o confirmación |
|---|---|---|---|---|
| Joel López | Administración/emisión | NO-GO provisional | 03/09/2026, 13:30 CEST | Aprobado por Joel López |
| Pau Dengra | Firma/verificación | NO-GO provisional | 03/09/2026, 13:30 CEST | Aprobado por Pau Dengra |
Esta acta es provisional y refleja el estado documentado a 04/09/2026, incluida la finalización de PRE-06 y de LIM-01 a LIM-05. Joel López y Pau Dengra han confirmado expresamente el NO-GO provisional; esta confirmación no autoriza producción y deberá renovarse tras resolver los bloqueos para adoptar una decisión final. Los recuentos de OK, KO y PENDIENTE incluyen las 120 pruebas con una única columna Estado, incluidos los controles de limpieza del punto 20; los 9 controles temporales del punto 18 se informan por separado porque cada fila contiene resultados independientes por componente.
23. Evidencias que deben guardarse
- Versión, commit y artefacto desplegado.
- Reporte Playwright, trazas y capturas relevantes.
- Resultados de DNS, TLS y cabeceras.
- Identificadores QA de usuarios, empresas, plantillas y acuerdos.
- Hashes del PDF original y firmado.
- Registro de correos enviados, entregados y rebotados.
- Métricas y alarmas de las dos primeras horas.
- Incidencias, decisiones y rollback, si lo hubiera.
- Acta final aprobada por ambos compañeros.
24. Documentación relacionada
docs/RUNBOOK_PREPRODUCCION_A_PRODUCCION.mddocs/PLAYWRIGHT_QA.mddocs/MANUAL_USUARIO_SIGNMETHOD.md