From 4f0c367d3e252009faaf67e990437c3e3f36e1de Mon Sep 17 00:00:00 2001 From: enlineawork Date: Fri, 11 Sep 2026 11:35:30 -0300 Subject: [PATCH] docs(android): documentar candidata final de campo 0.19.0 --- android-app/RELEASE.md | 64 +++++++++++++++++++++++++++--------------- 1 file changed, 41 insertions(+), 23 deletions(-) diff --git a/android-app/RELEASE.md b/android-app/RELEASE.md index 3e5acfa..2716bd2 100644 --- a/android-app/RELEASE.md +++ b/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.