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:

mi-modulo/
├── manifest.json
├── README.md
├── CHANGELOG.md
├── views/
├── actions/
├── mounts/
└── db/
    ├── install.mysql.sql
    ├── install.sqlite.sql
    ├── uninstall.mysql.sql
    └── uninstall.sqlite.sql

Los directorios solo son necesarios cuando el módulo utiliza esa superficie. Un módulo de integración que no almacena datos puede omitir db/.

Reglas del ZIP

• El ZIP contiene una única carpeta raíz del módulo.
• Hay un solo manifiesto en esa raíz.
• El nombre del directorio coincide con slug.
• No se incluyen .env, claves, tokens, volcados de base de datos ni archivos de desarrollo local.
• No se incluyen repositorios .git, dependencias innecesarias ni artefactos de compilación.
• Las rutas declaradas en el manifiesto usan / y respetan mayúsculas y minúsculas.

Convenciones

Usa un slug estable, en minúsculas, con números o guiones bajos. No lo cambies para corregir el nombre comercial: el slug identifica el módulo instalado.

Los identificadores de vistas, acciones y mounts también forman parte del contrato. Prefija los nombres propios del módulo cuando puedan coincidir con otra extensión, por ejemplo reservas.list o reservas.create.

Datos y desinstalación

Si el módulo crea tablas, ofrece instalaciones equivalentes para MySQL y SQLite. Las migraciones de una actualización deben ser explícitas y reversibles cuando sea posible. La desinstalación debe indicar si elimina datos, los conserva o requiere una exportación previa.

No dependas de tablas internas del CRM. Usa las capacidades y contratos públicos disponibles para relacionarte con clientes, prospectos, tareas o tickets.