docs(android): documentar candidata final de campo 0.19.0

android-app/RELEASE.md

@@ -1,40 +1,58 @@
-# DH Inspección Android · release Campo Moderno 0.18.0
+# DH Inspección Android · release de campo 0.19.0
 
 ## Candidata vigente
 
-- Fase funcional: **Campo Moderno / UX dinámica de Inventario y Actas**.
-- `versionName`: **0.18.0**.
-- `versionCode`: **27**.
+- Fase funcional: **Campo final / Inspección → Acta → Inventario → Hallazgos → Firma**.
+- `versionName`: **0.19.0**.
+- `versionCode`: **28**.
 - Application ID release: `com.korexlabs.dhinspeccion`.
 - Application ID debug/QA: `com.korexlabs.dhinspeccion.debug`.
 - API: `https://dhv2.korexlabs.com/api/v3/`.
 
 La variante debug es independiente de la app productiva y puede instalarse para QA/presentación sin sobrescribir una instalación release histórica.
 
-## Novedades de campo 0.18.0
+## Procedimiento de campo validado
 
-La APK adopta una capa visual Material 3 propia de DH: superficies más limpias, jerarquía visual más clara, botones y estados más legibles, tarjetas con menor ruido y una navegación consistente entre Inspección, Actas e Inventario.
+1. La inspección se **planifica y asigna desde el tablero web**. La APK no crea inspecciones nuevas.
+2. En la tablet el inspector abre una inspección asignada y, al llegar al lugar, pulsa **Iniciar inspección**.
+3. Con la inspección en curso se crea o selecciona el **Acta** de trabajo. Sólo puede existir un Acta en borrador a la vez; una inspección puede contener varias Actas sucesivas.
+4. Los **Hallazgos** se registran exclusivamente sobre **Instalaciones o Subinstalaciones**.
+5. Si el elemento ya existe, se busca y selecciona desde Inventario de campo.
+6. Si no existe, se da de alta desde la APK siguiendo la misma estructura que el tablero:
+   - Instalación dentro del Yacimiento de la inspección;
+   - Subinstalación dentro de una Instalación seleccionada;
+   - nombre técnico / identificación obligatorio;
+   - Código DH de campo autogenerado por el servidor;
+   - nombre habitual opcional;
+   - descripción y observaciones de alta opcionales;
+   - clasificación técnica obligatoria cuando el tipo la requiera;
+   - atributos técnicos dinámicos obligatorios según la configuración del tipo;
+   - Área y Operadora heredadas de la inspección planificada;
+   - ubicación del dispositivo y fotografía obligatorias antes de habilitar Hallazgos.
+7. Sobre el elemento se selecciona un Hallazgo del catálogo contextual o **OTROS** cuando corresponda; se registra descripción, gravedad y evidencia fotográfica si aplica.
+8. Al terminar el contenido se pulsa **Cerrar Acta y dejar pendiente de firma**. El contenido y los Hallazgos quedan inmutables y el estado visible pasa a **Pendiente de firma**.
+9. Se registran las firmas y la manifestación de la empresa. La ausencia por sí sola no modifica el contenido cerrado: el Acta permanece pendiente hasta resolver el circuito de firma/manifestación conforme a la regla vigente.
+10. Una vez resuelta la firma, el Acta queda **Firmada e inmutable**. La inspección sólo puede cerrarse cuando todas sus Actas no canceladas estén finalizadas.
 
-La carga de una Subinstalación mantiene la integridad del modelo físico pero reduce pasos:
+## Castellano y presentación
 
-1. el buscador de **Instalaciones padre** ahora consulta mientras el inspector escribe;
-2. cada coincidencia aparece como tarjeta seleccionable y tocarla avanza directamente a la identificación de la Subinstalación;
-3. la clasificación técnica continúa filtrada por compatibilidad con la Instalación elegida;
-4. **Guardar y tomar foto** captura GPS y abre la cámara automáticamente.
+La navegación operativa de la APK se presenta en castellano. Los valores técnicos que la API conserva internamente (`DRAFT`, `LOCKED`, `SEALED`, `PLANNED`, etc.) no se muestran al inspector; se traducen a **Borrador**, **Pendiente de firma**, **Firmada**, **Planificada**, **En curso**, etc.
 
-Se conserva la regla de que un elemento nacido en campo no puede recibir Hallazgos hasta contar con GPS y fotografía.
+También se incorporó la marca oficial de Mendoza provista para esta release en las pantallas de acceso y desbloqueo biométrico.
 
-## Actas en Android
+## Integridad del alta de Inventario
 
-El espacio de Actas fue rediseñado para mostrar con claridad:
+El alta móvil no duplica los formularios administrativos del tablero. Conserva los datos necesarios para que el registro tenga identidad y trazabilidad en campo, mientras que los datos administrativos que ya vienen determinados por la inspección (Área y Operadora) se heredan automáticamente.
 
-- contexto de la Inspección y Yacimiento;
-- estado de cada Acta y cantidad de Hallazgos;
-- urgencia mediante selección explícita;
-- responsable de empresa, bloqueo, firmas, manifestación y sellado;
-- condición necesaria para cerrar la Inspección.
+El servidor continúa siendo la autoridad para:
 
-El listado que consume Android usa un read-model móvil liviano (`/inspection-visits/:visitId/acts/mobile`). Esta lectura no depende del módulo documental de oficina ni de `inspection_reports`, de modo que entrar a una Inspección en campo no queda acoplado a la proyección de Informes/GEDO.
+- generar el Código DH `CAM-*` cuando el alta nace en campo;
+- validar la jerarquía Yacimiento → Instalación → Subinstalación;
+- exigir la familia/clasificación técnica compatible;
+- validar atributos dinámicos configurados en el tablero;
+- registrar ubicación de creación;
+- impedir crear Hallazgos sobre un alta de campo que todavía no tenga ubicación y fotografía;
+- conservar la trazabilidad si el alta provisional se fusiona posteriormente con un registro existente.
 
 ## Barrera obligatoria
 
@@ -42,12 +60,12 @@ Todo cambio Android o de API que pueda afectar al cliente móvil debe pasar `And
 
 1. validación de identidad, HTTPS y políticas básicas del manifest;
 2. Android lint;
-3. unit tests Android reales, con verificación de que exista al menos una prueba ejecutada;
+3. unit tests Android reales, incluyendo contratos del procedimiento final;
 4. `assembleDebug`;
 5. `assembleRelease` para comprobar que la variante productiva compile;
 6. empaquetado del APK debug con SHA-256 y metadata de commit/versionado.
 
-Además, `DH V2 CI` debe mantener verdes API, WEB y contrato Docker/migraciones antes de promover el cambio.
+Además, `DH V2 CI` debe mantener verdes API, WEB y contrato Docker/migraciones antes de incorporar la release a `main`.
 
 ## Firma release
 
@@ -62,5 +80,5 @@ Antes de distribuir una APK productiva:
 - todas las barreras de CI del SHA exacto deben estar verdes;
 - comprobar certificado/huella de firma contra la versión histórica;
 - realizar actualización sobre al menos una tablet con la versión productiva anterior;
-- ejecutar smoke funcional contra el entorno objetivo: login, abrir Inspección, abrir Actas sin error, crear Acta, búsqueda dinámica de Instalación, selección de padre, alta de Subinstalación, GPS/foto, Hallazgo y cierre;
+- ejecutar smoke funcional contra producción: ingreso, abrir inspección asignada, iniciar inspección, crear Acta, buscar Instalación/Subinstalación, alta de campo, ubicación/foto, Hallazgo, cerrar Acta a pendiente de firma, firma/finalización y cierre de inspección;
 - registrar el SHA Git y SHA-256 de la APK distribuida.