92 lines
5.3 KiB
Markdown
92 lines
5.3 KiB
Markdown
# 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.
|