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

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.