audfact-audit-gemini

Imported from jfrem/AudFact (.agent/skills/audfact-audit-gemini/SKILL.md). Install upstream with npx skills add jfrem/AudFact --skill audfact-audit-gemini. Copyright stays with the author.

AudFact Audit Gemini (Event-Driven)

Objetivo

Mantener confiable el pipeline event-driven de auditoría documental con Redis Streams, extracción Gemini por Structured Outputs nativos (responseSchema), normalización y policy en PHP puro, y persistencia final en SQL Server.

Archivos clave

Servicios del pipeline event-driven

Workers bootstrap (largas ejecuciones)

Tras la consolidación AUDIT-015 (2026-04-27), existe un único launcher bin/audit-worker.php que recibe el nombre de worker como primer argumento CLI y selecciona el consumer mediante un registry interno:

El launcher carga .env, instancia el consumer correspondiente, registra SIGTERM/SIGINT para stop gracioso y llama run(); pcntl_signal_dispatch se procesa dentro del loop del consumer base. Los consumer names son únicos por rol + hostname + PID para que Redis refleje réplicas reales. El inicio registra grupo, consumer, carril, streams, bloqueo, reintentos y límites de reclaim. Compose separa extracción en servicios VIP y batch usando el mismo launcher.

Controllers y endpoints

Streams y eventos

Invariante de transporte (2026-09-23)

Orquestación, descarga, extracción (éxito/cache/rechazo), normalización, reglas, persistencia y fallo terminal usan AuditEvent::followUp(eventType, payload, documentId). Conserva audit_id, job_id y referencia al evento padre; documentId es un argumento obligatorio: ID en etapas documentales y null explícito en etapas consolidadas. El payload funcional no puede reemplazar source o is_priority: esas claves provienen exclusivamente del evento padre. No inferir source=single desde prioridad o job_id=null; no copiar todo el payload anterior para conservar solo transporte. El clasificador sigue siendo AuditEventPublisher::isPriorityEvent() (source === 'single' o booleano true). Cada señal basta aunque falte la otra; eventos directos sin ambas quedan en batch, independientemente de job_id. No aceptar strings o enteros como booleano true. El orquestador usa followUp() tanto para registros como para rechazos de mapping; buildDocumentState() construye solo contexto funcional, sin copiar transporte. La lista cerrada ROUTING_PAYLOAD_KEYS y el helper privado inheritRoutingMetadata() concentran la copia de transporte; no duplicar esa lógica en workers ni exponer helpers productivos solo para pruebas.

RulesEvaluationWorker aplica transporte después de recuperar el outcome canónico de Redis, por lo que un reintento conserva origen y carril. audit_failed se publica en AuditEventConsumer; audit_completed, en AuditPersistenceWorker, después del cierre Redis. No publicar rules_evaluated fuera de AuditPersistenceQueue.

PEL no equivale a backlog sin entregar: /metrics/async suma PEL de varios grupos y no demuestra bloqueo en policy. El despliegue no corrige eventos antiguos sin metadatos. Diagnóstico y recuperación: ver plans/features/audit-workflow.md, sección «Despliegue, diagnóstico y recuperación del desvío a batch». Mantener consumidores batch activos durante el drenaje; no borrar ni duplicar mensajes para adelantar una auditoría.

Variables de entorno relevantes

GEMINI_MODEL es el único selector de versión de modelo usado por el gateway. GeminiConfig conserva un fallback local si la variable falta, pero GEMINI_EXTRACTION_* y GEMINI_SEMANTIC_* son perfiles de generación del mismo modelo configurado; no implementan fallback ni redirección a otra versión Gemini.

Flujo técnico

1. POST /audit/single valida DisDetNro → publica audit_created en audit.inbox.priority → retorna 202 con audit_id.
2. DocumentAuditOrchestrator consume audit_created, resuelve FDV, audit-config, catálogo y todos los adjuntos físicos. Ejecuta una sola reconciliación global mediante DocumentAttachmentMatcher: nombre exacto normalizado, ID corroborado y alias único. Cada attachment_id se usa como máximo una vez. Los matches publican document_registered con trazabilidad lógica/física; missing, ambiguous, no content y reused se registran como rechazados y publican document_rejected con rejection_category=DOCUMENT_MAPPING, sin descarga ni Gemini. La regla Autorizacion=R reutiliza ese mismo resultado y solo transforma ausencia real en el hallazgo sintético AUT existente.
3. AttachmentDownloadWorker consume document_registered, descarga el adjunto y lo almacena temporalmente en Redis con key lógica audit:blob:* (RedisClient aplica REDIS_PREFIX). Para BLOB exige bytes === DATALENGTH. Publica document_downloaded; fuente ausente/vacía, transferencia parcial, SQL o Drive son fallos técnicos y se propagan, nunca publican document_rejected.
4. DocumentExtractionWorker consume document_downloaded, lee el BLOB desde Redis y evalúa su integridad estructural mediante DocumentIntegrityValidator. Es el único productor autorizado de rechazos de contenido: todo rechazo incluye rejection_class=document_content, origen exacto y razón de DocumentRejectionReason. Si es válido, calcula document_hash, arma prompt compacto, consulta cache; si no hay hit, invoca Gemini con Structured Outputs nativos (responseSchema y responseMimeType: application/json). Si Gemini lanza HTTP 400 por error de decodificación o archivo corrupto confirmado, emite el rechazo tipado. Si es exitoso, parsea, rehidrata los campos planos a la forma canónica y publica document_extracted.
5. DocumentNormalizer normaliza fields/items/visual_checks (fechas ISO, identidad documental, numéricos canónicos, evidencia visual estructurada, null para vacío) y emite document_normalized con normalization_log sin PII cruda.
6. RulesEvaluationWorker evalúa document_normalized contra FDV usando DocumentPolicyEngine; FDV y documento se resuelven primero como ResolvedAuditValue. Valida dos contratos cerrados sin fallback: contenido solo desde DocumentExtractionWorker y mapping solo desde DocumentAuditOrchestrator. Mapping genera hallazgo MAP, severidad alta, RECHAZADO e integrity, preservando logical_doc_id y candidatos. Cualquier evento legacy o DOWNLOAD_ERROR falla técnicamente. Espera docs_done + docs_rejected >= docs_total, guarda el outcome y lo encola en AuditPersistenceQueue.
7. AuditPersistenceQueue publica un único turno activo por job en audit.persistence.priority o audit.persistence.batch; sin job usa un scope por auditoría. Jobs diferentes usan las réplicas configuradas en paralelo. audit.persistence:{queue}:* contiene claves de scheduling, no streams.
8. AuditPersistenceWorker aplica una barrera independiente contra DOWNLOAD_ERROR y contratos de rechazo inválidos, ejecuta la transacción dual idempotente sobre AudDispEst + AdjuntosDispensacion + DispensacionDetalleServicio, libera el turno y publica audit_completed.
9. SQL usa PDO fresco por operación y replay interno solo para lectura/escritura idempotente, con pausas de 1/5/30 segundos. Al agotar SQL o ante un fallo técnico tipado de descarga, AuditEventConsumer genera dead_letter, hace ACK y ejecuta el cierre terminal en la misma entrega; no espera XAUTOCLAIM.

Resiliencia y Manejo de Errores Documentales (Pre-IA y Post-IA)

flowchart TD
    A[Descarga de Documento / BLOB] --> B[Nivel 1: DocumentIntegrityValidator]
    B -->|PDF sin %%EOF o Truncado| C[Rechazo Preventivo: CORRUPTED_DOCUMENT]
    B -->|PDF sin Páginas| D[Rechazo Preventivo: EMPTY_PDF_NO_PAGES]
    B -->|PDF con Password| E[Rechazo Preventivo: ENCRYPTED_DOCUMENT]
    B -->|Estructura Válida| F[Llamada a Google Gemini API - Structured Output]

    F -->|200 OK| G[document_extracted]
    F -->|400 Decode Error / Corrupt File| H[Nivel 2: DocumentExtractionWorker]
    H -->|Clasificación Determinista| I[Rechazo: GEMINI_DECODE_FAILURE]

    C --> J[Emitir document_rejected]
    D --> J
    E --> J
    I --> J
    J --> K[Incrementar docs_done 3/3]
    G --> K
    K --> L[RulesEvaluationWorker: Sellar Auditoría y Batch al 100%]

Reglas de implementación (estrictas)

1. IA sólo extrae: Gemini nunca toma decisiones de negocio finales; la comparación y aplicación de severidades dinámicas (CRITICO, ALTA, MEDIA, BAJA, INFO) viven en DocumentPolicyEngine según el audit-config. Las señales de disconformidad tipológica (document_conformity.matches_expected_type === false) emiten hallazgo TIP con resultado NO_CONCLUYENTE y derivación a revisión humana, evitando rechazos definitivos automáticos basados en un único booleano de la IA.
2. TipoCampo gobierna la comparación y TipoDato gobierna el valor — fuente de verdad: columnas TipoCampo y TipoDato en Discolnet.dbo.AudDispCampo.
   • TipoCampo=E → EXACT (igualdad normalizada)
   • TipoCampo=S → SEMANTIC (umbral 0.82; Gemini solo si TipoDato=article_name)
   • TipoCampo=B → BUSINESS (sumatoria de items + comparación numérica; solo TipoDato=quantity)
   • TipoCampo=V → VISUAL (vive en visualChecks[]; no usa TipoDato)
   • TipoDato permitido: text, date, quantity, money, identity_doc_type, identity_doc_number, code, trace_token, person_name, institution_name, article_name, nit, auth_number. Prohibido inferir TipoDato por nombre del campo. AuditFieldValueType::fromInput() debe recibir metadata explícita del audit-config. La ubicación extract_fields vs extract_items la define DocumentExtractionContractBuilder con reglas explícitas de dominio para evitar mezclar cabecera y líneas.
3. [AUDIT-016] Subset matching para CODE: Campos con AuditFieldValueType::CODE usan evaluateSubsetField(). Si el FDV tiene un código (ej. S202) y el documento lista múltiples (ej. S202, S273, F432), se evalúa como COINCIDE con tipo_auditoria=exact. Si la evidencia llega como valor=null, valores=[...] y FOUND_IN_LIST, FieldValueResolver debe usar valores como evidencia encontrada, no emitir NO_ENCONTRADO. tokenizeCodeField() separa por coma, punto y coma o barra; normaliza a mayúsculas. El hallazgo incluye valueType=code y valoresDocumento (array de tokens).
4. [TRACE_TOKEN] Set-based matching para Trazabilidad: Campos como Lote usan TRACE_TOKEN. FDV y documento se resuelven como sets desde ResolvedAuditValue; si ambos sets son iguales, es COINCIDE. Si el documento trae solo una parte de un FDV múltiple, es NO_CONCLUYENTE (evidencia parcial). Si trae un lote no registrado en FDV, es VALOR_DISTINTO. El hallazgo incluye valoresFuenteVerdad y valoresDocumento.
5. [AUDIT-016] Token-sort para PERSON_NAME: Campos PERSON_NAME en modo semántico usan una heurística estructural de similitud por tokens (exigiendo que al menos 1 token de la parte más corta coincida exactamente). Si la heurística falla, hace fallback a SemanticMatchJudge para validar posibles alias o variaciones de escritura vía Gemini.
6. [AUDIT-016] No data-loss en multi-item/lista divergente (CAT-1): Si resolveDocumentValue() encuentra múltiples items con valores distintos en un campo no sumable, o una evidencia escalar con varios candidatos valores, emite NO_CONCLUYENTE con detalle: {ambiguous: true, valores: [...]}. Un único candidato en valores se usa como escalar. Ya no se descarta silenciosamente el campo ni se convierte en NO_ENCONTRADO cuando existe evidencia.
7. [AUDIT-016] Hallazgo canónico v1: buildDataFinding() inyecta valueType; para CODE y TRACE_TOKEN agrega valoresFuenteVerdad y/o valoresDocumento cuando existen tokens/set evaluables. Las cantidades TipoCampo=B reportan valorFuenteVerdad y valorDocumento como sumatoria agregada de items. Si un hallazgo configurable falla y existe codigoCampo, el detalle se enriquece con el prefijo textual -CODIGO- detalle.
8. Items y Reconciliación Multilote: no derivar items desde fields y viceversa. FdvItemAggregator consolida previamente la FDV agrupando por campos no sumables (código de producto, lote, CUM, etc., sin importar si tipoCampo es B, E o S), calculando con precisión $expectedItemsCount para documentos consolidados (ej. autorizaciones multilote). Si el extractor detecta segmentación incompleta, emite el warning ITEM_SEGMENTATION_INCOMPLETE en el payload. Luego, DocumentPolicyEngine evalúa primero si la comparación cuantitativa directa resulta en COINCIDE (balance 100% satisfecho); de ser así emite COINCIDE con telemetría en extraction_meta. Si el balance no coincide (faltante real), fuerza NO_CONCLUYENTE a nivel de línea (TipoCampo=B) para evitar sumatorias parciales peligrosas.
9. Prompt compacto de extracción: Gemini no recibe valores esperados de FDV (Campos de cabecera esperados, Campos de línea esperados, diagnósticos, fechas, identidad, etc.). Solo recibe contexto estructural: documento objetivo, campos solicitados, separación identidad, ubicación fields/items, checks visuales y segmentación de filas cuando aplican. El schema puede usar descripciones configuradas del audit-config como valor.description y conserva las descripciones PHP solo como fallback; el system prompt personalizado se deduplica contra esas descripciones antes de calcular prompt_context_hash. En el schema Gemini, valores se declara como array de strings solo para TRACE_TOKEN; los campos CODE son escalares y se tokenizan en PHP; DocumentNormalizer reconstruye valores desde valor para escalares. Las pistas de artículo para documentos prescriptivos se permiten solo cuando NombreArticulo está en items.
10. Comparación determinista: umbrales persona 0.85, artículo 0.82, texto 0.90; numéricos/IDs/fechas con igualdad normalizada.
11. Cadena documental: Fórmula → Autorización → Dispensa. El audit-config runtime no persiste rol; todo campo activo en fields se evalúa según TipoCampo y severidad.
12. Entrega parcial válida: cantidad_entregada_total <= cantidad_autorizada (o cantidad_prescrita si no hay autorización).
13. Exclusiones documentales: no documentar campos como "informativos" si el audit-config real no trae esa marca. Para omitir un campo de auditoría debe no estar activo en fields; omitirSi no está implementado en el runtime actual.
14. Sin código legacy: clean rebuild; no agregar shims ni compatibilidad con el pipeline monolítico anterior.
15. XACK solo tras éxito: acknowledge después de publicar el evento siguiente o persistir resultado final.
16. Errores técnicos de Gemini no son detalle funcional: loguear el error, devolver NO_CONCLUYENTE limpio y no cachear fallos transitorios del fallback semántico.
17. Métricas Gemini por tarea: preservar gemini_extraction, gemini_semantic y gemini_total en phase_timings, incluyendo respuestas malformadas cuando Gemini entregue usageMetadata.
18. Perfiles Gemini aislados: mediaResolution solo se permite en perfil extraction; semantic_match debe ser text-only, con cache semántica versionada. Política de homologación matizada: omisión de marca/modelo/presentación comercial es compatible (los médicos no prescriben marcas), pero omisión de dosis/concentración cuando el otro producto la especifica es unresolved_differences=true y decisión PHP conservadora (INCONCLUSIVE).
19. Visuales calculables: VigenciaEntrega no se cierra como booleano en DocumentPolicyEngine; Gemini extrae valor, unidad y fecha_base, DocumentNormalizer los canoniza y RulesEvaluationWorker calcula FechaEntrega <= fecha_base + valor. Si falta evidencia suficiente en un visual activo, el resultado agregado es NO_CONCLUYENTE.
20. Identidad canónica E2E: DisId de auditoría debe cumplir vw_discolnet_dispensas.DisId == AudDispEst.FacSec (columna legacy). DisDetNro/Dispensa se persiste como AudDispEst.FacNro, que es la PK operativa de resultados; AuditResultPersistenceModel hace el upsert serializable y AuditStatusModel consulta detalle y timings por FacNro. Ver plans/audit-identity-contract.md.
21. Persistencia justa y atómica: máximo un evento SQL activo por job; nunca separar el resumen, los hallazgos del adjunto y la trazabilidad en transacciones distintas.
22. Sin bypass de scheduling: está prohibido publicar rules_evaluated mediante AuditEventPublisher; usar siempre AuditPersistenceQueue.
23. Fallo técnico no es rechazo documental: PDO, SQL Server, Drive, fuente ausente/vacía durante descarga y transferencia parcial deben propagarse como excepciones técnicas. Está prohibido emitir DOWNLOAD_ERROR, document_rejected o un hallazgo funcional desde descarga. La ausencia o falta de contenido detectada durante la reconciliación de metadata sí pertenece a DOCUMENT_MAPPING y ocurre antes de encolar descarga.
24. Productores segregados y defensa en profundidad: DocumentAuditOrchestrator solo publica rechazos DOCUMENT_MAPPING; DocumentExtractionWorker solo publica rechazos document_content. RulesEvaluationWorker valida categoría/clase, origen y allowlist, y AuditPersistenceWorker repite la barrera antes de SQL.
25. Reconciliación cerrada 1:1: no seleccionar el primer candidato ni reutilizar un attachment_id. La única API del matcher es matchAll() y las únicas estrategias válidas son exact_name, validated_id y unique_alias.

Aplicabilidad condicional por servicio (AplicaServicio)

Vigencia de entrega por cliente

DocumentAuditOrchestrator copia auditConfig.diasVigencia a dias_vigencia del estado Redis. Conserva null y evita otra consulta desde policy. DeliveryValidityEvaluator prioriza evidencia visual completa, luego entero positivo configurado y finalmente 60 días. Usa el enum interno DeliveryValiditySource para distinguir el origen en detalle; no serializa el enum ni cambia la firma pública evaluate(array, array).

El sistema soporta aplicabilidad condicional declarativa por modalidad de servicio (AplicaServicio: TODOS, POS, MIPRES, etc.):

• DocumentAuditOrchestrator::resolveServiceType() extrae dinámicamente la clave canónica 'Tipo' de los ítems de la Fuente de Verdad ($fuenteVerdad['items']).
• Al armar configuredDocuments, DocumentAuditOrchestrator filtra en memoria los fields y visualChecks según el servicio resuelto ($aplica === 'TODOS' || $serviceType === 'TODOS' || $aplica === $serviceType).
• Los campos o checks visuales no aplicables (por ejemplo FirmaPrescriptor con AplicaServicio = 'POS' en una entrega con Tipo = 'MIPRES') se eliminan en PHP antes de compilar el contrato de Gemini (DocumentExtractionContractBuilder), ahorrando tokens y previniendo falsos rechazos en prescripciones electrónicas.
• AuditConfigModel::getConfig() retorna aplicaServicio en cada campo y check visual; AuditConfigController::sanitizeFields() lo valida y AuditConfigModel::replaceFields() lo persiste en Discolnet.dbo.AudDispCampo.

Implicación operativa:

• Si un campo tiene AplicaServicio = 'TODOS', se audita siempre en cualquier tipo de entrega.
• Si un campo tiene AplicaServicio = 'POS', solo se audita cuando items[].Tipo === 'POS'.
• Si un campo tiene AplicaServicio = 'MIPRES', solo se audita cuando items[].Tipo === 'MIPRES'.
• OMITIDO puede aparecer adicionalmente por condiciones internas del engine cuando hay ausencia simultánea de valor FDV y valor documental auditable.

Agregación de items en reglas B

Para TipoCampo = B, DocumentPolicyEngine suma los items de la FDV antes de comparar contra valorDocumento. Caso real T38250701547 (NitSec 2426): la FDV tiene 2 items con CantidadEntregada = 20 y 30; el hallazgo persistido reporta valorFuenteVerdad: "50", valorDocumento: "50", tipo_auditoria: "business", resultado: COINCIDE. Implicación: nunca documentar reglas B como "campo a campo" — son agregadas a nivel documento.

Contrato real de hallazgo (v1 — AUDIT-016)

Forma canónica del objeto en AudDispEst.Hallazgos[*]:

{
  "severidad":          "alta|media|baja",
  "campo":              "<nombre>",
  "documento":          "DISPENSA|AUTORIZACION|FORMULA MEDICA|...",
  "valorDocumento":     "<valor extraído por Gemini>",
  "valorFuenteVerdad":  "<valor de la FDV>",
  "resultado":          "COINCIDE|VALOR_DISTINTO|NO_ENCONTRADO|OMITIDO|NO_CONCLUYENTE|RECHAZADO",
  "detalle":            "<string|null>",
  "tipo_auditoria":     "exact|semantic|business|visual|integrity",
  "valueType":          "text|date|quantity|money|identity_doc_type|identity_doc_number|code|trace_token|person_name|institution_name|article_name",
  "valoresFuenteVerdad":["5D03364","5G00989"],    // opcional para CODE/TRACE_TOKEN
  "valoresDocumento":   ["5D03364","5G00989"]     // opcional para CODE/TRACE_TOKEN
}

[!NOTE] valueType, valoresFuenteVerdad y valoresDocumento son campos v1 inyectados por buildDataFinding(). valueType debe salir del TipoDato explícito del audit-config, no del nombre del campo. Para resultados fallidos (VALOR_DISTINTO, NO_ENCONTRADO, NO_CONCLUYENTE y RECHAZADO cuando haya código disponible), el detalle inicia con el prefijo textual -<codigoCampo>- tomado de AudDispCampo.CodigoCampo; no se agrega una propiedad pública separada.

El contrato runtime actual no incluye rol en hallazgos. Visual checks booleanos emiten un objeto similar, sin valueType; los visuales calculables como VigenciaEntrega emiten tipo_auditoria: "visual" desde la agregación de reglas.

Nota Gemini 3.x — thinking tokens

En Gemini 3.x los thinking tokens pueden superar 4× los output tokens (caso T38250701547: 5 594 thinking vs 1 177 output en extracción). Considerar al ajustar GEMINI_*_MAX_OUTPUT_TOKENS y GEMINI_*_THINKING_BUDGET para no truncar respuestas válidas.

Anti-patterns ⚠️

1. No consultar vistas SQL directamente desde workers para FDV/adjuntos — usar AuditDataService y AttachmentDownloadService.
2. No incluir base64, binarios o credenciales en el payload de eventos (solo en claves de estado Redis).
3. No inyectar valores FDV esperados en el prompt de extracción; Gemini extrae evidencia visible y PHP compara.
4. No fabricar items desde fields en normalizador o policy.
5. No borrar mensajes de streams; dejar ack/retry/DLQ hacer su trabajo.
6. No mezclar dos responsabilidades en un worker: cada etapa publica exactamente un evento siguiente.

Ejemplos

Validar contrato POST /audit/single

curl -X POST http://localhost:8080/audit/single \
  -H "Content-Type: application/json" \
  -d '{"DisDetNro":"T38250701547"}'
# Respuesta esperada: 202 { "data": { "audit_id": "...", "status": "pending", ... } }

Golden case (validación humana obligatoria)

Invoke-RestMethod -Uri "http://localhost:8080/audit/single" `
  -Method POST -ContentType "application/json" `
  -Body '{"DisDetNro":"T38250701547"}' | ConvertTo-Json -Depth 20

Resultado esperado: EstadoDetallado: "manual_review", 34 coincidencias, 1 discrepancia (NO_ENCONTRADO CodigoDiagnostico en FORMULA MEDICA), 1 NO_CONCLUYENTE (NombreArticulo por homologación de artículo).

Levantar los workers localmente

php bin/audit-worker.php orchestrator &
php bin/audit-worker.php downloader &
php bin/audit-worker.php extraction &
php bin/audit-worker.php normalizer &
php bin/audit-worker.php policy &
php bin/audit-worker.php persistence &

Listar DLQ

curl http://localhost:8080/audit/dlq?limit=20

Checklist rápido

1. POST /audit/single responde 202 con audit_id.
2. POST /audit/async responde 202 con job_id.
3. Workers procesan el flujo completo para T38250701547 (cliente 2426).
4. Búsqueda de nombres legacy de cola y llamadas Redis list (LPUSH/BRPOP) sin coincidencias; tampoco debe existir orquestador monolítico anterior en app/Services/Audit/.
5. audit.dlq recibe dead_letter al agotar reintentos.
6. Persistencia final transaccional en AudDispEst + AdjuntosDispensacion + DispensacionDetalleServicio.
7. PHPUnit completo verde antes de merge; suite organizada bajo tests/.
8. php vendor/bin/phpunit tests/Services/Audit/GoldenSetReplayTest.php --no-coverage valida los fixtures golden.
9. Hallazgos de tipo CODE/TRACE_TOKEN incluyen valueType y arrays de valores FDV/documento cuando aplican.
10. Multi-item divergente emite NO_CONCLUYENTE con ambiguous=true, no silencio.

⚠️ Auto-Sync (OBLIGATORIO post-implementación)

Después de cualquier cambio en el pipeline event-driven:

1. Verificar que los archivos listados en "Archivos clave" existan.
2. Confirmar que streams y consumer groups siguen alineados con AuditEventPublisher y AuditEventConsumer.
3. Ejecutar audfact-docs-sync como segunda capa.

[!CAUTION] Dejar la skill desactualizada genera drift que confunde a agentes futuros.

Referencias

• Sprint checkpoints: plans/checkpoints/
• Skill asociada para modelos SQL: audfact-sqlsrv-models
• Mapeo TipoCampo → tipo de comparación: app/Services/Audit/AuditComparisonType.php
• TipoDato explícito y reglas de compatibilidad TipoCampo/TipoDato: app/Services/Audit/AuditFieldValueType.php
• Casos de validación E2E: plans/changelog.md (entradas DOCS-SYNC y AUDIT-014/015)