Servicios públicos de consulta (Verifica y Seguimiento)

Patrón común de los servicios públicos del ecosistema que una persona usa sin sesión para consultar algo con un código: Verifica (documentos recibidos por PIDE, con el CVD) y Seguimiento de documentos (recorrido de un trámite de Mesa de Partes, con el número de emisión o la constancia). La Mesa de Partes Virtual y la portada del SGD comparten la cabecera. Los dos servicios usan la misma identidad, estructura y calidad de experiencia; solo cambian los textos, los datos pedidos y los resultados.

Implementaciones de referencia: verify/app/src/components/verifica/ y follow-up/app/src/components/seguimiento/.

Muestras con todos los estados (mockups)

Páginas estáticas (sin JavaScript, se abren en cualquier navegador) con cada estado en escritorio y móvil, claro y oscuro, según la implementación final:

Verifica (30/10/2026): los mockups de Verifica (verifica-estados.html, cvd-hoja.html y verifica-propuesta.html en verify/docs/mockups/) usan datos de ejemplo alineados con la Directiva N.º 002-2021-PCM/SGTD (§9): son el objetivo de diseño, no la implementación actual, que sigue con el CVD de 8 caracteres. Cada mockup lleva su bloque «Sustento normativo».

Copias en verify/docs/mockups/verifica-estados.html y follow-up/docs/mockups/seguimiento-propuesta.html. Son referencia visual: las medidas y reglas válidas son las de este documento. La hoja de ejemplo de la ayuda lleva espacios de un oficio real (membrete con su línea, lema, asunto en dos columnas, párrafos separados, firma y pie), nunca texto o líneas pegadas.

Seguimiento (30/10/2026): cada estado con su disparador, mensaje exacto, acciones, validaciones, recuperación y respuesta esperada del servicio está en seguimiento-estados.md («Seguimiento · todos los estados»). Distingue los estados de la consulta (técnicos) de los estados del trámite (administrativos, del catálogo del SGD).

Ancho del contenido (regla común)

Campos: fondo blanco (--sgd-field-background; oscuro en modo oscuro, nunca el fondo de página) y, al hacer clic o enfocar, el mismo efecto de todos los campos del ecosistema (sgd-field-focus: borde y halo del color primario; en error, del color de error). Sin contorno propio del navegador.

Barra de desplazamiento: todas las portadas usan la barra del Design System (6 px, sin flechas) y reservan su espacio con html { scrollbar-gutter: stable } (en el SGD solo en la portada, marcada con data-sgd-landing). Así el contenido centrado queda en la misma posición, y el logo de la cabecera no se corre unos píxeles, entre páginas con y sin desplazamiento y entre aplicaciones. Alto de la cabecera: 80 px en todos los anchos, sin partirse en dos filas.

No usar el contenedor container de Tailwind en portadas: llega a 1536 px y separa el logo de los botones en pantallas anchas. El valor se eligió para pantallas de 1440 px o más (en pantallas menores el contenido ocupa todo el ancho menos los márgenes). Aplica a la portada del SGD, la Mesa de Partes Virtual (sin sesión), Verifica y Seguimiento; el contenido de cada pantalla queda alineado con su cabecera.

1. Cabecera y pie

• Alto de 80 px, logo circular de 44 px, contenido de hasta 1440 px centrado con margen lateral de 16 px (móvil), 24 px (sm) y 32 px (lg). El pie usa el mismo ancho y va alineado a la izquierda.
• Nombre en dos líneas: arriba la sigla de la institución (12 px, semibold, gris) y debajo el nombre del servicio (14 px; 16 px desde lg; negrita; color primario). Nunca por debajo de 12 px.
• Cambio de tema con un solo icono (luna en modo claro, sol en modo oscuro), círculo de 36 px con icono de 20 px, aria-label y title «Cambiar a modo oscuro» / «Cambiar a modo claro». Ver «Cabecera de las aplicaciones y cambio de tema» en design-system-sgd.md.

2. Estado inicial: texto, tarjeta y «Cómo consultar»

• Sección principal a dos columnas desde 1024 px (minmax(0,1fr) + tarjeta de 500 px, 540 px desde xl), separación de 64 px y centrada verticalmente; una sola columna debajo. La sección ocupa el alto disponible para que la página no quede «colgada» arriba.
• Columna de texto: insignia con el origen («Documentos recibidos por PIDE» / «Documentos presentados en Mesa de Partes»), título h1 (30 px móvil, 36 px, 48 px desde lg), descripción de 16–18 px y, si hay un alcance que aclarar, una aclaración visible y discreta (icono de información y texto de 13 px, sin color de alerta). Una ilustración decorativa propia del servicio solo en pantallas anchas.
• Tarjeta del formulario: radio de 8 px, borde, sombra suave, relleno de 24 px (32 px desde sm); título de 20–24 px; campos de 52 px de alto con etiqueta visible encima (nunca solo placeholder) y borde de 6 px; ayuda del campo de 12 px; verificación de seguridad (Cloudflare Turnstile, size: flexible); botón principal de 48 px a todo el ancho; texto de estado de 12 px (aria-live="polite") que explica por qué el botón está apagado.
• Ayuda como enlace bajo el botón, separado por una línea: icono + texto («¿Dónde encuentro el CVD?», «¿Dónde encuentro el número?»). El subrayado al pasar el mouse es solo del texto, nunca del icono. Ver sección 3.
• «Cómo consultar»: banda blanca de ancho completo con tres pasos separados por divisores (iconos numerados de 40 px, título de 16 px y texto de 14 px). Solo en el estado inicial.
• El botón principal lleva un icono de 20 px y, en proceso, el icono giratorio y «Consultando…» (sin movimiento con «reducir movimiento»).
• Verificación de seguridad (Cloudflare Turnstile): el contenedor del widget lleva las esquinas de 6 px de los demás controles (overflow-hidden rounded-[6px]; el widget es un iframe de esquinas rectas que no se puede estilar por dentro). El aviso «Solo para pruebas» solo aparece con la clave de prueba de Cloudflare y desaparece con la clave real del ambiente.

3. Ayuda con documento de ejemplo

Un enlace abre una ventana con un documento de ejemplo donde las zonas útiles (CVD y QR, o número de emisión y constancia) están marcadas con borde punteado y etiqueta. Debe explicar en texto lo mismo que muestra el dibujo (el dibujo es aria-hidden) y avisar «Ejemplo ilustrativo: los datos no corresponden a un documento real».

• Escritorio: <dialog> nativo con el estilo de los diálogos del SGD: radio 14 px, sombra 0 18px 48px rgb(20 24 40 / 0.16), velo rgb(20 24 32 / 0.66), margen interior de 32 px, sin divisores en cabecera ni pie, título de 18 px, botón de cierre redondo de 44 px a 14 px de los bordes y botón «Cerrar» con borde de la marca. Ancho de hasta 840–880 px. La hoja se amplía hasta 1,3–1,45 veces según el alto de la pantalla y los pasos se centran a su lado. El foco entra al título, Escape cierra y el foco vuelve al enlace.
• Celular: hoja inferior (BottomSheet), con la misma hoja reducida, tirador, cierre de 44 px y arrastre hacia abajo.
• El botón de cierre es el DialogCloseButton del SGD (copiado en cada repo con las reglas .sgd-dialog-close): círculo gris al pasar el mouse y anillo de la marca al enfocar. No usar cuadros ni fondos propios.

4. Estados (cada uno se diseña por separado)

Las alertas llevan icono, título en negrita, texto y una acción; role="alert"; nunca solo color. «Corregir el número» lleva el foco al campo.

5. Resultado del seguimiento

• Resumen en tarjeta: título «Documento N», estado con el texto y color del catálogo, aviso cuando se buscó por una constancia («es de una subsanación de este documento: se mantiene el número de emisión»), asunto y cuatro datos (recibido, oficina de recepción, estado del trámite, se encuentra en).
• Pestañas accesibles (role="tablist", flechas, Inicio y Fin): Recorrido (vista principal), Relaciones entre documentos (el árbol de dos paneles del SGD) y Tabla (complemento, solo desde 768 px). En celular no hay tabla ancha con scroll horizontal: todo va en tarjetas y línea de tiempo.
• Recorrido = línea de tiempo vertical con puntos de color sobre anillo (el color siempre con texto): «En Mesa de Partes» (recibido, cada ronda de observado y subsanado con su constancia, registrado) y «En el ministerio» (cadena de documentos con «Usted está aquí», «Último movimiento», «Vencido»). Un documento con varias derivaciones muestra «Se derivó a N destinos (atienden en paralelo)» y una tarjeta por destino con estado, fecha, motivo y prioridad; con más de 5 se muestran los primeros y «Mostrar los N restantes». No se simplifica ni se aplana la ramificación.
• Al aparecer el resultado se lleva a la vista y el foco al título.
• Privacidad: nombres de personas ya ofuscados por el servidor («J*** P*** R***»), destinos externos solo por tipo, documentos reservados con tipo, número, fecha y oficina, sin notas, remitente, IP, DNI ni correos y sin enlaces a documentos ni anexos (eso es Verifica). Estas restricciones se conservan tal como las define el backend.

6. Accesibilidad

Etiquetas persistentes, foco visible en todo control, objetivos de 44 px en enlaces y botones, contraste AA en claro y oscuro, aria-live para el estado de la consulta, aria-invalid y descripción enlazada en el campo con error, movimiento reducido respetado, pestañas por teclado y diálogo con foco atrapado. Pendiente de pruebas con lector de pantalla real.

7. Verificación

Revisado en navegador a 1280, 820 y 375 px, en claro y oscuro, con datos de prueba (sin Oracle): inicio, ayuda, no encontrado, resultado por constancia de subsanación con ramificación, documento reservado y destino externo; sin desbordes horizontales. No probado: lector de pantalla real, teléfono físico ni datos reales de producción.

9. Verifica: sustento normativo del CVD (Directiva N.º 002-2021-PCM/SGTD)

Referencia central y matriz: docs/normativa/NORMATIVA-FORMULARIOS-Y-SERVICIOS-DIGITALES.md, §5. Qué cambia en los mockups y por qué (N = obligación de la Directiva; UX = decisión de diseño):

Hoja de ejemplo realista (30/10/2026): verifica-propuesta.html dibuja el oficio o la carta con los espacios de un documento real, no apretados: membrete con línea, lema, fecha a la derecha, título subrayado, destinatario, asunto y referencia en dos columnas, párrafos justificados, «Atentamente», sello de firma digital centrado, nombre y cargo del firmante y, al pie, la glosa en Courier con su QR. Proporción A4; todos los datos son ficticios.

Documento principal de Verifica: el CVD va solo en los oficios y cartas (documentos principales de PIDE); los anexos no viajan por PIDE y se consultan en Verifica con ese CVD (decisión funcional indicada el 30/10/2026). Los mockups de resultados muestran un oficio o una carta, nunca una hoja de envío.

Pendientes de validación (no se tocó código): la precarga del CVD al escanear el QR (el art. 8.4 dice que el QR codifica la URL y el art. 11.2 b que el CVD se digita) y la compatibilidad del uso anterior con el art. 13.2 a, que excluye la representación imprimible en PIDE, son decisiones funcionales del proyecto. La URL final del servicio es de ejemplo. La implementación sigue con el CVD de 8 caracteres.

Frontend de Verifica (30/10/2026): sigue con el CVD de 8 caracteres y deja preparado, configurable y apagado, el de 16 dígitos (NEXT_PUBLIC_CVD_FORMAT), los mensajes de la Directiva (NEXT_PUBLIC_VERIFICA_MESSAGES), el estado «documento no disponible» (respuesta 410), el tipo del documento (documentType) en el título del resultado, el aviso de precarga desde el QR y la ayuda con hoja de oficio o carta. Datos de prueba: NEXT_PUBLIC_VERIFICA_MOCK. Detalle, estados y contrato: components/casilla-estados-y-privacidad.md, §6, y docs/normativa/consultas/CONTRATO-API-FRONTEND-CASILLA-VERIFICA.md.

Lista de archivos del envío (propuesta, sin implementar)

verify/docs/mockups/verifica-propuesta.html (botones «Con anexos», «Sin anexos» y «Tipo»: Oficio o Carta) aligera el panel «Archivos del envío», que hoy repite en cada archivo una pastilla de estado, un aviso, «Ver» y un botón «Descargar» relleno. UX, pendiente de aprobación:

• Una fila por archivo, en una sola lista con divisores finos: icono, nombre y, debajo, formato en gris. La fila es lo que se pulsa para verlo en pantalla.
• Una sola acción visible: el icono de descarga a la derecha (círculo de 40 px; 44 px en celular), con tooltip y aria-label «Descargar ». Sin botones rellenos por fila.
• Estado dentro de la línea del formato, no en pastillas: «PDF · Viendo» para el archivo abierto (además de fondo y barra lateral, aria-current) y «Excel · Solo descarga» para los formatos sin vista previa; sin el párrafo «Este formato no se puede mostrar…» por fila.
• «Recibido por PIDE» como texto de apoyo; «Descargar todos los anexos» como enlace; la nota de los anexos, en una línea de texto sin recuadro.
• El documento principal se nombra por su tipo y número (por ejemplo, «Oficio N.º 000123-2026-JUS/OGTI»); mostrar el tipo requiere que la API lo entregue: pendiente.

8. Casilla electrónica (portal con cuenta)

La casilla no es un servicio de consulta pública: requiere cuenta y forma parte del portal de Mesa de Partes Virtual junto con Acceso a la información pública (misma sesión y mismos datos de la persona). Verifica y Seguimiento siguen siendo públicos y sin cuenta. La casilla sigue el mismo patrón visual de las portadas:

• Acceso sin sesión: cabecera de 80 px y contenido de 1440 px; texto a la izquierda (insignia «Casilla electrónica», título, descripción, «Quién puede usarla» y «Sus datos ya están cargados») y tarjeta «Ingrese a su casilla» a la derecha; banda «Con una sola cuenta» con tres beneficios; sin lista de pasos dentro de la tarjeta.
• Bandeja: barra lateral con grupos «Casilla» (Recibidas, Destacadas, Archivadas) y «Mesa de Partes Virtual»; pestañas Todas, Sin leer y Leídas; «Sin leer ·» como texto además del punto de color; insignia soft-primary para Notificación y soft-neutral para Comunicación; «Depositada:» en el detalle.
• Trato de «usted» en todo el portal ciudadano (Ingrese, Revise, Su casilla), como en Seguimiento y Verifica.
• Tipo de mensaje: es notificación el mensaje que trae los datos legales del acto (Ley 31736, art. 6); el resto es comunicación.
• No se muestran funciones inexistentes: aviso al celular, acuse de recibo ni exportación.
• Términos y condiciones: página pública de lectura (ancho de lectura de 48 rem dentro del contenedor de 1440 px, índice con enlaces, secciones numeradas con su base normativa al pie en texto de 12 px). Se enlaza desde el acceso y desde el recuadro de aceptación del registro.

Comportamiento pantalla por pantalla en docs/manual-usuario/casilla-electronica.md.