Casilla (acuse y avisos), privacidad y formularios ciudadanos
Patrones del portal ciudadano (gov-desk) y de Verifica (verify) preparados para el backend. Implementaciones de referencia:
gov-desk/app/src/features/{casilla,privacidad,forms,acceso-info} y verify/app/src/features/verifica. Contrato de API que esperan:
docs/normativa/consultas/CONTRATO-API-FRONTEND-CASILLA-VERIFICA.md (raíz del repositorio sgd). Normas y matriz:
docs/normativa/NORMATIVA-FORMULARIOS-Y-SERVICIOS-DIGITALES.md.
Estado (30/10/2026): interfaz lista para integrar; el backend no la proporciona todavía. Nada de lo nuevo está activo en producción.
1. Principios
- Mostrar solo lo que el servicio acredita. Un aviso «enviado» o una recepción «confirmada» solo se muestran si el servicio entregó el estado con fecha. Si el dato falta, se dice «El servicio aún no informa este dato».
- Apagado por defecto y configurable. Cada capacidad o decisión pendiente se enciende con una variable (sección 2); el valor por defecto es el comportamiento vigente.
- Datos de prueba separados. Viven en archivos
*.mock.tsy se usan solo con un interruptor; la integración real no los importa. Las pantallas lo dicen («Datos de prueba»). - Sin efectos jurídicos. Los textos no expresan validez, plazos ni consecuencias de confirmar o no confirmar el acuse: la ley no lo define (Ley 31736, arts. 5.6 y 5.7) y lo decide OGAJ.
- Tres cosas distintas: recepción del documento (lo que el sistema registró), confirmación de la persona (acuse) y estado de los avisos. La lectura y la apertura no son el acuse.
2. Interruptores y datos de prueba
| Variable | Repo | Valor por defecto | Qué hace |
|---|---|---|---|
NEXT_PUBLIC_CASILLA_MOCK | gov-desk | apagada | Casilla con datos de prueba y sin sesión real; enciende acuse y avisos; insignia «Datos de prueba». |
NEXT_PUBLIC_CASILLA_ACK | gov-desk | apagada | Muestra la confirmación de recepción (acuse). Encender solo cuando el servicio la entregue (contrato §1). |
NEXT_PUBLIC_CASILLA_ALERTS | gov-desk | apagada | Muestra el estado de los avisos por correo y celular. |
NEXT_PUBLIC_FORM_POLICY | gov-desk | actual | propuesta activa las opciones de las consultas Q-1 a Q-5 para revisarlas (sección 5). |
NEXT_PUBLIC_PRIVACY_POLICY | gov-desk | apagada | Publica /mesa-de-partes/privacidad; solo con la política aprobada. |
NEXT_PUBLIC_PRIVACY_PREVIEW | gov-desk | apagada | Muestra la política con los elementos en borrador marcados; para revisión. |
NEXT_PUBLIC_VERIFICA_MOCK | verify | apagada | Verifica sin servicio ni captcha; códigos TEST0001 a TEST0005 y dos CVD de 16 dígitos. |
NEXT_PUBLIC_CVD_FORMAT | verify | legacy | directive: el campo acepta el CVD de 16 dígitos y valida el dígito de chequeo. |
NEXT_PUBLIC_VERIFICA_MESSAGES | verify | actual | directiva: los tres mensajes del art. 11.2 d de la Directiva. |
Arranque local de revisión: casilla-mock (3002), casilla-mock-propuesta (3003), verifica-mock (3021) y verifica-mock-directiva (3022).
Datos de prueba de la casilla (features/casilla/mock/fixtures.mock.ts): ocho mensajes cuyo asunto empieza con «Prueba ·»: acuse pendiente con avisos enviados; recepción confirmada con sello de tiempo; aviso al celular con falla (la primera confirmación falla, para ver el error); correo en cola y sin celular registrado; acuse y celular no habilitados; el servicio no informa; «confirmada» sin fecha (no se muestra como confirmada); y una comunicación sin acuse.
3. Estado de la notificación (casilla)
Componente NotificationStatus (casilla/components/notification-status.tsx), en el detalle de una notificación (las comunicaciones no llevan acuse: Ley 31736, art. 5.5). Textos en casilla/status-texts.ts, cada uno marcado como obligación expresa o pendiente de aprobación.
| Bloque | Estado | Qué se ve | Sustento |
|---|---|---|---|
| Recepción del documento | Siempre | Depositada, leída o sin leer, documento abierto o aún no abierto (si el servicio lo informa) | Datos del propio sistema; nota: la lectura y la apertura no equivalen a la confirmación |
| Acuse | El servicio no informa | «El servicio aún no informa este dato» | — |
pending | «Pendiente de confirmar», fecha referencial informativa y «Confirmar recepción»; texto: cinco primeros días hábiles | OE Ley 31736, art. 5.6 | |
| Confirmando | Panel con «Al confirmar se registra la fecha y la hora de su confirmación», «Confirmar» y «Cancelar»; botón con aria-busy | Texto pendiente de aprobación (Q-6) | |
| Error | Alerta «No se pudo registrar la confirmación…» y reintento | — | |
confirmed con confirmedAt | «Recepción confirmada el…» (y «con sello de tiempo electrónico» solo si timeSealed) | OE art. 3 j (acuse) | |
confirmed sin fecha | «El servicio no informó la fecha…»: no se muestra como confirmada | — | |
unavailable | «La confirmación de recepción no está habilitada…» | — | |
| Avisos | Por canal: sent con fecha / pending / failed / not_registered / unavailable / sin dato | «Enviado el…», «En cola: aún no se envía», «No se pudo enviar», «No hay un celular registrado», «Este aviso no está habilitado» | OE arts. 4.3, 4.4 y 5.4; validez sin aviso al celular: IP (Q-7) |
Accesibilidad (WCAG 2.2 AA): sección con aria-labelledby; cada estado es texto con icono, nunca solo color; el resultado va en una región role="status" y recibe el foco al confirmar; al cancelar el foco vuelve al botón; los errores usan role="alert"; botones de 32 px de alto mínimo (size="sm"). No probado: lector de pantalla real, modo oscuro ni ancho de 320 px.
Carga, vacío y error de la lista y el detalle: los existentes de la casilla (esqueleto, «Aún no tiene comunicaciones…», «No se pudo cargar la comunicación» con reintento).
4. Aviso de privacidad y consentimiento
PrivacyNotice(privacidad/components/privacy-notice.tsx): aviso corto con el texto vigente y, solo si la política está publicada, el enlace «Leer la política de privacidad». Se muestra en los formularios que recogen datos conFORM_POLICY.privacyNoticeInForms(propuesta Q-1); hoy sigue apareciendo solo en «Mi cuenta».ConsentOption(privacidad/components/consent-option.tsx): casilla de aceptación no premarcada, con el texto completo junto a ella, aclaración «sin este consentimiento…», estado deshabilitado mientras se guarda y marca de revisión (pending) para lo no aprobado. Reemplaza el bloque repetido de «Mi cuenta» (notificación por correo y datos); no crear otra variante./mesa-de-partes/privacidad: política con los diez elementos del art. 6.1 del reglamento. 404 mientras no esté aprobada; en revisión, los elementos «borrador» y «por completar» salen marcados y nunca como vigentes. Contenido y estado de cada elemento:privacidad/privacy-config.ts.- Normas: Ley 29733, art. 18, y DS 016-2024-JUS, arts. 6.1 y 7 (OE informar antes de recoger los datos); art. 20.4 del TUO 27444 (OE autorización expresa para notificar por correo); consentimiento de datos como condición: IP (Ley 29733, art. 14.1; DS 016-2024-JUS, art. 3.2).
5. Política de formularios (decisiones pendientes)
gov-desk/app/src/features/forms/form-policy.ts reúne, configurables, las decisiones que esperan validación. El valor «actual» es el comportamiento vigente.
| Decisión | Consulta | Actual | Propuesta (revisión) | Norma | Tipo |
|---|---|---|---|---|---|
| Consentimiento de datos condiciona el envío del documento | Q-2 | Sí | No | Ley 29733, arts. 5 y 14.1; DS 016-2024-JUS, art. 3.2 | IP |
| Pregunta de discapacidad | Q-3 | Opcional | Opcional con consentimiento propio (solo interfaz: no se guarda hasta que exista consents.disability) | DS 016-2024-JUS, arts. III.5, III.6 y 8 | IP |
| Apellido materno y número de páginas impiden enviar | Q-4 | Sí | Se podrían observar después | TUO 27444, arts. 124, 135.1 y 136 | IP |
| Aviso de privacidad corto en los formularios | Q-1 | No | Sí | Ley 29733, art. 18 | OE |
| Forma de entrega en el acceso a la información | Q-5 | No se pide | Se pide, con copia simple por defecto | DS 007-2024-JUS, art. 13.3 | OE |
Se corrigió la cita del formulario de acceso a la información, que remitía al reglamento derogado (DS 072-2003-PCM): ahora cita el art. 13 del reglamento vigente (DS 007-2024-JUS).
6. Verifica: CVD, mensajes y datos de prueba
- Formato:
legacy(8 caracteres) por defecto;directive(16 dígitos con Luhn, grupos de cuatro) preparado. Endirective, un CVD con dígito de chequeo inválido no se envía al servicio («CVD no válido»). OE Directiva, art. 7 (formato); su activación depende de OGTI y SGTD. - Mensajes:
actualodirectiva(art. 11.2 d). «Documento no disponible» solo aparece si el servicio responde410(hoy no); OE en cuanto al mensaje, IP la política de disponibilidad (art. 11.3). - Precarga desde el QR: el código de
?code=se completa y se avisa «El CVD se completó desde el código QR. Compruebe que coincida…»; el aviso desaparece al editarlo. IP: el art. 8.4 dice que el QR codifica la URL y el art. 11.2 b que el CVD se digita. - Oficios y cartas: la ayuda «¿Dónde encuentro el CVD?» muestra una hoja de ejemplo con selector Oficio/Carta, con el pie que imprime el sistema hoy (clave, dirección y QR) y el sello visible de la firma del funcionario al centro. El resultado lleva el tipo en el título cuando el servicio entrega
documentType. Criterio funcional: el CVD va solo en oficios y cartas (compatibilidad con el art. 13.2 a por validar con SGTD y OGTI). - Datos de prueba (
features/verifica/mock/fixtures.mock.ts, archivos enpublic/mock/):TEST0001oficio con anexos,TEST0002carta sin anexos,TEST0003no disponible,TEST0004error,TEST0005muchas consultas, y dos CVD de 16 dígitos (válido e inválido).
7. Pendiente de validación institucional
Ver la matriz 6.2 y las consultas de docs/normativa/: efecto de no confirmar el acuse y sello de tiempo (OGAJ, OGTI); validez sin aviso al celular (OGAJ); aviso de privacidad (Oficial de Datos Personales); consentimiento como condición, discapacidad y validaciones de admisión (OGAJ, Oficial de Datos Personales); compatibilidad del CVD con PIDE y precarga desde el QR (SGTD, OGTI).