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

Se corrigió la terminología residual Área/Yacimiento en el lifecycle de Inspecciones. El contexto operativo queda definido inequívocamente como Área + Operadora vigente.
Se documentó en código la separación entre Empresa y la jerarquía física del Inventario.
Se documentó en la entidad Acta el contrato multi-Acta + único DRAFT simultáneo.
Se agregó un test transversal F6.1 que protege jerarquía, contexto operativo, multi-Acta, Hallazgos, apertura móvil y separación GEDO/vencimiento.
Se consolidó docs/F6_INVENTORY_MODEL.md como única referencia viva y los duplicados históricos apuntan a ella.
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.

5.3 KiB Raw Blame History