Activación de plugins y paneles¶

La activación en runtime usa una sola fuente de verdad: el state store PostgreSQL (platform_plugin_state), expuesto en /control/plugins.

Flujo SaaS¶

pip install deja el plugin instalado en el catálogo (descubrimiento por entry points).
El superadmin (scope sudo) activa o desactiva en /control/plugins.
El framework carga hooks, routers y composición UI solo de plugins habilitados.
Los paneles de dominio (operations, admin, accounting, …) emergen cuando plugins habilitados inyectan módulos, widgets, layouts o settings en ese panel_id.
El panel control es de plataforma: embebido en el framework, siempre presente, no toggleable.

Variables obsoletas (no usar)¶

No existen en Settings ni en el bootstrap de producción:

CORTEX_ENABLED_PLUGINS
CORTEX_ENABLED_PANELS

Si aparecen en un .env heredado, eliminarlas; el runtime las ignora.

Paneles de plataforma vs namespaces de dominio¶

Concepto	Ejemplo	Cómo existe
Panel de plataforma	`control`	Bootstrap del framework (`/control/`)
Namespace de dominio	`operations`, `admin`	Plugins habilitados con `panel_id` en `register_*`
Namespace dedicado	`accounting`, `trainer`	Plugin host opcional vía `cortex.panels` + inyección

operations y admin son convenciones de namespace para separar operación diaria y parametrización; no son productos pip obligatorios.

API de control¶

Listar catálogo:

curl -H "Authorization: Bearer <token>" http://localhost:8000/api/v1/control/plugins

Habilitar un plugin (superadmin):

curl -X PATCH http://localhost:8000/api/v1/control/plugins/booking \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"enabled": true}'

Si la respuesta incluye requiresRestart: true, reinicia cortex-api para cargar entry points nuevos.

Tests¶

Los tests usan create_test_app(..., enabled_plugins="...") en cortex_framework.testing.apps — perfil solo para pytest, equivalente al state store pero en memoria.