Módulos externos
manifest.json
El manifiesto describe qué es el módulo y qué superficies registra. Debe ser válido, legible y suficiente para que una persona pueda revisar el alcance antes de instalarlo.
El manifiesto describe qué es el módulo y qué superficies registra. Debe ser válido, legible y suficiente para que una persona pueda revisar el alcance antes de instalarlo.
Ejemplo mínimo ampliado
{
"slug": "reservas_demo",
"name": "Reservas Demo",
"version": "1.0.0",
"description": "Gestiona solicitudes de reserva relacionadas con clientes.",
"icon": "calendar",
"views": [
{
"id": "reservas.list",
"title": "Reservas",
"file": "views/list.php",
"menu": "CRM",
"order": 120,
"permissions": ["reservas.read"]
}
],
"actions": [
{
"id": "reservas.create",
"view": "reservas.list",
"file": "actions/create.php",
"permission": "reservas.write",
"methods": ["POST"]
}
],
"mounts": ["client.profile.panels"],
"depends_on": [],
"conflicts_with": [],
"suggests": [],
"provides": ["reservas"],
"consumes": ["clients", "calendar"],
"automation_nodes": [],
"agent_api": {
"version": 1,
"base_path": "/api/v1/agent/modules/reservas_demo/"
}
}Campos principales
| Campo | Uso |
|---|---|
slug | Identificador estable del paquete. |
name | Nombre visible para las personas. |
version | Versión compatible con SemVer. |
description | Resumen breve de la responsabilidad del módulo. |
icon | Icono permitido por el catálogo del CRM. |
views | Pantallas y sus permisos de lectura. |
actions | Operaciones, vista de origen, archivo, permiso y métodos admitidos. |
mounts | Puntos del CRM donde se inyecta UI o contexto. |
depends_on | Módulos necesarios para funcionar. |
conflicts_with | Módulos que no pueden coexistir. |
suggests | Integraciones opcionales recomendadas. |
provides / consumes | Capacidades que ofrece o utiliza. |
automation_nodes | Nodos que el módulo aporta al motor de automatización. |
agent_api | Contrato opcional para agentes autorizados. |
Buenas prácticas
- Declara solo permisos que realmente uses.
- Mantén los identificadores estables entre versiones.
- Evita dependencias circulares.
- Explica en el README qué datos crea y qué servicios externos necesita.
- No guardes secretos en el manifiesto.
- Si cambias una vista, acción o mount, documenta la compatibilidad y el impacto.
Estructura del paquete
Un paquete debe tener una raíz clara y un único manifest.json. La estructura recomendada para el contrato público v1 es:
Vistas y acciones
Las vistas presentan información y las acciones modifican datos o ejecutan procesos. La separación ayuda a aplicar permisos y evita que una pantalla termine concentrando lógica no relacionada.