Protocolo ante denuncias y requerimientos legales

Versión 1.0 — Qué hacer paso a paso si llega una denuncia, inspección o demanda

Documento confidencial de uso interno. No compartas este protocolo con trabajadores ni terceros salvo que sea imprescindible para la defensa legal.

1Recibir y documentar la denuncia

Identifica quién denuncia: trabajador, sindicato, Inspección de Trabajo o juzgado.
Copia el escrito/requerimiento en PDF y en papel.
Anota la fecha de recepción y el plazo para responder (normalmente 15 días hábiles).
NO toques nada en la app relacionado con el periodo denunciado. Cualquier modificación queda registrada en auditoría.

Prohibido: borrar registros, editar horarios del periodo denunciado, aprobar correcciones retrospectivas, o pedir al desarrollador que "arregle algo" del mes en cuestión.

2Identificar el periodo denunciado

Normalmente la denuncia menciona un mes o rango de fechas. Anótalo:

Mes(es) afectados

Ej: marzo 2026

Trabajador(es)

Ej: María Gómez

Motivo

Ej: horas extra no pagadas

3Consultar el estado del mes en la app

Entra en Panel de Administración → Certificaciones y verifica:

Qué mirar	Resultado esperado	Qué hacer si no
¿El mes está CERRADO?	Cerrado	Si está ABIERTO, ciérralo manualmente AHORA.
¿Hay hash SHA-256?	Cadena hexadecimal de 64 chars	Contacta con soporte urgentemente.
¿Hay sello .ots?	Válido	Contacta con soporte urgentemente.
¿Está subido a GitHub?	URL visible en el detalle	Contacta con soporte urgentemente.

4Descargar la prueba técnica

Desde el panel de Certificaciones del mes denunciado, pulsa cada botón:

1. Archivo .sha256

El hash en texto plano. Se sube automáticamente a GitHub junto al .ots.

2. Archivo .ots

El sello OpenTimestamps anclado en blockchain Bitcoin. Pruébalo en opentimestamps.org.

3. Snapshot completo (JSON)

El objeto exacto que se usó para calcular el hash. Incluye registros, incidencias, bajas, vacaciones, correcciones, logs de auditoría, config de empresa, festivos y trabajadores activos.

4. Informe legal (PDF)

Listado legible de registros, incidencias y vacaciones con hash en el pie de página. Se genera desde Reportes → Registros sellados.

Guarda todo en una carpeta local con nombre: Denuncia_YYYY-MM_NombreTrabajador.

5Verificar la integridad (auto-verificación)

La app tiene una función de verificación integrada:

En el panel de Certificaciones, pulsa "Verificar integridad" en el mes denunciado.
La app descarga el .ots desde GitHub, ejecuta ots verify y compara hashes.
El resultado te dirá: VÁLIDO, ALTERADO o PENDIENTE.

✅ Si dice VÁLIDO: la prueba técnica está intacta. Los datos no han sido modificados desde el cierre.

6Revisar los registros del trabajador

Abre el snapshot JSON descargado (usa un editor de texto o VS Code) y busca al trabajador denunciado. Revisa:

registrosHorario: sus fichajes de entrada y salida día a día.
incidencias: si hubo HORAS_EXTRA, AUSENCIA_TOTAL, SALIDA_OMITIDA, etc.
vacaciones: si tuvo vacaciones o permisos aprobados ese mes.
bajasMedicas: si estuvo de baja médica.
correcciones: si solicitó o se le aplicó alguna corrección.
logsAuditoria: quién modificó qué y cuándo (solo la tabla registros_horario en el backup JSON; el snapshot completo incluye todos).

7Contratar al abogado laboralista

Lleva al abogado:

Copia del escrito de denuncia.
Archivos .sha256, .ots, snapshot JSON e informe PDF.
Capturas del panel de Certificaciones mostrando estado CERRADO.
Contrato de suscripción con Jornatrack (cláusula de inmutabilidad).
Documento "Manual de Verificación para Peritos" (disponible en el repositorio del proyecto).

8Entregar registros a la Inspección o al juez

Entrega en formato PDF:

Informe legal mensual generado desde la app (registros + incidencias + vacaciones + bajas).
Certificación mensual con hash y fecha de cierre.
Captura del estado de certificación en la app.
(Opcional) Los archivos .ots y .sha256 para que el perito los verifique.
(Opcional) El snapshot JSON completo para que el perito recalcule el hash.

No entregues acceso directo a la app. Los datos deben ir en documento estático, no editable.

Caso práctico: María denuncia horas extra no pagadas

María Gómez presenta denuncia ante Inspección de Trabajo el 15 de junio de 2026. Alega que en marzo de 2026 hizo horas extra no pagadas.

El admin revisa el snapshot de marzo

Descarga el snapshot JSON completo y busca a María. Descubre:

El 15/03 fichó entrada 08:02 y salida 18:45.
Su horario teórico: 08:00-17:00 (8h netas).
Trabajó 10h 43min → 2h 43min extra.
El sistema detectó HORAS_EXTRA con 163 minutos.
María la justificó: "Quedé con el jefe de turno por avería en producción".
El admin la aprobó el 16/03.
Tiene 2 compensaciones programadas pendientes: salida anticipada el 20/03 (-76min) y retraso el 22/03 (-40min).
Saldo neto tras compensaciones: +47 minutos a favor de la empresa.

Escenario A: Todo válido

Las horas extra existen, fueron detectadas, justificadas y aprobadas. Además, María tiene compensaciones pendientes que las reducen. La empresa está cubierta.

Escenario B: Error humano detectado

Supongamos que el admin editó la salida de 18:45 a 17:00 el 12/03 (antes del cierre). El snapshot JSON incluye el registro original y el editado, con quién editó, cuándo y por qué. La auditoría lo documenta todo. Es legal siempre que haya trazabilidad.

Escenario C: El mes no estaba cerrado

Si por un error técnico marzo quedó ABIERTO y alguien editó datos después de la denuncia, la empresa pierde credibilidad. Contacta inmediatamente con soporte. El log de auditoría mostrará quién editó y cuándo.

Verificación por el perito (comandos exactos)

El perito necesita Python 3 y OpenTimestamps Client:

pip install opentimestamps-client

Paso 1: Ver información del sello

ots info 2026-03.ots

Muestra: File sha256 hash: a3f7b2c8...

Paso 2: Verificar en blockchain

ots verify 2026-03.ots

Resultado esperado: Success! Bitcoin attestation found at height 890123 (date: 2026-04-10 09:41:23 UTC)

Paso 3: Comparar hash del .ots con el .sha256

cat 2026-03.sha256 # Debe coincidir exactamente con el hash del paso 1

Paso 4: Recalcular hash del snapshot JSON

# Linux / macOS sha256sum snapshot-2026-03.json # Windows (PowerShell) Get-FileHash snapshot-2026-03.json -Algorithm SHA256

El hash debe coincidir con el hashCalculado dentro del propio JSON y con el hash del sello .ots.

Interpretación de resultados:

Escenario	Conclusión
`ots verify` OK + hash coincide	Prueba de inmutabilidad aceptada. Los datos no han sido alterados.
`ots verify` OK + hash NO coincide	Alteración detectada. Investigar si hubo anexo judicial.
`ots verify` FALLA	Prueba insuficiente. El sello puede estar corrupto o ser muy reciente.
Existe anexo (anexo-1, anexo-2...)	Modificación post-cierre documentada con trazabilidad.

Checklist de supervivencia legal (imprimir)

☐Tengo copia del escrito de denuncia/requerimiento
☐Anoté la fecha de recepción y el plazo de respuesta
☐No he tocado NINGÚN dato del periodo denunciado en la app
☐Identifiqué el mes, el trabajador y el motivo
☐Verifiqué que el mes esté CERRADO en Certificaciones
☐Descargué .sha256, .ots, snapshot JSON e informe PDF
☐La verificación de integridad dice VÁLIDO
☐Revisé los registros del trabajador en el snapshot
☐Revisé incidencias, vacaciones y bajas del periodo
☐Revisé los logs de auditoría del periodo
☐Contraté abogado laboralista
☐Entregué al abogado: denuncia + archivos técnicos + contrato + manual del perito
☐Preparé la defensa con los argumentos de inmutabilidad
☐(Si procede) El perito verificó ots verify y coincidió el hash