# Backlog ejecutable — Alineación 100% RRHH vs `plan-rrhh.md`

Fecha: 2026-05-13  
Base: `backend/docs/plan-rrhh.md` (Fase 2 + reglas obligatorias + API/permisos)

## Objetivo
Cerrar las brechas detectadas para lograr conformidad funcional y de cumplimiento al 100% en RRHH (backend + frontend), priorizando reglas legales y trazabilidad.

## Definición de Hecho (global)
- 12/12 reglas obligatorias del plan en estado `Cumple`.
- Endpoints RRHH con permisos alineados a matriz del plan.
- Auditoría de operaciones críticas RRHH disponible y consultable.
- Paginación consistente en listados operativos y documentada donde no aplica.
- Suite de pruebas RRHH (unit + integration/e2e) ejecutable en CI.
- Matriz de trazabilidad legal actualizada con evidencia por regla.

## Orden de ejecución recomendado
1. Bloque A: Reglas críticas de cálculo y cierre (obligatorio antes de nuevos features).
2. Bloque B: Auditoría y permisos.
3. Bloque C: Compatibilidad API/paginación y consistencia FE/BE.
4. Bloque D: Testing, evidencia y cierre documental.

## Backlog priorizado

| ID | Prioridad | Bloque | Tarea | Esfuerzo | Dependencias | Criterios de aceptación |
|---|---|---|---|---|---|---|
| RRHH-F2-01 | Crítica | A | Convertir límite de descuentos 30% a validación bloqueante en cierre de liquidación (salvo excepción válida). | 1-2 días | Ninguna | Cerrar liquidación devuelve `409` cuando descuentos superan 30% y no aplica excepción; test unit e integration cubren caso. |
| RRHH-F2-02 | Crítica | A | Implementar regla de embargo judicial (tope 50%) con clasificación explícita de conceptos de embargo. | 2-3 días | RRHH-F2-01 | Si descuento por embargo excede 50%, cierre bloqueado con mensaje claro; casos mixtos embargo/no embargo cubiertos por tests. |
| RRHH-F2-03 | Crítica | A | Implementar excepción formal parametrizada para neto negativo (con motivo y auditoría), manteniendo bloqueo por defecto. | 2-3 días | RRHH-F2-01 | Neto negativo bloquea por defecto; solo pasa con parámetro activo + evidencia de autorización y motivo auditado. |
| RRHH-F2-04 | Alta | A | Endurecer `rrhh-engine` con validadores centralizados de cumplimiento legal antes de `CERRADA`. | 1-2 días | RRHH-F2-01..03 | Existe capa única de validación legal invocada desde cierre; no hay validaciones duplicadas divergentes. |
| RRHH-F2-05 | Alta | B | Activar auditoría automática/manual en mutaciones RRHH críticas (liquidaciones, IPS, desvinculaciones, acreditaciones, planillas). | 2-4 días | RRHH-F2-04 | Toda mutación crítica genera audit log con usuario, empresa, acción, entidad, old/new cuando aplique. |
| RRHH-F2-06 | Alta | B | Estandarizar `created_by/updated_by` y timestamps en operaciones RRHH críticas que hoy no lo completan consistentemente. | 2-3 días | RRHH-F2-05 | Inserciones/actualizaciones RRHH críticas guardan metadatos de actor en forma consistente; verificado por tests. |
| RRHH-F2-07 | Alta | B | Implementar acceso de auditoría RRHH con permiso `RRHH_AUDITORIA_VER` y filtros por período/entidad/usuario. | 1-2 días | RRHH-F2-05 | Endpoint/consulta de auditoría requiere permiso; sin permiso retorna `403`; con permiso lista eventos RRHH. |
| RRHH-F2-08 | Alta | B | Cerrar matriz de permisos faltantes (`RRHH_REPORTES_VER`, y demás sugeridos por plan) endpoint por endpoint. | 1-2 días | RRHH-F2-07 | Matriz permisos->rutas publicada; tests de autorización pasan para rol permitido y denegado. |
| RRHH-F2-09 | Media | C | Agregar compatibilidad de API v1 del plan (aliases de rutas/métodos) sin romper clientes actuales. | 2-3 días | RRHH-F2-08 | Rutas equivalentes del plan responden correctamente o redirigen internamente; contrato documentado. |
| RRHH-F2-10 | Media | C | Estandarizar contrato de paginación en listados operativos (`data,total,page,limit`) y documentar listados no paginados. | 1-2 días | RRHH-F2-09 | Todos los listados operativos aceptan `page/limit`; catálogos/non-paginated quedan explícitos en doc técnica. |
| RRHH-F2-11 | Media | C | Verificar y ajustar frontend RRHH para usar paginación real donde backend la ofrece y evitar supuestos erróneos. | 1-2 días | RRHH-F2-10 | Tabs RRHH paginadas consumen `page/limit`; UI refleja `total` real; catálogos funcionan sin paginación. |
| RRHH-F2-12 | Alta | D | Crear suite unitaria del motor RRHH con foco en 12 reglas obligatorias y edge cases legales. | 3-4 días | RRHH-F2-04 | Cobertura de reglas obligatorias >= 90% de ramas críticas del engine. |
| RRHH-F2-13 | Alta | D | Crear integration tests de transiciones de estado y bloqueos (`BORRADOR`, `PRE_LIQUIDACION`, `CERRADA`, `ANULADA`). | 2-3 días | RRHH-F2-12 | No se permite editar `CERRADA`; bloqueos por reglas críticas verificados vía API. |
| RRHH-F2-14 | Alta | D | Crear E2E del flujo mensual completo: pre-liquidar -> cerrar -> IPS/REOP -> acreditación bancaria. | 3-4 días | RRHH-F2-13 | Flujo happy path y fallas críticas ejecutan en CI con datos semilla reproducibles. |
| RRHH-F2-15 | Media | D | Publicar matriz final de trazabilidad legal (Regla -> código -> test -> evidencia) y checklist M01-M15 firmado. | 1-2 días | RRHH-F2-14 | Documento de cierre actualizado en `backend/docs` con evidencia y fecha de validación. |

## Entregables por bloque

### Bloque A (Cumplimiento legal core)
- Cambios en `rrhh-engine` y cierre de liquidación con bloqueos duros.
- Tests unitarios de reglas 2, 9, 10 del plan.

### Bloque B (Auditoría y permisos)
- Auditoría RRHH operativa para mutaciones críticas.
- Permisos RRHH del plan aplicados y probados.

### Bloque C (Contrato API + paginación + FE)
- Compatibilidad funcional de rutas propuestas en plan.
- Inventario definitivo de endpoints paginados/no paginados.
- UI RRHH alineada al contrato real.

### Bloque D (Calidad y cierre)
- Cobertura de pruebas automatizadas para flujos críticos.
- Matriz de trazabilidad legal y acta de conformidad M01–M15.

## Sprint sugerido (4 semanas)
- Semana 1: RRHH-F2-01..04
- Semana 2: RRHH-F2-05..08
- Semana 3: RRHH-F2-09..11
- Semana 4: RRHH-F2-12..15

## Riesgos de ejecución y mitigación
- Riesgo: cambios de reglas legales durante implementación.  
  Mitigación: parametrizar vigencias y cubrir con tests de regresión por período.
- Riesgo: ruptura de clientes por cambios de API.  
  Mitigación: aliases backward-compatible + feature flag + smoke tests.
- Riesgo: baja trazabilidad en casos de excepción.  
  Mitigación: obligar motivo/usuario en excepciones y auditar old/new value.