❌ No es solo CMMS
Maintenance es una puerta de entrada, no el techo. Incluye OT y activos; no se define por ellos.
Sprint 6 · Arquitectura de plataforma
¿Cómo está construido Roustix
¿Cómo está construido Roustix
y hacia dónde crecerá?
El Architecture Handbook del producto. No es documentación de Flask — es documentación de plataforma.
Toda la operación.Una sola plataforma.
MPA-01-VIS
01 · Visión de plataforma
Sprint 6.1 · Cimiento del MPA
La identidad del producto.
Si el Brand Book explica la identidad de la marca, MPA-01 explica la identidad del producto.
MBB · Marca
¿Quiénes somos? Historia, voz, pilares, isotipo.
MPA · Producto
¿Qué construimos? EMP, módulos, tenancy, visión 10 años.
¿Qué es realmente Roustix?
Una Enterprise Management Platform (EMP) — SaaS multi-tenant que permite controlar la operación activando solo los módulos necesarios hoy, con crecimiento mañana sin cambiar de sistema.
❌ No es ERP tradicional
No compite con SAP. Compite con Excel + WhatsApp + caos operativo. Operación primero.
✅ Es EMP
Enterprise · Management · Platform. Una base, módulos activables.
EMP · Las tres palabras
| Enterprise | Tenant real: empresa, usuarios, roles, sedes, aislamiento empresa_id |
| Management | Gestión operativa diaria: activos, stock, compras, ventas, KPIs |
| Platform | Un codebase · módulos en modules.py · API e integraciones futuras |
Origen dual → una arquitectura
🇨🇴 Maintenance
Industrial Colombia — activos, OT, disponibilidad. Clave: mantenimiento.
🇻🇪 Inventory
Comercio Venezuela — stock, compras, ventas. Clave: inventario.
Mismo dolor: información dispersa. Misma decisión: una plataforma, no dos apps.
Principios inmutables
- 1Una plataforma — sin ediciones ni forks por industria
- 2Tenant primero —
empresa_iden toda entidad de negocio - 3Módulo explícito — registrar antes de exponer rutas
- 4Sector = configuración — plantillas, no tablas duplicadas
- 7Crecimiento interno — activar módulo, no migrar sistema
Visión · 10 años
2026 – 2028
Fundación: Maintenance + Inventory + Purchasing → ejecución guiada, CRM y Finance. EMP de referencia LatAm.
2029 – 2031
Ecosistema: API pública, marketplace, mobile, AI operativo. Hub que conecta con ERP del cliente.
2032 – 2036
Enterprise: 10 000+ empresas, AI Platform, compliance. La EMP que no se reemplaza al crecer.
Norte constante: Toda la operación. Una sola plataforma.
Checklist pre-merge
- ¿Activable por módulo sin romper otros tenants?
- ¿Respeta tenancy y permisos en servidor?
- ¿Sirve a la plataforma completa, no solo a un vertical?
MPA-02-ECO
02 · Ecosistema Roustix
Mapa oficial de producto
Taxonomía que el equipo usa para nombrar módulos, priorizar roadmap y evitar duplicar capacidades.
ROUSTIX
Enterprise Platform
│
────────────────────────────────────
│ │
Maintenance Inventory (hoy)
│ │
└──────────┬───────────────────────┘
│
────────────────────────────────────
Maintenance Execution · Automation · CRM · Sales · Finance
BI · IAM · AI · API · Mobile
────────────────────────────────────
| Módulo | Clave | Estado |
|---|---|---|
| Maintenance | mantenimiento | ✅ Producción |
| Inventory | inventario | ✅ Producción |
| Purchasing | purchasing | ✅ Producción |
| CRM · Sales Pro | — | 📋 Planificado |
| Finance · Analytics | — | 📋 Planificado |
MPA-03-MOD
Una plataforma.
03 · Arquitectura modular
Una plataforma.
Cero instalaciones distintas.
El concepto más importante: cada empresa activa únicamente lo que necesita sobre el mismo código.
Tenant (Empresa)empresa_id · slug · sector · plan
↓
Módulos activosmodulos_activos_json
↓
Permisosrol × módulo · permissions.py
↓
Datosaislados por empresa_id
↓
DashboardsKPIs por contexto y sector
Enforcement en app/modules.py y middleware de tenancy.
El menú oculta; el servidor rechaza.
MPA-04-SAAS
04 · Arquitectura SaaS
Multi-tenant desde el diseño
| Capa | Implementación |
|---|---|
| Empresas | Empresa · sedes · sector · módulos |
| Usuarios | Un tenant por usuario · Flask-Login + JWT API |
| Roles | superadmin · admin · tecnico · usuario |
| Planes | trial · basico · profesional · enterprise |
| Facturación | /platform/ · suscripciones |
| Aislamiento | empresa_id · suspendida · auditoría |
| Backups | backup_service.py · SQLite / PostgreSQL |
MPA-05-ROAD
05 · Roadmap de módulos
Hoy, próximo y largo plazo
| Horizonte | Módulos |
|---|---|
| Hoy | Maintenance · Maintenance Execution · Automation · Asset Health · Inventory · Purchasing |
| Próximo | CRM · Sales Pro · Analytics |
| Largo plazo | IAM · Marketplace · API pública · AI · Mobile · ERP |
Los módulos futuros se añaden al catálogo, no a productos con otra marca. Alineado con planes Start → Grow → Scale (MCM-06).
MPA-06-INT
06 · Integraciones
La plataforma habla con el mundo real
| Canal | Estado | Notas |
|---|---|---|
| Excel | ✅ | Import/export Inventory |
| ✅ | ReportLab · estándar MRL | |
| Correo | 🟡 | Notificaciones · invitaciones |
| API REST | 🟡 | JWT tenancy · admin API |
| 📋 | Crítico LatAm | |
| Webhooks · ERP · Power BI | 📋 | MAG (07) · SDK (08) |
MPA-07-SEC
07 · Seguridad
Confianza en multi-tenant
Login · permisos en servidor · auditoría de plataforma · backups · MFA en evolución.
Regla: «Si está en el menú» no es seguridad. «Si pasa el check en el servidor» sí.
- Cross-tenant →
empresa_idobligatorio + middleware - CSRF en web · JWT en API
platform_audit.py— impersonación registradaflask backup-db— retención 7 días
MPA-08-SCALE
08 · Escalabilidad
De 10 usuarios a 10.000 empresas
| Escala | Enfoque |
|---|---|
| 10 usuarios / empresa | Single instance · DB compartida |
| 100 usuarios | Pooling · índices empresa_id |
| 100 empresas | Monolito modular bien indexado |
| 10.000 empresas | Jobs async · cache KPIs · sharding tier |
MPA-09-PHIL
09 · Filosofía técnica
Cada línea de código debe servir a la plataforma completa, no únicamente a un módulo.
| Principio | Práctica |
|---|---|
| Tenant primero | empresa_id en toda entidad |
| Módulo explícito | modules.py antes de rutas |
| Una UI | MDL mtx-* |
| UX no negociable | MUX Laws pre-merge |
| Sector = config | Plantillas, no tablas duplicadas |
MPA-10-2030
10 · Roadmap 2030
Dirección, no fecha contractual
2026
- Maintenance
- Inventory
- MPA v1.0
2027
- CRM
- Purchasing
- Webhooks
2028
- Finance
- Analytics
- IAM
2029
- Marketplace
- API pública
2030
- AI Platform
- Mobile
- Enterprise
Una plataforma. Multi-tenant. LatAm primero. Modular siempre.
MPA-11-LOG
11 · Arquitectura lógica
Complemento · Onboarding desarrollador
Mapa conceptual de capas.
Sin nombres de archivos — solo por dónde fluye una petición en Roustix.
FrontendPlantillas · Bootstrap · MDL (mtx-*)
↓
FlaskBlueprints · rutas · middleware tenancy
↓
ServicesReglas de negocio · orquestación
↓
RepositoriesQueries · filtro empresa_id
↓
SQLAlchemyModelos · sesión · migraciones
↓
DatabaseSQLite (dev) · PostgreSQL (prod)
Transversales: tenancy · permisos · módulos · MUX · MDL
| Si cambias… | Capa principal |
|---|---|
| Color de botón | MDL |
| Validación de negocio | Service |
| Nueva columna | Modelo + migración |
| Bloqueo sin módulo | Flask · modules.py |
MPA-12-EVO
12 · Principios de evolución
Complemento · Constitución del desarrollo
Lo que no se negocia.
Reglas aplicables en cada PR y cada decisión de diseño. MPA-09 inspira; MPA-12 obliga.
- Artículo I · Compatibilidad No romper compatibilidad sin migración. Alembic obligatorio. Plan de rollback.
- Artículo II · MDL Un módulo nuevo reutiliza componentes mtx-* y tokens — sin CSS paralelo.
- Artículo III · Tenant Todo módulo respeta aislamiento por empresa_id. Sin fugas cross-tenant.
- Artículo IV · Impacto Toda funcionalidad nueva tiene impacto medible — KPI o métrica MUX.
- Artículo V · No duplicar Ningún módulo repite lógica existente. Tercera copia = refactor.
- Artículo VI · UX primero La experiencia de usuario prevalece sobre la complejidad técnica interna.
Jerarquía: Seguridad/tenant → UX → Compatibilidad → No duplicar → MDL → Impacto medible.