Cómo funciona

Plataforma

Un programa, un modelo de datos, tres formas de entrar. Esta página explica cómo encajan las piezas.

Una instancia por negocio ​

Cada negocio funciona en su propia instancia, con su propia base de datos, sus propios usuarios y su propia dirección. En el servicio alojado, un plano de control crea la instancia por ti tras el registro y te da su dirección; la persona que se registró se convierte en su primer administrador. También puedes ejecutar el mismo programa tú mismo. Consulta Instancias.

El almacenamiento es SQLite para probar y PostgreSQL para un uso real. Por ahora, los registros se guardan como documentos JSON; la capa de comandos comprueba los tipos de los campos y está previsto un gestor de esquemas.

Los módulos son aplicaciones ​

Una aplicación es un módulo: una descripción de modelos, campos, grupos de permisos y acciones de flujo de trabajo. Cinco módulos vienen incluidos (Contacts, Products, CRM, Sales, Invoicing). Otros veintidós se distribuyen como paquetes. Añades aplicaciones desde el marketplace con un clic, o subes tu propio archivo.

Como todos los módulos pasan por un único registro, un contacto es el mismo contacto en CRM, Sales e Invoicing, y cada módulo obtiene la misma API, las mismas pantallas, los mismos permisos y las mismas reglas de privacidad. Consulta Aplicaciones y módulos y la lista de aplicaciones.

Marketplace ​

El marketplace es un host estático que sirve index.json y un obop.toml por paquete. El catálogo incluido viene dentro del programa; también puedes apuntar una instancia a tu propio host. Cada descarga se valida igual que una subida. Consulta Marketplace.

Permisos ​

Los grupos de permisos, como crm.user o invoicing.manager, se nombran en modelos, campos y acciones. Las personas pertenecen a grupos; los tokens de agente tienen un subconjunto de los grupos de su propietario. Consulta Grupos de permisos.

Clases de datos y enmascarado ​

Cada campo declara una clase de datos (ninguna, directorio público, interna, RR. HH. confidencial, categoría especial, financiera, secreta) y si es un dato personal. Las personas ven los valores según sus permisos. Los agentes ven los datos personales como tokens marcadores estables y las clases sensibles no las ven en absoluto, y pueden devolver tokens para referirse a un valor sin verlo. Consulta Clases de datos y enmascarado.

Flujos de trabajo y aprobaciones ​

Los cambios de estado son acciones con nombre. Una acción puede requerir un grupo más estricto y puede requerir aprobación. Un agente solo puede proponer una acción que requiera aprobación: el servidor devuelve un plan y no cambia nada hasta que una persona lo aprueba. Los agentes también solo pueden proponer la eliminación de registros. Consulta Flujos de trabajo y aprobaciones.

Tres superficies, un mismo conjunto de comandos ​

SuperficieParaCómo
Aplicación webPersonasGenerada a partir de las descripciones de los módulos: listas, tableros, formularios.
RESTScripts, servicios, agentesPOST /api/{model}/{command} con un bearer token. Referencia REST
MCPAsistentes de IAobop mcp sobre stdio, una herramienta por comando. Conectar mediante MCP
CLIShells y cronobop call model command key=value. Referencia de la CLI

Todas llaman al mismo despachador, por lo que las comprobaciones de permisos, el enmascarado y las aprobaciones son idénticos.

Lo que (todavía) no es ​

Ten en cuenta esto antes de comprometerte: no hay niveles de código, por lo que los módulos no pueden calcular campos ni ejecutar efectos secundarios; no hay permisos a nivel de fila; no hay registro de auditoría, ni herramienta de exportación de datos, ni copias de seguridad para el servicio alojado. La hoja de ruta indica qué está construido y qué no.