docs: registrar auditoría de consistencia F6.1

docs/AUDITORIA_CONSISTENCIA_F6_1.md

@@ -0,0 +1,91 @@
+# Auditoría de consistencia · F6.1
+
+**Baseline revisado:** `25a63cd3d4b2c561803cc5105cce100983c8eeff`  
+**Alcance:** API, modelo de datos, Inventarios, Inspecciones, Actas, Hallazgos, Informes/GEDO, WEB, Android, permisos, versionado documental y CI.
+
+## Resultado
+
+El modelo funcional consolidado de F6.1 es coherente. No se detectó una contradicción estructural que requiera rediseñar tablas o migrar datos antes de continuar.
+
+La auditoría sí encontró deuda de terminología/documentación y una inconsistencia de metadata generada. Las correcciones funcionales/documentales se integran en esta rama; la metadata de lockfiles se documenta como observación no funcional y debe regenerarse con npm en un corte controlado, no editarse parcialmente a mano.
+
+## Contratos verificados
+
+### Inventario
+
+- Jerarquía física única: Departamento → Área → Yacimiento → Instalación → Subinstalación.
+- Empresa es un maestro independiente.
+- Operadora vigente se resuelve por relación temporal Área ⇄ Empresa.
+- Cambiar Operadora no reparenta Inventario.
+- Departamento, Área y Yacimiento no llevan familia técnica.
+- Instalación y Subinstalación requieren familia técnica.
+- Subinstalación debe ser compatible con la familia de la Instalación padre.
+- PostgreSQL protege jerarquía y compatibilidad, además de las validaciones de API.
+
+### Inspecciones
+
+- Lifecycle canónico DRAFT → PLANNED → IN_PROGRESS → CLOSED.
+- Planificación requiere Área, Operadora vigente, Inspector responsable, fecha/hora y checklist.
+- La APK abre una Inspección reutilizando el mismo create/plan/start; no existe un lifecycle móvil paralelo.
+- No hay referencias activas a `plannedEndAt` / `planned_end_at` en el código actual.
+
+### Actas
+
+- Una Inspección puede contener múltiples Actas.
+- El constraint histórico de una sola Acta por visita fue eliminado por F1.1.
+- Existe un índice parcial que permite sólo un Acta DRAFT simultánea por Inspección.
+- El cierre de la Inspección exige que todas las Actas no canceladas estén SELLADAS.
+- El Acta finalizada/bloqueada es inmutable.
+
+### Hallazgos
+
+- Destinos directos: Yacimiento, Instalación y Subinstalación.
+- Departamento y Área no son destinos directos.
+- OTROS / Agregar otro permanece disponible.
+- Yacimiento no requiere familia técnica.
+- Instalación/Subinstalación sí requieren clasificación.
+- Inventario nacido en campo necesita GPS + foto antes de admitir Hallazgos.
+
+### Informes / GEDO
+
+- El Informe pertenece al Acta.
+- La oficialización GEDO/IF es inmutable.
+- Oficializar en GEDO no activa por sí solo el vencimiento No urgente.
+- El valor persistido histórico `GEDO_DATE` se conserva como ABI de base; en código existe el alias semántico `NOTIFICATION_DATE` para evitar interpretar GEDO como notificación automática.
+
+## Correcciones integradas en la auditoría
+
+1. Se corrigió la terminología residual `Área/Yacimiento` en el lifecycle de Inspecciones. El contexto operativo queda definido inequívocamente como **Área + Operadora vigente**.
+2. Se documentó en código la separación entre Empresa y la jerarquía física del Inventario.
+3. Se documentó en la entidad Acta el contrato multi-Acta + único DRAFT simultáneo.
+4. Se agregó un test transversal F6.1 que protege jerarquía, contexto operativo, multi-Acta, Hallazgos, apertura móvil y separación GEDO/vencimiento.
+5. Se consolidó `docs/F6_INVENTORY_MODEL.md` como única referencia viva y los duplicados históricos apuntan a ella.
+6. Se crearon `MANUAL_PROGRAMADOR.md` y `MANUAL_USUARIO.md`.
+
+## Compatibilidades históricas que NO deben “limpiarse” sin migración
+
+- Migraciones antiguas conservan nombres y reglas que fueron válidas en fases anteriores. No se modifican; migraciones posteriores son las que expresan la evolución.
+- `InspectionDeadlineBasis.GEDO_DATE` comparte valor persistido con `NOTIFICATION_DATE` por compatibilidad de esquema.
+- `assets.operator_company_id` puede conservar una fotografía de compatibilidad incluso cuando la relación temporal ya finalizó. La fuente de verdad vigente/histórica sigue siendo `area_company_relations`.
+- F5.1 es una migración destructiva de inicio limpio y no tiene `down()` reconstructivo; su rollback es el backup PRE.
+
+## Observación no funcional: metadata de package-lock
+
+Los `package.json` actuales declaran las versiones de producto vigentes, pero la metadata `name/version` de la raíz de ambos `package-lock.json` todavía conserva `0.20.0-2` de un corte anterior.
+
+Esto no cambia el grafo de dependencias ni el runtime y `npm ci` continúa siendo la barrera de instalación. Se deja explícitamente registrado para no ocultarlo.
+
+**Tratamiento correcto:** regenerar cada lockfile con npm (`npm install --package-lock-only`) cuando se haga el próximo corte controlado de metadata/dependencias y verificar el diff completo. No editar manualmente sólo las primeras líneas del lockfile.
+
+## Criterio de aceptación de esta auditoría
+
+Antes de mergear esta rama deben pasar nuevamente:
+
+- API typecheck + tests + build.
+- WEB typecheck + contrato + build.
+- migraciones sobre PostGIS limpio.
+- preflight aislado equivalente al VPS.
+- build de imágenes productivas.
+- Android assemble + unit tests cuando el workflow se dispare por el PR.
+
+La rama de documentación/consistencia no debe promoverse a `deploy` durante esta revisión. El despliegue queda deliberadamente pausado.