From 51ace362d7ef22eee3a9838f26da0e6d7186d312 Mon Sep 17 00:00:00 2001 From: enlineawork Date: Wed, 9 Sep 2026 14:52:03 -0300 Subject: [PATCH] =?UTF-8?q?docs:=20registrar=20auditor=C3=ADa=20de=20consi?= =?UTF-8?q?stencia=20F6.1?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/AUDITORIA_CONSISTENCIA_F6_1.md | 91 +++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 docs/AUDITORIA_CONSISTENCIA_F6_1.md diff --git a/docs/AUDITORIA_CONSISTENCIA_F6_1.md b/docs/AUDITORIA_CONSISTENCIA_F6_1.md new file mode 100644 index 0000000..cc9a0ae --- /dev/null +++ b/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.