DH Inspección V2 · corte de presentación F6.1

Este documento define el alcance verificable del corte F6.1 y el recorrido recomendado para una presentación funcional. No reemplaza al Manual de Usuario ni al Manual del Programador.

Versiones del corte

API: 0.29.0-1.
WEB: 0.23.0-1.
Android: 0.15.0 (versionCode 22).
Modelo funcional: F6.1 · contexto operativo Área–Operadora consolidado.

La versión visible en el footer WEB debe coincidir con web-v2/package.json; este contrato queda protegido por tests.

Matriz de aceptación funcional

Inventario

Jerarquía física vigente: Departamento → Área → Yacimiento → Instalación → Subinstalación.
Empresa permanece fuera del árbol físico.
La Operadora se resuelve por relación temporal vigente con el Área.
Instalación y Subinstalación admiten familia Otro / no catalogado cuando corresponda.
Un alta de campo conserva inspección, actor, fecha, contexto, GPS y evidencia exigida por el flujo.

El issue histórico F3.1 describía un árbol que comenzaba en Área. Esa definición fue supersedida por F5.1/F6, que incorporó Departamento como raíz territorial autorizada.

Merge cronológico de Inventario

Sólo se fusionan Instalaciones/Subinstalaciones compatibles.
El registro duplicado no se elimina: queda fusionado/inactivo y conserva identidad histórica.
Las referencias históricas emitidas no se reescriben.
El dossier canónico agrega cronológicamente alias y eventos, mostrando el Inventario original cuando corresponde.
WEB muestra el destino canónico.
Android, al conciliar un alta nacida en campo, selecciona inmediatamente el canónico y confirma qué código se conserva.

Hallazgos y catálogo

OTROS permanece disponible en el resolver de Hallazgos.
La fusión de catálogo mueve aplicabilidad futura al canónico sin reescribir Hallazgos ya emitidos.
Las instancias históricas conservan el modelo append-only y la trazabilidad de auditoría.

Inspecciones y Android

Una inspección planificada puede iniciarse desde Android por un Inspector autorizado y asignado.
El inicio registra actualStartedAt, actor y auditoría del servidor.
El contexto operativo es Área + Operadora vigente.
Una Inspección puede tener múltiples Actas, con un único borrador simultáneo.
El cierre exige Actas selladas y verificaciones requeridas completas.

Perfil del Inspector

Nombre y apellido obligatorios.
Datos administrativos disponibles: DNI, email, teléfono, cargo/función y legajo/matrícula.
El email es obligatorio para rol Inspector.

Entrega documental

El Acta PDF se prepara para Empresa, Oficina e Inspector principal.
El INF Word se prepara también para el Inspector principal cuando existe.
El outbox conserva destinatario, estado, intentos, error y fecha de envío; los pendientes son reintentables.
La entrega depende de SMTP y destinatarios configurados: si faltan, el registro queda en un estado de espera auditable en lugar de perderse.

Relevamientos

Relevamientos no existe como módulo/ruta/entrada de menú activa.
La captura en campo vive dentro de Inspecciones + Inventario de campo.

Barrera técnica obligatoria

Un SHA sólo es candidato de presentación cuando pasan:

API typecheck, tests y build.
WEB typecheck y build.
migraciones sobre PostGIS limpio.
arranque real de API.
preflight aislado equivalente al entorno Docker.
build de imágenes productivas.
Android lint.
Android unit tests reales.
Android assembleDebug.
Android assembleRelease.
APK debug con SHA-256 y metadata del SHA exacto.

Recorrido sugerido de demo

Login WEB y Dashboard.
Inventarios: navegar Departamento → Área → Yacimiento → Instalación → Subinstalación y abrir un dossier.
Mostrar la cronología/dossier, documentos, fotos y Hallazgos.
Mostrar, si existe un caso preparado, una fusión cronológica y el aviso de registro canónico.
Usuarios: abrir un Inspector y mostrar perfil, email documental y roles.
Inspecciones: crear/abrir una planificación con Área + Operadora, Inspector y checklist.
Android: ingresar con Inspector, abrir o seleccionar la Inspección e iniciarla.
En Android, abrir Inventario de campo, seleccionar un registro o crear uno nuevo con GPS y foto. Para una familia no catalogada, usar Otro / no catalogado.
Crear un Acta, registrar un Hallazgo (incluyendo OTROS si se quiere demostrar el fallback), adjuntar evidencia y sellar el Acta.
Cerrar la Inspección cuando todas las Actas estén selladas.
En WEB, mostrar Actas / Informes / Entrega documental y el estado auditable de los envíos.

Preparación del entorno de presentación

Antes de una demo con envío real de correo, verificar en Administración:

email institucional de Oficina;
email de la Empresa involucrada;
email del Inspector principal;
SMTP configurado y operativo.

Para una demo sin correo saliente, el resto del flujo puede demostrarse y la bandeja de entrega debe reflejar el estado de espera correspondiente; no se debe presentar un envío como exitoso si el transporte no está configurado.

Evidencia del corte

El SHA presentado debe conservarse junto con:

resultado verde de GitHub Actions;
metadata de versiones;
APK debug de la candidata y su SHA-256;
si se distribuye APK productiva, firma histórica verificada y SHA-256 del artefacto firmado.

5.4 KiB Raw Blame History Unescape Escape