Skip to main content

Fase 4: Automatización de Auditoría, Procesamiento de Fondo y Despliegue

Objetivo: Centralizar logs forenses mediante JSONB, habilitar colas de tareas asíncronas y lanzar la plataforma a la infraestructura global de Cloudflare.

1. Track Backend (.NET 10 & Docker Compose)​

[ ] Task 4.1: Interceptor Centralizado de Auditoría Forense​

  • Descripción: Automatizar el log de cambios en base de datos.
  • Detalle:
    • Sobreescribir el método SaveChangesAsync() en la clase del DbContext de EF Core.
    • Mapear el tracker del ORM para identificar inserciones, actualizaciones y borrados lógicos.
    • Serializar automáticamente el estado anterior y posterior de los registros en columnas JSONB de la tabla auditoria.logs, vinculándolos al ID del empleado ejecutor.

[ ] Task 4.2: Configuración de Colas Persistentes (Hangfire)​

  • Descripción: Implementar e instanciar el servidor de procesamiento en segundo plano.
  • Detalle:
    • Configurar Hangfire en la solución backend de .NET utilizando el esquema PostgreSQL como almacenamiento persistente de estados de tareas.
    • Declarar las políticas globales de reintento exponencial a 3 intentos para prevenir caídas definitivas de red con APIs externas.

[ ] Task 4.3: Implementación de Jobs Asíncronos (Timbrado CFDI 4.0 vía Factura.com)​

  • Descripción: Desacoplar las tareas lentas de la API del PAC del hilo principal del servidor.
  • Detalle:
    • Escribir el TimbradoJob asíncrono que consolida la venta y envía el Payload JSON a la API de Factura.com. Recibe el UID, descarga el XML/PDF timbrado y los persiste en Cloudflare R2 (ver § 15).
    • Implementar la política de reintentos exponenciales (2 min → 4 min → 8 min) y la clasificación de errores transitorios vs permanentes del PAC.
    • Escribir el CancelacionJob para gestionar cancelaciones de CFDI ante el SAT de forma atómica (SAT + reintegro de stock + ajuste contable).
    • Configurar las tareas periódicas mediante Cron de Hangfire: alertas sanitarias de caducidad, sugerencia automática de compras y evaluación diaria del candado contable de remisiones (>30 días).

[ ] Task 4.4: Empaquetado y Hardening de Producción​

  • Descripción: Preparar el entorno físico definitivo del backend y el proxy inverso.
  • Detalle:
    • Generar el Dockerfile de producción optimizado en múltiples etapas (Multi-stage build) para el backend .NET 10 (puerto interno 8080, sin exposición al host).
    • Redactar el Caddyfile de producción con: TLS de origen Cloudflare, headers de seguridad HTTP, rate limiting (20 req/s), health checks hacia .NET y soporte HTTP/3 (QUIC).
    • Actualizar docker-compose.yml de producción con los tres servicios: mdx-caddy (único con puertos públicos), mdx-backend (solo expose: 8080) y mdx-database (solo expose: 5432).
    • Configurar variables de entorno y llaves criptográficas en el archivo .env del VPS (nunca en Git): DB_PASSWORD, CLOUDFLARE_API_TOKEN, PAC_CONTRASENA, PAC_LLAVE_PRIVADA.
    • Aplicar hardening del VPS Linux: reglas UFW (solo puertos 80, 443 y 443/udp abiertos al exterior), invisibilidad total del puerto 5432 y 8080 desde el exterior.

2. Track Frontend (React SPA & Dexie.js)​

[ ] Task 4.5: Motor de Sincronización en Segundo Plano (Background Sync)​

  • Descripción: Automatizar el vaciado de todas las colas pending_* al recuperar la conexión.
  • Detalle:
    • Implementar observadores de red en el cliente de React (navigator.onLine + evento online).
    • Al recuperar la señal de red, el motor de sincronización procesa en orden:
      1. pending_pedidos → POST /api/ventas/pedidos
      2. pending_movimientos → POST /api/wms/movimientos
      3. pending_pickings → POST /api/wms/picking/confirmar
      4. pending_abonos → POST /api/credito/abonos
    • Cada petición se envía firmada con su Idempotency-Key original para garantizar que los reintentos de red no dupliquen registros.
    • Vaciar el registro de Dexie únicamente tras recibir HTTP 200/201 del backend.

[ ] Task 4.6: Panel de Control de Auditoría para Administradores​

  • Descripción: Diseñar una interfaz interactiva de trazabilidad operativa.
  • Detalle:
    • Desarrollar la vista de consulta de auditoría forense (auditoria.logs) en el frontend.
    • Habilitar visualización de diferencias estructuradas (diffs de campos antiguos contra nuevos) y filtros rápidos por ID de empleado y entidad.

[ ] Task 4.7: Script de Compilación Estática y Publicación Directa​

  • Descripción: Compilar y desplegar los assets de React en la nube global.
  • Detalle:
    • Crear el script de construcción de producción en package.json.
    • Configurar e instanciar Wrangler CLI para empujar la carpeta compilada directamente hacia los buckets globales de Cloudflare Pages.

[ ] Task 4.8: Estrategia de Caching del Service Worker (Workbox)​

  • Descripción: Optimizar los tiempos de carga estática de la PWA.
  • Detalle:
    • Configurar el Service Worker para aplicar estrategias CacheFirst y StaleWhileRevalidate en assets estáticos (fuentes de Google, iconos vectoriales, estilos de CSS) garantizando cargas inmediatas de interfaz en campo o mostrador.

[ ] Task 4.9: Manejo de Actualizaciones de la App (Prompt de Nueva Versión)​

  • Descripción: Notificar a los operadores la presencia de cambios en producción sin entorpecer su flujo.
  • Detalle:
    • Programar un Toast interactivo en React que reciba avisos del Service Worker al detectar que el manifest o el build cambió en Cloudflare Pages.
    • Presentar la opción de recarga en caliente de la aplicación sin alterar o borrar los datos locales activos en Dexie.js.

3. Track Infraestructura y Calidad​

[ ] Task 4.10: Configuración de Grupos de SignalR (Segmentación de Eventos)​

  • Descripción: Implementar el modelo jerárquico de grupos de SignalR para evitar la emisión de broadcast indiscriminado (ver § 11.6).
  • Detalle:
    • Al establecer la conexión WebSocket, suscribir cada cliente al grupo de su sucursal: Groups.AddToGroupAsync(connectionId, "Sucursal_{SucursalId}").
    • Configurar grupos por rol para eventos de autoridad (ej. Role_Gerentes para notificaciones de excepción de crédito).
    • Prohibir explícitamente el uso de Clients.All en cualquier Hub de negocio. Solo se permite en eventos de sistema como actualización de versión.

[ ] Task 4.11: Health Check del PAC y Panel de Salud de Servicios Externos​

  • Descripción: Implementar monitoreo activo del PAC para detectar indisponibilidad antes de que afecte el timbrado en producción (ver § 15.7).
  • Detalle:
    • Registrar el UrlGroup health check del PAC en el endpoint /health de .NET con failureStatus: Degraded.
    • Exponer el endpoint /health exclusivamente desde la red interna Docker (no accesible desde internet público).
    • Configurar Grafana para leer el estado del PAC y disparar alerta preventiva al equipo de soporte cuando el estado sea Degraded.