Some checks failed
Build / Build Backend (push) Has been cancelled
Build / Build Mobile (TypeScript Check) (push) Has been cancelled
Lint / Lint Backend (push) Has been cancelled
Lint / Lint Mobile (push) Has been cancelled
Test / Backend E2E Tests (push) Has been cancelled
Test / Mobile Unit Tests (push) Has been cancelled
Build / Build Docker Image (push) Has been cancelled
- Add orchestration/directivas/ with proyecto-triggers - TRIGGER-COHERENCIA-CAPAS.md for DDL/Backend coherence - TRIGGER-INVENTARIOS.md for inventory synchronization - Add orchestration/agents/ with perfiles - PERFIL-DDL-AGENT.md - PERFIL-BACKEND-AGENT.md - PERFIL-MOBILE-AGENT.md (React Native/Expo specialized) - Add MAPA-DOCUMENTACION.yml as central reference Inheritance: INTEGRATES from template-saas Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2.8 KiB
2.8 KiB
TRIGGER: Coherencia Entre Capas
ID: TRIGGER-MI-COHERENCIA Version: 1.0.0 Prioridad: P1 (Bloqueante) Activacion: Automatica en cambios DDL/Backend Hereda de: template-saas (INTEGRATES)
Proposito
Garantizar coherencia entre las capas DDL, Backend y Mobile del proyecto MiInventario. Cada tabla DDL debe tener su entity correspondiente en el backend.
Contexto del Proyecto
MiInventario es un SaaS movil para inventario automatico por video con:
- Backend: NestJS + TypeScript
- Mobile: React Native (Expo)
- Database: PostgreSQL + Redis
- AI: Deteccion de productos por video
Activacion
Este trigger se activa cuando:
- Se crea/modifica archivo en
database/schemas/*/tables/*.sql - Se crea/modifica archivo en
apps/backend/src/modules/*/entities/*.entity.ts - Se ejecuta validacion manual con
@MI_VALIDATE_COHERENCIA
Validaciones
1. DDL -> Entity (Obligatorio)
Para cada tabla en DDL:
├── Verificar que existe entity correspondiente
├── Verificar que columnas coincidan (nombre, tipo)
├── Verificar que relaciones esten mapeadas
└── Documentar excepciones justificadas
Excepciones Permitidas:
- Tablas M:N gestionadas por TypeORM (documentar en ENTITIES-CATALOG)
- Tablas de auditoria automatica (documentar en DATABASE-SCHEMA)
- Tablas de sistema/migracion
- Tablas de ML/AI temporales
2. Entity -> Service (Recomendado)
Para cada entity:
├── Verificar que existe service que la usa
└── Verificar que operaciones CRUD estan implementadas (si aplica)
3. Service -> Controller (Si expone API)
Para cada service expuesto:
├── Verificar que existe controller
├── Verificar que endpoints estan documentados
└── Verificar que DTOs existen para request/response
Ubicaciones Especificas
| Capa | Ubicacion |
|---|---|
| DDL | database/schemas/{schema}/tables/ |
| Entities | apps/backend/src/modules/{mod}/entities/ |
| Services | apps/backend/src/modules/{mod}/ |
| Controllers | apps/backend/src/modules/{mod}/ |
Resultado de Validacion
Exito
status: "pass"
ddl_tables: <total>
entities: <total>
coverage: 100%
exceptions: 0
Fallo (Bloqueante)
status: "fail"
ddl_tables: <total+1>
entities: <total>
coverage: <porcentaje>
missing:
- tabla: "new_table"
schema: "new_schema"
accion_requerida: "Crear entity o documentar excepcion"
Acciones Correctivas
- Si falta entity: Crear entity en
apps/backend/src/modules/{modulo}/entities/ - Si es excepcion: Documentar en
docs/_definitions/ENTITIES-CATALOG.md - Si es tabla temporal: Agregar a lista de exclusiones
Referencias
@MI_DEF_ENTITIES- Catalogo de entities@MI_DEF_DB- Schema de base de datos@MI_INV_BE- Inventario backend