Operación y arquitectura de la eliminación permanente de empresas

Resumen ejecutivo y límite más importante

Neges distingue tres acciones diferentes: suspender, eliminar de forma lógica y solicitar una eliminación permanente. Suspender y eliminar lógicamente son reversibles. La eliminación permanente usa un flujo separado, reforzado y durable que sólo aparece cuando la empresa ya está archivada.

Este cierre por defecto es intencional: evita que una configuración incompleta, un error de ownership o una expectativa equivocada sobre backups y proveedores externos termine en una pérdida parcial e imposible de auditar.

Suspender, eliminar y eliminar permanentemente

Cómo opera un administrador de Platform

1. Revisa el interruptor de infraestructura

   TENANT_PURGE_WORKER_ENABLED debe estar en true si se espera que Strapi procese la cola. Si está en false o no existe, Configuración muestra un aviso explícito y el worker no toma jobs.

   Tip: Cambiar una variable de entorno requiere reiniciar o redesplegar Strapi.
2. Selecciona el modo en Platform / Configuración

   Abre /admin/settings/tenant-purge, elige Vista previa, Staging o Producción, indica la contraseña actual y, opcionalmente, el motivo del cambio.

   Tip: Si presionas Guardar sin cambiar el modo, la UI responde “No hay cambios para aplicar”.
3. Revisa las protecciones técnicas

   El acordeón resume ocho señales administradas por infraestructura. Producción no se puede guardar mientras cualquiera permanezca bloqueada.

4. Prepara la empresa

   En /admin/tenants/:documentId usa Eliminar para dejar la empresa archived. Una empresa active o suspended no puede entrar directamente a la cola permanente.

5. Abre Eliminación permanente

   La pantalla calcula el inventario, las filas contadas, los recursos sin ownership concluyente, los blockers y un digest del preview.

6. Confirma la solicitud

   Escribe exactamente el slug de la empresa, la frase ELIMINAR.PERMANENTEMENTE y tu contraseña actual. Strapi genera un challenge de un solo uso válido por cinco minutos.

7. Sigue el job

   Actualiza el estado y usa Verificar datos restantes, Reintentar o Cancelar cuando el estado lo permita. Conserva el documentId del job para soporte e investigación.

Modos de eliminación: Vista previa, Staging y Producción

El modo ya no es una variable de entorno. Se guarda como purgeMode en el single type platform_settings de PostgreSQL y se cambia desde /admin/settings/tenant-purge. Cada modificación aumenta revision y crea un registro en platform_setting_audits con actor, ambiente, valor anterior, valor nuevo, campos modificados y motivo.

Dos controles complementarios: infraestructura y operación

TENANT_PURGE_WORKER_ENABLED es un kill switch de infraestructura. Vive en el proceso de Strapi tanto en local como en Railway y no puede ser activado por la UI. purgeMode es una decisión operativa guardada en base de datos. Para que el worker procese un job deben cumplirse ambos controles: variable true y modo staging o production.

Qué son las ocho protecciones técnicas

Las protecciones son precondiciones de seguridad visibles en Configuración. No son simples adornos de UI: Strapi vuelve a evaluarlas en el backend. Para guardar Producción las ocho deben estar listas; además, el preview de una empresa puede añadir blockers específicos según sus datos.

Blockers específicos de una empresa

El catálogo resource-catalog.ts descubre content types tenant-aware, define la estrategia de ownership y cuenta hasta ocho recursos en paralelo. Los tipos globales no se borran; los recursos de ownership incierto se informan sin inventar un conteo. El digest SHA-256 del manifest evita aprobar un inventario y luego encolar otro distinto.

Arquitectura del control plane

El backoffice es la consola. Strapi conserva la autoridad: valida autenticación y rol Platform, aplica la allowlist de operadores destructivos, calcula el preview, crea el challenge, persiste los jobs y ejecuta el cron. PostgreSQL vuelve durable el proceso; cerrar el navegador o reiniciar el frontend no elimina el job.

neges-inbox participa como barrera externa: freeze impide nuevas escrituras asociadas al tenant y verify devuelve frozen, residualRows y conteos por tabla. GCS, backups y DTE se modelan actualmente como decisiones de retención y blockers; todavía no son ejecutados por un adaptador destructivo.

Flujo completo de una solicitud

Jobs durables, cancelar, reintentar y verificar residuos

Durable significa que la solicitud y cada paso se almacenan en PostgreSQL, no sólo en memoria. Un reinicio de Strapi no borra la intención ni su estado. El job guarda tenant, usuario solicitante, digest, preview, opciones, intentos, lease, errores y timestamps. Los steps guardan por separado freeze, destructive-gate y verify.

El worker usa un lease de 60 segundos con RAILWAY_REPLICA_ID o el PID local como owner. Si un proceso muere durante freezing y el lease vence, el siguiente ciclo marca el job failed con TENANT_PURGE_WORKER_LEASE_EXPIRED. La clave de idempotencia evita crear duplicados por doble clic o reintento de red.

Dónde vive el worker y cada cuánto corre

El worker está implementado en neges-strapi/config/cron-tasks.ts usando el cron integrado de Strapi. La expresión */1 * * * * ejecuta el ciclo cada minuto. processPending consulta Platform Settings y retorna sin trabajo si el resultado efectivo está apagado.

config/server.ts habilita el motor de cron si está activo tenant purge, notification outbox o domain verification. Por eso el cron global puede estar encendido aunque TENANT_PURGE_WORKER_ENABLED sea false; processPending aplica de nuevo el control específico y no procesa la cola de purge.

Variables de entorno

# Interruptor maestro de infraestructura. False o ausente = worker apagado.
TENANT_PURGE_WORKER_ENABLED=false

# IDs numéricos de usuarios Strapi autorizados a crear challenges y operar jobs.
TENANT_PURGE_ADMIN_USER_IDS=123,456

# Denylist de tenants que la UI nunca puede sobrepasar.
TENANT_PURGE_PROTECTED_DOCUMENT_IDS=documentId-critico

# Orígenes exactos permitidos para crear el challenge.
TENANT_PURGE_ALLOWED_ORIGINS=http://localhost:4300,https://backoffice.neges.cl

# Secreto aleatorio de 32 caracteres o más. No usar este ejemplo en producción.
TENANT_PURGE_CHALLENGE_SECRET=<secret-random-de-32-o-mas-caracteres>

# Barrera interna de neges-inbox.
TENANT_PURGE_INBOX_API_BASE_URL=http://localhost:3100/api
TENANT_PURGE_INBOX_INTERNAL_TOKEN=<token-interno>

# Aprobaciones explícitas. Mantener false hasta contar con evidencia real.
TENANT_PURGE_DTE_RETENTION_APPROVED=false
TENANT_PURGE_SHARED_BACKUP_RETENTION_ACCEPTED=false
TENANT_PURGE_GCS_RETENTION_ACCEPTED=false
TENANT_PURGE_UNRESOLVED_OWNERSHIP_ACCEPTED=false
TENANT_PURGE_DESTRUCTIVE_ADAPTERS_READY=false

Seguridad, reautenticación y auditoría

Operación segura e incidentes

1. Detención de emergencia

   Configura TENANT_PURGE_WORKER_ENABLED=false en el entorno afectado y reinicia Strapi. Esto detiene nuevos ciclos, pero no borra jobs ni revierte automáticamente una empresa ya congelada.

2. Cierre operativo sin cambiar infraestructura

   Cambia el modo a Vista previa desde Platform / Configuración. El cron sigue vivo para otros features, pero tenant purge deja de tomar jobs.

3. Inspección

   Conserva documentId del tenant y del job. Revisa purgeStatus, currentStep, blockerCodes, errorCode, attempts, leaseExpiresAt y los tres tenant_purge_steps.

4. Recuperación

   Si el job está blocked o failed, corrige la causa y usa Reintentar. Si la solicitud debe abandonarse, usa Cancelar para retirar la barrera de Inbox y volver a archived.

5. Evidencia

   Ejecuta Verificar datos restantes y conserva su result. No cambies estados directamente en PostgreSQL salvo un runbook de incidente revisado.

Contratos API y modelo persistido

Mapa de implementación para desarrolladores y agentes de código

neges-backoffice/
  src/app/features/platform-settings/       # modo, protecciones y auditoría
  src/app/features/platform-tenants/
    pages/platform-tenant-detail-page/       # suspender, eliminar, restaurar
    pages/platform-tenant-purge-page/        # preview, confirmación y job
    data-access/platform-tenant-purge.service.ts

neges-strapi/
  config/cron-tasks.ts                       # ciclo */1 * * * *
  config/server.ts                           # habilitación del cron de Strapi
  src/policies/require-tenant-purge-admin.ts
  src/api/platform-setting/                  # purgeMode y auditoría
  src/api/tenant-purge/                      # preview, challenge, worker y acciones
  src/api/tenant-purge-job/                  # job durable
  src/api/tenant-purge-step/                 # evidencia por paso
  src/api/tenant-purge-challenge/            # challenge temporal
  src/api/tenant-purge/services/resource-catalog.ts

neges-inbox/
  endpoint interno tenant-purge              # freeze, unfreeze y verify

Las reglas decisivas deben permanecer en Strapi. El backoffice puede anticipar validaciones para UX, pero no debe decidir elegibilidad, gates ni estados finales. Al ampliar el inventario, resource-catalog.ts debe cubrir cada nuevo content type tenant-aware; su guard de cobertura existe para impedir que un recurso nuevo quede fuera silenciosamente.

El feature usa documentId como identificador público de Strapi 5. Los jobs, steps y challenges son content types de control, no datos de negocio del tenant, y se excluyen del catálogo destructivo. Los cambios en estos endpoints deben mantener DTOs estrictos y actualizar las pruebas del backoffice y de Strapi.

Pruebas y camino para habilitar borrado físico

Diagnóstico rápido