docs(F6.1): add presentation acceptance and demo guide

2026-09-09 18:10:27 -03:00
parent 88b469b6fa
commit 3b6c2c1220
1 changed files with 115 additions and 0 deletions
@@ -0,0 +1,115 @@
 # 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:
 1. API typecheck, tests y build.
 2. WEB typecheck y build.
 3. migraciones sobre PostGIS limpio.
 4. arranque real de API.
 5. preflight aislado equivalente al entorno Docker.
 6. build de imágenes productivas.
 7. Android lint.
 8. Android unit tests reales.
 9. Android `assembleDebug`.
 10. Android `assembleRelease`.
 11. APK debug con SHA-256 y metadata del SHA exacto.
 ## Recorrido sugerido de demo
 1. **Login WEB** y Dashboard.
 2. **Inventarios**: navegar Departamento → Área → Yacimiento → Instalación → Subinstalación y abrir un dossier.
 3. Mostrar la **cronología/dossier**, documentos, fotos y Hallazgos.
 4. Mostrar, si existe un caso preparado, una **fusión cronológica** y el aviso de registro canónico.
 5. **Usuarios**: abrir un Inspector y mostrar perfil, email documental y roles.
 6. **Inspecciones**: crear/abrir una planificación con Área + Operadora, Inspector y checklist.
 7. **Android**: ingresar con Inspector, abrir o seleccionar la Inspección e iniciarla.
 8. 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**.
 9. Crear un **Acta**, registrar un **Hallazgo** (incluyendo `OTROS` si se quiere demostrar el fallback), adjuntar evidencia y sellar el Acta.
 10. Cerrar la Inspección cuando todas las Actas estén selladas.
 11. 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.