# DH Inspección Android · release de campo 0.19.0

## Candidata vigente

- 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.

## Procedimiento de campo validado

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.

## Castellano y presentación

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.

También se incorporó la marca oficial de Mendoza provista para esta release en las pantallas de acceso y desbloqueo biométrico.

## Integridad del alta de Inventario

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.

El servidor continúa siendo la autoridad para:

- 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

Todo cambio Android o de API que pueda afectar al cliente móvil debe pasar `Android CI / RC`:

1. validación de identidad, HTTPS y políticas básicas del manifest;
2. Android lint;
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 incorporar la release a `main`.

## Firma release

La clave histórica de firma **no se versiona ni se reemplaza**. La CI compila la variante release para detectar roturas, pero la APK productiva final debe firmarse con la clave histórica antes de instalarse como actualización de `com.korexlabs.dhinspeccion`.

No se debe crear una clave nueva para resolver una falta de acceso: eso rompería la continuidad de actualización de tablets que ya tengan una versión firmada con la clave anterior.

## Criterio de distribución

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 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.