From 3b6c2c1220fb56f31981614aabcf8f31bc19887e Mon Sep 17 00:00:00 2001 From: enlineawork Date: Wed, 9 Sep 2026 18:10:27 -0300 Subject: [PATCH] docs(F6.1): add presentation acceptance and demo guide --- docs/PRESENTACION_F6_1.md | 115 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 docs/PRESENTACION_F6_1.md diff --git a/docs/PRESENTACION_F6_1.md b/docs/PRESENTACION_F6_1.md new file mode 100644 index 0000000..3f37354 --- /dev/null +++ b/docs/PRESENTACION_F6_1.md @@ -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.