diff --git a/backend/core/celery_app.py b/backend/core/celery_app.py
index 08b1c58..40b25c3 100644
--- a/backend/core/celery_app.py
+++ b/backend/core/celery_app.py
@@ -96,6 +96,10 @@ def _reset_rls_context_from_task(task_id=None, task=None, **_):
 celery_app.conf.update(
     include=[
         "api.v1.modules.core.help_center.tasks",
+        # Sin esta línea el worker rechaza las tareas del carril con "Received unregistered
+        # task of type 'expediente_gateway.deliver_outbox_row'": la fila queda en `pending`
+        # con 0 intentos y NUNCA se drena, aunque el encolado se vea perfecto.
+        "api.v1.modules.crm.expediente_gateway.tasks",
         # Agrega aquí las tareas de tu proyecto:
         # "api.v1.modules.example.tasks",
     ]
@@ -120,6 +124,25 @@ celery_app.conf.beat_schedule = {
         "task": "cleanup_orphan_layout_imports",
         "schedule": 3600.0,
     },
+    # Carril CRM -> EFC. Los tres intervalos vienen del carril de referencia de Anexo22: 120 s para
+    # las dos colas y 300 s para la reconciliación. El reintento NO es exponencial a propósito —el
+    # backoff corto vive en el cliente HTTP y el largo es este barrido de intervalo fijo.
+    #
+    # Estos barridos son la red que atrapa la ventana entre el encolado y el commit: el despacho
+    # inmediato puede llegar al worker antes de que la transacción confirme, no encontrar la fila
+    # y darse por vencido. Aquí se recoge.
+    "efc-sweep-outbox-every-2-min": {
+        "task": "expediente_gateway.sweep_outbox",
+        "schedule": 120.0,
+    },
+    "efc-sweep-file-outbox-every-2-min": {
+        "task": "expediente_gateway.sweep_file_outbox",
+        "schedule": 120.0,
+    },
+    "efc-sweep-expediente-gaps-every-5-min": {
+        "task": "expediente_gateway.sweep_expediente_gaps",
+        "schedule": 300.0,
+    },
 }
 
 if __name__ == "__main__":