Límites y deuda técnica

Mentat es un MVP funcional, honesto sobre lo que es y lo que no. Estos límites están reconocidos desde el día uno, cada uno con su disparador de migración.

Lo que se puede configurar (sin código)

Properties: string, number, boolean, date, datetime, enum, reference.
Actions: rules modify / create / delete; validations permission / stateCheck; side effects notification / webhook.
Fuentes: CSV, REST (GET), webhook, manual.

Lo que NO se puede sin tocar código

⚠️

Si el caso del cliente necesita algo de esta lista, no es configuración: es desarrollo, y va por el proceso completo (documento maestro primero → ontology-core → código → tests → E2E).

Acciones por query / masivas. El target de una Action sale siempre de un parámetro reference (un objeto que el operador elige). No existe “aplicá esto a todos los que cumplan X” en una sola acción.
Acciones que modifican links (las rules cambian properties; modelá la relación como reference si tiene que mutar).
ETL avanzado (joins, transformaciones SQL). Solo mappings campo-a-campo con transformers por nombre.
Constructor visual de apps (drag-and-drop). Las apps se configuran por código y datos, no por el cliente.
Búsqueda full-text (tipo Algolia), paginación real, bulk operations.
functionCall / audit en Actions (forward-compat, no implementados).

Escala del MVP

Decisión actual	Límite	Disparador de migración
Firestore como única DB	sin joins ni agregaciones complejas	cuando un caso requiera queries que no soportamos
~50.000 objetos por caso	el Inbox filtra client-side (lee todos los del tipo)	cuando un tipo tenga cientos de miles de instancias
Multi-tenant lógico (Security Rules)	riesgo teórico cross-tenant	cliente con compliance crítico (salud/finanzas) → multi-tenant físico
Cloud Functions (timeout ~9 min)	no soporta batch muy largos	procesamientos > 50K objetos por corrida
Sin versionado de Ontología por snapshots	no hay rollback estructural	incidente por cambio mal hecho de Ontología
`metrics.firestoreOpsCurrentPeriod`	contador aproximado (cuenta las ops que las functions incrementan, no la facturación real)	si el costo necesita precisión contable

Deudas operativas conocidas

Onboarding sin panel de admin: el alta de usuarios es por scripts (no autoservicio). Es por diseño en el modelo “ingeniero acompaña” (estilo Foundry), pero el panel llegará.
Gating client-side (sin session cookies): una página protegida puede pestañear antes de redirigir. La autorización real vive en el backend.
Transición invited → active manual (hoy por script).

La migración futura (12-24 meses, si hay tracción) a un stack más especializado (PostgreSQL + servicios dedicados) está prevista desde el inicio. Cada límite de arriba tiene un disparador explícito: cuando se cumple, se discute — no antes.

Scripts (CLI)