docs(code): documentar apertura móvil canónica

Hallazgos directos en Yacimiento, Instalación y Subinstalación con OTROS siempre disponible. Apertura de inspección desde Android mediante Área → Operadora vigente, autoasignación y lifecycle canónico.

.github/workflows/android.yml

@@ -1,5 +1,5 @@
 name: Android APK
-# F6: genera una APK debug verificable contra la API productiva F6.
+# F6.1: genera una APK debug verificable contra la API productiva F6.1.
 
 on:
   push:
@@ -11,6 +11,7 @@ on:
       - 'feature/f2-4*'
       - 'feature/f3-1*'
       - 'feature/f3-2*'
+      - 'feature/f6-1*'
     paths:
       - 'android-app/**'
       - '.github/workflows/android.yml'
@@ -62,7 +63,7 @@ jobs:
       - name: Upload APK
         uses: actions/upload-artifact@v4
         with:
-          name: DH-Inspeccion-F6-0.14.0-debug
+          name: DH-Inspeccion-F6.1-0.15.0-debug
           path: android-app/app/build/outputs/apk/debug/app-debug.apk
           if-no-files-found: error
           retention-days: 30

README.md

@@ -2,9 +2,28 @@
 
 Repositorio del sistema DH Inspección V2.
 
-## Estructura
+## Componentes
 
-- `api-v3/`: API v3.
-- `web-v2/`: aplicación web.
-- `scripts/`: utilidades operativas y de despliegue.
-- `docs/`: documentación técnica.
+- `api-v3/`: API NestJS/TypeORM y contratos de dominio.
+- `web-v2/`: aplicación WEB React/Vite.
+- `android-app/`: aplicación Android para trabajo de campo.
+- `scripts/`: utilidades operativas, preflight y despliegue.
+- `docs/`: documentación funcional y técnica.
+
+## Documentación vigente
+
+- [Manual del Programador](docs/MANUAL_PROGRAMADOR.md)
+- [Manual de Usuario](docs/MANUAL_USUARIO.md)
+- [Modelo canónico de Inventarios F6.1](docs/F6_INVENTORY_MODEL.md)
+- [Auditoría de consistencia F6.1](docs/AUDITORIA_CONSISTENCIA_F6_1.md)
+
+## Contratos que no deben romperse
+
+- Inventario físico: **Departamento → Área → Yacimiento → Instalación → Subinstalación**.
+- Empresa es un maestro independiente; la Operadora se relaciona temporalmente con Área.
+- Una Inspección puede tener múltiples Actas, pero sólo un Acta `DRAFT` simultánea.
+- Hallazgos directos: Yacimiento, Instalación y Subinstalación, siempre con `OTROS` disponible.
+- La APK puede abrir una Inspección reutilizando el lifecycle canónico del backend.
+- GEDO/IF oficializa el Informe, pero no activa por sí solo el vencimiento No urgente.
+
+Las reglas detalladas y el procedimiento de cambio seguro están en los manuales enlazados arriba.

android-app/app/build.gradle.kts

@@ -12,8 +12,8 @@ android {
         applicationId = "com.korexlabs.dhinspeccion"
         minSdk = 26
         targetSdk = 36
-        versionCode = 21
-        versionName = "0.14.0"
+        versionCode = 22
+        versionName = "0.15.0"
 
         testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
         vectorDrawables.useSupportLibrary = true

android-app/app/src/main/java/com/korexlabs/dhinspeccion/data/MobileInspectionOpen.kt

@@ -0,0 +1,103 @@
+package com.korexlabs.dhinspeccion.data
+
+import android.content.Context
+import com.korexlabs.dhinspeccion.BuildConfig
+import com.squareup.moshi.Moshi
+import com.squareup.moshi.kotlin.reflect.KotlinJsonAdapterFactory
+import kotlinx.coroutines.sync.Mutex
+import kotlinx.coroutines.sync.withLock
+import okhttp3.OkHttpClient
+import retrofit2.HttpException
+import retrofit2.Retrofit
+import retrofit2.converter.moshi.MoshiConverterFactory
+import retrofit2.http.Body
+import retrofit2.http.GET
+import retrofit2.http.Header
+import retrofit2.http.POST
+import retrofit2.http.Path
+
+data class MobilePlanningAsset(
+    val id: String,
+    val code: String,
+    val name: String,
+)
+
+data class MobilePlanningAssetResponse(
+    val data: List<MobilePlanningAsset> = emptyList(),
+)
+
+data class OpenMobileInspectionRequest(
+    val operationalAreaId: String,
+    val operatorCompanyId: String,
+)
+
+private interface MobileInspectionOpenApi {
+    @GET("inspection-visits/mobile/planning-context/areas")
+    suspend fun areas(
+        @Header("Authorization") authorization: String,
+    ): MobilePlanningAssetResponse
+
+    @GET("inspection-visits/mobile/planning-context/areas/{areaId}/operators")
+    suspend fun operators(
+        @Header("Authorization") authorization: String,
+        @Path("areaId") areaId: String,
+    ): MobilePlanningAssetResponse
+
+    @POST("inspection-visits/mobile/open")
+    suspend fun open(
+        @Header("Authorization") authorization: String,
+        @Body request: OpenMobileInspectionRequest,
+    ): VisitDetail
+
+    @POST("auth/mobile/refresh")
+    suspend fun refresh(@Body request: RefreshRequest): MobileSessionResponse
+}
+
+class MobileInspectionOpenRepository(context: Context) {
+    private val store = SecureSessionStore(context.applicationContext)
+    private val refreshMutex = Mutex()
+    private val moshi = Moshi.Builder().addLast(KotlinJsonAdapterFactory()).build()
+    private val api: MobileInspectionOpenApi = Retrofit.Builder()
+        .baseUrl(BuildConfig.API_BASE_URL)
+        .client(OkHttpClient.Builder().build())
+        .addConverterFactory(MoshiConverterFactory.create(moshi))
+        .build()
+        .create(MobileInspectionOpenApi::class.java)
+
+    suspend fun areas(): MobilePlanningAssetResponse = authorized { session ->
+        api.areas("Bearer ${session.accessToken}")
+    }
+
+    suspend fun operators(areaId: String): MobilePlanningAssetResponse = authorized { session ->
+        api.operators("Bearer ${session.accessToken}", areaId)
+    }
+
+    suspend fun open(areaId: String, companyId: String): VisitDetail = authorized { session ->
+        api.open(
+            "Bearer ${session.accessToken}",
+            OpenMobileInspectionRequest(areaId, companyId),
+        )
+    }
+
+    private suspend fun <T> authorized(block: suspend (StoredSession) -> T): T {
+        var session = store.load() ?: throw IllegalStateException("Sesión no iniciada")
+        try {
+            return block(session)
+        } catch (error: HttpException) {
+            if (error.code() != 401) throw error
+        }
+        session = refresh(session.refreshToken)
+        return block(session)
+    }
+
+    private suspend fun refresh(previousRefreshToken: String): StoredSession = refreshMutex.withLock {
+        val latest = store.load() ?: throw IllegalStateException("Sesión no iniciada")
+        if (latest.refreshToken != previousRefreshToken) return@withLock latest
+        try {
+            store.save(api.refresh(RefreshRequest(previousRefreshToken)))
+        } catch (error: Throwable) {
+            store.clear()
+            throw error
+        }
+    }
+}

android-app/app/src/main/java/com/korexlabs/dhinspeccion/ui/LoginGate.kt

@@ -92,7 +92,7 @@ fun DhRoot(model: MainViewModel, activity: FragmentActivity) {
                 )
                 model.fieldFindingOptions != null -> FieldFindingScreen(model)
                 model.visit != null -> F3VisitRoot(model)
-                else -> DhApp(model)
+                else -> MobileHomeScreen(model)
             }
         }
     }

android-app/app/src/main/java/com/korexlabs/dhinspeccion/ui/MobileHomeScreen.kt

@@ -0,0 +1,231 @@
+package com.korexlabs.dhinspeccion.ui
+
+import androidx.compose.foundation.layout.Arrangement
+import androidx.compose.foundation.layout.Box
+import androidx.compose.foundation.layout.Column
+import androidx.compose.foundation.layout.Row
+import androidx.compose.foundation.layout.Spacer
+import androidx.compose.foundation.layout.fillMaxSize
+import androidx.compose.foundation.layout.fillMaxWidth
+import androidx.compose.foundation.layout.height
+import androidx.compose.foundation.layout.padding
+import androidx.compose.foundation.layout.width
+import androidx.compose.foundation.lazy.LazyColumn
+import androidx.compose.foundation.lazy.LazyRow
+import androidx.compose.foundation.lazy.items
+import androidx.compose.material3.AssistChip
+import androidx.compose.material3.Button
+import androidx.compose.material3.Card
+import androidx.compose.material3.CircularProgressIndicator
+import androidx.compose.material3.MaterialTheme
+import androidx.compose.material3.OutlinedButton
+import androidx.compose.material3.Text
+import androidx.compose.runtime.Composable
+import androidx.compose.runtime.LaunchedEffect
+import androidx.compose.runtime.getValue
+import androidx.compose.runtime.mutableStateOf
+import androidx.compose.runtime.remember
+import androidx.compose.runtime.rememberCoroutineScope
+import androidx.compose.runtime.saveable.rememberSaveable
+import androidx.compose.runtime.setValue
+import androidx.compose.ui.Alignment
+import androidx.compose.ui.Modifier
+import androidx.compose.ui.platform.LocalContext
+import androidx.compose.ui.text.font.FontWeight
+import androidx.compose.ui.unit.dp
+import com.korexlabs.dhinspeccion.MainViewModel
+import com.korexlabs.dhinspeccion.data.DhRepository
+import com.korexlabs.dhinspeccion.data.MobileInspectionOpenRepository
+import com.korexlabs.dhinspeccion.data.MobilePlanningAsset
+import com.korexlabs.dhinspeccion.data.VisitSummary
+import kotlinx.coroutines.launch
+
+@Composable
+fun MobileHomeScreen(model: MainViewModel) {
+    val session = model.session ?: return
+    val context = LocalContext.current
+    val scope = rememberCoroutineScope()
+    val openRepository = remember(context) { MobileInspectionOpenRepository(context) }
+
+    var showOpen by rememberSaveable { mutableStateOf(false) }
+    var areas by remember { mutableStateOf<List<MobilePlanningAsset>>(emptyList()) }
+    var operators by remember { mutableStateOf<List<MobilePlanningAsset>>(emptyList()) }
+    var selectedAreaId by rememberSaveable { mutableStateOf<String?>(null) }
+    var selectedCompanyId by rememberSaveable { mutableStateOf<String?>(null) }
+    var loadingContext by remember { mutableStateOf(false) }
+    var opening by remember { mutableStateOf(false) }
+    var localError by remember { mutableStateOf<String?>(null) }
+
+    fun loadAreas() {
+        scope.launch {
+            loadingContext = true
+            localError = null
+            runCatching { openRepository.areas().data }
+                .onSuccess { areas = it }
+                .onFailure { localError = DhRepository.humanError(it) }
+            loadingContext = false
+        }
+    }
+
+    fun chooseArea(areaId: String) {
+        selectedAreaId = areaId
+        selectedCompanyId = null
+        operators = emptyList()
+        scope.launch {
+            loadingContext = true
+            localError = null
+            runCatching { openRepository.operators(areaId).data }
+                .onSuccess { operators = it }
+                .onFailure { localError = DhRepository.humanError(it) }
+            loadingContext = false
+        }
+    }
+
+    LaunchedEffect(showOpen) {
+        if (showOpen && areas.isEmpty()) loadAreas()
+    }
+
+    Column(Modifier.fillMaxSize().padding(top = 28.dp)) {
+        Row(
+            Modifier.fillMaxWidth().padding(horizontal = 16.dp, vertical = 10.dp),
+            verticalAlignment = Alignment.CenterVertically,
+            horizontalArrangement = Arrangement.SpaceBetween,
+        ) {
+            Column {
+                Text("Mis inspecciones", style = MaterialTheme.typography.headlineSmall, fontWeight = FontWeight.Bold)
+                Text(session.displayName, style = MaterialTheme.typography.bodySmall)
+            }
+            Row {
+                OutlinedButton(onClick = { model.loadVisits() }, enabled = !model.busy && !opening) {
+                    Text("Actualizar")
+                }
+                Spacer(Modifier.width(8.dp))
+                OutlinedButton(onClick = { model.logout() }, enabled = !opening) { Text("Salir") }
+            }
+        }
+
+        Column(
+            Modifier.fillMaxWidth().padding(horizontal = 16.dp),
+            verticalArrangement = Arrangement.spacedBy(10.dp),
+        ) {
+            model.error?.let { Text(it, color = MaterialTheme.colorScheme.error) }
+            model.notice?.let { Text(it, color = MaterialTheme.colorScheme.primary) }
+            localError?.let { Text(it, color = MaterialTheme.colorScheme.error) }
+
+            Button(
+                onClick = {
+                    showOpen = !showOpen
+                    localError = null
+                },
+                modifier = Modifier.fillMaxWidth(),
+                enabled = !opening,
+            ) {
+                Text(if (showOpen) "Cancelar nueva inspección" else "Abrir inspección")
+            }
+
+            if (showOpen) {
+                Card(Modifier.fillMaxWidth()) {
+                    Column(
+                        Modifier.fillMaxWidth().padding(14.dp),
+                        verticalArrangement = Arrangement.spacedBy(10.dp),
+                    ) {
+                        Text("Abrir inspección en campo", style = MaterialTheme.typography.titleMedium, fontWeight = FontWeight.Bold)
+                        Text(
+                            "Elegí el Área y la Operadora vigente. La inspección se crea autoasignada a vos y queda iniciada con la fecha y hora del servidor.",
+                            style = MaterialTheme.typography.bodySmall,
+                        )
+
+                        Text("1. Área", fontWeight = FontWeight.SemiBold)
+                        if (loadingContext && areas.isEmpty()) CircularProgressIndicator()
+                        LazyRow(horizontalArrangement = Arrangement.spacedBy(8.dp)) {
+                            items(areas, key = { it.id }) { area ->
+                                AssistChip(
+                                    onClick = { chooseArea(area.id) },
+                                    label = { Text(if (area.id == selectedAreaId) "✓ ${area.name}" else area.name) },
+                                )
+                            }
+                        }
+
+                        if (selectedAreaId != null) {
+                            Text("2. Operadora", fontWeight = FontWeight.SemiBold)
+                            if (loadingContext && operators.isEmpty()) {
+                                CircularProgressIndicator()
+                            } else if (operators.isEmpty()) {
+                                Text("No hay una Operadora vigente para el Área seleccionada.", color = MaterialTheme.colorScheme.error)
+                            }
+                            LazyRow(horizontalArrangement = Arrangement.spacedBy(8.dp)) {
+                                items(operators, key = { it.id }) { company ->
+                                    AssistChip(
+                                        onClick = { selectedCompanyId = company.id },
+                                        label = { Text(if (company.id == selectedCompanyId) "✓ ${company.name}" else company.name) },
+                                    )
+                                }
+                            }
+                        }
+
+                        Button(
+                            onClick = {
+                                val areaId = selectedAreaId ?: return@Button
+                                val companyId = selectedCompanyId ?: return@Button
+                                scope.launch {
+                                    opening = true
+                                    localError = null
+                                    runCatching { openRepository.open(areaId, companyId) }
+                                        .onSuccess { opened ->
+                                            showOpen = false
+                                            model.openVisit(opened.id)
+                                        }
+                                        .onFailure { localError = DhRepository.humanError(it) }
+                                    opening = false
+                                }
+                            },
+                            modifier = Modifier.fillMaxWidth(),
+                            enabled = selectedAreaId != null && selectedCompanyId != null && !opening && !loadingContext,
+                        ) {
+                            Text(if (opening) "Abriendo…" else "Abrir inspección ahora")
+                        }
+                    }
+                }
+            }
+        }
+
+        if (model.busy && model.visits.isEmpty()) {
+            Box(Modifier.fillMaxSize(), contentAlignment = Alignment.Center) { CircularProgressIndicator() }
+        } else if (model.visits.isEmpty()) {
+            Box(Modifier.fillMaxSize(), contentAlignment = Alignment.Center) {
+                Text("No tenés inspecciones asignadas. Podés abrir una nueva desde esta tablet.")
+            }
+        } else {
+            LazyColumn(
+                Modifier.fillMaxSize().padding(horizontal = 16.dp, vertical = 10.dp),
+                verticalArrangement = Arrangement.spacedBy(10.dp),
+            ) {
+                items(model.visits, key = { it.id }) { visit ->
+                    MobileVisitCard(visit) { model.openVisit(visit.id) }
+                }
+                item { Spacer(Modifier.height(24.dp)) }
+            }
+        }
+    }
+}
+
+@Composable
+private fun MobileVisitCard(visit: VisitSummary, onOpen: () -> Unit) {
+    Card(onClick = onOpen, modifier = Modifier.fillMaxWidth()) {
+        Column(Modifier.padding(14.dp), verticalArrangement = Arrangement.spacedBy(5.dp)) {
+            Row(Modifier.fillMaxWidth(), horizontalArrangement = Arrangement.SpaceBetween) {
+                Text(visit.code, fontWeight = FontWeight.Bold)
+                Text(visit.status)
+            }
+            Text(visit.operatorCompany?.name ?: "Operadora sin definir")
+            Text(visit.operationalArea?.name ?: "Área sin definir", style = MaterialTheme.typography.bodySmall)
+            visit.plannedStartAt?.let {
+                Text("Prevista: ${it.replace('T', ' ').take(16)}", style = MaterialTheme.typography.bodySmall)
+            }
+            Text(
+                "Inventario: ${visit.assetCount} · Equipo inspector: ${visit.memberCount}",
+                style = MaterialTheme.typography.bodySmall,
+            )
+        }
+    }
+}

api-v3/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dhv2-api",
-  "version": "0.28.0-1",
+  "version": "0.29.0-1",
   "private": true,
   "license": "UNLICENSED",
   "scripts": {

api-v3/src/asset-master/dto/create-inventory-structure.dto.ts

@@ -9,6 +9,8 @@ import {
   MinLength,
 } from 'class-validator';
 
+// Invariante de dominio: Empresa es un maestro independiente. La jerarquía física
+// se expresa sólo como Departamento → Área → Yacimiento → Instalación → Subinstalación.
 export const INVENTORY_STRUCTURE_KINDS = [
   'EMPRESA',
   'DEPARTAMENTO',

api-v3/src/database/entities/inspection-act.entity.ts

@@ -30,6 +30,8 @@ export enum InspectionDeadlineBasis {
   GEDO_DATE = 'GEDO_DATE',
 }
 
+// Una Inspección puede acumular múltiples Actas. El índice parcial de DRAFT es
+// deliberado: permite el historial multi-Acta y bloquea dos borradores simultáneos.
 @Entity({ name: 'inspection_acts' })
 @Index('uq_inspection_acts_one_draft_per_visit', ['visitId'], { unique: true, where: "status = 'DRAFT'" })
 @Index('uq_inspection_acts_year_number', ['actYear', 'actNumber'], { unique: true })

api-v3/src/inspection-findings/f3-finding-catalog-resolver.service.ts

@@ -1,10 +1,14 @@
 import { Injectable, NotFoundException } from '@nestjs/common';
 import { DataSource } from 'typeorm';
 import type { ListFindingCatalogQueryDto } from './dto/list-finding-catalog-query.dto';
+import { FindingCatalogService } from './finding-catalog.service';
 
 @Injectable()
 export class F3FindingCatalogResolverService {
-  constructor(private readonly dataSource: DataSource) {}
+  constructor(
+    private readonly dataSource: DataSource,
+    private readonly contextualCatalog: FindingCatalogService,
+  ) {}
 
   async listApplicableForAsset(assetId: string, query: ListFindingCatalogQueryDto) {
     const [asset] = await this.dataSource.query(`
@@ -36,17 +40,28 @@ export class F3FindingCatalogResolverService {
       enabled: true,
       code: 'OTHER',
       label: 'OTROS',
-      help: 'Usalo cuando el Hallazgo no exista entre los asociados a esta clasificación. Quedará registrado para revisión en oficina.',
+      help: 'Usalo cuando el Hallazgo no exista entre los asociados a este Inventario. Quedará registrado para revisión en oficina.',
     };
 
+    if (asset.typeCode.toLowerCase() === 'yacimiento') {
+      const contextual = await this.contextualCatalog.listApplicableForAsset(assetId, query);
+      return {
+        ...contextual,
+        inventoryFamily: null,
+        catalogSource: 'ASSET_TYPE' as const,
+        configurationReason: contextual.configurationReason
+          ?? 'Hallazgos asociados al tipo Yacimiento. OTROS permanece siempre disponible.',
+        other,
+      };
+    }
+
     if (!asset.familyId || asset.familyActive !== true) {
       return {
         asset: { id: asset.id, code: asset.code, name: asset.name },
         inventoryFamily: null,
+        catalogSource: 'INVENTORY_FAMILY' as const,
         typeConfigured: false,
-        configurationReason: asset.typeCode.toLowerCase() === 'yacimiento'
-          ? 'El Yacimiento es contexto estructural y no posee clasificación técnica. Usá OTROS sólo si necesitás registrar una observación excepcional.'
-          : 'El elemento todavía no tiene una clasificación técnica activa.',
+        configurationReason: 'El elemento todavía no tiene una clasificación técnica activa.',
         categories: [],
         items: [],
         other,
@@ -103,6 +118,7 @@ export class F3FindingCatalogResolverService {
         name: asset.familyName,
         level: asset.familyLevel,
       },
+      catalogSource: 'INVENTORY_FAMILY' as const,
       typeConfigured: true,
       configurationReason: `Hallazgos asociados a la clasificación técnica ${asset.familyName ?? asset.familyCode ?? ''}`.trim(),
       categories,

api-v3/src/inspection-visits/dto/open-mobile-inspection.dto.ts

@@ -0,0 +1,9 @@
+import { IsUUID } from 'class-validator';
+
+export class OpenMobileInspectionDto {
+  @IsUUID('4')
+  operationalAreaId!: string;
+
+  @IsUUID('4')
+  operatorCompanyId!: string;
+}

api-v3/src/inspection-visits/field-findings.service.ts

@@ -265,13 +265,14 @@ export class FieldFindingsService {
         message: 'Registro de Inventario no encontrado',
       });
     }
-    if (!['instalacion', 'subinstalacion'].includes(String(row.assetTypeCode).toLowerCase())) {
+    const assetTypeCode = String(row.assetTypeCode).toLowerCase();
+    if (!['yacimiento', 'instalacion', 'subinstalacion'].includes(assetTypeCode)) {
       throw new BadRequestException({
-        code: 'FIELD_FINDING_TECHNICAL_LEVEL_REQUIRED',
-        message: 'Los Hallazgos se registran sobre una Instalación o Subinstalación, no sobre Área/Yacimiento',
+        code: 'FIELD_FINDING_TARGET_LEVEL_INVALID',
+        message: 'Los Hallazgos pueden registrarse sobre Yacimiento, Instalación o Subinstalación',
       });
     }
-    if (!row.inventoryFamilyId) {
+    if (assetTypeCode !== 'yacimiento' && !row.inventoryFamilyId) {
       throw new ConflictException({
         code: 'FIELD_FINDING_FAMILY_REQUIRED',
         message: 'La Instalación/Subinstalación debe tener una clasificación técnica antes de registrar Hallazgos',

api-v3/src/inspection-visits/inspection-visit-lifecycle.service.ts

@@ -295,11 +295,13 @@ export class InspectionVisitLifecycleService {
     }
   }
 
+  // El contexto operativo de una Inspección es Área + Operadora vigente. El
+  // Yacimiento pertenece al alcance físico y nunca reemplaza al Área raíz.
   private async validatePlanningContext(manager: EntityManager, visit: InspectionVisit): Promise<void> {
     if (!visit.operationalAreaId || !visit.operatorCompanyId || !visit.leadInspectorUserId || !visit.plannedStartAt) {
       throw new ConflictException({
         code: 'INSPECTION_PLANNING_INCOMPLETE',
-        message: 'Definí Área/Yacimiento, Operadora, Inspector responsable y fecha de inicio antes de planificar',
+        message: 'Definí Área, Operadora, Inspector responsable y fecha de inicio antes de planificar',
       });
     }
     if (!visit.checklistGeneratedAt || visit.checklistGeneration < 1) {
@@ -320,7 +322,7 @@ export class InspectionVisitLifecycleService {
     if (!relation) {
       throw new ConflictException({
         code: 'INSPECTION_OPERATOR_RELATION_INVALID',
-        message: 'La Operadora seleccionada no tiene una relación operativa vigente con el Área/Yacimiento',
+        message: 'La Operadora seleccionada no tiene una relación operativa vigente con el Área',
       });
     }
     const [inspector] = await manager.query(`

api-v3/src/inspection-visits/inspection-visits.controller.ts

@@ -13,11 +13,13 @@ import {
 import { CurrentAuth } from '../auth/decorators/current-auth.decorator';
 import { RequirePermissions } from '../authorization/decorators/require-permissions.decorator';
 import type { AuthPrincipal, RequestWithContext } from '../common/http/request-context';
+import { assertMobileInspector } from '../inspection-operations/mobile-inspector-policy';
 import { CancelInspectionVisitDto } from './dto/cancel-inspection-visit.dto';
 import { CloseInspectionVisitDto } from './dto/close-inspection-visit.dto';
 import { CreateInspectionVisitDto } from './dto/create-inspection-visit.dto';
 import { ExcludeInspectionVisitAssetDto } from './dto/exclude-inspection-visit-asset.dto';
 import { ListInspectionVisitsQueryDto } from './dto/list-inspection-visits-query.dto';
+import { OpenMobileInspectionDto } from './dto/open-mobile-inspection.dto';
 import { ReplaceInspectionVisitAssetsDto } from './dto/replace-inspection-visit-assets.dto';
 import { ReplaceInspectionVisitTeamDto } from './dto/replace-inspection-visit-team.dto';
 import { UpdateInspectionVisitDto } from './dto/update-inspection-visit.dto';
@@ -57,6 +59,43 @@ export class InspectionVisitsController {
     return this.visits.listPlanningOperators(areaId);
   }
 
+  @Get('mobile/planning-context/areas')
+  @RequirePermissions('inspections.execute')
+  mobilePlanningAreas(@CurrentAuth() principal: AuthPrincipal) {
+    assertMobileInspector(principal);
+    return this.visits.listPlanningAreas();
+  }
+
+  @Get('mobile/planning-context/areas/:areaId/operators')
+  @RequirePermissions('inspections.execute')
+  mobilePlanningOperators(
+    @Param('areaId', new ParseUUIDPipe({ version: '4' })) areaId: string,
+    @CurrentAuth() principal: AuthPrincipal,
+  ) {
+    assertMobileInspector(principal);
+    return this.visits.listPlanningOperators(areaId);
+  }
+
+  @Post('mobile/open')
+  @RequirePermissions('inspections.execute')
+  async openMobile(
+    @Body() dto: OpenMobileInspectionDto,
+    @CurrentAuth() principal: AuthPrincipal,
+    @Req() request: RequestWithContext,
+  ) {
+    assertMobileInspector(principal);
+    // Android no tiene un lifecycle paralelo: crea la visita y delega las
+    // transiciones DRAFT → PLANNED → IN_PROGRESS a los servicios canónicos.
+    const created = await this.visits.create({
+      operationalAreaId: dto.operationalAreaId,
+      operatorCompanyId: dto.operatorCompanyId,
+      plannedStartAt: new Date().toISOString(),
+      leadInspectorUserId: principal.userId,
+    }, principal, request);
+    await this.lifecycle.plan(created.id, principal, request);
+    return this.lifecycle.start(created.id, principal, request);
+  }
+
   @Get(':id')
   @RequirePermissions('inspections.read')
   get(@Param('id', new ParseUUIDPipe({ version: '4' })) id: string) {

api-v3/src/version.ts

@@ -1,2 +1,2 @@
-export const API_VERSION = '0.28.0-1';
-export const API_PHASE = 'F6';
+export const API_VERSION = '0.29.0-1';
+export const API_PHASE = 'F6.1';

api-v3/test/unit/f4-health-metadata.test.ts

@@ -2,7 +2,7 @@ import assert from 'node:assert/strict';
 import test from 'node:test';
 import { API_PHASE, API_VERSION } from '../../src/version';
 
-test('health metadata reports the current F6 release', () => {
-  assert.equal(API_PHASE, 'F6');
-  assert.equal(API_VERSION, '0.28.0-1');
+test('health metadata reports the current F6.1 release', () => {
+  assert.equal(API_PHASE, 'F6.1');
+  assert.equal(API_VERSION, '0.29.0-1');
 });

api-v3/test/unit/f5-android-test-cut.test.ts

@@ -7,16 +7,16 @@ function mountedRepoFile(path: string): string {
   return readFileSync(resolve(process.cwd(), '..', path), 'utf8');
 }
 
-test('F6 Android test cut targets production API and has a distinct installable debug version', () => {
+test('F6.1 Android test cut targets production API and has a distinct installable debug version', () => {
   const gradle = mountedRepoFile('android-app/app/build.gradle.kts');
 
-  assert.match(gradle, /versionCode = 21/);
-  assert.match(gradle, /versionName = "0\.14\.0"/);
+  assert.match(gradle, /versionCode = 22/);
+  assert.match(gradle, /versionName = "0\.15\.0"/);
   assert.match(gradle, /https:\/\/dhv2\.korexlabs\.com\/api\/v3\//);
   assert.match(gradle, /applicationIdSuffix = "\.debug"/);
 });
 
-test('F5/F6 field inventory exposes Other families as reviewable choices to Android', () => {
+test('F5/F6.1 field inventory exposes Other families as reviewable choices to Android', () => {
   const service = readFileSync(
     resolve(process.cwd(), 'src/inspection-visits/f3-field-inventory-structure.service.ts'),
     'utf8',

api-v3/test/unit/f6-1-findings-mobile-open.test.ts

@@ -0,0 +1,67 @@
+import assert from 'node:assert/strict';
+import { readFileSync } from 'node:fs';
+import { resolve } from 'node:path';
+import test from 'node:test';
+
+function source(path: string) {
+  return readFileSync(resolve(process.cwd(), path), 'utf8');
+}
+
+test('F6.1 allows direct findings only on Yacimiento, Instalacion and Subinstalacion', () => {
+  const findings = source('src/inspection-visits/field-findings.service.ts');
+
+  assert.match(findings, /\['yacimiento', 'instalacion', 'subinstalacion'\]\.includes\(assetTypeCode\)/);
+  assert.match(findings, /FIELD_FINDING_TARGET_LEVEL_INVALID/);
+  assert.match(findings, /Los Hallazgos pueden registrarse sobre Yacimiento, Instalación o Subinstalación/);
+  assert.match(findings, /assetTypeCode !== 'yacimiento' && !row\.inventoryFamilyId/);
+  assert.match(findings, /FIELD_FINDING_FAMILY_REQUIRED/);
+});
+
+test('F6.1 uses contextual type catalog for Yacimiento and keeps OTROS/add-another everywhere', () => {
+  const findings = source('src/inspection-visits/field-findings.service.ts');
+  const resolver = source('src/inspection-findings/f3-finding-catalog-resolver.service.ts');
+  const catalog = source('src/inspection-findings/finding-catalog.service.ts');
+  const androidFinding = source('../android-app/app/src/main/java/com/korexlabs/dhinspeccion/ui/FieldFindingScreen.kt');
+
+  assert.match(findings, /canAddAnother: true/);
+  assert.match(resolver, /typeCode\.toLowerCase\(\) === 'yacimiento'/);
+  assert.match(resolver, /contextualCatalog\.listApplicableForAsset\(assetId, query\)/);
+  assert.match(resolver, /catalogSource: 'ASSET_TYPE'/);
+  assert.match(catalog, /finding_catalog_item_asset_types mapping/);
+  assert.match(catalog, /finding_catalog_asset_overrides override/);
+  assert.match(resolver, /code: 'OTHER'/);
+  assert.match(resolver, /label: 'OTROS'/);
+  assert.match(androidFinding, /OTROS · No está en el catálogo/);
+  assert.match(androidFinding, /También podés registrar otro Hallazgo sobre el mismo Inventario/);
+});
+
+test('F6.1 exposes mobile planning context and opens an inspection self-assigned to the current inspector', () => {
+  const controller = source('src/inspection-visits/inspection-visits.controller.ts');
+  const dto = source('src/inspection-visits/dto/open-mobile-inspection.dto.ts');
+
+  assert.match(controller, /@Get\('mobile\/planning-context\/areas'\)/);
+  assert.match(controller, /@Get\('mobile\/planning-context\/areas\/:areaId\/operators'\)/);
+  assert.match(controller, /@Post\('mobile\/open'\)/);
+  assert.match(controller, /@RequirePermissions\('inspections\.execute'\)/);
+  assert.match(controller, /assertMobileInspector\(principal\)/);
+  assert.match(controller, /leadInspectorUserId: principal\.userId/);
+  assert.match(controller, /plannedStartAt: new Date\(\)\.toISOString\(\)/);
+  assert.match(controller, /this\.lifecycle\.plan\(created\.id/);
+  assert.match(controller, /this\.lifecycle\.start\(created\.id/);
+  assert.match(dto, /operationalAreaId!: string/);
+  assert.match(dto, /operatorCompanyId!: string/);
+});
+
+test('F6.1 Android lets the inspector choose Area and current Operator and open the inspection now', () => {
+  const client = source('../android-app/app/src/main/java/com/korexlabs/dhinspeccion/data/MobileInspectionOpen.kt');
+  const home = source('../android-app/app/src/main/java/com/korexlabs/dhinspeccion/ui/MobileHomeScreen.kt');
+  const gate = source('../android-app/app/src/main/java/com/korexlabs/dhinspeccion/ui/LoginGate.kt');
+
+  assert.match(client, /inspection-visits\/mobile\/planning-context\/areas/);
+  assert.match(client, /inspection-visits\/mobile\/open/);
+  assert.match(home, /Abrir inspección/);
+  assert.match(home, /Abrir inspección ahora/);
+  assert.match(home, /Operadora vigente/);
+  assert.match(home, /model\.openVisit\(opened\.id\)/);
+  assert.match(gate, /else -> MobileHomeScreen\(model\)/);
+});

api-v3/test/unit/f6-1-project-invariants.test.ts

@@ -0,0 +1,71 @@
+import assert from 'node:assert/strict';
+import { readFileSync } from 'node:fs';
+import { resolve } from 'node:path';
+import test from 'node:test';
+
+function source(path: string): string {
+  return readFileSync(resolve(process.cwd(), path), 'utf8');
+}
+
+test('F6.1 conserva una jerarquía territorial única y Empresa fuera del árbol físico', () => {
+  const structure = source('src/asset-master/inventory-structure.service.ts');
+  const dto = source('src/asset-master/dto/create-inventory-structure.dto.ts');
+
+  assert.match(dto, /'EMPRESA',[\s\S]*'DEPARTAMENTO',[\s\S]*'AREA',[\s\S]*'YACIMIENTO',[\s\S]*'INSTALACION',[\s\S]*'SUBINSTALACION'/);
+  assert.match(structure, /EMPRESA:\s*null/);
+  assert.match(structure, /DEPARTAMENTO:\s*null/);
+  assert.match(structure, /AREA:\s*'departamento'/);
+  assert.match(structure, /YACIMIENTO:\s*'area'/);
+  assert.match(structure, /INSTALACION:\s*'yacimiento'/);
+  assert.match(structure, /SUBINSTALACION:\s*'instalacion'/);
+  assert.match(structure, /Departamento → Área → Yacimiento → Instalación → Subinstalación/);
+});
+
+test('F6.1 usa Área + Operadora como contexto de planificación y no mezcla Yacimiento con Área', () => {
+  const lifecycle = source('src/inspection-visits/inspection-visit-lifecycle.service.ts');
+  const visits = source('src/inspection-visits/inspection-visits.service.ts');
+
+  assert.match(lifecycle, /El contexto operativo de una Inspección es Área \+ Operadora vigente/);
+  assert.doesNotMatch(lifecycle, /Área\/Yacimiento/);
+  assert.match(visits, /FROM area_company_relations/);
+  assert.match(visits, /relation\.relation_role = 'OPERATOR'/);
+});
+
+test('F6.1 mantiene múltiples Actas por Inspección pero un solo borrador simultáneo', () => {
+  const act = source('src/database/entities/inspection-act.entity.ts');
+  const lifecycle = source('src/inspection-visits/inspection-visit-lifecycle.service.ts');
+
+  assert.match(act, /uq_inspection_acts_one_draft_per_visit/);
+  assert.match(act, /where: "status = 'DRAFT'"/);
+  assert.match(act, /Una Inspección puede acumular múltiples Actas/);
+  assert.match(lifecycle, /Todas las Actas deben estar SELLADAS antes de cerrar la Inspección/);
+});
+
+test('F6.1 permite Hallazgos directos sólo en Yacimiento, Instalación y Subinstalación y conserva OTROS', () => {
+  const field = source('src/inspection-visits/field-findings.service.ts');
+  const resolver = source('src/inspection-findings/f3-finding-catalog-resolver.service.ts');
+
+  assert.match(field, /\['yacimiento', 'instalacion', 'subinstalacion'\]\.includes\(assetTypeCode\)/);
+  assert.match(field, /assetTypeCode !== 'yacimiento' && !row\.inventoryFamilyId/);
+  assert.match(field, /canAddAnother: true/);
+  assert.match(resolver, /code: 'OTHER'/);
+  assert.match(resolver, /label: 'OTROS'/);
+});
+
+test('F6.1 abre Inspecciones desde Android usando el lifecycle canónico', () => {
+  const controller = source('src/inspection-visits/inspection-visits.controller.ts');
+
+  assert.match(controller, /@Post\('mobile\/open'\)/);
+  assert.match(controller, /leadInspectorUserId: principal\.userId/);
+  assert.match(controller, /this\.lifecycle\.plan\(created\.id/);
+  assert.match(controller, /this\.lifecycle\.start\(created\.id/);
+});
+
+test('F6.1 separa oficialización GEDO de la activación del vencimiento no urgente', () => {
+  const report = source('src/inspection-reports/inspection-report-workflow.service.ts');
+  const act = source('src/database/entities/inspection-act.entity.ts');
+
+  assert.match(report, /GEDO oficializa el INF, pero no equivale por sí solo a la notificación/);
+  assert.match(report, /deadlineActivation: 'PENDING_NOTIFICATION_EVENT'/);
+  assert.match(act, /NOTIFICATION_DATE = 'GEDO_DATE'/);
+});

docs/AUDITORIA_CONSISTENCIA_F6_1.md

@@ -0,0 +1,91 @@
+# Auditoría de consistencia · F6.1
+
+**Baseline revisado:** `25a63cd3d4b2c561803cc5105cce100983c8eeff`  
+**Alcance:** API, modelo de datos, Inventarios, Inspecciones, Actas, Hallazgos, Informes/GEDO, WEB, Android, permisos, versionado documental y CI.
+
+## Resultado
+
+El modelo funcional consolidado de F6.1 es coherente. No se detectó una contradicción estructural que requiera rediseñar tablas o migrar datos antes de continuar.
+
+La auditoría sí encontró deuda de terminología/documentación y una inconsistencia de metadata generada. Las correcciones funcionales/documentales se integran en esta rama; la metadata de lockfiles se documenta como observación no funcional y debe regenerarse con npm en un corte controlado, no editarse parcialmente a mano.
+
+## Contratos verificados
+
+### Inventario
+
+- Jerarquía física única: Departamento → Área → Yacimiento → Instalación → Subinstalación.
+- Empresa es un maestro independiente.
+- Operadora vigente se resuelve por relación temporal Área ⇄ Empresa.
+- Cambiar Operadora no reparenta Inventario.
+- Departamento, Área y Yacimiento no llevan familia técnica.
+- Instalación y Subinstalación requieren familia técnica.
+- Subinstalación debe ser compatible con la familia de la Instalación padre.
+- PostgreSQL protege jerarquía y compatibilidad, además de las validaciones de API.
+
+### Inspecciones
+
+- Lifecycle canónico DRAFT → PLANNED → IN_PROGRESS → CLOSED.
+- Planificación requiere Área, Operadora vigente, Inspector responsable, fecha/hora y checklist.
+- La APK abre una Inspección reutilizando el mismo create/plan/start; no existe un lifecycle móvil paralelo.
+- No hay referencias activas a `plannedEndAt` / `planned_end_at` en el código actual.
+
+### Actas
+
+- Una Inspección puede contener múltiples Actas.
+- El constraint histórico de una sola Acta por visita fue eliminado por F1.1.
+- Existe un índice parcial que permite sólo un Acta DRAFT simultánea por Inspección.
+- El cierre de la Inspección exige que todas las Actas no canceladas estén SELLADAS.
+- El Acta finalizada/bloqueada es inmutable.
+
+### Hallazgos
+
+- Destinos directos: Yacimiento, Instalación y Subinstalación.
+- Departamento y Área no son destinos directos.
+- OTROS / Agregar otro permanece disponible.
+- Yacimiento no requiere familia técnica.
+- Instalación/Subinstalación sí requieren clasificación.
+- Inventario nacido en campo necesita GPS + foto antes de admitir Hallazgos.
+
+### Informes / GEDO
+
+- El Informe pertenece al Acta.
+- La oficialización GEDO/IF es inmutable.
+- Oficializar en GEDO no activa por sí solo el vencimiento No urgente.
+- El valor persistido histórico `GEDO_DATE` se conserva como ABI de base; en código existe el alias semántico `NOTIFICATION_DATE` para evitar interpretar GEDO como notificación automática.
+
+## Correcciones integradas en la auditoría
+
+1. Se corrigió la terminología residual `Área/Yacimiento` en el lifecycle de Inspecciones. El contexto operativo queda definido inequívocamente como **Área + Operadora vigente**.
+2. Se documentó en código la separación entre Empresa y la jerarquía física del Inventario.
+3. Se documentó en la entidad Acta el contrato multi-Acta + único DRAFT simultáneo.
+4. Se agregó un test transversal F6.1 que protege jerarquía, contexto operativo, multi-Acta, Hallazgos, apertura móvil y separación GEDO/vencimiento.
+5. Se consolidó `docs/F6_INVENTORY_MODEL.md` como única referencia viva y los duplicados históricos apuntan a ella.
+6. Se crearon `MANUAL_PROGRAMADOR.md` y `MANUAL_USUARIO.md`.
+
+## Compatibilidades históricas que NO deben “limpiarse” sin migración
+
+- Migraciones antiguas conservan nombres y reglas que fueron válidas en fases anteriores. No se modifican; migraciones posteriores son las que expresan la evolución.
+- `InspectionDeadlineBasis.GEDO_DATE` comparte valor persistido con `NOTIFICATION_DATE` por compatibilidad de esquema.
+- `assets.operator_company_id` puede conservar una fotografía de compatibilidad incluso cuando la relación temporal ya finalizó. La fuente de verdad vigente/histórica sigue siendo `area_company_relations`.
+- F5.1 es una migración destructiva de inicio limpio y no tiene `down()` reconstructivo; su rollback es el backup PRE.
+
+## Observación no funcional: metadata de package-lock
+
+Los `package.json` actuales declaran las versiones de producto vigentes, pero la metadata `name/version` de la raíz de ambos `package-lock.json` todavía conserva `0.20.0-2` de un corte anterior.
+
+Esto no cambia el grafo de dependencias ni el runtime y `npm ci` continúa siendo la barrera de instalación. Se deja explícitamente registrado para no ocultarlo.
+
+**Tratamiento correcto:** regenerar cada lockfile con npm (`npm install --package-lock-only`) cuando se haga el próximo corte controlado de metadata/dependencias y verificar el diff completo. No editar manualmente sólo las primeras líneas del lockfile.
+
+## Criterio de aceptación de esta auditoría
+
+Antes de mergear esta rama deben pasar nuevamente:
+
+- API typecheck + tests + build.
+- WEB typecheck + contrato + build.
+- migraciones sobre PostGIS limpio.
+- preflight aislado equivalente al VPS.
+- build de imágenes productivas.
+- Android assemble + unit tests cuando el workflow se dispare por el PR.
+
+La rama de documentación/consistencia no debe promoverse a `deploy` durante esta revisión. El despliegue queda deliberadamente pausado.

docs/F6_INVENTORY_MODEL.md

@@ -1 +1,131 @@
-# F6 · Modelo definitivo de Inventarios
+# F6.1 · Modelo canónico de Inventarios
+
+Este documento es la referencia funcional y técnica del modelo de Inventarios de DH Inspección V2. Ante una contradicción con documentación histórica, prevalecen este documento, las migraciones vigentes y los contratos automatizados de F6.1.
+
+## 1. Jerarquía física
+
+La estructura territorial y física es única:
+
+**Departamento → Área → Yacimiento → Instalación → Subinstalación**
+
+Reglas:
+
+- `Departamento` es raíz.
+- `Área` requiere un Departamento padre.
+- `Yacimiento` requiere un Área padre.
+- `Instalación` requiere un Yacimiento padre.
+- `Subinstalación` requiere una Instalación padre.
+- La base de datos rechaza combinaciones de padre/hijo que no respeten esta secuencia.
+- El campo `parent_id` expresa exclusivamente esta pertenencia física.
+
+## 2. Empresa no pertenece al árbol físico
+
+`Empresa` es un maestro independiente. No es padre de Departamento, Área, Yacimiento, Instalación ni Subinstalación.
+
+La Operadora vigente de un Área se expresa mediante `area_company_relations`, con `relation_role = 'OPERATOR'` y vigencia temporal. Esta relación es la fuente de verdad para saber qué Empresa opera un Área en una fecha determinada.
+
+`assets.operator_company_id` puede existir como fotografía de compatibilidad del contexto actual, pero no debe utilizarse para reconstruir la historia ni para reparentar Inventario.
+
+**Cambiar de Operadora nunca mueve la jerarquía física.** Se finaliza la relación temporal anterior y se crea la nueva relación Empresa ⇄ Área.
+
+## 3. Contexto transversal de Área
+
+Los elementos bajo un Área conservan `operational_area_id` como contexto transversal para consultas, planificación y trazabilidad. El Yacimiento forma parte del alcance físico, pero no sustituye al Área como contexto operativo de una Inspección.
+
+Por lo tanto, la planificación de una Inspección trabaja con:
+
+**Área + Operadora vigente + Inspector responsable + fecha/hora de inicio**.
+
+## 4. Clasificación técnica
+
+Los niveles territoriales no usan clasificación técnica:
+
+- Departamento: sin familia técnica.
+- Área: sin familia técnica.
+- Yacimiento: sin familia técnica.
+
+Los niveles físicos sí la requieren:
+
+- Instalación: una familia de nivel `INSTALLATION`.
+- Subinstalación: una familia de nivel `SUBINSTALLATION` compatible con la familia de la Instalación padre.
+
+La compatibilidad se almacena en `inventory_family_parent_rules` y se valida también en PostgreSQL. Una misma familia de Subinstalación puede ser compatible con varias familias de Instalación.
+
+Los campos técnicos específicos de cada familia se definen en `inventory_family_attribute_definitions` y sus valores por Inventario en `asset_inventory_attribute_values`.
+
+## 5. Hallazgos
+
+Un Hallazgo puede asignarse directamente a:
+
+- Yacimiento.
+- Instalación.
+- Subinstalación.
+
+No se asignan Hallazgos directos a Departamento ni Área.
+
+`OTROS / Agregar otro` debe estar siempre disponible. Permite describir un Hallazgo que no exista todavía en el catálogo aplicable y dejarlo registrado para revisión posterior.
+
+Para Yacimiento, la aplicabilidad del catálogo puede resolverse por tipo de Inventario y por excepciones del objeto concreto. Yacimiento no necesita una familia técnica para recibir Hallazgos.
+
+Instalación y Subinstalación deben estar clasificadas antes de recibir un Hallazgo.
+
+## 6. Inventario nacido en campo
+
+La APK puede incorporar Inventario encontrado durante una Inspección. Un registro creado en campo conserva su trazabilidad de origen y, antes de permitir Hallazgos sobre él, debe tener como mínimo:
+
+- GPS capturado para la creación.
+- al menos una fotografía de campo.
+- clasificación técnica cuando se trate de Instalación o Subinstalación.
+
+La excepción transitoria que permite crear un registro `FIELD_SURVEY + DRAFT` sin familia existe únicamente para completar la transacción de alta; no habilita Hallazgos sin clasificación.
+
+## 7. Carga manual recomendada
+
+El orden seguro para construir una estructura desde cero es:
+
+1. Crear las Empresas necesarias como maestros independientes.
+2. Crear Departamento.
+3. Crear Área dentro del Departamento.
+4. Registrar la Operadora vigente del Área, si ya se conoce.
+5. Crear Yacimiento dentro del Área.
+6. Crear Instalación dentro del Yacimiento y seleccionar su familia técnica.
+7. Crear Subinstalación dentro de la Instalación y seleccionar una familia compatible.
+
+La importación de archivos no debe definir la arquitectura del modelo. Los datos externos se adaptan a este contrato; el contrato no se deforma para adaptarse a cada planilla.
+
+## 8. Historia y consulta temporal
+
+DH conserva dos conceptos separados:
+
+- historia física/contextual del Inventario;
+- historia temporal de la relación Área ⇄ Empresa.
+
+Los cambios relevantes generan versiones y eventos de auditoría. Las consultas históricas deben utilizar la vigencia correspondiente a la fecha consultada, no sólo la fotografía actual de las columnas de `assets`.
+
+## 9. Barreras de integridad
+
+La consistencia no depende sólo de la interfaz. Se protege en varias capas:
+
+- DTO y servicios de API validan niveles y padres.
+- PostgreSQL valida la jerarquía canónica.
+- PostgreSQL valida nivel y compatibilidad de familias técnicas.
+- la planificación valida una relación Operadora ⇄ Área vigente.
+- los Hallazgos validan nivel permitido, clasificación técnica y pertenencia a la Inspección/Acta.
+- CI ejecuta la cadena completa de migraciones sobre PostGIS limpio y los contratos transversales.
+
+## 10. Corte limpio F5.1
+
+`F51CleanManualInventory1790087400000` fue un corte intencional de inicio limpio. Eliminó datos operativos/importados de desarrollo y dejó los maestros técnicos necesarios para reconstruir manualmente una estructura confiable.
+
+Es una migración deliberadamente no reversible mediante `migration:revert`. Su recuperación depende del backup PRE del despliegue. No debe copiarse este patrón para migraciones normales sin una decisión explícita y una estrategia de restauración probada.
+
+## 11. Regla para cambios futuros
+
+Cualquier modificación del modelo debe mantener simultáneamente:
+
+1. la jerarquía física canónica;
+2. Empresa fuera del árbol;
+3. relación temporal Área ⇄ Empresa como fuente de verdad operativa;
+4. compatibilidad técnica de familias;
+5. trazabilidad histórica;
+6. protección en base de datos y tests, no sólo en la UI.

docs/F6_INVENTORY_MODEL_FINAL.md

@@ -1,7 +1,5 @@
-# F6 · Modelo definitivo de Inventarios
+# F6 · Modelo de Inventarios
 
-La jerarquía física canónica es fija:
+Este archivo se conserva por compatibilidad con referencias históricas.
 
-Departamento → Área → Yacimiento → Instalación → Subinstalación
-
-Empresa es un maestro independiente y se relaciona temporalmente con Área.
+La documentación canónica y mantenida está en [`F6_INVENTORY_MODEL.md`](./F6_INVENTORY_MODEL.md).

docs/F6_INVENTORY_MODEL_FULL.md

@@ -1,7 +1,5 @@
-# F6 · Modelo definitivo de Inventarios
+# F6 · Modelo de Inventarios
 
-La jerarquía física canónica es fija:
+Este archivo se conserva por compatibilidad con referencias históricas.
 
-Departamento → Área → Yacimiento → Instalación → Subinstalación
-
-Empresa es un maestro independiente y se relaciona temporalmente con Área.
+La documentación canónica y mantenida está en [`F6_INVENTORY_MODEL.md`](./F6_INVENTORY_MODEL.md).

docs/MANUAL_PROGRAMADOR.md

@@ -0,0 +1,370 @@
+# Manual del Programador · DH Inspección V2
+
+**Baseline documental:** F6.1  
+**API:** 0.29.0-1  
+**WEB:** 0.23.0-1  
+**Android:** 0.15.0
+
+Este manual describe la arquitectura, las reglas que no deben romperse y el procedimiento seguro para modificar DH Inspección V2. No reemplaza los tests ni las restricciones de base de datos: los tres forman juntos el contrato del sistema.
+
+---
+
+## 1. Estructura del repositorio
+
+- `api-v3/`: API NestJS + TypeORM + PostgreSQL/PostGIS.
+- `web-v2/`: aplicación WEB React/Vite.
+- `android-app/`: aplicación Android Kotlin/Compose.
+- `scripts/`: despliegue, preflight y utilidades operativas.
+- `docs/`: documentación funcional y técnica viva.
+- `.github/workflows/`: CI de API/WEB/Docker y build/test de Android.
+
+El backend expone `/api/v3`. Los cambios de dominio deben resolverse primero en API/base de datos; WEB y Android consumen ese contrato y no deben inventar reglas paralelas.
+
+---
+
+## 2. Invariantes de dominio
+
+### 2.1 Inventario físico
+
+La jerarquía canónica es:
+
+**Departamento → Área → Yacimiento → Instalación → Subinstalación**
+
+`parent_id` expresa exclusivamente esa jerarquía. No agregue Empresa dentro de este árbol.
+
+### 2.2 Empresa y Operadora
+
+`Empresa` es un maestro independiente.
+
+La relación operativa vigente se modela en `area_company_relations`:
+
+- Área ↔ Empresa.
+- `relation_role = 'OPERATOR'` para la Operadora.
+- `valid_from` / `valid_until` para vigencia.
+
+Esta tabla es la fuente temporal de verdad. `assets.operator_company_id` es una fotografía de compatibilidad; nunca debe usarse como sustituto del historial.
+
+Cambiar Operadora no mueve Yacimientos, Instalaciones ni Subinstalaciones.
+
+### 2.3 Clasificación técnica
+
+- Departamento: sin familia.
+- Área: sin familia.
+- Yacimiento: sin familia.
+- Instalación: requiere familia `INSTALLATION`.
+- Subinstalación: requiere familia `SUBINSTALLATION` compatible con la Instalación padre.
+
+La compatibilidad está protegida por PostgreSQL, no sólo por la UI.
+
+### 2.4 Hallazgos
+
+Un Hallazgo directo sólo puede asignarse a:
+
+- Yacimiento.
+- Instalación.
+- Subinstalación.
+
+Departamento y Área no reciben Hallazgos directos.
+
+`OTROS / Agregar otro` debe permanecer disponible siempre. En Yacimiento no se exige familia técnica. En Instalación/Subinstalación sí.
+
+Si un elemento fue creado en campo, antes de admitir un Hallazgo debe tener GPS de creación y al menos una fotografía; Instalación/Subinstalación además deben quedar clasificadas.
+
+### 2.5 Inspecciones
+
+Lifecycle operativo:
+
+`DRAFT → PLANNED → IN_PROGRESS → CLOSED`
+
+La planificación requiere:
+
+- Área.
+- Operadora vigente del Área.
+- Inspector responsable habilitado.
+- fecha/hora prevista de inicio.
+- checklist generado.
+
+La APK puede abrir una Inspección, pero no posee un lifecycle alternativo: el endpoint móvil crea la visita y utiliza los mismos servicios `plan()` y `start()` que el resto del sistema.
+
+### 2.6 Actas
+
+Una Inspección puede tener **múltiples Actas**.
+
+Reglas críticas:
+
+- sólo puede existir un `DRAFT` simultáneo por Inspección;
+- un Acta en `DRAFT` es editable;
+- al finalizar se bloquea y queda inmutable;
+- el sellado conserva integridad y firmas;
+- no existe reapertura normal de un Acta bloqueada a borrador;
+- para cerrar la Inspección todas las Actas no canceladas deben estar `SEALED`;
+- el Informe pertenece al Acta, no a la Inspección completa.
+
+La unicidad del borrador está protegida por el índice parcial `uq_inspection_acts_one_draft_per_visit`.
+
+### 2.7 Informe, GEDO y vencimientos
+
+Flujo conceptual:
+
+**Acta → INF → oficialización GEDO/IF**
+
+GEDO oficializa el Informe, pero **no equivale por sí solo a la notificación administrativa que inicia el plazo No urgente**.
+
+Existe una compatibilidad histórica importante: el valor físico `GEDO_DATE` se conserva en el enum/base, mientras el significado funcional vigente es `NOTIFICATION_DATE`. No cambie el valor persistido en una refactorización sin una migración explícita y pruebas de compatibilidad.
+
+---
+
+## 3. Modelo de Inventarios
+
+La referencia completa es [`F6_INVENTORY_MODEL.md`](./F6_INVENTORY_MODEL.md).
+
+Puntos técnicos centrales:
+
+- `assets.parent_id`: pertenencia física.
+- `assets.operational_area_id`: contexto transversal de Área.
+- `area_company_relations`: historia de Operadora.
+- `inventory_families`: clasificaciones técnicas.
+- `inventory_family_parent_rules`: compatibilidad Subinstalación ↔ Instalación.
+- `inventory_family_attribute_definitions`: campos técnicos por familia.
+- `asset_inventory_attribute_values`: valores técnicos por objeto.
+- `asset_context_history` y versiones: trazabilidad contextual/histórica.
+
+No se debe rediseñar el esquema para coincidir con una planilla importada. Los archivos externos se normalizan al modelo canónico.
+
+---
+
+## 4. Migraciones
+
+### Regla principal
+
+**Nunca modifique una migración ya aplicada.**
+
+Si cambia esquema, constraints, seeds o reglas persistentes:
+
+1. cree una migración nueva;
+2. haga `up()` determinista;
+3. agregue verificación al final cuando la regla sea crítica;
+4. implemente `down()` cuando la operación sea razonablemente reversible;
+5. agregue/actualice tests de contrato;
+6. pruebe la cadena completa sobre PostGIS limpio.
+
+### F5.1 es una excepción histórica
+
+`F51CleanManualInventory1790087400000` fue un corte destructivo intencional para reiniciar los datos de dominio. Su `down()` no intenta reconstruir información eliminada: el rollback depende del backup PRE.
+
+No repita este patrón para una migración normal sin una decisión explícita, backup validado y procedimiento de restauración.
+
+### Guards importantes de base de datos
+
+PostgreSQL protege, entre otras cosas:
+
+- jerarquía Departamento → Área → Yacimiento → Instalación → Subinstalación;
+- familia correcta según el nivel físico;
+- compatibilidad de familia de Subinstalación con su Instalación padre;
+- un solo Acta `DRAFT` por Inspección.
+
+Las validaciones de API mejoran la experiencia, pero no reemplazan estos guards.
+
+---
+
+## 5. API
+
+### Principios
+
+- Reutilice servicios canónicos; no duplique lifecycle en controllers móviles.
+- Las mutaciones relevantes deben producir auditoría.
+- Los errores de dominio deben tener `code` estable y mensaje legible.
+- Los estados históricos/inmutables no deben reabrirse por conveniencia de UI.
+- Para relaciones temporales, valide la vigencia en la fecha correspondiente, no sólo `valid_until IS NULL` cuando el caso exige reconstrucción histórica.
+
+### Áreas a revisar antes de tocar un flujo
+
+- Inventario: `src/asset-master/`.
+- Inspecciones: `src/inspection-visits/`.
+- Actas: `src/inspection-acts/`, `src/inspection-closing/`, `src/act-administration/`.
+- Hallazgos: `src/inspection-findings/` y gate móvil en `src/inspection-visits/field-findings.service.ts`.
+- Informes/GEDO: `src/inspection-reports/`.
+- Verificaciones: `src/inspection-verifications/`.
+- Entidades/migraciones: `src/database/`.
+
+---
+
+## 6. WEB
+
+La WEB es el frente principal de administración, planificación y seguimiento. Las rutas protegidas se declaran en `web-v2/src/app/App.tsx` y usan permisos para controlar acceso.
+
+Módulos principales:
+
+- Dashboard.
+- Mapa.
+- Inventarios y dossier.
+- Revisión de Inventario nacido en campo.
+- Inspecciones y preparación de campo.
+- Actas.
+- Hallazgos y planificación de verificaciones.
+- Seguimiento de Actas.
+- Informes.
+- Historial y consulta temporal.
+- Administración de usuarios, roles, auditoría, tipos y catálogo.
+
+No esconda una regla sólo en la WEB: toda restricción de integridad debe existir también en API/DB.
+
+---
+
+## 7. Android
+
+La APK está orientada a ejecución en campo.
+
+Reglas que deben mantenerse:
+
+- sólo un usuario con capacidad de ejecución puede iniciar/operar una Inspección;
+- `Abrir inspección` selecciona Área y Operadora vigente;
+- la nueva visita queda autoasignada al inspector actual;
+- se genera checklist antes de iniciar;
+- el backend recorre DRAFT → PLANNED → IN_PROGRESS con el lifecycle canónico;
+- Inventario nuevo en campo captura evidencia mínima antes de Hallazgos;
+- Hallazgos respetan los mismos niveles y catálogo que la API.
+
+Al cambiar contratos móviles, actualice tanto Kotlin como los tests de contrato montados por el preflight de API.
+
+---
+
+## 8. Permisos y seguridad
+
+El sistema utiliza permisos finos; las pantallas no deben asumir permisos por nombre visual del rol. La fuente efectiva es la matriz rol-permiso de base de datos.
+
+Buenas prácticas:
+
+- proteja controllers con permisos explícitos;
+- no confíe en que una ruta esté oculta en la WEB;
+- preserve la política especial del inspector móvil;
+- mantenga auditadas las mutaciones administrativas;
+- no exponga secretos ni credenciales en repositorio, logs o documentación.
+
+---
+
+## 9. Tests y CI
+
+La barrera principal está en `.github/workflows/ci.yml`.
+
+### API
+
+Ejecuta:
+
+```bash
+npm ci
+npm run typecheck
+npm test
+npm run build
+```
+
+### WEB
+
+Ejecuta:
+
+```bash
+npm ci
+npm run typecheck
+bash ../scripts/check-f3-1-web-contract.sh
+npm run build
+```
+
+### Docker / contratos
+
+Valida:
+
+- sintaxis de scripts shell;
+- paridad del preflight de deploy;
+- `docker compose config`;
+- cadena de migraciones sobre PostGIS limpio;
+- estado limpio F5.1 y preservación de maestros técnicos;
+- segunda ejecución sin migraciones pendientes;
+- preflight API aislado equivalente al VPS;
+- build de imágenes productivas.
+
+### Android
+
+El workflow específico de Android debe completar:
+
+- `assembleDebug`;
+- unit tests;
+- publicación del artefacto APK.
+
+### Contrato transversal F6.1
+
+`api-v3/test/unit/f6-1-project-invariants.test.ts` fija las reglas que más fácilmente podrían degradarse por refactors: jerarquía, contexto Área+Operadora, multi-Acta, Hallazgos, apertura móvil y separación GEDO/vencimiento.
+
+---
+
+## 10. Versionado
+
+Cuando una entrega cambia versión, revise como mínimo:
+
+- `api-v3/package.json`;
+- `api-v3/src/version.ts`;
+- `web-v2/package.json`;
+- `android-app/app/build.gradle.kts` si cambia APK;
+- tests que fijen metadata de versión;
+- metadata raíz de `package-lock.json` regenerándola con npm cuando corresponda.
+
+Los lockfiles son archivos generados: no los edite manualmente en forma parcial. Use npm para reconciliarlos.
+
+---
+
+## 11. Flujo Git y despliegue
+
+Secuencia recomendada:
+
+1. crear rama desde `main` estable;
+2. implementar código + migración + tests + documentación;
+3. abrir PR;
+4. exigir API + WEB + Docker/migraciones + Android verdes cuando aplique;
+5. mergear a `main`;
+6. exigir nuevamente CI verde sobre el SHA de `main`;
+7. recién entonces promover el SHA exacto a `deploy`;
+8. esperar el watcher/deploy;
+9. comprobar SHA objetivo, health, versiones y backup generado.
+
+Nunca despliegue un SHA distinto al que pasó la barrera. Nunca use `deploy` para “probar” una rama incompleta.
+
+Si una migración es de una sola vía, el rollback operativo es el backup PRE validado, no un `migration:revert` improvisado.
+
+---
+
+## 12. Checklist antes de aprobar un cambio
+
+- ¿Respeta la jerarquía canónica?
+- ¿Empresa sigue fuera del árbol físico?
+- ¿Una modificación de Operadora conserva historia temporal?
+- ¿La regla importante está protegida también en API/DB?
+- ¿Hallazgos siguen limitados a Yacimiento/Instalación/Subinstalación?
+- ¿OTROS sigue disponible?
+- ¿Una Inspección puede tener varias Actas y sólo un DRAFT simultáneo?
+- ¿Actas finalizadas siguen inmutables?
+- ¿Informe sigue perteneciendo al Acta?
+- ¿GEDO sigue separado del inicio automático del plazo No urgente?
+- ¿WEB y Android consumen el mismo contrato?
+- ¿Se agregó un test para la nueva regla o regresión?
+- ¿CI completa está verde?
+- ¿Documentación viva quedó actualizada?
+
+---
+
+## 13. Terminología canónica
+
+Use consistentemente:
+
+- **Inventario**, no “Activo” en la interfaz de usuario cuando se refiere al módulo funcional.
+- **Departamento**.
+- **Área**.
+- **Yacimiento**.
+- **Instalación**.
+- **Subinstalación**.
+- **Empresa / Operadora** como maestro/rol operativo, no como padre físico.
+- **Inspección** para la visita operativa.
+- **Acta** para el documento de campo; una Inspección puede contener varias.
+- **Hallazgo** para la observación fiscalizable asociada a Inventario.
+- **Informe / INF** por Acta.
+- **GEDO / IF** para la oficialización documental, separada de la notificación administrativa cuando corresponda.
+
+Si una etiqueta histórica contradice estos términos, corrija la etiqueta; no cambie el modelo para conservar una denominación obsoleta.

docs/MANUAL_USUARIO.md

@@ -0,0 +1,353 @@
+# Manual de Usuario · DH Inspección V2
+
+**Versión funcional de referencia:** F6.1
+
+Este manual explica el uso cotidiano del sistema. Las opciones visibles dependen de los permisos asignados a cada usuario, por lo que un Inspector, Supervisor, Director o Administrador puede ver acciones distintas.
+
+---
+
+## 1. Conceptos principales
+
+DH Inspección V2 organiza el trabajo alrededor de cuatro elementos:
+
+1. **Inventario:** dónde se inspecciona.
+2. **Inspección:** la visita de trabajo.
+3. **Acta:** documento generado durante la Inspección; una Inspección puede tener varias Actas.
+4. **Hallazgo:** observación asociada a un elemento concreto del Inventario.
+
+Además, cada Acta puede continuar con su **Informe (INF)**, oficialización documental y seguimiento posterior.
+
+---
+
+## 2. Ingreso al sistema
+
+1. Abra la WEB de DH Inspección V2.
+2. Ingrese usuario y contraseña.
+3. El menú mostrará solamente los módulos habilitados por sus permisos.
+
+Si una opción no aparece o el sistema informa que no tiene autorización, consulte al Administrador antes de intentar resolverlo creando datos alternativos.
+
+---
+
+## 3. Cómo se organiza el Inventario
+
+La estructura física correcta es siempre:
+
+**Departamento → Área → Yacimiento → Instalación → Subinstalación**
+
+La **Empresa** no forma parte de esa cadena. Se administra por separado y se vincula al Área cuando actúa como Operadora.
+
+Ejemplo:
+
+- Departamento: Malargüe
+  - Área: Área A
+    - Yacimiento: Yacimiento Norte
+      - Instalación: Planta de Tratamiento
+        - Subinstalación: Separador 01
+
+Una Empresa puede cambiar con el tiempo sin modificar esta estructura física.
+
+---
+
+## 4. Carga manual de Inventario
+
+Para construir una estructura confiable desde cero, use este orden:
+
+1. Cree las **Empresas** necesarias.
+2. Cree el **Departamento**.
+3. Cree el **Área** dentro del Departamento.
+4. Registre la **Operadora vigente** del Área si corresponde.
+5. Cree el **Yacimiento** dentro del Área.
+6. Cree la **Instalación** dentro del Yacimiento.
+7. Seleccione la clasificación técnica de la Instalación.
+8. Cree la **Subinstalación** dentro de la Instalación.
+9. Seleccione una clasificación técnica compatible para la Subinstalación.
+
+El sistema no permite saltear niveles. Por ejemplo, una Instalación no puede depender directamente de un Área.
+
+### Empresa y Operadora
+
+Cuando una Empresa opera un Área, registre la relación operativa correspondiente. Si cambia la Operadora:
+
+1. finalice la relación vigente anterior;
+2. registre la nueva Operadora;
+3. no mueva Yacimientos, Instalaciones ni Subinstalaciones.
+
+El historial queda conservado para consultas temporales.
+
+---
+
+## 5. Consultar Inventario
+
+Desde **Inventarios** puede navegar la estructura territorial y abrir el dossier de cada registro.
+
+Utilice el breadcrumb para volver hacia niveles superiores. El dossier concentra, según la información disponible:
+
+- datos actuales;
+- ubicación y clasificación;
+- fotografías;
+- historial de cambios;
+- Hallazgos;
+- verificaciones;
+- Actas e Informes relacionados.
+
+Cuando necesite saber cómo estaba un elemento en una fecha anterior, use la **Consulta temporal** en lugar de interpretar sólo sus datos actuales.
+
+---
+
+## 6. Crear una Inspección desde la WEB
+
+En **Inspecciones → Nueva Inspección**:
+
+1. seleccione el **Área**;
+2. seleccione una **Operadora vigente** para esa Área;
+3. seleccione el **Inspector responsable**;
+4. indique la fecha y hora prevista de inicio;
+5. confirme la creación.
+
+Al crearse la Inspección, el sistema genera su checklist de antecedentes. Antes de planificar, la información obligatoria debe estar completa.
+
+Una Inspección planificada se inicia operativamente desde la APK por un Inspector habilitado y asignado.
+
+---
+
+## 7. Abrir una Inspección directamente desde la APK
+
+La APK también permite comenzar una Inspección que no haya sido preparada previamente en la WEB.
+
+Desde la pantalla principal:
+
+1. pulse **Abrir inspección**;
+2. elija el **Área**;
+3. elija la **Operadora vigente**;
+4. pulse **Abrir inspección ahora**.
+
+El sistema:
+
+- crea la Inspección;
+- la asigna al Inspector que inició sesión;
+- genera su checklist;
+- la planifica;
+- la deja **En curso**.
+
+No elija una Empresa por aproximación: la APK muestra la relación operativa válida del Área.
+
+---
+
+## 8. Trabajar con Inventario durante una Inspección
+
+Dentro de una Inspección en curso puede seleccionar Inventario existente del Área y agregarlo al trabajo de campo/Acta correspondiente.
+
+Los niveles relevantes para Hallazgos son:
+
+- Yacimiento;
+- Instalación;
+- Subinstalación.
+
+### Inventario encontrado en campo
+
+Si encuentra una Instalación o Subinstalación que todavía no existe, la APK puede darla de alta dentro de la jerarquía correspondiente.
+
+Antes de poder registrar Hallazgos sobre un elemento nuevo de campo, debe quedar como mínimo con:
+
+- GPS de creación;
+- al menos una fotografía;
+- clasificación técnica si es Instalación o Subinstalación.
+
+Esto evita que un Hallazgo quede asociado a un objeto sin identificación suficiente.
+
+---
+
+## 9. Actas: una Inspección puede tener varias
+
+Una misma Inspección puede generar **varias Actas**.
+
+La regla práctica es:
+
+- puede haber varias Actas históricas dentro de la Inspección;
+- sólo puede existir **un Acta en borrador al mismo tiempo**.
+
+Mientras un Acta está en borrador puede completar su contenido y agregar Hallazgos. Una vez finalizada/bloqueada deja de ser editable como un borrador normal.
+
+Para continuar con una nueva Acta dentro de la misma Inspección, finalice correctamente la actual antes de abrir la siguiente.
+
+---
+
+## 10. Registrar Hallazgos
+
+Los Hallazgos se asignan directamente a:
+
+- **Yacimiento**;
+- **Instalación**;
+- **Subinstalación**.
+
+No se crean Hallazgos directos sobre Departamento ni Área.
+
+### Hallazgo de catálogo
+
+Si el sistema muestra un Hallazgo aplicable al elemento seleccionado:
+
+1. elija el Hallazgo del catálogo;
+2. complete la descripción y datos requeridos;
+3. guarde.
+
+### OTROS / Agregar otro
+
+La opción **OTROS** debe estar siempre disponible.
+
+Úsela cuando el Hallazgo observado no exista en la lista disponible. Describa claramente qué se encontró para que luego pueda revisarse y normalizarse en oficina.
+
+Después de guardar un Hallazgo puede utilizar **Agregar otro** para continuar cargando Hallazgos sobre el mismo Inventario.
+
+### En Yacimiento
+
+Un Yacimiento puede recibir Hallazgos aunque no tenga clasificación técnica. Cuando exista catálogo configurado para ese tipo, el sistema puede ofrecerlo; en todos los casos conserva la opción OTROS.
+
+---
+
+## 11. Finalizar y sellar un Acta
+
+Antes de finalizar un Acta revise especialmente:
+
+- Inventario incluido;
+- Hallazgos;
+- observaciones;
+- firmas y datos requeridos por el flujo.
+
+Al finalizar, el sistema bloquea el contenido y genera controles de integridad. Esto significa que **el Acta deja de ser editable como borrador**.
+
+No finalice un Acta para “probar” cómo queda. Primero revise todo su contenido.
+
+Cuando el flujo de firmas y sellado termina, el Acta queda `SELLADA` y preparada para continuar con su documentación posterior.
+
+---
+
+## 12. Cerrar una Inspección
+
+Para cerrar una Inspección en curso deben cumplirse las condiciones operativas, entre ellas:
+
+- existir al menos un Acta;
+- todas las Actas no canceladas deben estar selladas;
+- si la Inspección contiene verificaciones, sus resultados deben estar registrados.
+
+Si el sistema impide el cierre, revise el mensaje mostrado: normalmente identifica el Acta o la verificación pendiente.
+
+---
+
+## 13. Informes por Acta
+
+El Informe se genera y administra **por Acta**.
+
+Por eso, si una Inspección tuvo tres Actas, el seguimiento documental no debe tratarla como si existiera un único Informe global.
+
+Desde **Informes** puede consultar el estado del INF y continuar el flujo habilitado para su rol.
+
+---
+
+## 14. GEDO / IF y plazo No urgente
+
+Registrar el identificador y PDF oficial de GEDO/IF **oficializa el Informe**, pero por sí solo no significa que haya comenzado automáticamente el plazo administrativo de una Acta No urgente.
+
+El vencimiento debe activarse a partir del evento administrativo de notificación que corresponda al procedimiento vigente.
+
+Si ve un Informe oficializado sin fecha de vencimiento activa, no lo corrija cargando una fecha ficticia de GEDO como notificación.
+
+---
+
+## 15. Seguimiento de Hallazgos
+
+Después del trabajo de campo, un Hallazgo mantiene su historia. El seguimiento puede incluir:
+
+- respuesta de la Empresa;
+- documentos y evidencias;
+- fecha de control;
+- planificación de una verificación;
+- resultado de verificación;
+- nueva fecha si continúa pendiente;
+- cierre administrativo.
+
+No reescriba el Hallazgo original para reflejar novedades posteriores. Use los eventos de seguimiento para conservar la trazabilidad.
+
+---
+
+## 16. Verificaciones
+
+Cuando un Hallazgo requiere control posterior:
+
+1. defina la fecha de verificación cuando corresponda;
+2. planifique la visita de verificación;
+3. ejecute la verificación;
+4. registre el resultado y evidencia;
+5. si no está resuelto, reprograme según el flujo;
+6. si está resuelto y la visita quedó cerrada, continúe con el cierre administrativo del Hallazgo.
+
+El historial de verificaciones no debe borrarse para reemplazarlo por el último resultado.
+
+---
+
+## 17. Historial y Consulta temporal
+
+Use **Historial** para revisar cambios y eventos registrados.
+
+Use **Consulta temporal** cuando la pregunta sea, por ejemplo:
+
+- “¿qué Empresa operaba esta Área en esa fecha?”;
+- “¿dónde estaba ubicado este elemento?”;
+- “¿qué estado tenía el Inventario en ese momento?”.
+
+La vista actual y la vista histórica cumplen funciones distintas.
+
+---
+
+## 18. Revisión de Inventario nacido en campo
+
+Los registros creados por Inspectores en la APK pueden requerir revisión posterior en oficina.
+
+Al revisar:
+
+- confirme nombre/código;
+- confirme la ubicación jerárquica;
+- verifique clasificación técnica;
+- revise GPS/fotografías;
+- normalice información pendiente sin perder el origen de campo.
+
+No cree un duplicado sólo porque el nombre no coincide exactamente; primero confirme si se trata del mismo objeto.
+
+---
+
+## 19. Mensajes frecuentes
+
+### “La Operadora seleccionada no tiene una relación operativa vigente con el Área”
+
+Revise la relación Empresa ⇄ Área y su vigencia. No cambie la jerarquía física para resolverlo.
+
+### “La Instalación/Subinstalación debe tener una clasificación técnica”
+
+Complete la familia técnica del elemento antes de registrar el Hallazgo.
+
+### “El Inventario creado en campo debe tener GPS y al menos una foto”
+
+Complete la captura de campo requerida y vuelva a intentar.
+
+### “Todas las Actas deben estar SELLADAS antes de cerrar la Inspección”
+
+Abra la Inspección y revise cuáles Actas todavía están en borrador, bloqueadas o pendientes de sellado.
+
+### “La inspección no tiene un Acta borrador abierta”
+
+Cree/abra un Acta borrador para esa Inspección antes de cargar nuevos Hallazgos.
+
+---
+
+## 20. Buenas prácticas
+
+- Cargue la estructura de Inventario en orden jerárquico.
+- No use Empresa como padre físico.
+- No duplique Inventario ante la primera diferencia de nombre.
+- Use OTROS cuando el Hallazgo no exista en catálogo.
+- Revise un Acta antes de finalizarla: luego queda inmutable.
+- Use seguimiento y verificaciones para agregar historia; no reescriba hechos anteriores.
+- Use Consulta temporal para preguntas históricas.
+- Respete los mensajes de integridad del sistema en lugar de forzar datos ficticios.
+
+Ante una duda funcional que pueda modificar jerarquía, Actas, Hallazgos o vencimientos, consulte antes de cargar datos masivamente.