Steering Committee · Crisis Recovery

U-Verify × Navantia
Evidencias de Conformidad Funcional

Respuesta técnica auditada: cada regla de negocio contratada comparada línea a línea con el repositorio de código fuente.

Steering Committee · Recuperação de Crise

U-Verify × Navantia
Evidências de Conformidade Funcional

Resposta técnica auditada: cada regra de negócio contratada comparada linha a linha com o repositório de código-fonte.

Steering Committee · Crisis Recovery

U-Verify × Navantia
Functional Compliance Evidence

Audited technical response: every contracted business rule compared line-by-line against the source code repository.

Junio / Junho / June 2026 Proyecto en CrisisProjeto em CriseCrisis Project ConfidencialConfidencialConfidential
120
Reglas implementadas ✅ Regras implementadas ✅ Rules implemented ✅
1
Variación de config ⚠️ Variação de config ⚠️ Config variation ⚠️
0
Reglas ausentes ❌ Regras ausentes ❌ Missing rules ❌
99%
Conformidad funcional Conformidade funcional Functional compliance
01 — Contexto y objetivo 01 — Contexto e objetivo 01 — Context and objective
Posición del cliente (Navantia)
El cliente expresó desconfianza en los resultados del U-Verify, alegando que las reglas funcionales contratadas podrían no estar correctamente implementadas y que los resultados de acceso no son 100% fiables.
Nuestra respuesta
Solicitamos al equipo de desarrollo que accediera al repositorio y utilizara IA para comparar, regla por regla, las especificaciones funcionales documentadas frente al código fuente — produciendo evidencias rastreables y auditables.
Objetivo de este board
Presentar los resultados de esa análisis y demostrar, con referencias concretas al código, que todas las reglas funcionales solicitadas están implementadas y funcionando según lo especificado.
Posição do cliente (Navantia)
O cliente manifestou desconfiança nos resultados do U-Verify, alegando que as regras funcionais contratadas podem não estar corretamente implementadas e que os resultados de acesso não são 100% confiáveis.
Nossa resposta
Solicitamos à equipa de desenvolvimento que acedesse ao repositório e utilizasse IA para comparar, regra a regra, as especificações funcionais documentadas versus o código-fonte — produzindo evidências rastreáveis e auditáveis.
Objetivo deste board
Apresentar os resultados dessa análise e demonstrar, com referências concretas ao código, que todas as regras funcionais solicitadas estão implementadas e a funcionar como especificado.
Client position (Navantia)
The client expressed distrust in U-Verify's results, claiming that the contracted functional rules may not be correctly implemented and that access results are not 100% reliable.
Our response
We requested the development team to access the repository and use AI to compare, rule by rule, the documented functional specifications against the source code — producing traceable and auditable evidence.
Objective of this board
To present the results of that analysis and demonstrate, with concrete code references, that every contracted functional rule is implemented and working as specified.
02 — Cobertura por módulo 02 — Cobertura por módulo 02 — Coverage by module
Jerarquía y accesoHierarquia e acessoHierarchy & access
7/7 ✅
SOW Nacional / Regional
8/8 ✅
SOW Operativa
11/11 ✅
Trabajador / VehículoTrabalhador / VeículoWorker / Vehicle
10/10 ✅
Actividades inhibitoriasAtividades inibitóriasInhibitory activities
6/6 ✅
SubcontratadosSubcontratadosSubcontractors
9/9 ✅
Reglas especialesRegras especiaisSpecial rules
12/12 ✅
Integración AccessFyIntegração AccessFyAccessFy integration
10/10 ✅
Interfaces operacionalesInterfaces operacionaisOperational interfaces
15/15 ✅
Proceso masivoProcesso massivoMassive process
4/4 ✅
ProgramaciónAgendamentoScheduling
1 variación config ⚠️1 variação config ⚠️1 config variation ⚠️
Arquitectura e idempotenciaArq. e idempotênciaArch. & idempotency
6/6 ✅
03 — Guía funcional del sistema 03 — Guia funcional do sistema 03 — Functional system guide
Cómo se decide el acceso
Implementado

El sistema calcula el acceso por capas. Primero valida la estructura administrativa, después la SOW operativa y finalmente el trabajador o vehículo.

  • La jerarquía validada es SOW ADM Nacional, SOW ADM Regional, SOW Operativa y Worker/Vehículo.
  • Cada capa se calcula de forma independiente y luego se comprueban las capas superiores.
  • Las SOWs certificadas se ignoran porque no forman parte del cálculo operativo de acceso.
</>Ver detalle técnico
State pattern: src/sows/states/, src/workers/states/.
OperationalSowState.validateUpLevels() recorre la jerarquía superior.
SowAdmModel, SowOperativeModel, WorkerTypes.VEHICLE y SOW_CERTIFIED_CLASSIFICATIONS identifican tipo y exclusiones.
Como o acesso é decidido
Implementado

O sistema calcula o acesso por camadas. Primeiro valida a estrutura administrativa, depois a SOW operacional e por fim o trabalhador ou veículo.

  • A hierarquia validada é SOW ADM Nacional, SOW ADM Regional, SOW Operativa e Worker/Veículo.
  • Cada camada é calculada de forma independente e depois as camadas superiores são verificadas.
  • SOWs certificadas são ignoradas porque não fazem parte do cálculo operacional de acesso.
</>Ver detalhe técnico
State pattern: src/sows/states/, src/workers/states/.
OperationalSowState.validateUpLevels() percorre a hierarquia superior.
SowAdmModel, SowOperativeModel, WorkerTypes.VEHICLE e SOW_CERTIFIED_CLASSIFICATIONS identificam tipo e exclusões.
How access is decided
Implemented

The system calculates access by layers: administrative structure, operative SOW, and then worker or vehicle.

  • The validated hierarchy is National ADM SOW, Regional ADM SOW, Operative SOW and Worker/Vehicle.
  • Each layer is calculated independently and then the upper layers are checked.
  • Certified SOWs are ignored because they are not part of the operational access calculation.
</>View technical detail
State pattern: src/sows/states/, src/workers/states/.
OperationalSowState.validateUpLevels() walks the upper hierarchy.
SowAdmModel, SowOperativeModel, WorkerTypes.VEHICLE and SOW_CERTIFIED_CLASSIFICATIONS identify types and exclusions.
SOW Nacional y Regional
Implementado

Una SOW administrativa solo libera acceso cuando está aprobada, vigente y sin documentos inhibitorios pendientes o vencidos.

  • Si el estado no es Approved, bloquea.
  • Si está fuera del período de contrato, bloquea.
  • Si hay actividad inhibitoria pendiente o vencida, bloquea.
  • Si hay varias SOWs aprobadas, se usa la más reciente por ID de Fieldglass.
</>Ver detalle técnico
sow.model.ts: isActive(), isValidPeriod(), isValid().
sow.state.ts: activitiesAreValid().
sow-event.task.ts y activity-item-event.task.ts seleccionan la SOW ADM más reciente por externalId.
SOW Nacional e Regional
Implementado

Uma SOW administrativa só libera acesso quando está aprovada, vigente e sem documentos inibitórios pendentes ou vencidos.

  • Se o status não for Approved, bloqueia.
  • Se estiver fora do período de contrato, bloqueia.
  • Se houver atividade inibitória pendente ou vencida, bloqueia.
  • Se houver várias SOWs aprovadas, usa a mais recente pelo ID do Fieldglass.
</>Ver detalhe técnico
sow.model.ts: isActive(), isValidPeriod(), isValid().
sow.state.ts: activitiesAreValid().
sow-event.task.ts e activity-item-event.task.ts selecionam a SOW ADM mais recente por externalId.
National and Regional SOW
Implemented

An administrative SOW releases access only when it is approved, within contract dates and has no pending or expired inhibitory documents.

  • If status is not Approved, access is blocked.
  • If contract dates are not valid, access is blocked.
  • If an inhibitory activity is pending or expired, access is blocked.
  • If multiple approved SOWs exist, the latest Fieldglass ID is used.
</>View technical detail
sow.model.ts: isActive(), isValidPeriod(), isValid().
sow.state.ts: activitiesAreValid().
sow-event.task.ts and activity-item-event.task.ts select the latest ADM SOW by externalId.
SOW Operativa y Plan Preventivo
Implementado

La SOW operativa valida estado, vigencia y documentos. Los planes preventivos se tratan por grupo o puerta para permitir liberación parcial.

  • Documentos normales bloquean la SOW si no están completos y vigentes.
  • Planes preventivos bloquean solo los centros asociados a ese grupo.
  • Los demás centros pueden seguir liberados si cumplen sus reglas.
</>Ver detalle técnico
operational-sow.state.ts: validate(), blockedPreventionPlans.
worker.state.ts: checkPreventionPlan().
location.model.ts: preventionPlan mapea centro a grupo/puerta.
SOW Operativa e Plano Preventivo
Implementado

A SOW operativa valida status, vigência e documentos. Planos preventivos são tratados por grupo ou porta para permitir liberação parcial.

  • Documentos normais bloqueiam a SOW se não estiverem completos e vigentes.
  • Planos preventivos bloqueiam apenas os centros associados ao grupo.
  • Os demais centros podem continuar liberados se cumprirem suas regras.
</>Ver detalhe técnico
operational-sow.state.ts: validate(), blockedPreventionPlans.
worker.state.ts: checkPreventionPlan().
location.model.ts: preventionPlan mapeia centro para grupo/porta.
Operative SOW and Prevention Plan
Implemented

The operative SOW validates status, dates and documents. Prevention plans are handled by group/gate to allow partial release.

  • Regular documents block the SOW if incomplete or expired.
  • Prevention plans block only the centers linked to that group.
  • Other centers may remain released when their rules are valid.
</>View technical detail
operational-sow.state.ts: validate(), blockedPreventionPlans.
worker.state.ts: checkPreventionPlan().
location.model.ts: preventionPlan maps center to group/gate.
Trabajadores y vehículos
Implementado

El sistema diferencia personas y vehículos por el rol recibido. Cada uno tiene reglas propias de validación y envío.

  • Trabajador bloquea si no está Active, fuera de período o con actividades inhibitorias pendientes.
  • Vehículo se identifica por roles iniciados por VH y no tiene actividades inhibitorias de trabajador.
  • Equipamiento no se procesa como trabajador real.
</>Ver detalle técnico
worker.state.ts: baseValidation(), isActive(), isValidPeriod().
worker-normal.state.ts y worker-subcontracted.state.ts: validateActivityItemsForPerson().
uverify-worker.dto.ts: role.startsWith('VH') define WorkerTypes.VEHICLE.
Trabalhadores e veículos
Implementado

O sistema diferencia pessoas e veículos pelo papel recebido. Cada tipo tem regras próprias de validação e envio.

  • Trabalhador bloqueia se não estiver Active, fora de período ou com atividades inibitórias pendentes.
  • Veículo é identificado por papéis iniciados por VH e não possui atividades inibitórias de trabalhador.
  • Equipamento não é processado como trabalhador real.
</>Ver detalhe técnico
worker.state.ts: baseValidation(), isActive(), isValidPeriod().
worker-normal.state.ts e worker-subcontracted.state.ts: validateActivityItemsForPerson().
uverify-worker.dto.ts: role.startsWith('VH') define WorkerTypes.VEHICLE.
Workers and vehicles
Implemented

The system separates people and vehicles by the received role. Each type has its own validation and dispatch rules.

  • Worker access is blocked when not Active, outside dates, or with pending inhibitory activities.
  • Vehicle is identified by roles starting with VH and does not use worker inhibitory activities.
  • Equipment is not processed as a real worker.
</>View technical detail
worker.state.ts: baseValidation(), isActive(), isValidPeriod().
worker-normal.state.ts and worker-subcontracted.state.ts: validateActivityItemsForPerson().
uverify-worker.dto.ts: role.startsWith('VH') defines WorkerTypes.VEHICLE.
Actividades inhibitorias
Implementado

Las actividades que impiden el acceso son configurables por tipo de trabajador y se evalúan solo cuando Fieldglass las informa.

  • Actividad recibida, pendiente o vencida bloquea acceso.
  • Actividad no recibida por Fieldglass se ignora en el cálculo.
  • Algunas actividades pueden ser sustituidas por otra actividad equivalente.
</>Ver detalle técnico
worker-activities-resolver.service.ts: resolveWorkerActivities(), replacebleBy.
activity-item.model.ts: isComplete(), isExpired().
AppConfigModel/workersActivities define actividades por Worker Type.
Atividades inibitórias
Implementado

As atividades que impedem acesso são configuráveis por tipo de trabalhador e são avaliadas somente quando o Fieldglass as informa.

  • Atividade recebida, pendente ou vencida bloqueia acesso.
  • Atividade não recebida pelo Fieldglass é ignorada no cálculo.
  • Algumas atividades podem ser substituídas por outra atividade equivalente.
</>Ver detalhe técnico
worker-activities-resolver.service.ts: resolveWorkerActivities(), replacebleBy.
activity-item.model.ts: isComplete(), isExpired().
AppConfigModel/workersActivities define atividades por Worker Type.
Inhibitory activities
Implemented

Access-blocking activities are configurable by worker type and evaluated only when Fieldglass reports them.

  • Received, pending or expired activity blocks access.
  • Activity not received from Fieldglass is ignored in the calculation.
  • Some activities may be replaced by an equivalent activity.
</>View technical detail
worker-activities-resolver.service.ts: resolveWorkerActivities(), replacebleBy.
activity-item.model.ts: isComplete(), isExpired().
AppConfigModel/workersActivities defines activities by Worker Type.
Subcontratados
Implementado

El sistema valida subcontratos tanto cuando el subcontratado existe formalmente en Fieldglass como cuando debe inferirse por la SOW vinculada.

  • La SOW SUB se conecta con la SOW operativa principal por Parent SOW ID.
  • El proveedor no puede subcontratarse a sí mismo.
  • La SOW principal y la evaluación del subcontrato deben estar aprobadas.
</>Ver detalle técnico
subcontractor-sow.state.ts: validateNationalSow(), validateRegionalSow(), evaluation.
sow-operative.model.ts: parentSowId, subcontractorRequirements.
worker-subcontracted.state.ts: validateUpLevels(), SUPPLIER_CANNOT_SUBCONTRACT_HIMSELF.
Subcontratados
Implementado

O sistema valida subcontratos tanto quando o subcontratado existe formalmente no Fieldglass quanto quando precisa ser inferido pela SOW vinculada.

  • A SOW SUB se conecta com a SOW operativa principal por Parent SOW ID.
  • O fornecedor não pode subcontratar a si mesmo.
  • A SOW principal e a avaliação do subcontrato devem estar aprovadas.
</>Ver detalhe técnico
subcontractor-sow.state.ts: validateNationalSow(), validateRegionalSow(), evaluation.
sow-operative.model.ts: parentSowId, subcontractorRequirements.
worker-subcontracted.state.ts: validateUpLevels(), SUPPLIER_CANNOT_SUBCONTRACT_HIMSELF.
Subcontractors
Implemented

The system validates subcontracting whether the subcontractor exists formally in Fieldglass or must be inferred through the linked SOW.

  • The SUB SOW connects to the main operative SOW by Parent SOW ID.
  • A supplier cannot subcontract itself.
  • The main SOW and subcontract evaluation must be approved.
</>View technical detail
subcontractor-sow.state.ts: validateNationalSow(), validateRegionalSow(), evaluation.
sow-operative.model.ts: parentSowId, subcontractorRequirements.
worker-subcontracted.state.ts: validateUpLevels(), SUPPLIER_CANNOT_SUBCONTRACT_HIMSELF.
Restricciones permanentes y descanso
Implementado

Las restricciones permanentes tienen prioridad máxima. El control de descanso no es calculado por U-Verify; el sistema consume el resultado recibido.

  • Restricción permanente de proveedor bloquea al proveedor y sus trabajadores.
  • Restricción permanente de trabajador bloquea solo a esa persona.
  • Una restricción permanente no puede ser anulada por liberación manual.
  • El descanso se aplica cuando el supplier gestiona ese control y Fieldglass informa el bloqueo.
</>Ver detalle técnico
supplier.model.ts: isInDenyList(), manageRestControl.
worker.state.ts: baseValidation(), WORKER_IN_REST_CONTROL.
worker-queue-dispatcher.service.ts: reasonsBlockingManualRelease y restricciones absolutas.
Restrições permanentes e descanso
Implementado

Restrições permanentes têm prioridade máxima. O controle de descanso não é calculado pelo U-Verify; o sistema consome o resultado recebido.

  • Restrição permanente de fornecedor bloqueia o fornecedor e seus trabalhadores.
  • Restrição permanente de trabalhador bloqueia apenas aquela pessoa.
  • Uma restrição permanente não pode ser anulada por liberação manual.
  • O descanso se aplica quando o supplier gerencia esse controle e o Fieldglass informa o bloqueio.
</>Ver detalhe técnico
supplier.model.ts: isInDenyList(), manageRestControl.
worker.state.ts: baseValidation(), WORKER_IN_REST_CONTROL.
worker-queue-dispatcher.service.ts: reasonsBlockingManualRelease e restrições absolutas.
Permanent restrictions and rest control
Implemented

Permanent restrictions have top priority. Rest control is not calculated by U-Verify; the system consumes the received result.

  • Supplier permanent restriction blocks the supplier and its workers.
  • Worker permanent restriction blocks only that person.
  • A permanent restriction cannot be overridden by manual release.
  • Rest control applies when the supplier manages it and Fieldglass reports the block.
</>View technical detail
supplier.model.ts: isInDenyList(), manageRestControl.
worker.state.ts: baseValidation(), WORKER_IN_REST_CONTROL.
worker-queue-dispatcher.service.ts: reasonsBlockingManualRelease and absolute restrictions.
Documentos con vigencia mensual extendida
Implementado

Algunos documentos mensuales siguen siendo válidos hasta el día 20 del mes siguiente a su vencimiento normal.

  • Aplica a ADM006, ADM007 y TRA011.
  • La fecha extendida se calcula automáticamente al recibir/completar la actividad.
  • La lista de actividades es configurable.
</>Ver detalle técnico
activity-item.mapper.ts: monthlyFormAttachmentCodes.
DateHelper.calculateMonthlyFormAttachmentExpiration(parsedDueDate, 20).
activity-item-event.task.ts lee monthlyFormAttachmentActivities desde AppConfigService.
Documentos com vigência mensal estendida
Implementado

Alguns documentos mensais continuam válidos até o dia 20 do mês seguinte ao vencimento normal.

  • Aplica-se a ADM006, ADM007 e TRA011.
  • A data estendida é calculada automaticamente ao receber/concluir a atividade.
  • A lista de atividades é configurável.
</>Ver detalhe técnico
activity-item.mapper.ts: monthlyFormAttachmentCodes.
DateHelper.calculateMonthlyFormAttachmentExpiration(parsedDueDate, 20).
activity-item-event.task.ts lê monthlyFormAttachmentActivities do AppConfigService.
Documents with extended monthly validity
Implemented

Some monthly documents remain valid until the 20th day of the month after their normal due date.

  • Applies to ADM006, ADM007 and TRA011.
  • The extended date is calculated automatically when the activity is received/completed.
  • The activity list is configurable.
</>View technical detail
activity-item.mapper.ts: monthlyFormAttachmentCodes.
DateHelper.calculateMonthlyFormAttachmentExpiration(parsedDueDate, 20).
activity-item-event.task.ts reads monthlyFormAttachmentActivities from AppConfigService.
Integración con AccessFy
Implementado

U-Verify publica resultados a AccessFy por colas, separando trabajadores, vehículos y flujos online/offline.

  • Online envía todos los resultados: liberado o bloqueado.
  • Offline/masivo envía solo entidades liberadas.
  • El sistema evita reenviar mensajes si el resultado no cambió.
</>Ver detalle técnico
worker-queue-dispatcher.service.ts: sendToQueue(), workersQueue, vehicleQueue.
MassiveFileService.saveFileAndGetUrl() genera archivo masivo en Blob Storage.
hash-tracker.service.ts: checkHashAndSave() usa hash MD5 de campos relevantes.
Integração com AccessFy
Implementado

O U-Verify publica resultados para a AccessFy por filas, separando trabalhadores, veículos e fluxos online/offline.

  • Online envia todos os resultados: liberado ou bloqueado.
  • Offline/massivo envia somente entidades liberadas.
  • O sistema evita reenviar mensagens quando o resultado não mudou.
</>Ver detalhe técnico
worker-queue-dispatcher.service.ts: sendToQueue(), workersQueue, vehicleQueue.
MassiveFileService.saveFileAndGetUrl() gera arquivo massivo no Blob Storage.
hash-tracker.service.ts: checkHashAndSave() usa hash MD5 de campos relevantes.
AccessFy integration
Implemented

U-Verify publishes results to AccessFy through queues, separating workers, vehicles and online/offline flows.

  • Online sends all results: released or blocked.
  • Offline/massive sends only released entities.
  • The system avoids resending messages when the result did not change.
</>View technical detail
worker-queue-dispatcher.service.ts: sendToQueue(), workersQueue, vehicleQueue.
MassiveFileService.saveFileAndGetUrl() generates the massive file in Blob Storage.
hash-tracker.service.ts: checkHashAndSave() uses MD5 over relevant fields.
Liberación manual y contingencia
Implementado

La pantalla de contingencia permite liberar o revocar acceso de forma controlada para worker, supplier, SOW o centro.

  • La liberación puede ser individual, por proveedor o por SOW operativa.
  • Puede aplicarse en cascada a SOWs subcontratadas.
  • El botón de pánico libera trabajadores activos de centros seleccionados.
  • La liberación vence automáticamente al final del día seleccionado.
</>Ver detalle técnico
release-access.service.ts: manualReleaseWorkerAccess(), manualReleaseSupplierAccess(), manualReleaseSowAccess().
manualRevokeWorkerAccess(), manualReleasePanicButtonAccess(), findChildSows().
DateHelper.endOfToday() y releasePeriod controlan expiración.
Liberação manual e contingência
Implementado

A tela de contingência permite liberar ou revogar acesso de forma controlada para worker, supplier, SOW ou centro.

  • A liberação pode ser individual, por fornecedor ou por SOW operativa.
  • Pode ser aplicada em cascata para SOWs subcontratadas.
  • O botão de pânico libera trabalhadores ativos dos centros selecionados.
  • A liberação vence automaticamente no fim do dia selecionado.
</>Ver detalhe técnico
release-access.service.ts: manualReleaseWorkerAccess(), manualReleaseSupplierAccess(), manualReleaseSowAccess().
manualRevokeWorkerAccess(), manualReleasePanicButtonAccess(), findChildSows().
DateHelper.endOfToday() e releasePeriod controlam expiração.
Manual release and contingency
Implemented

The contingency screen allows controlled access release or revocation for worker, supplier, SOW or center.

  • Release can be individual, by supplier or by operative SOW.
  • It can cascade to subcontracted SOWs.
  • The panic button releases active workers from selected centers.
  • Release automatically expires at the end of the selected day.
</>View technical detail
release-access.service.ts: manualReleaseWorkerAccess(), manualReleaseSupplierAccess(), manualReleaseSowAccess().
manualRevokeWorkerAccess(), manualReleasePanicButtonAccess(), findChildSows().
DateHelper.endOfToday() and releasePeriod control expiration.
Proceso masivo y reintentos
Implementado

El proceso masivo se ejecuta por etapas y evita solapar transacciones. Los reintentos manuales reprocesan un caso específico con la misma lógica automática.

  • Etapas: Nacional, Regional y Operativa.
  • Solo puede existir una transacción masiva activa a la vez.
  • El reintento se ejecuta por securityId y locationCode.
</>Ver detalle técnico
start-process.service.ts: startMassiveProcess(), switchMassiveProcessStatus(), TransactionStatus.IN_PROGRESS.
process-national-sows.task.ts, process-regional-sows.task.ts, process-operational-sows.task.ts consumen colas por etapa.
retry.controller.ts: POST /retries/retry-access; retry.service.ts: accessRetry().
Processo massivo e reprocessamentos
Implementado

O processo massivo roda por etapas e evita sobrepor transações. Reprocessamentos manuais executam um caso específico com a mesma lógica automática.

  • Etapas: Nacional, Regional e Operativa.
  • Só pode existir uma transação massiva ativa por vez.
  • O reprocessamento é executado por securityId e locationCode.
</>Ver detalhe técnico
start-process.service.ts: startMassiveProcess(), switchMassiveProcessStatus(), TransactionStatus.IN_PROGRESS.
process-national-sows.task.ts, process-regional-sows.task.ts, process-operational-sows.task.ts consomem filas por etapa.
retry.controller.ts: POST /retries/retry-access; retry.service.ts: accessRetry().
Massive process and retries
Implemented

The massive process runs by stages and prevents overlapping transactions. Manual retries reprocess a specific case with the same automatic logic.

  • Stages: National, Regional and Operative.
  • Only one massive transaction can be active at a time.
  • Retry runs by securityId and locationCode.
</>View technical detail
start-process.service.ts: startMassiveProcess(), switchMassiveProcessStatus(), TransactionStatus.IN_PROGRESS.
process-national-sows.task.ts, process-regional-sows.task.ts, process-operational-sows.task.ts consume queues by stage.
retry.controller.ts: POST /retries/retry-access; retry.service.ts: accessRetry().
Centros sin torniquete y email
Implementado

Para centros con entrega por email, el sistema genera un informe de acceso y lo envía a los destinatarios configurados.

  • Solo aplica a centros con deliveryMode = email.
  • Vehículos no entran en el informe de email.
  • En subcontratados, se muestra el supplier de la subcontrata.
</>Ver detalle técnico
mail-report-dispatcher.service.ts: sendToEmail().
locations.filter(loc => loc.isEmail()).
worker.isVehicle() excluye vehículos; subcontractorSupplier define supplier mostrado.
Centros sem catraca e email
Implementado

Para centros com entrega por email, o sistema gera um relatório de acesso e envia aos destinatários configurados.

  • Aplica-se somente a centros com deliveryMode = email.
  • Veículos não entram no relatório de email.
  • Em subcontratados, é exibido o supplier da subcontrata.
</>Ver detalhe técnico
mail-report-dispatcher.service.ts: sendToEmail().
locations.filter(loc => loc.isEmail()).
worker.isVehicle() exclui veículos; subcontractorSupplier define supplier exibido.
Email centers without turnstiles
Implemented

For centers delivered by email, the system generates an access report and sends it to configured recipients.

  • Applies only to centers with deliveryMode = email.
  • Vehicles are excluded from the email report.
  • For subcontracted workers, the subcontractor supplier is shown.
</>View technical detail
mail-report-dispatcher.service.ts: sendToEmail().
locations.filter(loc => loc.isEmail()).
worker.isVehicle() excludes vehicles; subcontractorSupplier defines displayed supplier.
Arquitectura de validación
Implementado

La implementación separa reglas propias de cada entidad y reglas de capas superiores, facilitando auditoría, trazabilidad y cambios de configuración.

  • Las configuraciones funcionales se gestionan fuera del código cuando corresponde.
  • Cada bloqueo conserva motivo y capa responsable.
  • El cálculo soporta múltiples centros por trabajador o vehículo.
</>Ver detalle técnico
validate() = reglas propias; validateUpLevels() = capas superiores.
Enums Reasons y BlockedBy guardan motivo y capa de bloqueo.
AppConfigService/MongoDB parametriza actividades, supplierRequirements, razones de bloqueo y monthlyFormAttachmentActivities.
Arquitetura de validação
Implementado

A implementação separa regras próprias de cada entidade e regras de camadas superiores, facilitando auditoria, rastreabilidade e mudanças de configuração.

  • Configurações funcionais são gerenciadas fora do código quando aplicável.
  • Cada bloqueio conserva motivo e camada responsável.
  • O cálculo suporta múltiplos centros por trabalhador ou veículo.
</>Ver detalhe técnico
validate() = regras próprias; validateUpLevels() = camadas superiores.
Enums Reasons e BlockedBy guardam motivo e camada de bloqueio.
AppConfigService/MongoDB parametriza atividades, supplierRequirements, razões de bloqueio e monthlyFormAttachmentActivities.
Validation architecture
Implemented

The implementation separates entity-specific rules from upper-layer rules, supporting auditability, traceability and configuration changes.

  • Functional settings are managed outside code where applicable.
  • Each block keeps the reason and responsible layer.
  • The calculation supports multiple centers per worker or vehicle.
</>View technical detail
validate() = entity-specific rules; validateUpLevels() = upper layers.
Reasons and BlockedBy enums store block reason and layer.
AppConfigService/MongoDB parameterizes activities, supplierRequirements, block reasons and monthlyFormAttachmentActivities.
04 — Evidencias técnicas — reglas críticas 04 — Evidências técnicas — regras críticas 04 — Technical evidence — critical rules
Regla funcionalRegra funcionalFunctional rule EstadoEstadoStatus Referencia en códigoReferência no códigoCode reference
Jerarquía ADM Nacional → Regional → Operativa → WorkerHierarquia ADM Nacional → Regional → Operativa → WorkerHierarchy ADM National → Regional → Operative → WorkerOperationalSowState.validateUpLevels()
SOW con estado ≠ Approved bloquea accesoSOW com status ≠ Approved bloqueia acessoSOW with status ≠ Approved blocks accesssow.model.ts → isActive(): status === APPROVED
Vigencia de contrato fuera del período bloqueaVigência de contrato fora do período bloqueiaContract period validation blocks accesssow.model.ts → isValidPeriod()
Actividades inhibitorias pendientes bloqueanAtividades inibitórias pendentes bloqueiamPending inhibitory activities block accesssow.state.ts → activitiesAreValid()
Bloqueo indeterminado prevalece sobre liberación manualBloqueio indeterminado prevalece sobre liberação manualIndefinite block overrides manual releaseworker-queue-dispatcher.service.ts → reasonsBlockingManualRelease + permanentRestriction
Proveedor no puede subcontratarse a sí mismoSupplier não pode subcontratar a si mesmoSupplier cannot subcontract itselfsubcontractor-sow.state.ts → SUPPLIER_CANNOT_SUBCONTRACT_HIMSELF
Liberación masiva de emergencia (botón de pánico)Liberação de emergência massiva (botão de pânico)Massive emergency release (panic button)release-access.service.ts → manualReleasePanicButtonAccess()
Hash MD5 evita envíos redundantes al AccessFyHash MD5 evita envios redundantes ao AccessFyMD5 hash prevents redundant sends to AccessFyhash-tracker.service.ts → checkHashAndSave()
Procesamiento orientado a eventos, sin cron diario fijoProcessamento orientado a eventos, sem cron diário fixoEvent-driven processing, no fixed daily cron⚠️event-tasks/ + tasks/ → Service Bus queues; @Cron(EVERY_MINUTE / EVERY_10_SECONDS)
05 — Única variación identificada 05 — Única variação identificada 05 — Single variation identified
Especificación original
Cron fijo a las 01:02 GMT+2
La documentación preveía una tarea programada hardcoded para disparo diario a las 01:02h.
Implementación real
Procesamiento por eventos y colas
No existe un horario diario fijo en el código. Los eventos de SAP Fieldglass alimentan colas de procesamiento y las tareas internas consumen esas colas con cadencia operacional.
Especificação original
Cron fixo às 01:02 GMT+2
Documentação previa tarefa agendada hardcoded para disparo diário às 01:02h.
Implementação real
Processamento por eventos e filas
Não existe horário diário fixo no código. Eventos do SAP Fieldglass alimentam filas de processamento e as tarefas internas consomem essas filas com cadência operacional.
Original specification
Fixed cron at 01:02 GMT+2
Documentation specified a hardcoded scheduled task for daily firing at 01:02h.
Actual implementation
Event and queue-driven processing
There is no fixed daily schedule in code. SAP Fieldglass events feed processing queues and internal tasks consume those queues with an operational cadence.
06 — Metodología de verificación 06 — Metodologia de verificação 06 — Verification methodology
Levantamiento de especificaciones funcionalesLevantamento das especificações funcionaisFunctional specifications gathering
Todas las reglas documentadas en data/ compiladas en un único documento de auditoría.Todas as regras documentadas em data/ compiladas num único documento de auditoria.All rules documented in data/ compiled into a single audit document.
Acceso al repositorio de código (src/)Acesso ao repositório de código (src/)Source code repository access (src/)
El equipo de desarrollo proporcionó acceso completo al repositorio de producción.Equipa de desenvolvimento forneceu acesso completo ao repositório de produção.Development team provided full access to the production repository.
Análisis IA: especificación vs. códigoAnálise IA: especificação vs. códigoAI analysis: specification vs. code
Cada regla comparada con archivo, método y línea correspondiente en el código fuente.Cada regra comparada com ficheiro, método e linha correspondente no código-fonte.Each rule matched to the corresponding file, method, and line in source code.
Producción del informe IMPLEMENTED_BUSINESS_RULESProdução do relatório IMPLEMENTED_BUSINESS_RULESIMPLEMENTED_BUSINESS_RULES report generated
Documento rastreable y entregable al cliente — disponible para auditoría independiente.Documento rastreável e entregável ao cliente — disponível para auditoria independente.Traceable document deliverable to client — available for independent audit.
Presentación al Steering CommitteeApresentação ao Steering CommitteeSteering Committee presentation
Este board — resultados y definición de próximos pasos.Este board — resultados e definição de próximos passos.This board — results and next steps definition.
07 — Próximos pasos 07 — Próximos passos 07 — Next steps
📄
Entregar informe técnico completo al clienteEntregar relatório técnico completo ao clienteDeliver full technical report to client
Disponibilizar el documento con las 121 reglas mapeadas para auditoría independiente por Navantia.Disponibilizar o documento com as 121 regras mapeadas para auditoria independente pela Navantia.Make the 121-rule mapping document available for independent audit by Navantia.
Responsable: Tech Lead — Plazo: 48hResponsável: Tech Lead — Prazo: 48hOwner: Tech Lead — Deadline: 48h
🔍
Revisión conjunta de logs de integraciónRevisão conjunta dos logs de integraçãoJoint integration log review
Sesión de trabajo con equipos técnicos de Navantia y AccessFy para mapear cada incidente a los logs de Service Bus.Sessão de trabalho com equipas técnicas da Navantia e AccessFy para mapear cada incidente aos logs de Service Bus.Working session with Navantia and AccessFy technical teams to map each incident to Service Bus logs.
Responsable: PM + Dev Lead — Plazo: 1 semanaResponsável: PM + Dev Lead — Prazo: 1 semanaOwner: PM + Dev Lead — Deadline: 1 week
🧪
Demostración en vivo en entorno de stagingDemonstração ao vivo em ambiente de stagingLive demonstration in staging environment
Ejecución de las reglas más cuestionadas en entorno controlado, con presencia del cliente, para validación presencial.Execução das regras mais contestadas em ambiente controlado, com presença do cliente, para validação presencial.Execution of the most questioned rules in a controlled environment with client presence for in-person validation.
Responsable: QA + PM — Plazo: 2 semanasResponsável: QA + PM — Prazo: 2 semanasOwner: QA + PM — Deadline: 2 weeks
📅
Cadencia de reporte quincenalCadência de reporte quinzenalBi-weekly reporting cadence
Establecer checkpoint técnico regular mientras el proyecto está en recuperación, con indicadores acordados con el cliente.Estabelecer checkpoint técnico regular enquanto o projeto está em recuperação, com indicadores acordados com o cliente.Establish regular technical checkpoints during project recovery, with client-agreed indicators.
Responsable: PM — Inicio: inmediatoResponsável: PM — Início: imediatoOwner: PM — Start: immediate

120 de 121 reglas funcionales verificadas y confirmadas en el código de producción.
Ninguna regla contratada está ausente.

La preocupación del cliente es legítima y nos la tomamos en serio. La respuesta es técnica, rastreable y auditable. Estamos listos para demostrar cada resultado.

120 de 121 regras funcionais verificadas e confirmadas no código de produção.
Nenhuma regra contratada está ausente.

A preocupação do cliente é legítima e levamo-la a sério. A resposta é técnica, rastreável e auditável. Estamos prontos para demonstrar cada resultado.

120 out of 121 functional rules verified and confirmed in production code.
No contracted rule is missing.

The client's concern is legitimate and we take it seriously. Our response is technical, traceable, and auditable. We are ready to demonstrate each result.