Changes on workspace projects, new project platform_marketing_content

This commit is contained in:
rckrdmrd 2025-12-08 18:33:25 -06:00
parent 35020e02f1
commit db4bf55c31
309 changed files with 42535 additions and 986 deletions

View File

@ -31,24 +31,42 @@ core/
└── orchestration/
├── directivas/
│ ├── simco/ # DIRECTIVAS POR OPERACIÓN
│ ├── simco/ # DIRECTIVAS POR OPERACIÓN (20 archivos)
│ │ ├── _INDEX.md ← ESTÁS AQUÍ
│ │ ├── SIMCO-TAREA.md # 🆕 CICLO CAPVED - Punto de entrada para HUs
│ │ │
│ │ │ # === CICLO DE VIDA ===
│ │ ├── SIMCO-TAREA.md # CICLO CAPVED - Punto de entrada para HUs
│ │ ├── SIMCO-INICIALIZACION.md # Bootstrap de agentes (CCA)
│ │ ├── SIMCO-REUTILIZAR.md # Reutilizar del catálogo
│ │ ├── SIMCO-CONTRIBUIR-CATALOGO.md # 🆕 Contribuir al catálogo
│ │
│ │ │ # === OPERACIONES UNIVERSALES ===
│ │ ├── SIMCO-CREAR.md # Crear cualquier archivo
│ │ ├── SIMCO-MODIFICAR.md # Modificar archivos existentes
│ │ ├── SIMCO-VALIDAR.md # Validar código (build, lint)
│ │ ├── SIMCO-DOCUMENTAR.md # Documentar trabajo realizado
│ │ ├── SIMCO-BUSCAR.md # Buscar archivos e información
│ │ ├── SIMCO-DELEGACION.md # Delegar a subagentes (con CCA)
│ │ │
│ │ │ # === CATÁLOGO ===
│ │ ├── SIMCO-REUTILIZAR.md # Reutilizar del catálogo
│ │ ├── SIMCO-CONTRIBUIR-CATALOGO.md # Contribuir al catálogo
│ │ │
│ │ │ # === POR DOMINIO TÉCNICO ===
│ │ ├── SIMCO-DDL.md # Operaciones de base de datos
│ │ ├── SIMCO-BACKEND.md # Operaciones de backend NestJS
│ │ ├── SIMCO-FRONTEND.md # Operaciones de frontend React
│ │ ├── SIMCO-NIVELES.md # 🆕 Identificación de nivel jerárquico
│ │ ├── SIMCO-PROPAGACION.md # 🆕 Propagación de documentación
│ │ └── SIMCO-QUICK-REFERENCE.md # 🆕 Referencia rápida (optimizado para tokens)
│ │ ├── SIMCO-MOBILE.md # Operaciones React Native
│ │ ├── SIMCO-ML.md # Machine Learning y AI
│ │ │
│ │ │ # === NIVELES Y PROPAGACIÓN ===
│ │ ├── SIMCO-NIVELES.md # Identificación de nivel jerárquico
│ │ ├── SIMCO-PROPAGACION.md # Propagación de documentación
│ │ │
│ │ │ # === TOMA DE DECISIONES ===
│ │ ├── SIMCO-ALINEACION.md # Alineación entre capas
│ │ ├── SIMCO-DECISION-MATRIZ.md # Matriz de decisión para agentes
│ │ │
│ │ │ # === REFERENCIA ===
│ │ └── SIMCO-QUICK-REFERENCE.md # Referencia rápida (optimizado para tokens)
│ │
│ └── principios/ # PRINCIPIOS FUNDAMENTALES (5)
│ ├── PRINCIPIO-CAPVED.md # 🆕 Ciclo de vida de tareas
@ -58,21 +76,53 @@ core/
│ └── PRINCIPIO-ECONOMIA-TOKENS.md # 🆕 Límites y desglose de tareas
├── agents/
│ └── perfiles/ # PERFILES LIGEROS + CCA
│ ├── PERFIL-DATABASE.md # PostgreSQL DDL - Incluye protocolo CCA
│ ├── PERFIL-BACKEND.md # NestJS/TypeORM - Incluye protocolo CCA
│ ├── PERFIL-BACKEND-EXPRESS.md # Express.js/Prisma - Incluye protocolo CCA
│ ├── PERFIL-FRONTEND.md # React Web - Incluye protocolo CCA
│ ├── PERFIL-MOBILE-AGENT.md # React Native - Incluye protocolo CCA
│ ├── PERFIL-ML-SPECIALIST.md # Python/ML/AI - Incluye protocolo CCA
│ └── PERFIL-ORQUESTADOR.md # Coordinación - Incluye protocolo CCA
│ └── perfiles/ # PERFILES DE AGENTES (13 archivos)
│ │
│ │ # === PERFILES TÉCNICOS ===
│ ├── PERFIL-DATABASE.md # PostgreSQL DDL
│ ├── PERFIL-BACKEND.md # NestJS/TypeORM
│ ├── PERFIL-BACKEND-EXPRESS.md # Express.js/Prisma
│ ├── PERFIL-FRONTEND.md # React Web
│ ├── PERFIL-MOBILE-AGENT.md # React Native
│ ├── PERFIL-ML-SPECIALIST.md # Python/ML/AI
│ │
│ │ # === PERFILES DE COORDINACIÓN ===
│ ├── PERFIL-ORQUESTADOR.md # Coordinación general
│ ├── PERFIL-ARCHITECTURE-ANALYST.md # Análisis de arquitectura
│ ├── PERFIL-REQUIREMENTS-ANALYST.md # Análisis de requerimientos
│ │
│ │ # === PERFILES DE CALIDAD ===
│ ├── PERFIL-CODE-REVIEWER.md # Revisión de código
│ ├── PERFIL-BUG-FIXER.md # Corrección de bugs
│ ├── PERFIL-DOCUMENTATION-VALIDATOR.md # Validación de documentación
│ └── PERFIL-WORKSPACE-MANAGER.md # Gestión de workspace
├── templates/
│ ├── TEMPLATE-DELEGACION-SUBAGENTE.md # Template con contexto heredado
│ ├── CONTEXTO-NIVEL-STANDALONE.md # 🆕 Template para proyectos standalone
│ ├── CONTEXTO-NIVEL-SUITE.md # 🆕 Template para suites multi-vertical
│ ├── CONTEXTO-NIVEL-SUITE-CORE.md # 🆕 Template para core de suite
│ └── CONTEXTO-NIVEL-VERTICAL.md # 🆕 Template para verticales
├── templates/ # TEMPLATES (17 archivos)
│ │
│ │ # === CONTEXTO POR NIVEL ===
│ ├── CONTEXTO-NIVEL-STANDALONE.md # Template para proyectos standalone
│ ├── CONTEXTO-NIVEL-SUITE.md # Template para suites multi-vertical
│ ├── CONTEXTO-NIVEL-SUITE-CORE.md # Template para core de suite
│ ├── CONTEXTO-NIVEL-VERTICAL.md # Template para verticales
│ │
│ │ # === TEMPLATES DE AGENTES ===
│ ├── TEMPLATE-DELEGACION-SUBAGENTE.md # Delegación a subagentes
│ ├── TEMPLATE-CONTEXTO-SUBAGENTE.md # Contexto para subagentes
│ ├── TEMPLATE-CONTEXTO-PROYECTO.md # Contexto de proyecto
│ ├── TEMPLATES-SUBAGENTES.md # Guía de subagentes
│ │
│ │ # === TEMPLATES DE TAREAS ===
│ ├── TEMPLATE-TAREA-CAPVED.md # Tarea con ciclo CAPVED
│ ├── TEMPLATE-TAREA-TECNICA.md # Tarea técnica simple
│ ├── TEMPLATE-HISTORIA-USUARIO.md # Historia de usuario
│ ├── TEMPLATE-EPICA.md # Épica
│ ├── TEMPLATE-PLAN.md # Plan de implementación
│ │
│ │ # === TEMPLATES DE VALIDACIÓN ===
│ ├── TEMPLATE-ANALISIS.md # Análisis de impacto
│ ├── TEMPLATE-VALIDACION.md # Validación de entregables
│ ├── CHECKLIST-ESTRUCTURA-PROYECTO.md # Estructura de proyecto
│ └── _MAP.md # Mapa de templates
├── patrones/ # PATRONES DE CÓDIGO
│ ├── MAPEO-TIPOS-DDL-TYPESCRIPT.md # Mapeo PostgreSQL ↔ TypeScript
@ -97,6 +147,11 @@ core/
├── procesos/ # PROCESOS DE TRABAJO
│ └── ORDEN-IMPLEMENTACION.md # DDL-First, orden de capas
├── checklists/ # CHECKLISTS DE VERIFICACIÓN
│ ├── CHECKLIST-CODE-REVIEW-API.md # Revisión de código API
│ ├── CHECKLIST-REFACTORIZACION.md # Checklist de refactoring
│ └── CHECKLIST-PROPAGACION.md # Propagación de cambios
├── _historico/
│ └── MAPA-CONTEXTO-AGENTE.md # Trazabilidad (histórico)
@ -139,7 +194,8 @@ Antes de actuar, ejecuta el protocolo CCA (Carga de Contexto Automática)."
| Operación | Archivo SIMCO | Cuándo Usar |
|-----------|---------------|-------------|
| **🆕 Tarea/HU** | `SIMCO-TAREA.md` | **PUNTO DE ENTRADA** - Toda HU/tarea que modifica código |
| **Tarea/HU** | `SIMCO-TAREA.md` | **PUNTO DE ENTRADA** - Toda HU/tarea que modifica código |
| **Inicialización** | `SIMCO-INICIALIZACION.md` | Bootstrap de agentes (protocolo CCA) |
| **Reutilizar** | `SIMCO-REUTILIZAR.md` | ANTES de implementar funcionalidad común |
| **Contribuir** | `SIMCO-CONTRIBUIR-CATALOGO.md` | DESPUÉS de implementar funcionalidad reutilizable |
| **Crear** | `SIMCO-CREAR.md` | Al crear cualquier archivo nuevo |
@ -148,6 +204,8 @@ Antes de actuar, ejecuta el protocolo CCA (Carga de Contexto Automática)."
| **Documentar** | `SIMCO-DOCUMENTAR.md` | Al finalizar cualquier tarea |
| **Buscar** | `SIMCO-BUSCAR.md` | Para encontrar archivos/info |
| **Delegar** | `SIMCO-DELEGACION.md` | Al asignar trabajo a subagentes |
| **Alineación** | `SIMCO-ALINEACION.md` | Validar alineación entre capas (DDL↔Entity↔DTO) |
| **Decisión** | `SIMCO-DECISION-MATRIZ.md` | Clarificar qué directiva ejecutar |
### Por Dominio Técnico:
@ -210,16 +268,17 @@ Cada SIMCO tiene un checklist. Seguirlo paso a paso.
## ALIAS MÁS USADOS
```yaml
# 🆕 CAPVED - CICLO DE VIDA DE TAREAS
@CAPVED: core/orchestration/directivas/principios/PRINCIPIO-CAPVED.md
@TAREA: core/orchestration/directivas/simco/SIMCO-TAREA.md
@TPL_CAPVED: core/orchestration/templates/TEMPLATE-TAREA-CAPVED.md
# CICLO DE VIDA Y BOOTSTRAP
@CAPVED: core/orchestration/directivas/principios/PRINCIPIO-CAPVED.md
@TAREA: core/orchestration/directivas/simco/SIMCO-TAREA.md
@INICIALIZACION: core/orchestration/directivas/simco/SIMCO-INICIALIZACION.md
@TPL_CAPVED: core/orchestration/templates/TEMPLATE-TAREA-CAPVED.md
# CATÁLOGO DE FUNCIONALIDADES (CONSULTAR PRIMERO)
@CATALOG: core/catalog/
@CATALOG_INDEX: core/catalog/CATALOG-INDEX.yml
# Operaciones
# OPERACIONES UNIVERSALES
@REUTILIZAR: core/orchestration/directivas/simco/SIMCO-REUTILIZAR.md
@CREAR: core/orchestration/directivas/simco/SIMCO-CREAR.md
@MODIFICAR: core/orchestration/directivas/simco/SIMCO-MODIFICAR.md
@ -228,34 +287,38 @@ Cada SIMCO tiene un checklist. Seguirlo paso a paso.
@BUSCAR: core/orchestration/directivas/simco/SIMCO-BUSCAR.md
@DELEGAR: core/orchestration/directivas/simco/SIMCO-DELEGACION.md
# Especializados por Dominio
# POR DOMINIO TÉCNICO
@OP_DDL: core/orchestration/directivas/simco/SIMCO-DDL.md
@OP_BACKEND: core/orchestration/directivas/simco/SIMCO-BACKEND.md
@OP_FRONTEND: core/orchestration/directivas/simco/SIMCO-FRONTEND.md
@OP_MOBILE: core/orchestration/directivas/simco/SIMCO-MOBILE.md
@OP_ML: core/orchestration/directivas/simco/SIMCO-ML.md
# Niveles Jerárquicos
# NIVELES Y PROPAGACIÓN
@NIVELES: core/orchestration/directivas/simco/SIMCO-NIVELES.md
@PROPAGACION: core/orchestration/directivas/simco/SIMCO-PROPAGACION.md
# Templates de Contexto por Nivel
# TOMA DE DECISIONES
@ALINEACION: core/orchestration/directivas/simco/SIMCO-ALINEACION.md
@DECISION_MATRIZ: core/orchestration/directivas/simco/SIMCO-DECISION-MATRIZ.md
# TEMPLATES DE CONTEXTO
@CTX_STANDALONE: core/orchestration/templates/CONTEXTO-NIVEL-STANDALONE.md
@CTX_SUITE: core/orchestration/templates/CONTEXTO-NIVEL-SUITE.md
@CTX_SUITE_CORE: core/orchestration/templates/CONTEXTO-NIVEL-SUITE-CORE.md
@CTX_VERTICAL: core/orchestration/templates/CONTEXTO-NIVEL-VERTICAL.md
# Principios (5 fundamentales)
# PRINCIPIOS
@PRINCIPIOS: core/orchestration/directivas/principios/
@TOKENS: core/orchestration/directivas/principios/PRINCIPIO-ECONOMIA-TOKENS.md
# Referencia rápida (optimizado para tokens)
# PATRONES Y REFERENCIAS
@PATRONES: core/orchestration/patrones/
@IMPACTOS: core/orchestration/impactos/
@QUICK_REF: core/orchestration/directivas/simco/SIMCO-QUICK-REFERENCE.md
# Inventarios (proyecto)
# PROYECTO
@INVENTORY: orchestration/inventarios/MASTER_INVENTORY.yml
# Aliases completos
@ALIASES: core/orchestration/referencias/ALIASES.yml
```

View File

@ -0,0 +1,329 @@
# Plan de Propagación SIMCO + CAPVED a Proyectos Heredados
**Versión:** 1.1.0
**Fecha:** 2025-12-08
**Estado:** ✅ IMPLEMENTACIÓN COMPLETADA
---
## Resumen Ejecutivo
Este documento analiza la implementación del sistema SIMCO v2.2.0 + CAPVED en los proyectos del workspace y define el plan de propagación a proyectos hermanos/heredados.
### Estado de Implementación
| Métrica | Antes | Después |
|---------|-------|---------|
| Archivos HERENCIA-SIMCO.md | 0 | **15** |
| Proyectos actualizados | 0 | **14** |
| Template en core | No | **Sí** |
| Sistema SIMCO propagado | Parcial | **100%** |
### Archivos Creados
| Proyecto | Archivo | Nivel |
|----------|---------|-------|
| core/templates | HERENCIA-SIMCO.md | Template |
| erp-suite | HERENCIA-SIMCO.md | Suite (1) |
| erp-core | HERENCIA-SIMCO.md | Suite-Core (2) |
| erp-basico | HERENCIA-SIMCO.md | Product (2) |
| pos-micro | HERENCIA-SIMCO.md | Product (2) |
| construccion | HERENCIA-SIMCO.md | Vertical (3) |
| vidrio-templado | HERENCIA-SIMCO.md | Vertical (3) |
| mecanicas-diesel | HERENCIA-SIMCO.md | Vertical (3) |
| retail | HERENCIA-SIMCO.md | Vertical (3) |
| clinicas | HERENCIA-SIMCO.md | Vertical (3) |
| gamilit | HERENCIA-SIMCO.md | Standalone |
| trading-platform | HERENCIA-SIMCO.md | Standalone |
| betting-analytics | HERENCIA-SIMCO.md | Standalone |
| inmobiliaria-analytics | HERENCIA-SIMCO.md | Standalone |
| platform_marketing_content | HERENCIA-SIMCO.md | Standalone |
---
## Arquitectura de Herencia del Workspace
```
┌─────────────────────────────────────┐
│ NIVEL 0 - WORKSPACE │
│ core/orchestration/ (76 docs) │
│ SIMCO v2.2.0 + CAPVED + CCA │
└──────────────────┬──────────────────┘
┌───────────────────────────┼───────────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
│ STANDALONE │ │ SUITE (ERP) │ │ STANDALONE │
│ - gamilit │ │ projects/erp-suite│ │ - trading-platform│
│ - betting-analytics│ │ │ │ - inmobiliaria │
│ - platform_mkt │ │ │ │ - pos-micro │
└─────────────────────┘ └──────────┬──────────┘ └─────────────────────┘
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ SUITE-CORE │ │ PRODUCTS │ │ SAAS │
│ erp-core │ │ erp-basico │ │ (tenant) │
└──────┬──────┘ │ pos-micro │ └─────────────┘
│ └─────────────┘
┌────────────┼────────────┬────────────┬────────────┐
▼ ▼ ▼ ▼ ▼
┌────────┐ ┌──────────┐ ┌─────────┐ ┌────────┐ ┌──────────┐
│construc│ │vidrio- │ │mecanicas│ │ retail │ │ clinicas │
│ción │ │templado │ │-diesel │ │ │ │ │
└────────┘ └──────────┘ └─────────┘ └────────┘ └──────────┘
NIVEL 3 - VERTICALES (5 proyectos)
```
---
## Análisis por Proyecto
### NIVEL 1: SUITE (ERP-SUITE)
| Proyecto | Ruta | Estado SIMCO | HERENCIA-DIRECTIVAS | Acción Requerida |
|----------|------|--------------|---------------------|------------------|
| **erp-suite** | `projects/erp-suite/orchestration` | ⚠️ Parcial | ❌ Obsoleto | Actualizar |
**Archivos a actualizar:**
- `00-guidelines/HERENCIA-DIRECTIVAS.md` → Referenciar SIMCO
- Crear `00-guidelines/HERENCIA-SIMCO.md` (nuevo)
### NIVEL 2: SUITE-CORE
| Proyecto | Ruta | Estado SIMCO | HERENCIA-DIRECTIVAS | Acción Requerida |
|----------|------|--------------|---------------------|------------------|
| **erp-core** | `projects/erp-suite/apps/erp-core/orchestration` | ⚠️ Parcial | ❌ Obsoleto | Actualizar |
**Archivos a actualizar:**
- `00-guidelines/HERENCIA-DIRECTIVAS.md` → Mapear a SIMCO
- `00-guidelines/CONTEXTO-PROYECTO.md` → Agregar CCA Protocol
### NIVEL 3: VERTICALES
| Vertical | Estado SIMCO | HERENCIA-DIRECTIVAS | Inventarios | Acción |
|----------|--------------|---------------------|-------------|--------|
| **construccion** | ⚠️ Parcial | ❌ Obsoleto | ✅ Completos | Actualizar herencia |
| **vidrio-templado** | ⚠️ Parcial | ❌ Obsoleto | ✅ Completos | Actualizar herencia |
| **mecanicas-diesel** | ⚠️ Parcial | ❌ Obsoleto | ✅ Completos | Actualizar herencia |
| **retail** | ⚠️ Parcial | ❌ Obsoleto | ✅ Completos | Actualizar herencia |
| **clinicas** | ⚠️ Parcial | ❌ Obsoleto | ✅ Completos | Actualizar herencia |
### NIVEL 3: PRODUCTS
| Producto | Estado | Acción |
|----------|--------|--------|
| **erp-basico** | 🆕 Nuevo | Configurar desde cero |
| **pos-micro** | 🆕 Nuevo | Configurar desde cero |
### PROYECTOS STANDALONE
| Proyecto | Estado SIMCO | HERENCIA | Inventarios | Acción |
|----------|--------------|----------|-------------|--------|
| **gamilit** | ⚠️ Parcial | ❌ Obsoleto | ⚠️ Falta | Actualizar + crear inventarios |
| **trading-platform** | ⚠️ Parcial | ❌ Obsoleto | ✅ Completos | Actualizar herencia |
| **betting-analytics** | ⚠️ Parcial | ❌ Obsoleto | ⚠️ Falta | Actualizar + crear inventarios |
| **inmobiliaria-analytics** | ⚠️ Parcial | ❌ Obsoleto | ✅ Completos | Actualizar herencia |
| **platform_marketing_content** | ⚠️ Parcial | ❌ Obsoleto | ✅ Completos | Actualizar herencia |
---
## Referencias Obsoletas a Eliminar/Actualizar
Los siguientes archivos referencian directivas del sistema antiguo:
```
16 archivos con referencias a:
- DIRECTIVA-FLUJO-5-FASES.md → Reemplazar por SIMCO-TAREA.md + CAPVED
- DIRECTIVA-VALIDACION-SUBAGENTES.md → Reemplazar por SIMCO-VALIDAR.md
- POLITICAS-USO-AGENTES.md → Reemplazar por SIMCO-DELEGACION.md
```
### Archivos Específicos a Actualizar
| Archivo | Proyecto | Prioridad |
|---------|----------|-----------|
| `HERENCIA-DIRECTIVAS.md` | erp-suite | ALTA |
| `HERENCIA-DIRECTIVAS.md` | erp-core | ALTA |
| `HERENCIA-DIRECTIVAS.md` | construccion | ALTA |
| `HERENCIA-DIRECTIVAS.md` | vidrio-templado | MEDIA |
| `HERENCIA-DIRECTIVAS.md` | mecanicas-diesel | MEDIA |
| `HERENCIA-DIRECTIVAS.md` | retail | MEDIA |
| `HERENCIA-DIRECTIVAS.md` | clinicas | MEDIA |
| `HERENCIA-DIRECTIVAS.md` | gamilit | MEDIA |
| `HERENCIA-DIRECTIVAS.md` | trading-platform | MEDIA |
| `HERENCIA-DIRECTIVAS.md` | inmobiliaria-analytics | BAJA |
| `HERENCIA-DIRECTIVAS.md` | betting-analytics | BAJA |
| `HERENCIA-DIRECTIVAS.md` | platform_marketing_content | BAJA |
---
## Plan de Propagación
### FASE 1: Crear Template de Herencia SIMCO (INMEDIATO)
Crear archivo `HERENCIA-SIMCO.md` en `core/orchestration/templates/` que los proyectos heredarán.
**Contenido del template:**
```yaml
nivel: "{STANDALONE|SUITE|SUITE_CORE|VERTICAL}"
hereda_de:
- core/orchestration/directivas/simco/ # OBLIGATORIO
- core/orchestration/directivas/principios/ # OBLIGATORIO
- core/orchestration/patrones/ # RECOMENDADO
- core/orchestration/impactos/ # SEGÚN NECESIDAD
simco_version: "2.2.0"
capved_enabled: true
cca_protocol: true
```
### FASE 2: Actualizar Proyectos de Alta Prioridad
**Orden de actualización:**
1. **erp-suite** (Nivel 1) - Base para verticales
2. **erp-core** (Nivel 2) - Core compartido
3. **construccion** (Nivel 3) - Vertical más avanzada
4. **gamilit** (Standalone) - Proyecto activo
**Por cada proyecto:**
1. Actualizar `HERENCIA-DIRECTIVAS.md` con mapeo SIMCO
2. Crear/actualizar `CONTEXTO-PROYECTO.md` con variables CCA
3. Verificar que `ALIASES.yml` del proyecto referencie core
### FASE 3: Actualizar Proyectos de Media Prioridad
- vidrio-templado
- mecanicas-diesel
- retail
- clinicas
- trading-platform
### FASE 4: Actualizar Proyectos de Baja Prioridad
- inmobiliaria-analytics
- betting-analytics
- platform_marketing_content
### FASE 5: Configurar Productos Nuevos
- erp-basico
- pos-micro
---
## Mapeo de Directivas: Antiguo → Nuevo
| Sistema Antiguo | Sistema SIMCO | Alias |
|-----------------|---------------|-------|
| `DIRECTIVA-FLUJO-5-FASES.md` | `SIMCO-TAREA.md` + `PRINCIPIO-CAPVED.md` | @TAREA, @CAPVED |
| `DIRECTIVA-VALIDACION-SUBAGENTES.md` | `SIMCO-VALIDAR.md` | @VALIDAR |
| `POLITICAS-USO-AGENTES.md` | `SIMCO-DELEGACION.md` | @DELEGAR |
| `DIRECTIVA-DOCUMENTACION-OBLIGATORIA.md` | `SIMCO-DOCUMENTAR.md` | @DOCUMENTAR |
| `DIRECTIVA-CALIDAD-CODIGO.md` | `PATRON-VALIDACION.md` + `ANTIPATRONES.md` | @PATRONES |
| `DIRECTIVA-DISENO-BASE-DATOS.md` | `SIMCO-DDL.md` | @OP_DDL |
| `ESTANDARES-API-REST-GENERICO.md` | `SIMCO-BACKEND.md` | @OP_BACKEND |
| `DIRECTIVA-CONTROL-VERSIONES.md` | (sin cambio, mantener) | - |
---
## Template: HERENCIA-SIMCO.md para Proyectos
```markdown
# Herencia SIMCO - {NOMBRE_PROYECTO}
## Configuración
| Propiedad | Valor |
|-----------|-------|
| **Nivel** | {STANDALONE/SUITE/SUITE_CORE/VERTICAL} |
| **SIMCO Version** | 2.2.0 |
| **CAPVED** | Habilitado |
| **CCA Protocol** | Habilitado |
## Directivas Heredadas (OBLIGATORIAS)
Ubicación: `core/orchestration/`
### Ciclo de Vida (usar SIEMPRE)
| Alias | Ruta | Uso |
|-------|------|-----|
| @TAREA | `directivas/simco/SIMCO-TAREA.md` | Punto de entrada para toda HU |
| @CAPVED | `directivas/principios/PRINCIPIO-CAPVED.md` | Ciclo de 6 fases |
| @INICIALIZACION | `directivas/simco/SIMCO-INICIALIZACION.md` | Bootstrap de agentes |
### Operaciones Universales
| Alias | Ruta | Uso |
|-------|------|-----|
| @CREAR | `directivas/simco/SIMCO-CREAR.md` | Crear archivos |
| @MODIFICAR | `directivas/simco/SIMCO-MODIFICAR.md` | Modificar archivos |
| @VALIDAR | `directivas/simco/SIMCO-VALIDAR.md` | Validar código |
| @DOCUMENTAR | `directivas/simco/SIMCO-DOCUMENTAR.md` | Documentar trabajo |
| @BUSCAR | `directivas/simco/SIMCO-BUSCAR.md` | Buscar información |
| @DELEGAR | `directivas/simco/SIMCO-DELEGACION.md` | Delegar a subagentes |
### Por Dominio (según proyecto)
| Alias | Ruta | Aplica a |
|-------|------|----------|
| @OP_DDL | `directivas/simco/SIMCO-DDL.md` | Proyectos con PostgreSQL |
| @OP_BACKEND | `directivas/simco/SIMCO-BACKEND.md` | Proyectos con NestJS/Express |
| @OP_FRONTEND | `directivas/simco/SIMCO-FRONTEND.md` | Proyectos con React |
| @OP_MOBILE | `directivas/simco/SIMCO-MOBILE.md` | Proyectos con React Native |
| @OP_ML | `directivas/simco/SIMCO-ML.md` | Proyectos con ML/AI |
### Principios (OBLIGATORIOS)
- `PRINCIPIO-DOC-PRIMERO.md`
- `PRINCIPIO-ANTI-DUPLICACION.md`
- `PRINCIPIO-VALIDACION-OBLIGATORIA.md`
- `PRINCIPIO-ECONOMIA-TOKENS.md`
## Patrones Heredados (RECOMENDADOS)
| Patrón | Cuándo Usar |
|--------|-------------|
| `PATRON-VALIDACION.md` | Toda validación de inputs |
| `PATRON-EXCEPTION-HANDLING.md` | Manejo de errores |
| `PATRON-TESTING.md` | Escribir tests |
| `PATRON-LOGGING.md` | Configurar logs |
| `PATRON-SEGURIDAD.md` | Implementar auth/seguridad |
## Extensiones Específicas del Proyecto
*(Agregar directivas específicas que EXTIENDEN las de core)*
| Directiva Local | Extiende | Propósito |
|-----------------|----------|-----------|
| `./directivas/...` | `@OP_DDL` | Schemas específicos |
---
**Regla de Oro:** Las directivas locales pueden EXTENDER las de core, nunca REDUCIRLAS.
```
---
## Estimación de Esfuerzo
| Fase | Proyectos | Archivos | Complejidad |
|------|-----------|----------|-------------|
| 1 | 1 template | 1 | Baja |
| 2 | 4 proyectos | ~16 | Media |
| 3 | 5 proyectos | ~20 | Media |
| 4 | 3 proyectos | ~12 | Baja |
| 5 | 2 proyectos | ~8 | Baja |
| **TOTAL** | **15 proyectos** | **~57 archivos** | - |
---
## Siguiente Paso Recomendado
1. **Aprobar este plan** de propagación
2. **Ejecutar Fase 1**: Crear template `HERENCIA-SIMCO.md` en core
3. **Ejecutar Fase 2**: Comenzar con erp-suite (proyecto padre)
---
**Autor:** Sistema SIMCO v2.2.0
**Fecha:** 2025-12-08

View File

@ -78,6 +78,27 @@ global:
"@CHECKLISTS": "core/orchestration/checklists/"
"@CHK_API": "core/orchestration/checklists/CHECKLIST-CODE-REVIEW-API.md"
"@CHK_REFACTOR": "core/orchestration/checklists/CHECKLIST-REFACTORIZACION.md"
"@CHK_PROPAGACION": "core/orchestration/checklists/CHECKLIST-PROPAGACION.md"
# ═══════════════════════════════════════════════════════════════════
# PERFILES DE AGENTES ESPECÍFICOS
# ═══════════════════════════════════════════════════════════════════
# Técnicos
"@PERFIL_DATABASE": "core/orchestration/agents/perfiles/PERFIL-DATABASE.md"
"@PERFIL_BACKEND": "core/orchestration/agents/perfiles/PERFIL-BACKEND.md"
"@PERFIL_BACKEND_EXPRESS": "core/orchestration/agents/perfiles/PERFIL-BACKEND-EXPRESS.md"
"@PERFIL_FRONTEND": "core/orchestration/agents/perfiles/PERFIL-FRONTEND.md"
"@PERFIL_MOBILE": "core/orchestration/agents/perfiles/PERFIL-MOBILE-AGENT.md"
"@PERFIL_ML": "core/orchestration/agents/perfiles/PERFIL-ML-SPECIALIST.md"
# Coordinación
"@PERFIL_ORQUESTADOR": "core/orchestration/agents/perfiles/PERFIL-ORQUESTADOR.md"
"@PERFIL_ARCHITECT": "core/orchestration/agents/perfiles/PERFIL-ARCHITECTURE-ANALYST.md"
"@PERFIL_ANALYST": "core/orchestration/agents/perfiles/PERFIL-REQUIREMENTS-ANALYST.md"
# Calidad
"@PERFIL_REVIEWER": "core/orchestration/agents/perfiles/PERFIL-CODE-REVIEWER.md"
"@PERFIL_BUG_FIXER": "core/orchestration/agents/perfiles/PERFIL-BUG-FIXER.md"
"@PERFIL_DOC_VALIDATOR": "core/orchestration/agents/perfiles/PERFIL-DOCUMENTATION-VALIDATOR.md"
"@PERFIL_WORKSPACE": "core/orchestration/agents/perfiles/PERFIL-WORKSPACE-MANAGER.md"
# ═══════════════════════════════════════════════════════════════════
# PATRONES DE CÓDIGO (CONSULTAR ANTES DE IMPLEMENTAR)
@ -116,9 +137,10 @@ global:
# ─────────────────────────────────────────────────────────────────────────────────
operaciones:
# ═══════════════════════════════════════════════════════════════════
# PUNTO DE ENTRADA CAPVED (🆕 v2.0)
# CICLO DE VIDA Y BOOTSTRAP
# ═══════════════════════════════════════════════════════════════════
"@TAREA": "core/orchestration/directivas/simco/SIMCO-TAREA.md"
"@INICIALIZACION": "core/orchestration/directivas/simco/SIMCO-INICIALIZACION.md"
# ═══════════════════════════════════════════════════════════════════
# OPERACIONES UNIVERSALES (TODO agente debe conocerlas)
@ -147,6 +169,12 @@ operaciones:
"@NIVELES": "core/orchestration/directivas/simco/SIMCO-NIVELES.md"
"@PROPAGACION": "core/orchestration/directivas/simco/SIMCO-PROPAGACION.md"
# ═══════════════════════════════════════════════════════════════════
# TOMA DE DECISIONES Y ALINEACIÓN
# ═══════════════════════════════════════════════════════════════════
"@ALINEACION": "core/orchestration/directivas/simco/SIMCO-ALINEACION.md"
"@DECISION_MATRIZ": "core/orchestration/directivas/simco/SIMCO-DECISION-MATRIZ.md"
# ─────────────────────────────────────────────────────────────────────────────────
# ALIAS DE NIVELES JERÁRQUICOS (templates de contexto por nivel)
# ─────────────────────────────────────────────────────────────────────────────────

View File

@ -0,0 +1,313 @@
# Template: Herencia SIMCO para Proyectos
**Versión:** 1.0.0
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA
**Uso:** Copiar y adaptar para cada proyecto
---
## Instrucciones de Uso
1. Copiar este archivo a `{proyecto}/orchestration/00-guidelines/HERENCIA-SIMCO.md`
2. Reemplazar todas las variables `{VARIABLE}` con valores del proyecto
3. Eliminar secciones que no apliquen según el nivel del proyecto
4. Este archivo REEMPLAZA el antiguo `HERENCIA-DIRECTIVAS.md`
---
# Herencia SIMCO - {NOMBRE_PROYECTO}
## Configuración del Proyecto
| Propiedad | Valor |
|-----------|-------|
| **Proyecto** | {NOMBRE_PROYECTO} |
| **Nivel** | {STANDALONE / SUITE / SUITE_CORE / VERTICAL / PRODUCT} |
| **Padre** | {PROYECTO_PADRE o "core" si es standalone} |
| **SIMCO Version** | 2.2.0 |
| **CAPVED** | Habilitado |
| **CCA Protocol** | Habilitado |
## Jerarquía de Herencia
```
{AJUSTAR SEGÚN NIVEL DEL PROYECTO}
Nivel 0: core/orchestration/ ← FUENTE PRINCIPAL
└── Nivel 1: {suite}/orchestration/ ← (si aplica)
└── Nivel 2: {suite-core}/orchestration/ ← (si aplica)
└── Nivel 3: {ESTE_PROYECTO}/orchestration/
```
**Regla:** Las directivas de nivel inferior pueden EXTENDER las superiores, nunca REDUCIRLAS.
---
## Directivas Heredadas de CORE (OBLIGATORIAS)
Ubicación: `core/orchestration/`
### 1. Ciclo de Vida - USAR SIEMPRE
| Alias | Archivo | Propósito | Cuándo Usar |
|-------|---------|-----------|-------------|
| `@TAREA` | `directivas/simco/SIMCO-TAREA.md` | Punto de entrada | **Toda HU/tarea que genera commit** |
| `@CAPVED` | `directivas/principios/PRINCIPIO-CAPVED.md` | Ciclo de 6 fases | Contexto→Análisis→Plan→Validación→Ejecución→Doc |
| `@INICIALIZACION` | `directivas/simco/SIMCO-INICIALIZACION.md` | Bootstrap de agentes | Al iniciar cualquier agente |
### 2. Operaciones Universales
| Alias | Archivo | Propósito |
|-------|---------|-----------|
| `@CREAR` | `directivas/simco/SIMCO-CREAR.md` | Crear cualquier archivo nuevo |
| `@MODIFICAR` | `directivas/simco/SIMCO-MODIFICAR.md` | Modificar archivos existentes |
| `@VALIDAR` | `directivas/simco/SIMCO-VALIDAR.md` | Validar código (build, lint, tests) |
| `@DOCUMENTAR` | `directivas/simco/SIMCO-DOCUMENTAR.md` | Documentar trabajo realizado |
| `@BUSCAR` | `directivas/simco/SIMCO-BUSCAR.md` | Buscar archivos e información |
| `@DELEGAR` | `directivas/simco/SIMCO-DELEGACION.md` | Delegar trabajo a subagentes |
### 3. Catálogo de Funcionalidades
| Alias | Archivo | Propósito |
|-------|---------|-----------|
| `@CATALOG` | `catalog/` | Directorio de funcionalidades reutilizables |
| `@CATALOG_INDEX` | `catalog/CATALOG-INDEX.yml` | Índice machine-readable |
| `@REUTILIZAR` | `directivas/simco/SIMCO-REUTILIZAR.md` | ANTES de implementar algo común |
| `@CONTRIBUIR` | `directivas/simco/SIMCO-CONTRIBUIR-CATALOGO.md` | DESPUÉS de crear algo reutilizable |
### 4. Principios Fundamentales (5)
| Alias | Archivo | Resumen |
|-------|---------|---------|
| `@CAPVED` | `PRINCIPIO-CAPVED.md` | Toda tarea pasa por 6 fases |
| `@DOC_PRIMERO` | `PRINCIPIO-DOC-PRIMERO.md` | Consultar docs/ antes de implementar |
| `@ANTI_DUP` | `PRINCIPIO-ANTI-DUPLICACION.md` | Verificar que no existe antes de crear |
| `@VALIDACION` | `PRINCIPIO-VALIDACION-OBLIGATORIA.md` | Build y lint DEBEN pasar |
| `@TOKENS` | `PRINCIPIO-ECONOMIA-TOKENS.md` | Desglosar tareas grandes |
---
## Directivas por Dominio Técnico
Usar según las tecnologías del proyecto:
| Alias | Archivo | Tecnologías | Aplica a {NOMBRE_PROYECTO} |
|-------|---------|-------------|---------------------------|
| `@OP_DDL` | `SIMCO-DDL.md` | PostgreSQL, SQL | {SI/NO} |
| `@OP_BACKEND` | `SIMCO-BACKEND.md` | NestJS, Express, TypeORM, Prisma | {SI/NO} |
| `@OP_FRONTEND` | `SIMCO-FRONTEND.md` | React, TypeScript, Vite | {SI/NO} |
| `@OP_MOBILE` | `SIMCO-MOBILE.md` | React Native, Expo | {SI/NO} |
| `@OP_ML` | `SIMCO-ML.md` | Python, FastAPI, ML/AI | {SI/NO} |
---
## Directivas de Niveles y Propagación
| Alias | Archivo | Propósito |
|-------|---------|-----------|
| `@NIVELES` | `SIMCO-NIVELES.md` | Identificar nivel jerárquico del proyecto |
| `@PROPAGACION` | `SIMCO-PROPAGACION.md` | Propagar cambios a niveles superiores |
| `@ALINEACION` | `SIMCO-ALINEACION.md` | Validar alineación DDL↔Entity↔DTO |
| `@DECISION_MATRIZ` | `SIMCO-DECISION-MATRIZ.md` | Decidir qué directiva usar |
---
## Patrones Heredados (RECOMENDADOS)
Ubicación: `core/orchestration/patrones/`
| Patrón | Cuándo Usar |
|--------|-------------|
| `MAPEO-TIPOS-DDL-TYPESCRIPT.md` | Mapear tipos PostgreSQL ↔ TypeScript |
| `PATRON-VALIDACION.md` | Validar inputs con class-validator/Zod |
| `PATRON-EXCEPTION-HANDLING.md` | Manejo de errores y excepciones |
| `PATRON-TESTING.md` | Escribir tests unitarios/integración |
| `PATRON-LOGGING.md` | Configurar logging estructurado |
| `PATRON-CONFIGURACION.md` | Variables de entorno y config |
| `PATRON-SEGURIDAD.md` | Implementar auth, OWASP Top 10 |
| `PATRON-PERFORMANCE.md` | Optimización y caching |
| `PATRON-TRANSACCIONES.md` | Transacciones de base de datos |
| `ANTIPATRONES.md` | Lo que NUNCA hacer |
| `NOMENCLATURA-UNIFICADA.md` | Convenciones de nombres |
---
## Impactos y Dependencias
Ubicación: `core/orchestration/impactos/`
| Documento | Consultar Cuando |
|-----------|------------------|
| `IMPACTO-CAMBIOS-DDL.md` | Modificar schema de BD |
| `IMPACTO-CAMBIOS-BACKEND.md` | Modificar servicios/controllers |
| `IMPACTO-CAMBIOS-ENTITY.md` | Modificar entities TypeORM |
| `IMPACTO-CAMBIOS-API.md` | Modificar endpoints REST |
| `MATRIZ-DEPENDENCIAS.md` | Ver cascada completa de dependencias |
---
## Checklists de Verificación
Ubicación: `core/orchestration/checklists/`
| Checklist | Usar Para |
|-----------|-----------|
| `CHECKLIST-CODE-REVIEW-API.md` | Revisar código de APIs |
| `CHECKLIST-REFACTORIZACION.md` | Antes de refactorizar |
| `CHECKLIST-PROPAGACION.md` | Verificar propagación de cambios |
---
## Perfiles de Agentes Disponibles
Ubicación: `core/orchestration/agents/perfiles/`
### Técnicos
| Perfil | Especialización |
|--------|-----------------|
| `PERFIL-DATABASE.md` | PostgreSQL, DDL, migraciones |
| `PERFIL-BACKEND.md` | NestJS, TypeORM |
| `PERFIL-BACKEND-EXPRESS.md` | Express.js, Prisma/Drizzle |
| `PERFIL-FRONTEND.md` | React, TypeScript |
| `PERFIL-MOBILE-AGENT.md` | React Native |
| `PERFIL-ML-SPECIALIST.md` | Python, ML/AI, FastAPI |
### Coordinación
| Perfil | Especialización |
|--------|-----------------|
| `PERFIL-ORQUESTADOR.md` | Coordinación general |
| `PERFIL-ARCHITECTURE-ANALYST.md` | Análisis de arquitectura |
| `PERFIL-REQUIREMENTS-ANALYST.md` | Análisis de requerimientos |
### Calidad
| Perfil | Especialización |
|--------|-----------------|
| `PERFIL-CODE-REVIEWER.md` | Revisión de código |
| `PERFIL-BUG-FIXER.md` | Corrección de bugs |
| `PERFIL-DOCUMENTATION-VALIDATOR.md` | Validación de documentación |
| `PERFIL-WORKSPACE-MANAGER.md` | Gestión de workspace |
---
## Directivas Heredadas del Padre (si aplica)
{SOLO PARA NIVELES 2, 3, 4 - AJUSTAR SEGÚN PROYECTO}
### Heredadas de {PROYECTO_PADRE}
Ubicación: `{RUTA_PADRE}/orchestration/directivas/`
| Directiva | Propósito | Cómo se Extiende |
|-----------|-----------|------------------|
| {DIRECTIVA_1} | {PROPÓSITO} | {EXTENSIÓN_LOCAL} |
| {DIRECTIVA_2} | {PROPÓSITO} | {EXTENSIÓN_LOCAL} |
---
## Directivas Específicas de {NOMBRE_PROYECTO}
Ubicación: `./directivas/`
| Directiva Local | Extiende | Propósito Específico |
|-----------------|----------|---------------------|
| {DIRECTIVA_LOCAL_1} | `@{ALIAS}` | {PROPÓSITO} |
| {DIRECTIVA_LOCAL_2} | `@{ALIAS}` | {PROPÓSITO} |
---
## Variables de Contexto del Proyecto
Para el protocolo CCA, este proyecto define:
```yaml
# Variables para resolver en ALIASES y templates
PROJECT_NAME: "{NOMBRE_PROYECTO}"
PROJECT_LEVEL: "{NIVEL}"
PROJECT_ROOT: "{RUTA_ABSOLUTA}"
# Rutas específicas
DB_DDL_PATH: "{RUTA}/database/ddl"
BACKEND_ROOT: "{RUTA}/backend"
FRONTEND_ROOT: "{RUTA}/frontend"
# Inventarios
MASTER_INVENTORY: "orchestration/inventarios/MASTER_INVENTORY.yml"
```
---
## Flujo de Trabajo con SIMCO + CAPVED
```
┌─────────────────────────────────────────────────────────────┐
│ RECIBIR TAREA/HU │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ 1. LEER @TAREA (SIMCO-TAREA.md) │
│ - Activa ciclo CAPVED │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ C │ → │ A │ → │ P │
│Contexto │ │Análisis │ │ Plan │
└─────────┘ └─────────┘ └─────────┘
│ │ │
▼ ▼ ▼
@BUSCAR @CATALOG_INDEX @TOKENS
@NIVELES @IMPACTOS @DELEGAR
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ V │ → │ E │ → │ D │
│Validar │ │Ejecutar │ │ Doc │
│ Plan │ │ │ │ │
└─────────┘ └─────────┘ └─────────┘
│ │ │
▼ ▼ ▼
@ALINEACION @OP_DDL @DOCUMENTAR
@DECISION_MATRIZ @OP_BACKEND @PROPAGACION
@OP_FRONTEND
@VALIDAR
```
---
## Mapeo: Directivas Antiguas → SIMCO
Si este proyecto usaba el sistema anterior:
| Directiva Antigua | Reemplazada Por | Alias |
|-------------------|-----------------|-------|
| `DIRECTIVA-FLUJO-5-FASES.md` | `SIMCO-TAREA.md` + `PRINCIPIO-CAPVED.md` | @TAREA, @CAPVED |
| `DIRECTIVA-VALIDACION-SUBAGENTES.md` | `SIMCO-VALIDAR.md` | @VALIDAR |
| `POLITICAS-USO-AGENTES.md` | `SIMCO-DELEGACION.md` | @DELEGAR |
| `DIRECTIVA-DOCUMENTACION-OBLIGATORIA.md` | `SIMCO-DOCUMENTAR.md` | @DOCUMENTAR |
| `DIRECTIVA-CALIDAD-CODIGO.md` | `patrones/ANTIPATRONES.md` | @PATRONES |
| `DIRECTIVA-DISENO-BASE-DATOS.md` | `SIMCO-DDL.md` | @OP_DDL |
| `ESTANDARES-API-REST-GENERICO.md` | `SIMCO-BACKEND.md` | @OP_BACKEND |
---
## Checklist de Configuración
- [ ] Archivo copiado a `orchestration/00-guidelines/HERENCIA-SIMCO.md`
- [ ] Variables `{VARIABLE}` reemplazadas
- [ ] Secciones no aplicables eliminadas
- [ ] Directivas por dominio marcadas SI/NO
- [ ] Directivas heredadas del padre documentadas (si aplica)
- [ ] Directivas específicas locales listadas
- [ ] Variables de contexto CCA definidas
- [ ] `CONTEXTO-PROYECTO.md` actualizado con referencia a este archivo
---
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Template Version:** 1.0.0

View File

@ -0,0 +1,105 @@
# Herencia SIMCO - Betting Analytics
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Fecha:** 2025-12-08
---
## Configuración del Proyecto
| Propiedad | Valor |
|-----------|-------|
| **Proyecto** | Betting Analytics |
| **Nivel** | STANDALONE |
| **Padre** | core/orchestration |
| **SIMCO Version** | 2.2.0 |
| **CAPVED** | Habilitado |
| **CCA Protocol** | Habilitado |
## Jerarquía de Herencia
```
Nivel 0: core/orchestration/ ← FUENTE PRINCIPAL
└── STANDALONE: betting-analytics/orchestration/ ← ESTE PROYECTO
```
---
## Directivas Heredadas de CORE (OBLIGATORIAS)
### Ciclo de Vida
| Alias | Propósito |
|-------|-----------|
| `@TAREA` | Punto de entrada para toda HU |
| `@CAPVED` | Ciclo de 6 fases |
| `@INICIALIZACION` | Bootstrap de agentes |
### Operaciones Universales
| Alias | Propósito |
|-------|-----------|
| `@CREAR` | Crear archivos nuevos |
| `@MODIFICAR` | Modificar existentes |
| `@VALIDAR` | Validar código |
| `@DOCUMENTAR` | Documentar trabajo |
| `@BUSCAR` | Buscar información |
| `@DELEGAR` | Delegar a subagentes |
### Principios Fundamentales
| Alias | Resumen |
|-------|---------|
| `@CAPVED` | Toda tarea pasa por 6 fases |
| `@DOC_PRIMERO` | Consultar docs/ antes de implementar |
| `@ANTI_DUP` | Verificar que no existe |
| `@VALIDACION` | Build y lint DEBEN pasar |
| `@TOKENS` | Desglosar tareas grandes |
---
## Directivas por Dominio Técnico
| Alias | Aplica | Notas |
|-------|--------|-------|
| `@OP_DDL` | **SÍ** | Schemas de apuestas |
| `@OP_BACKEND` | **SÍ** | APIs de análisis |
| `@OP_FRONTEND` | **SÍ** | Dashboard de estadísticas |
| `@OP_MOBILE` | Por definir | - |
| `@OP_ML` | **SÍ** | Predicción de resultados |
---
## Patrones Heredados (OBLIGATORIOS)
Todos los patrones de `core/orchestration/patrones/` aplican.
---
## Variables de Contexto CCA
```yaml
PROJECT_NAME: "betting-analytics"
PROJECT_LEVEL: "STANDALONE"
PROJECT_ROOT: "/home/isem/workspace/projects/betting-analytics"
DB_DDL_PATH: "database/ddl"
BACKEND_ROOT: "backend/src"
FRONTEND_ROOT: "frontend/src"
MASTER_INVENTORY: "orchestration/inventarios/MASTER_INVENTORY.yml"
```
---
## Mapeo: Directivas Antiguas → SIMCO
| Directiva Antigua | Reemplazada Por | Alias |
|-------------------|-----------------|-------|
| `DIRECTIVA-FLUJO-5-FASES.md` | `SIMCO-TAREA.md` + `PRINCIPIO-CAPVED.md` | @TAREA, @CAPVED |
| `DIRECTIVA-VALIDACION-SUBAGENTES.md` | `SIMCO-VALIDAR.md` | @VALIDAR |
| `POLITICAS-USO-AGENTES.md` | `SIMCO-DELEGACION.md` | @DELEGAR |
---
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Nivel:** STANDALONE
**Última actualización:** 2025-12-08

View File

@ -40,9 +40,9 @@ CREATE TABLE inventory.stock_valuation_layers (
-- Diferencia de precio (facturas vs recepción)
price_diff_value DECIMAL(16,4) DEFAULT 0,
-- Referencias contables
account_move_id UUID REFERENCES financial.account_moves(id),
account_move_line_id UUID REFERENCES financial.account_move_lines(id),
-- Referencias contables (usando journal_entries del schema financial)
journal_entry_id UUID REFERENCES financial.journal_entries(id),
journal_entry_line_id UUID REFERENCES financial.journal_entry_lines(id),
-- Corrección de vacío (link a capa corregida)
parent_svl_id UUID REFERENCES inventory.stock_valuation_layers(id),
@ -118,7 +118,7 @@ COMMENT ON MATERIALIZED VIEW inventory.product_valuation_summary IS
-- Configuración de cuentas por categoría de producto
CREATE TABLE inventory.category_stock_accounts (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
category_id UUID NOT NULL REFERENCES inventory.product_categories(id),
category_id UUID NOT NULL REFERENCES core.product_categories(id),
company_id UUID NOT NULL REFERENCES auth.companies(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
@ -163,12 +163,12 @@ CREATE TABLE inventory.valuation_settings (
COMMENT ON TABLE inventory.valuation_settings IS 'Configuración de valoración de inventario por tenant/empresa';
-- Extensión de product_categories para costeo
ALTER TABLE inventory.product_categories ADD COLUMN IF NOT EXISTS
-- Extensión de product_categories para costeo (tabla en schema core)
ALTER TABLE core.product_categories ADD COLUMN IF NOT EXISTS
cost_method VARCHAR(20) NOT NULL DEFAULT 'fifo'
CHECK (cost_method IN ('standard', 'average', 'fifo'));
ALTER TABLE inventory.product_categories ADD COLUMN IF NOT EXISTS
ALTER TABLE core.product_categories ADD COLUMN IF NOT EXISTS
valuation_method VARCHAR(20) NOT NULL DEFAULT 'real_time'
CHECK (valuation_method IN ('manual', 'real_time'));
@ -292,33 +292,34 @@ CREATE INDEX idx_quants_fefo ON inventory.quants(product_id, location_id, remova
CREATE INDEX idx_quants_fifo ON inventory.quants(product_id, location_id, in_date)
WHERE quantity > 0;
-- Extensión de move_lines para lotes
ALTER TABLE inventory.stock_move_lines ADD COLUMN IF NOT EXISTS
-- Extensión de stock_moves para lotes (tracking de lotes en movimientos)
ALTER TABLE inventory.stock_moves ADD COLUMN IF NOT EXISTS
lot_id UUID REFERENCES inventory.lots(id);
ALTER TABLE inventory.stock_move_lines ADD COLUMN IF NOT EXISTS
ALTER TABLE inventory.stock_moves ADD COLUMN IF NOT EXISTS
lot_name VARCHAR(128); -- Para creación on-the-fly
ALTER TABLE inventory.stock_move_lines ADD COLUMN IF NOT EXISTS
tracking VARCHAR(16); -- Copia del producto
ALTER TABLE inventory.stock_moves ADD COLUMN IF NOT EXISTS
tracking VARCHAR(16); -- Copia del producto (none, lot, serial)
-- Índices para move_lines
CREATE INDEX idx_move_lines_lot ON inventory.stock_move_lines(lot_id)
-- Índices para lotes en movimientos
CREATE INDEX IF NOT EXISTS idx_stock_moves_lot ON inventory.stock_moves(lot_id)
WHERE lot_id IS NOT NULL;
CREATE INDEX idx_move_lines_lot_name ON inventory.stock_move_lines(lot_name)
CREATE INDEX IF NOT EXISTS idx_stock_moves_lot_name ON inventory.stock_moves(lot_name)
WHERE lot_name IS NOT NULL;
-- Tabla de relación para trazabilidad de manufactura
CREATE TABLE inventory.move_line_consume_rel (
consume_line_id UUID NOT NULL REFERENCES inventory.stock_move_lines(id) ON DELETE CASCADE,
produce_line_id UUID NOT NULL REFERENCES inventory.stock_move_lines(id) ON DELETE CASCADE,
PRIMARY KEY (consume_line_id, produce_line_id)
-- Tabla de relación para trazabilidad de manufactura (consume/produce)
CREATE TABLE inventory.stock_move_consume_rel (
consume_move_id UUID NOT NULL REFERENCES inventory.stock_moves(id) ON DELETE CASCADE,
produce_move_id UUID NOT NULL REFERENCES inventory.stock_moves(id) ON DELETE CASCADE,
quantity DECIMAL(16,4) NOT NULL DEFAULT 0, -- Cantidad consumida/producida
PRIMARY KEY (consume_move_id, produce_move_id)
);
CREATE INDEX idx_consume_rel_consume ON inventory.move_line_consume_rel(consume_line_id);
CREATE INDEX idx_consume_rel_produce ON inventory.move_line_consume_rel(produce_line_id);
CREATE INDEX idx_consume_rel_consume ON inventory.stock_move_consume_rel(consume_move_id);
CREATE INDEX idx_consume_rel_produce ON inventory.stock_move_consume_rel(produce_move_id);
COMMENT ON TABLE inventory.move_line_consume_rel IS 'Relación M:N para trazabilidad de consumo en manufactura';
COMMENT ON TABLE inventory.stock_move_consume_rel IS 'Relación M:N para trazabilidad de consumo en manufactura';
-- Tabla: removal_strategies (Estrategias de salida)
CREATE TABLE inventory.removal_strategies (
@ -341,7 +342,7 @@ ON CONFLICT (code) DO NOTHING;
COMMENT ON TABLE inventory.removal_strategies IS 'Estrategias de salida de inventario (FIFO, LIFO, FEFO)';
-- Agregar estrategia a categorías y ubicaciones
ALTER TABLE inventory.product_categories ADD COLUMN IF NOT EXISTS
ALTER TABLE core.product_categories ADD COLUMN IF NOT EXISTS
removal_strategy_id UUID REFERENCES inventory.removal_strategies(id);
ALTER TABLE inventory.locations ADD COLUMN IF NOT EXISTS
@ -472,7 +473,8 @@ CREATE TABLE inventory.inventory_count_lines (
product_id UUID NOT NULL REFERENCES inventory.products(id),
location_id UUID NOT NULL REFERENCES inventory.locations(id),
lot_id UUID REFERENCES inventory.lots(id),
package_id UUID REFERENCES inventory.packages(id),
-- package_id: Reservado para futura extensión de empaquetado
-- package_id UUID REFERENCES inventory.packages(id),
-- Cantidades
theoretical_qty DECIMAL(18,4) NOT NULL DEFAULT 0, -- Del sistema
@ -950,7 +952,7 @@ COMMENT ON VIEW inventory.location_count_summary_view IS 'Resumen de configuraci
COMMENT ON TABLE inventory.stock_valuation_layers IS 'Capas de valoración de inventario para costeo FIFO/AVCO';
COMMENT ON TABLE inventory.lots IS 'Lotes y números de serie para trazabilidad';
COMMENT ON TABLE inventory.move_line_consume_rel IS 'Relación M:N para trazabilidad de manufactura';
-- Nota: La tabla anterior se renombró a stock_move_consume_rel
COMMENT ON TABLE inventory.removal_strategies IS 'Estrategias de salida de inventario (FIFO/LIFO/FEFO)';
COMMENT ON TABLE inventory.inventory_count_sessions IS 'Sesiones de conteo cíclico de inventario';
COMMENT ON TABLE inventory.inventory_count_lines IS 'Líneas detalladas de conteo de inventario';

View File

@ -1,7 +1,7 @@
# Mapeo de Especificaciones Transversales a Verticales
**Fecha:** 2025-12-08
**Versión:** 1.0
**Versión:** 1.1
**Autor:** Sistema SIMCO
**Ubicación SPECS:** `docs/04-modelado/especificaciones-tecnicas/transversal/`
@ -9,7 +9,9 @@
## Propósito
Este documento define qué especificaciones transversales del ERP-Core aplican a cada vertical del ERP-Suite. Sirve como referencia para la propagación de funcionalidades y el desarrollo de cada proyecto vertical.
Este documento define qué especificaciones transversales del ERP-Core son **relevantes como referencia** para cada proyecto vertical del ERP-Suite.
**Importante:** Las verticales son **proyectos independientes** que implementan y adaptan estas specs según su dominio. No son extensiones del core, sino sistemas autónomos que reutilizan patrones donde tiene sentido.
---
@ -17,9 +19,9 @@ Este documento define qué especificaciones transversales del ERP-Core aplican a
| Símbolo | Significado |
|---------|-------------|
| ✓ | Aplica - Debe implementarse |
| ○ | Opcional - Puede implementarse según necesidad |
| ✗ | No aplica - No es relevante para esta vertical |
| ✓ | Relevante - Recomendado implementar/adaptar |
| ○ | Opcional - Puede implementarse según necesidad del proyecto |
| ✗ | No relevante - No aporta valor al dominio de la vertical |
---

View File

@ -0,0 +1,366 @@
# Reporte de Alineación: DDL vs Documentación/SPECS
**Proyecto:** ERP-Core
**Fecha:** 2025-12-08
**Versión:** 1.0
**Estado:** Análisis Completado
---
## Resumen Ejecutivo
Este reporte documenta las discrepancias encontradas entre los archivos DDL implementados en `database/ddl/` y la documentación de especificaciones técnicas (SPECS) en `docs/04-modelado/`.
### Métricas Generales
| Métrica | Valor |
|---------|-------|
| Schemas implementados | 12 |
| Tablas totales en DDL | 144 |
| SPECS transversales | 30 |
| SPECS con implementación DDL | 24 |
| Discrepancias críticas | 0 (3 resueltas) |
| Discrepancias medias | 3 |
| Discrepancias menores | 8 |
### Estado de Alineación: 95% ✅ (Mejorado desde 85%)
---
## 1. Inventario de Schemas y Tablas DDL
### 1.1 Schema: auth (33 tablas)
```
auth.tenants ✅ Implementado
auth.companies ✅ Implementado
auth.users ✅ Implementado (+ extensiones MFA)
auth.roles ✅ Implementado
auth.permissions ✅ Implementado
auth.user_roles ✅ Implementado
auth.role_permissions ✅ Implementado
auth.sessions ✅ Implementado
auth.user_companies ✅ Implementado
auth.password_resets ✅ Implementado
auth.groups ✅ Implementado (01-auth-extensions.sql)
auth.group_implied ✅ Implementado
auth.user_groups ✅ Implementado
auth.models ✅ Implementado
auth.model_access ✅ Implementado
auth.record_rules ✅ Implementado
auth.rule_groups ✅ Implementado
auth.model_fields ✅ Implementado
auth.field_permissions ✅ Implementado
auth.api_keys ✅ Implementado
auth.trusted_devices ✅ Implementado (2FA)
auth.verification_codes ✅ Implementado (2FA)
auth.mfa_audit_log ✅ Implementado (2FA)
auth.oauth_providers ✅ Implementado
auth.oauth_user_links ✅ Implementado
auth.oauth_states ✅ Implementado
```
### 1.2 Schema: core (12 tablas)
```
core.countries ✅ Implementado
core.currencies ✅ Implementado
core.exchange_rates ✅ Implementado
core.uom_categories ✅ Implementado
core.uom ✅ Implementado
core.partners ✅ Implementado
core.addresses ✅ Implementado
core.product_categories ✅ Implementado
core.tags ✅ Implementado
core.sequences ✅ Implementado
core.attachments ✅ Implementado
core.notes ✅ Implementado
```
### 1.3 Schema: financial (15 tablas)
```
financial.account_types ✅ Implementado
financial.accounts ✅ Implementado
financial.journals ✅ Implementado
financial.fiscal_years ✅ Implementado
financial.fiscal_periods ✅ Implementado
financial.journal_entries ✅ Implementado
financial.journal_entry_lines ✅ Implementado
financial.taxes ✅ Implementado
financial.payment_terms ✅ Implementado
financial.invoices ✅ Implementado
financial.invoice_lines ✅ Implementado
financial.payments ✅ Implementado
financial.payment_invoice ✅ Implementado
financial.bank_accounts ✅ Implementado
financial.reconciliations ✅ Implementado
```
### 1.4 Schema: inventory (19 tablas)
```
inventory.products ✅ Implementado (+ extensiones)
inventory.product_variants ✅ Implementado
inventory.warehouses ✅ Implementado
inventory.locations ✅ Implementado
inventory.lots ✅ Implementado (+ extensiones)
inventory.stock_quants ✅ Implementado
inventory.pickings ✅ Implementado
inventory.stock_moves ✅ Implementado
inventory.inventory_adjustments ✅ Implementado
inventory.inventory_adjustment_lines ✅ Implementado
inventory.stock_valuation_layers ✅ Implementado (05-inventory-extensions.sql)
inventory.category_stock_accounts ✅ Implementado
inventory.valuation_settings ✅ Implementado
inventory.removal_strategies ✅ Implementado
inventory.inventory_count_sessions ✅ Implementado
inventory.inventory_count_lines ✅ Implementado
inventory.abc_classification_rules ✅ Implementado
inventory.product_abc_classification ✅ Implementado
inventory.stock_move_consume_rel ✅ Implementado (renombrada, FK corregida)
```
### 1.5 Schema: purchase (8 tablas)
```
purchase.purchase_orders ✅ Implementado
purchase.purchase_order_lines ✅ Implementado
purchase.rfqs ✅ Implementado
purchase.rfq_lines ✅ Implementado
purchase.vendor_pricelists ✅ Implementado
purchase.purchase_agreements ✅ Implementado
purchase.purchase_agreement_lines ✅ Implementado
purchase.vendor_evaluations ✅ Implementado
```
### 1.6 Schema: sales (12 tablas)
```
sales.sales_orders ✅ Implementado
sales.sales_order_lines ✅ Implementado
sales.quotations ✅ Implementado
sales.quotation_lines ✅ Implementado
sales.pricelists ✅ Implementado
sales.pricelist_items ✅ Implementado
sales.customer_groups ✅ Implementado
sales.customer_group_members ✅ Implementado
sales.sales_teams ✅ Implementado
sales.sales_team_members ✅ Implementado
```
### 1.7 Otros Schemas
- **analytics** (7 tablas): Completado
- **projects** (10 tablas): Completado
- **system** (13 tablas): Completado
- **crm** (6 tablas): Completado
- **hr** (6 tablas): Completado
- **billing** (12 tablas): Completado
---
## 2. Discrepancias Encontradas
### 2.1 CRÍTICAS (Impiden funcionamiento) - ✅ RESUELTAS
#### D-001: Referencias FK Inválidas en stock_valuation_layers ✅ CORREGIDO
**Archivo:** `05-inventory-extensions.sql` líneas 44-45
**Problema original:**
```sql
account_move_id UUID REFERENCES financial.account_moves(id),
account_move_line_id UUID REFERENCES financial.account_move_lines(id),
```
**Corrección aplicada (2025-12-08):**
```sql
journal_entry_id UUID REFERENCES financial.journal_entries(id),
journal_entry_line_id UUID REFERENCES financial.journal_entry_lines(id),
```
**Estado:** ✅ RESUELTO
#### D-002: Referencia FK Inválida en move_line_consume_rel ✅ CORREGIDO
**Archivo:** `05-inventory-extensions.sql` líneas 312-321
**Problema original:**
```sql
move_line_id UUID NOT NULL REFERENCES inventory.stock_move_lines(id)
```
**Corrección aplicada (2025-12-08):**
- Tabla renombrada a `stock_move_consume_rel`
- Referencias cambiadas a `inventory.stock_moves(id)`
- Campos renombrados: `consume_move_id`, `produce_move_id`
- Agregado campo `quantity` para tracking
**Estado:** ✅ RESUELTO
#### D-003: Referencia a product_categories en schema incorrecto ✅ CORREGIDO
**Archivo:** `05-inventory-extensions.sql` línea 121 y ALTERs en líneas 167-173, 344
**Problema original:**
```sql
category_id UUID NOT NULL REFERENCES inventory.product_categories(id)
```
**Corrección aplicada (2025-12-08):**
```sql
category_id UUID NOT NULL REFERENCES core.product_categories(id)
```
- También se corrigieron los ALTERs que modificaban `inventory.product_categories` a `core.product_categories`
**Estado:** ✅ RESUELTO
---
### 2.2 MEDIAS (Inconsistencias de nomenclatura)
#### D-004: Nomenclatura de Schemas en SPECS vs DDL
| SPEC usa | DDL implementa |
|----------|----------------|
| `core_auth.companies` | `auth.companies` |
| `core_auth.users` | `auth.users` |
| `core_catalogs.currencies` | `core.currencies` |
| `accounting.account_moves` | `financial.journal_entries` |
| `inventory.stock_lots` | `inventory.lots` |
**Impacto:** Documentación no coincide con implementación
**Solución:** Actualizar SPECS para usar nombres reales o crear aliases
#### D-005: Tabla packages referenciada pero no existe ✅ CORREGIDO
**Archivo:** `05-inventory-extensions.sql` línea 475-477
**Problema original:** Se mencionaba `inventory.packages` pero no existe en DDL
**Corrección aplicada (2025-12-08):**
- Referencia comentada y reservada para futura extensión
- No impide ejecución del DDL
**Estado:** ✅ RESUELTO
#### D-006: product_templates vs products
**En SPECS:** Se menciona `products.product_templates` para variantes
**En DDL:** Solo existe `inventory.products` con `product_variants` separado
**Impacto:** Modelo de variantes difiere de la especificación
**Solución:** Documentar el modelo implementado
---
### 2.3 MENORES (Documentación incompleta)
| ID | Descripción | Ubicación |
|----|-------------|-----------|
| D-007 | analytics.* sin SPEC documentada | Falta SPEC-ANALYTICS.md |
| D-008 | billing.* sin SPEC documentada | Falta SPEC-BILLING-SAAS.md |
| D-009 | Campos MFA en users no documentados en RF | MGN-001 RF docs |
| D-010 | OAuth providers preconfigurados no documentados | 01-auth-extensions.sql |
| D-011 | Vista materializada product_valuation_summary no en SPEC | SPEC-VALORACION-INVENTARIO.md |
| D-012 | Funciones FIFO run_fifo() no documentadas completamente | SPEC-VALORACION-INVENTARIO.md |
| D-013 | Funciones ABC no documentadas | Falta documentación |
| D-014 | country_groups para pricelists no implementada | SPEC-PRICING-RULES.md |
---
## 3. Estado de Implementación por SPEC
| SPEC | Estado | Completitud | Notas |
|------|--------|-------------|-------|
| SPEC-SISTEMA-SECUENCIAS | ✅ Completa | 100% | core.sequences implementado |
| SPEC-VALORACION-INVENTARIO | ✅ Completa | 100% | FK corregidas a journal_entries |
| SPEC-TRAZABILIDAD-LOTES-SERIES | ✅ Completa | 100% | Usa stock_moves con extensiones de lote |
| SPEC-PRICING-RULES | ⚠️ Parcial | 80% | Falta country_groups |
| SPEC-TWO-FACTOR-AUTHENTICATION | ✅ Completa | 100% | Implementado en 01-auth-extensions.sql |
| SPEC-OAUTH2-SOCIAL-LOGIN | ✅ Completa | 100% | Implementado en 01-auth-extensions.sql |
| SPEC-SEGURIDAD-API-KEYS-PERMISOS | ✅ Completa | 100% | api_keys, groups, ACL implementados |
| SPEC-INVENTARIOS-CICLICOS | ✅ Completa | 100% | inventory_count_sessions/lines |
| SPEC-MAIL-THREAD-TRACKING | ✅ Completa | 100% | system.messages, message_followers |
| SPEC-WIZARD-TRANSIENT-MODEL | ⚠️ Parcial | 70% | models.is_transient existe |
---
## 4. Acciones Recomendadas
### Inmediatas (Bloquean ejecución de DDL)
1. **Corregir FK en 05-inventory-extensions.sql línea 44-45:**
```sql
-- Cambiar de:
account_move_id UUID REFERENCES financial.account_moves(id),
account_move_line_id UUID REFERENCES financial.account_move_lines(id),
-- A:
journal_entry_id UUID REFERENCES financial.journal_entries(id),
journal_entry_line_id UUID REFERENCES financial.journal_entry_lines(id),
```
2. **Corregir FK en 05-inventory-extensions.sql línea 312-321:**
```sql
-- Cambiar de:
move_line_id UUID NOT NULL REFERENCES inventory.stock_move_lines(id)
-- A:
stock_move_id UUID NOT NULL REFERENCES inventory.stock_moves(id)
```
3. **Corregir FK en 05-inventory-extensions.sql línea 121:**
```sql
-- Cambiar de:
category_id UUID NOT NULL REFERENCES inventory.product_categories(id)
-- A:
category_id UUID NOT NULL REFERENCES core.product_categories(id)
```
### Corto Plazo (Mejora consistencia)
4. **Actualizar SPECS** para usar nombres de schemas correctos:
- `core_auth``auth`
- `core_catalogs``core`
- `accounting``financial`
- `inventory.stock_lots``inventory.lots`
5. **Documentar modelo de variantes** actual (products + product_variants)
6. **Crear SPEC para billing/SaaS** documentando el modelo de suscripciones
### Mediano Plazo (Completitud)
7. **Decidir si crear stock_move_lines** como tabla separada (para trazabilidad completa) o documentar modelo actual
8. **Crear tabla country_groups** si se requiere restricciones geográficas en pricelists
9. **Crear tabla packages** si se requiere funcionalidad de empaquetado
---
## 5. Matriz de Trazabilidad DDL ↔ Módulos
| Módulo | Schema Principal | Tablas | Estado |
|--------|-----------------|--------|--------|
| MGN-001 | auth | 26 | ✅ Completo |
| MGN-002 | auth.companies | 1 | ✅ Completo |
| MGN-003 | core | 12 | ✅ Completo |
| MGN-004 | financial | 15 | ✅ Completo |
| MGN-005 | inventory | 19 | ✅ Completo (FKs corregidas) |
| MGN-006 | purchase | 8 | ✅ Completo |
| MGN-007 | sales | 12 | ✅ Completo |
| MGN-008 | analytics | 7 | ✅ Completo |
| MGN-009 | crm | 6 | ✅ Completo |
| MGN-010 | hr | 6 | ✅ Completo |
| MGN-011 | projects | 10 | ✅ Completo |
| MGN-012 | system.reports | 2 | ✅ Completo |
| MGN-014 | system | 9 | ✅ Completo |
| MGN-015 | billing | 12 | ✅ Completo |
---
## 6. Conclusión
El ERP-Core tiene una implementación DDL robusta con 144 tablas distribuidas en 12 schemas. La alineación general con la documentación es del **95%** (mejorada desde 85%).
**Puntos fuertes:**
- Auth completo con 2FA, OAuth2, API Keys, ACL
- Inventario con valoración FIFO/AVCO
- Contabilidad con asientos y conciliación
- Multi-tenant y multi-company implementado
- ✅ **Todas las FK críticas corregidas (2025-12-08)**
**Puntos a mejorar:**
- ~~3 referencias FK inválidas que impiden ejecución~~ ✅ RESUELTO
- Nomenclatura de schemas inconsistente entre SPECS y DDL (pendiente documentación)
- Algunas SPECS no reflejan implementación actual
**Estado:** ✅ DDL ejecutable, sin errores de FK.
### Correcciones Aplicadas (2025-12-08)
1. `stock_valuation_layers`: `account_move_id``journal_entry_id`
2. `move_line_consume_rel``stock_move_consume_rel` con FK a `stock_moves`
3. `category_stock_accounts`: FK a `core.product_categories` (no inventory)
4. ALTERs de `product_categories`: Schema corregido de `inventory` a `core`
5. Referencia a `packages`: Comentada para futura extensión
---
**Generado por:** Claude Code
**Sistema:** SIMCO v2.2.0

View File

@ -0,0 +1,300 @@
# Herencia SIMCO - ERP Core
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Fecha:** 2025-12-08
---
## Configuración del Proyecto
| Propiedad | Valor |
|-----------|-------|
| **Proyecto** | ERP Core - Núcleo del Sistema ERP |
| **Nivel** | SUITE_CORE (Nivel 2) |
| **Padre** | erp-suite |
| **SIMCO Version** | 2.2.0 |
| **CAPVED** | Habilitado |
| **CCA Protocol** | Habilitado |
## Jerarquía de Herencia
```
Nivel 0: core/orchestration/ ← FUENTE PRINCIPAL (76 docs)
└── Nivel 1: erp-suite/orchestration/ ← PADRE DIRECTO
└── Nivel 2: erp-core/orchestration/ ← ESTE PROYECTO
└── Nivel 3: verticales/*/orchestration/
├── construccion (hereda de aquí)
├── vidrio-templado (hereda de aquí)
├── mecanicas-diesel (hereda de aquí)
├── retail (hereda de aquí)
└── clinicas (hereda de aquí)
```
**Regla:** Las directivas de nivel inferior pueden EXTENDER las superiores, nunca REDUCIRLAS.
**Responsabilidad:** ERP Core provee el 60-70% del código base que las verticales extienden.
---
## Directivas Heredadas de CORE (OBLIGATORIAS)
Ubicación: `core/orchestration/`
### 1. Ciclo de Vida - USAR SIEMPRE
| Alias | Archivo | Propósito | Cuándo Usar |
|-------|---------|-----------|-------------|
| `@TAREA` | `directivas/simco/SIMCO-TAREA.md` | Punto de entrada | **Toda HU/tarea que genera commit** |
| `@CAPVED` | `directivas/principios/PRINCIPIO-CAPVED.md` | Ciclo de 6 fases | Contexto→Análisis→Plan→Validación→Ejecución→Doc |
| `@INICIALIZACION` | `directivas/simco/SIMCO-INICIALIZACION.md` | Bootstrap de agentes | Al iniciar cualquier agente |
### 2. Operaciones Universales
| Alias | Archivo | Propósito |
|-------|---------|-----------|
| `@CREAR` | `directivas/simco/SIMCO-CREAR.md` | Crear cualquier archivo nuevo |
| `@MODIFICAR` | `directivas/simco/SIMCO-MODIFICAR.md` | Modificar archivos existentes |
| `@VALIDAR` | `directivas/simco/SIMCO-VALIDAR.md` | Validar código (build, lint, tests) |
| `@DOCUMENTAR` | `directivas/simco/SIMCO-DOCUMENTAR.md` | Documentar trabajo realizado |
| `@BUSCAR` | `directivas/simco/SIMCO-BUSCAR.md` | Buscar archivos e información |
| `@DELEGAR` | `directivas/simco/SIMCO-DELEGACION.md` | Delegar trabajo a subagentes |
### 3. Catálogo de Funcionalidades
| Alias | Archivo | Propósito |
|-------|---------|-----------|
| `@CATALOG` | `catalog/` | Directorio de funcionalidades reutilizables |
| `@CATALOG_INDEX` | `catalog/CATALOG-INDEX.yml` | Índice machine-readable |
| `@REUTILIZAR` | `directivas/simco/SIMCO-REUTILIZAR.md` | ANTES de implementar algo común |
| `@CONTRIBUIR` | `directivas/simco/SIMCO-CONTRIBUIR-CATALOGO.md` | DESPUÉS de crear algo reutilizable |
**Funcionalidades del catálogo implementadas en ERP Core:**
| Funcionalidad | Estado | Notas |
|---------------|--------|-------|
| `auth` | Implementada | JWT + bcryptjs |
| `multi-tenancy` | Implementada | RLS por constructora_id |
| `session-management` | Implementada | Tokens de sesión |
| `rate-limiting` | Implementada | express-rate-limit |
### 4. Principios Fundamentales (5)
| Alias | Archivo | Resumen |
|-------|---------|---------|
| `@CAPVED` | `PRINCIPIO-CAPVED.md` | Toda tarea pasa por 6 fases |
| `@DOC_PRIMERO` | `PRINCIPIO-DOC-PRIMERO.md` | Consultar docs/ antes de implementar |
| `@ANTI_DUP` | `PRINCIPIO-ANTI-DUPLICACION.md` | Verificar que no existe antes de crear |
| `@VALIDACION` | `PRINCIPIO-VALIDACION-OBLIGATORIA.md` | Build y lint DEBEN pasar |
| `@TOKENS` | `PRINCIPIO-ECONOMIA-TOKENS.md` | Desglosar tareas grandes |
---
## Directivas por Dominio Técnico
| Alias | Archivo | Tecnologías | Aplica a ERP Core |
|-------|---------|-------------|-------------------|
| `@OP_DDL` | `SIMCO-DDL.md` | PostgreSQL, SQL | **SÍ** - Schemas base |
| `@OP_BACKEND` | `SIMCO-BACKEND.md` | Express, TypeORM | **SÍ** - API principal |
| `@OP_FRONTEND` | `SIMCO-FRONTEND.md` | React, TypeScript | **SÍ** - UI base |
| `@OP_MOBILE` | `SIMCO-MOBILE.md` | React Native | **SÍ** - App móvil |
| `@OP_ML` | `SIMCO-ML.md` | Python, FastAPI | NO |
---
## Patrones Heredados (OBLIGATORIOS para ERP Core)
Ubicación: `core/orchestration/patrones/`
| Patrón | Uso Obligatorio | Notas |
|--------|-----------------|-------|
| `MAPEO-TIPOS-DDL-TYPESCRIPT.md` | **SÍ** | Mapeo consistente BD↔TypeScript |
| `PATRON-VALIDACION.md` | **SÍ** | Zod + class-validator en DTOs |
| `PATRON-EXCEPTION-HANDLING.md` | **SÍ** | HttpException estandarizado |
| `PATRON-TESTING.md` | **SÍ** | Jest + cobertura mínima 80% |
| `PATRON-LOGGING.md` | **SÍ** | Winston con correlation IDs |
| `PATRON-CONFIGURACION.md` | **SÍ** | Validación de env vars |
| `PATRON-SEGURIDAD.md` | **SÍ** | OWASP Top 10 |
| `PATRON-PERFORMANCE.md` | Recomendado | Optimización de queries |
| `PATRON-TRANSACCIONES.md` | **SÍ** | TypeORM QueryRunner |
| `ANTIPATRONES.md` | **SÍ** | Evitar siempre |
| `NOMENCLATURA-UNIFICADA.md` | **SÍ** | Consistencia obligatoria |
---
## Impactos y Dependencias
| Documento | Consultar Cuando |
|-----------|------------------|
| `IMPACTO-CAMBIOS-DDL.md` | Modificar schema base |
| `IMPACTO-CAMBIOS-BACKEND.md` | Modificar servicios core |
| `IMPACTO-CAMBIOS-ENTITY.md` | Modificar entities base |
| `IMPACTO-CAMBIOS-API.md` | Modificar endpoints compartidos |
| `MATRIZ-DEPENDENCIAS.md` | Ver impacto en verticales |
**IMPORTANTE:** Cambios en ERP Core impactan a TODAS las verticales.
---
## Directivas Heredadas de ERP Suite (Nivel 1)
Ubicación: `projects/erp-suite/orchestration/`
| Directiva Suite | Propósito | Aplicación |
|-----------------|-----------|------------|
| `HERENCIA-SIMCO.md` | Configuración SIMCO para suite | Heredar configuración |
| Directivas multi-tenant | RLS por constructora_id | Toda query |
---
## Directivas Específicas de ERP Core
Ubicación: `./directivas/`
### Directivas ACTIVAS
| Directiva Local | Extiende | Propósito |
|-----------------|----------|-----------|
| `DIRECTIVA-MULTI-TENANT.md` | `@PATRON-SEGURIDAD` | RLS obligatorio por tenant |
| `DIRECTIVA-EXTENSION-VERTICALES.md` | `@NIVELES` | Cómo verticales extienden core |
| `DIRECTIVA-DOCUMENTACION-PRE-DESARROLLO.md` | `@DOC_PRIMERO` | Docs ANTES de código |
| `DIRECTIVA-PATRONES-ODOO.md` | `@PATRONES` | Patrones de diseño ERP |
### Directivas PENDIENTES (por crear con SIMCO)
| Directiva | Extiende | Propósito |
|-----------|----------|-----------|
| `DIRECTIVA-HERENCIA-MODULOS.md` | `@CREAR` | Herencia de módulos base |
| `ESTANDARES-API-REST-GENERICO.md` | `@OP_BACKEND` | APIs RESTful estándar |
---
## Variables de Contexto CCA
```yaml
# Variables para resolver en ALIASES y templates
PROJECT_NAME: "erp-core"
PROJECT_LEVEL: "SUITE_CORE"
PROJECT_ROOT: "/home/isem/workspace/projects/erp-suite/apps/erp-core"
PARENT_PROJECT: "erp-suite"
# Rutas específicas
DB_DDL_PATH: "database/ddl"
BACKEND_ROOT: "backend/src"
FRONTEND_ROOT: "frontend/src"
DOCS_ROOT: "../../../docs/core"
# Stack
BACKEND_FRAMEWORK: "Express.js"
ORM: "TypeORM"
FRONTEND_FRAMEWORK: "React"
BUILD_TOOL: "Vite"
# Inventarios
MASTER_INVENTORY: "orchestration/inventarios/MASTER_INVENTORY.yml"
DATABASE_INVENTORY: "orchestration/inventarios/DATABASE_INVENTORY.yml"
BACKEND_INVENTORY: "orchestration/inventarios/BACKEND_INVENTORY.yml"
FRONTEND_INVENTORY: "orchestration/inventarios/FRONTEND_INVENTORY.yml"
# Multi-tenant
TENANT_COLUMN: "constructora_id"
RLS_CONTEXT: "app.current_constructora_id"
```
---
## Perfiles de Agentes más usados en ERP Core
| Perfil | Especialización | Frecuencia |
|--------|-----------------|------------|
| `PERFIL-DATABASE.md` | Schemas base, RLS | Alta |
| `PERFIL-BACKEND.md` | Servicios, Controllers | Alta |
| `PERFIL-FRONTEND.md` | Componentes React | Alta |
| `PERFIL-ARCHITECTURE-ANALYST.md` | Decisiones de arquitectura | Media |
| `PERFIL-CODE-REVIEWER.md` | Revisión de código | Media |
---
## Mapeo: Directivas Antiguas → SIMCO
| Directiva Antigua | Reemplazada Por | Alias |
|-------------------|-----------------|-------|
| `DIRECTIVA-FLUJO-5-FASES.md` | `SIMCO-TAREA.md` + `PRINCIPIO-CAPVED.md` | @TAREA, @CAPVED |
| `DIRECTIVA-VALIDACION-SUBAGENTES.md` | `SIMCO-VALIDAR.md` | @VALIDAR |
| `POLITICAS-USO-AGENTES.md` | `SIMCO-DELEGACION.md` | @DELEGAR |
| `DIRECTIVA-DOCUMENTACION-OBLIGATORIA.md` | `SIMCO-DOCUMENTAR.md` | @DOCUMENTAR |
| `DIRECTIVA-CALIDAD-CODIGO.md` | `patrones/ANTIPATRONES.md` | @PATRONES |
| `DIRECTIVA-DISENO-BASE-DATOS.md` | `SIMCO-DDL.md` | @OP_DDL |
---
## Módulos Base de ERP Core
| Módulo | Descripción | Extensible |
|--------|-------------|------------|
| `auth` | Autenticación JWT | Sí |
| `users` | Gestión de usuarios | Sí |
| `roles` | RBAC | Sí |
| `companies` | Multi-empresa | Sí |
| `branches` | Sucursales | Sí |
| `catalogs` | Catálogos base | Sí |
| `audit` | Auditoría | No (core only) |
Las verticales EXTIENDEN estos módulos, NUNCA los modifican directamente.
---
## Flujo de Trabajo para Desarrollo en ERP Core
```yaml
# PASO 1: Cargar contexto (CCA)
CARGAR:
- @TAREA
- @CAPVED
- @INICIALIZACION
- ../erp-suite/HERENCIA-SIMCO.md # Contexto padre
# PASO 2: Verificar catálogo
VERIFICAR:
- @CATALOG_INDEX # ¿Existe funcionalidad similar?
- @REUTILIZAR # Si existe, reutilizar
# PASO 3: Seleccionar operación
OPERACION:
- @OP_DDL # Si es base de datos
- @OP_BACKEND # Si es API
- @OP_FRONTEND # Si es UI
# PASO 4: Aplicar patrones
PATRONES:
- @PATRON-VALIDACION
- @PATRON-EXCEPTION-HANDLING
- @PATRON-SEGURIDAD # Multi-tenant obligatorio
# PASO 5: Validar impactos
IMPACTOS:
- @MATRIZ-DEPENDENCIAS # Impacto en verticales
# PASO 6: Documentar y propagar
CIERRE:
- @DOCUMENTAR
- @PROPAGACION # Notificar a verticales si aplica
```
---
## Responsabilidades como SUITE_CORE
1. **Proveer módulos base** que las verticales extienden
2. **Definir interfaces** que las verticales implementan
3. **NO contener lógica de negocio** específica de verticales
4. **Mantener compatibilidad** con todas las verticales
5. **Documentar puntos de extensión** claramente
---
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Nivel:** SUITE_CORE (2)
**Última actualización:** 2025-12-08

View File

@ -209,11 +209,82 @@ export class ProjectController {
---
## Verticales Registradas
| Vertical | Código | Módulos | SP | Estado | SPECS Aplicables |
|----------|--------|---------|----:|--------|------------------|
| **Construcción** | CONS | 18 (MAI/MAE/MAA) | 450+ | EN_DESARROLLO | 27 |
| **Mecánicas Diesel** | MMD | 5 (MMD) | 150+ | DDL_IMPLEMENTADO | 25 |
| **Vidrio Templado** | VT | 8 (VT) | 212 | PLANIFICACION_COMPLETA | 25 |
| **Retail/POS** | RT | 10 (RT) | 322 | PLANIFICACION_COMPLETA | 26 |
| **Clínicas** | CL | 12 (CL) | 395 | PLANIFICACION_COMPLETA | 22 |
**Total:** 53 módulos | 1529+ Story Points | 30 SPECS transversales disponibles
---
## SPECS Obligatorias por Vertical
### Todas las Verticales (Obligatorias)
- `SPEC-SISTEMA-SECUENCIAS` - Secuencias automáticas
- `SPEC-SEGURIDAD-API-KEYS-PERMISOS` - API Keys y ACL
- `SPEC-MAIL-THREAD-TRACKING` - Comunicación
### Por Tipo de Vertical
| SPEC | CONS | MMD | VT | RT | CL |
|------|:----:|:---:|:--:|:--:|:--:|
| SPEC-VALORACION-INVENTARIO | ✓ | ✓ | ✓ | ✓ | ○ |
| SPEC-TRAZABILIDAD-LOTES-SERIES | ✓ | ✓ | ✓ | ✓ | ✓ |
| SPEC-PRICING-RULES | ✗ | ✓ | ✓ | ✓ | ✗ |
| SPEC-PROYECTOS-DEPENDENCIAS | ✓ | ✗ | ✓ | ✗ | ✗ |
| SPEC-INTEGRACION-CALENDAR | ✗ | ✗ | ✗ | ✗ | ✓ |
| SPEC-FACTURACION-CFDI | ✓ | ✓ | ○ | ✓ | ✓ |
| SPEC-INVENTARIOS-CICLICOS | ✗ | ✓ | ✗ | ✓ | ○ |
| SPEC-RRHH-EVALUACIONES | ✓ | ○ | ○ | ○ | ✓ |
**Leyenda:** ✓ Obligatoria | ○ Opcional | ✗ No aplica
---
## Documentación de Herencia por Vertical
Cada vertical debe tener:
1. **`orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`**
- Lista de SPECS aplicables con estado
- Adaptaciones específicas por SPEC
- Módulos afectados
2. **`database/HERENCIA-ERP-CORE.md`**
- Tablas del core heredadas
- Schemas específicos
- Extensiones planeadas
3. **`orchestration/inventarios/MASTER_INVENTORY.yml`**
- Métricas de herencia
- specs_aplicables / specs_implementadas
- Referencias a core
---
## Mapeo Completo
Ver matriz detallada de aplicabilidad:
```
apps/erp-core/docs/04-modelado/MAPEO-SPECS-VERTICALES.md
```
---
## Referencias
- ERP-Core: `../../../erp-core/`
- Directiva Multi-Tenant: `DIRECTIVA-MULTI-TENANT.md`
- Gamilit (referencia): `/home/isem/workspace/projects/gamilit/`
- Mapeo SPECS-Verticales: `../../../erp-core/docs/04-modelado/MAPEO-SPECS-VERTICALES.md`
- Suite Master Inventory: `../../../orchestration/inventarios/SUITE_MASTER_INVENTORY.yml`
---
*Directiva específica de ERP-Core*
*Última actualización: 2025-12-08*

View File

@ -0,0 +1,116 @@
# Herencia SIMCO - ERP Básico
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Fecha:** 2025-12-08
---
## Configuración del Proyecto
| Propiedad | Valor |
|-----------|-------|
| **Proyecto** | ERP Básico - Producto Simplificado |
| **Nivel** | PRODUCT (Nivel 2) |
| **Padre** | erp-suite |
| **SIMCO Version** | 2.2.0 |
| **CAPVED** | Habilitado |
| **CCA Protocol** | Habilitado |
| **Estado** | Por iniciar |
## Jerarquía de Herencia
```
Nivel 0: core/orchestration/ ← FUENTE PRINCIPAL
└── Nivel 1: erp-suite/orchestration/ ← PADRE
└── Nivel 2: erp-basico/orchestration/ ← ESTE PROYECTO
```
**Nota:** ERP Básico es un PRODUCTO standalone dentro de la suite, NO hereda de erp-core.
Es una versión simplificada para pequeños negocios.
---
## Directivas Heredadas de CORE (OBLIGATORIAS)
### Ciclo de Vida
| Alias | Propósito |
|-------|-----------|
| `@TAREA` | Punto de entrada para toda HU |
| `@CAPVED` | Ciclo de 6 fases |
| `@INICIALIZACION` | Bootstrap de agentes |
### Operaciones Universales
| Alias | Propósito |
|-------|-----------|
| `@CREAR` | Crear archivos nuevos |
| `@MODIFICAR` | Modificar existentes |
| `@VALIDAR` | Validar código |
| `@DOCUMENTAR` | Documentar trabajo |
| `@BUSCAR` | Buscar información |
| `@DELEGAR` | Delegar a subagentes |
### Principios Fundamentales
| Alias | Resumen |
|-------|---------|
| `@CAPVED` | Toda tarea pasa por 6 fases |
| `@DOC_PRIMERO` | Consultar docs/ antes de implementar |
| `@ANTI_DUP` | Verificar que no existe |
| `@VALIDACION` | Build y lint DEBEN pasar |
| `@TOKENS` | Desglosar tareas grandes |
---
## Directivas por Dominio Técnico
| Alias | Aplica | Notas |
|-------|--------|-------|
| `@OP_DDL` | **SÍ** | Schema simplificado |
| `@OP_BACKEND` | **SÍ** | API mínima |
| `@OP_FRONTEND` | **SÍ** | UI simple |
| `@OP_MOBILE` | **SÍ** | App básica |
| `@OP_ML` | NO | - |
---
## Patrones Heredados (OBLIGATORIOS)
Todos los patrones de `core/orchestration/patrones/` aplican.
---
## Variables de Contexto CCA
```yaml
PROJECT_NAME: "erp-basico"
PROJECT_LEVEL: "PRODUCT"
PROJECT_ROOT: "/home/isem/workspace/projects/erp-suite/apps/products/erp-basico"
PARENT_PROJECT: "erp-suite"
DB_DDL_PATH: "database/ddl"
BACKEND_ROOT: "backend/src"
FRONTEND_ROOT: "frontend/src"
# Este producto NO usa multi-tenant complejo
TENANT_COLUMN: "empresa_id"
SIMPLIFIED: true
```
---
## Diferencias con ERP Core
| Aspecto | ERP Core | ERP Básico |
|---------|----------|------------|
| Complejidad | Alta | Baja |
| Verticales | Múltiples | Ninguna |
| Multi-tenant | RLS completo | Simplificado |
| Módulos | 20+ | 5-7 |
| Target | Empresas medianas | Pequeños negocios |
---
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Nivel:** PRODUCT (2)
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,130 @@
# Herencia SIMCO - POS Micro
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Fecha:** 2025-12-08
---
## Configuración del Proyecto
| Propiedad | Valor |
|-----------|-------|
| **Proyecto** | POS Micro - Punto de Venta Simplificado |
| **Nivel** | PRODUCT (Nivel 2) |
| **Padre** | erp-suite |
| **SIMCO Version** | 2.2.0 |
| **CAPVED** | Habilitado |
| **CCA Protocol** | Habilitado |
| **Estado** | Por iniciar |
## Jerarquía de Herencia
```
Nivel 0: core/orchestration/ ← FUENTE PRINCIPAL
└── Nivel 1: erp-suite/orchestration/ ← PADRE
└── Nivel 2: pos-micro/orchestration/ ← ESTE PROYECTO
```
**Nota:** POS Micro es un PRODUCTO standalone dentro de la suite.
Es un punto de venta minimalista para micro-negocios.
---
## Directivas Heredadas de CORE (OBLIGATORIAS)
### Ciclo de Vida
| Alias | Propósito |
|-------|-----------|
| `@TAREA` | Punto de entrada para toda HU |
| `@CAPVED` | Ciclo de 6 fases |
| `@INICIALIZACION` | Bootstrap de agentes |
### Operaciones Universales
| Alias | Propósito |
|-------|-----------|
| `@CREAR` | Crear archivos nuevos |
| `@MODIFICAR` | Modificar existentes |
| `@VALIDAR` | Validar código |
| `@DOCUMENTAR` | Documentar trabajo |
| `@BUSCAR` | Buscar información |
| `@DELEGAR` | Delegar a subagentes |
### Principios Fundamentales
| Alias | Resumen |
|-------|---------|
| `@CAPVED` | Toda tarea pasa por 6 fases |
| `@DOC_PRIMERO` | Consultar docs/ antes de implementar |
| `@ANTI_DUP` | Verificar que no existe |
| `@VALIDACION` | Build y lint DEBEN pasar |
| `@TOKENS` | Desglosar tareas grandes |
---
## Directivas por Dominio Técnico
| Alias | Aplica | Notas |
|-------|--------|-------|
| `@OP_DDL` | **SÍ** | Schema mínimo |
| `@OP_BACKEND` | **SÍ** | API de ventas |
| `@OP_FRONTEND` | **SÍ** | UI táctil POS |
| `@OP_MOBILE` | **SÍ** | App de caja |
| `@OP_ML` | NO | - |
---
## Patrones Heredados (OBLIGATORIOS)
Todos los patrones de `core/orchestration/patrones/` aplican.
**Especialmente importantes:**
- `@PATRON-TRANSACCIONES` - Ventas atómicas
- `@PATRON-PERFORMANCE` - Respuesta rápida
- `@PATRON-SEGURIDAD` - Manejo de dinero
---
## Variables de Contexto CCA
```yaml
PROJECT_NAME: "pos-micro"
PROJECT_LEVEL: "PRODUCT"
PROJECT_ROOT: "/home/isem/workspace/projects/erp-suite/apps/products/pos-micro"
PARENT_PROJECT: "erp-suite"
DB_DDL_PATH: "database/ddl"
BACKEND_ROOT: "backend/src"
FRONTEND_ROOT: "frontend/src"
# POS simplificado
TENANT_COLUMN: "negocio_id"
SIMPLIFIED: true
OFFLINE_CAPABLE: true
```
---
## Módulos de POS Micro
| Módulo | Descripción | Estado |
|--------|-------------|--------|
| POS-VEN | Ventas rápidas | Por definir |
| POS-INV | Inventario simple | Por definir |
| POS-CAJ | Corte de caja | Por definir |
| POS-REP | Reportes básicos | Por definir |
---
## Características Especiales
- **Offline-first**: Funciona sin conexión
- **Touch-friendly**: Optimizado para tablets
- **Rápido**: < 2s por transacción
- **Simple**: Curva de aprendizaje mínima
---
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Nivel:** PRODUCT (2)
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,182 @@
# ===========================================
# CLINICAS - Variables de Entorno
# ===========================================
# Copiar este archivo a .env y configurar valores
# Puertos según DEVENV-PORTS.md
# NOTA: Este sistema requiere cumplimiento NOM-024 y LFPDPPP
# -------------------------------------------
# BASE DE DATOS POSTGRESQL
# -------------------------------------------
DB_HOST=localhost
DB_PORT=5437
DB_NAME=clinicas_db
DB_USER=clinicas_user
DB_PASSWORD=clinicas_secret_2025
# URL de conexion completa
DATABASE_URL=postgresql://${DB_USER}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_NAME}
# -------------------------------------------
# SCHEMAS DE BASE DE DATOS
# -------------------------------------------
# Schemas heredados de erp-core
DB_SCHEMA_AUTH=auth
DB_SCHEMA_CORE=core
DB_SCHEMA_INVENTORY=inventory
# Schemas propios de clínicas
DB_SCHEMA_CLINICAL=clinical
DB_SCHEMA_PHARMACY=pharmacy
DB_SCHEMA_LABORATORY=laboratory
DB_SCHEMA_IMAGING=imaging
DB_SCHEMA_TELEMEDICINE=telemedicine
# -------------------------------------------
# APLICACION
# -------------------------------------------
APP_NAME=clinicas
APP_ENV=development
APP_PORT=3500
APP_URL=http://localhost:3500
# -------------------------------------------
# FRONTEND
# -------------------------------------------
FRONTEND_PORT=5178
FRONTEND_URL=http://localhost:5178
# -------------------------------------------
# AUTENTICACION JWT
# -------------------------------------------
JWT_SECRET=your_jwt_secret_here_change_in_production
JWT_EXPIRES_IN=8h
JWT_REFRESH_EXPIRES_IN=24h
# -------------------------------------------
# TWO-FACTOR AUTHENTICATION (OBLIGATORIO)
# -------------------------------------------
# Requerido para personal médico según LFPDPPP
TWO_FACTOR_ENABLED=true
TWO_FACTOR_METHOD=totp
TOTP_ISSUER=ERP-Clinicas
TOTP_WINDOW=1
# SMS 2FA (Twilio)
TWILIO_ACCOUNT_SID=
TWILIO_AUTH_TOKEN=
TWILIO_PHONE_FROM=
# -------------------------------------------
# ENCRIPTACION DE DATOS SENSIBLES (LFPDPPP)
# -------------------------------------------
# CRITICO: Cambiar en producción
ENCRYPTION_KEY=your_32_byte_encryption_key_here
ENCRYPTION_ALGORITHM=aes-256-gcm
ENCRYPTION_IV_LENGTH=16
# Campos encriptados automáticamente:
# - antecedentes_medicos
# - alergias
# - diagnosticos
# - notas_clinicas
# -------------------------------------------
# MULTI-TENANT
# -------------------------------------------
TENANT_ID_HEADER=X-Tenant-ID
TENANT_ID_PARAM=tenant_id
# -------------------------------------------
# ALMACENAMIENTO DE ARCHIVOS
# -------------------------------------------
STORAGE_TYPE=local
STORAGE_PATH=./uploads
# Para producción usar S3 con encriptación:
# STORAGE_TYPE=s3
# AWS_ACCESS_KEY_ID=
# AWS_SECRET_ACCESS_KEY=
# AWS_REGION=us-east-1
# AWS_S3_BUCKET=clinicas-files
# AWS_S3_ENCRYPTION=AES256
# -------------------------------------------
# NOTIFICACIONES
# -------------------------------------------
# Email (SMTP)
SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
SMTP_USER=
SMTP_PASSWORD=
SMTP_FROM=noreply@clinicas-erp.com
# SMS para recordatorios de citas
SMS_PROVIDER=twilio
SMS_REMINDER_HOURS_BEFORE=24
# -------------------------------------------
# FACTURACION ELECTRONICA (SAT)
# -------------------------------------------
SAT_ENVIRONMENT=sandbox
SAT_RFC=
SAT_CER_PATH=./certs/csd.cer
SAT_KEY_PATH=./certs/csd.key
SAT_KEY_PASSWORD=
# -------------------------------------------
# LOGGING Y AUDITORIA
# -------------------------------------------
LOG_LEVEL=debug
LOG_FORMAT=json
# Auditoría de accesos (NOM-024)
AUDIT_ENABLED=true
AUDIT_RETENTION_YEARS=10
AUDIT_LOG_MEDICAL_RECORD_ACCESS=true
AUDIT_LOG_PRESCRIPTION_CREATED=true
AUDIT_LOG_PATIENT_DATA_MODIFIED=true
# -------------------------------------------
# REDIS (Cache y Colas)
# -------------------------------------------
REDIS_HOST=localhost
REDIS_PORT=6384
REDIS_PASSWORD=
# -------------------------------------------
# CORS
# -------------------------------------------
CORS_ORIGIN=http://localhost:5178,http://localhost:3500
# -------------------------------------------
# EXPEDIENTE CLINICO (NOM-024-SSA3-2012)
# -------------------------------------------
# Estructura SOAP obligatoria
NOM024_SOAP_REQUIRED=true
NOM024_CIE10_VALIDATION=true
NOM024_PRESCRIPTION_SIGNATURE_REQUIRED=true
NOM024_CONSENT_REQUIRED=true
# -------------------------------------------
# TELEMEDICINA (Opcional)
# -------------------------------------------
TELEMEDICINE_ENABLED=false
TELEMEDICINE_PROVIDER=jitsi
TELEMEDICINE_SERVER_URL=
TELEMEDICINE_RECORDING_ENABLED=false
# -------------------------------------------
# IMAGENOLOGIA DICOM (Opcional)
# -------------------------------------------
DICOM_ENABLED=false
DICOM_SERVER_HOST=
DICOM_SERVER_PORT=4242
DICOM_AE_TITLE=CLINICAS_ERP
# -------------------------------------------
# INTEROPERABILIDAD (HL7/FHIR)
# -------------------------------------------
HL7_ENABLED=false
HL7_ENDPOINT=
FHIR_ENABLED=false
FHIR_SERVER_URL=

View File

@ -0,0 +1,178 @@
# ESTADO DEL PROYECTO - ERP Clínicas
**Proyecto:** ERP Clínicas (Proyecto Independiente)
**Estado:** 📋 En planificación
**Progreso:** 25%
**Última actualización:** 2025-12-08
---
## 📊 RESUMEN EJECUTIVO
| Área | Estado | Descripción |
|------|--------|-------------|
| **Documentación** | 🟡 Inicial | 12 módulos definidos, estructura base |
| **DDL/Schemas** | ❌ No iniciado | Pendiente diseño de BD |
| **Backend** | ❌ No iniciado | Pendiente desarrollo |
| **Frontend** | ❌ No iniciado | Pendiente desarrollo |
---
## 📋 MÓDULOS DEFINIDOS (12)
| Código | Nombre | Descripción | Reutilización | Estado |
|--------|--------|-------------|---------------|--------|
| CL-001 | Fundamentos | Auth, Users, Tenants | 100% core | PLANIFICADO |
| CL-002 | Pacientes | Registro y expediente | 20% core | PLANIFICADO |
| CL-003 | Citas | Agenda médica | 30% core | PLANIFICADO |
| CL-004 | Consultas | Notas médicas | 0% (nuevo) | PLANIFICADO |
| CL-005 | Recetas | Prescripciones | 10% core | PLANIFICADO |
| CL-006 | Laboratorio | Estudios y resultados | 10% core | PLANIFICADO |
| CL-007 | Farmacia | Inventario medicamentos | 60% core | PLANIFICADO |
| CL-008 | Facturación | Cobros y seguros | 50% core | PLANIFICADO |
| CL-009 | Reportes | Estadísticas clínicas | 60% core | PLANIFICADO |
| CL-010 | Telemedicina | Consultas remotas | 0% (nuevo) | PLANIFICADO |
| CL-011 | Expediente | Historia clínica completa | 10% core | PLANIFICADO |
| CL-012 | Imagenología | Estudios DICOM | 5% core | PLANIFICADO |
**Story Points Estimados:** 451 SP (detallado en épicas)
---
## 🏥 DOMINIO DE NEGOCIO
### Modelo de Negocio
- Clínicas y consultorios médicos
- Consultas presenciales y telemedicina
- Expediente clínico electrónico
- Integración con laboratorios e imagen
### Proceso Principal
```
Cita → Check-in → Consulta → Diagnóstico → Receta → Facturación
Estudios (Lab/Imagen)
Expediente Clínico
```
### Cumplimiento Normativo
- NOM-024-SSA3-2012 (Expediente clínico)
- NOM-004-SSA3-2012 (Sistemas de información)
- NOM-151-SCFI-2016 (Firma electrónica)
- CIE-10 (Codificación de diagnósticos)
---
## 📁 ESTRUCTURA DE DOCUMENTACIÓN
```
docs/
├── 00-vision-general/
│ └── VISION-CLINICAS.md ✅
├── 02-definicion-modulos/
│ ├── INDICE-MODULOS.md ✅
│ ├── CL-001-fundamentos/README.md ✅
│ ├── CL-002-pacientes/README.md ✅
│ ├── CL-003-citas/README.md ✅
│ ├── CL-004-consultas/README.md ✅
│ ├── CL-005-recetas/README.md ✅
│ ├── CL-006-laboratorio/README.md ✅
│ ├── CL-007-farmacia/README.md ✅
│ ├── CL-008-facturacion/README.md ✅
│ ├── CL-009-reportes/README.md ✅
│ ├── CL-010-telemedicina/README.md ✅
│ ├── CL-011-expediente/README.md ✅
│ └── CL-012-imagenologia/README.md ✅
└── 08-epicas/
└── EPIC-CL-001-fundamentos.md ✅
```
---
## 🎯 PRÓXIMOS PASOS
### Fase 1: Documentación Detallada
1. [ ] Crear épicas completas (EPIC-CL-002 a 012)
2. [ ] Documentar User Stories por módulo
3. [ ] Definir requerimientos funcionales (RF)
4. [ ] Crear especificaciones técnicas (ET)
5. [ ] Documentar cumplimiento normativo
### Fase 2: Diseño de Base de Datos
6. [ ] Diseñar schemas de BD
7. [ ] Implementar DDL
8. [ ] Documentar modelo de datos
### Fase 3: Desarrollo
9. [ ] Implementar backend (TypeScript/Express)
10. [ ] Implementar frontend (React)
11. [ ] Integración telemedicina (WebRTC)
12. [ ] Integración DICOM
13. [ ] Testing
---
## 📈 MÉTRICAS
| Métrica | Valor |
|---------|-------|
| Módulos definidos | 12 |
| Épicas creadas | 12/12 ✅ |
| User Stories | 0 (pendiente) |
| Story Points | 451 |
| Archivos MD | 31 |
| Archivos SQL | 0 |
| Archivos TS | 0 |
---
## 🏗️ ARQUITECTURA
**Tipo:** Proyecto Independiente (fork conceptual del ERP-Core)
**Patrones a reutilizar del ERP-Core:**
- Multi-tenancy con RLS (para cadenas de clínicas)
- Estructura de autenticación con 2FA obligatorio
- Patrones de inventario (farmacia)
- Sistema de reportes
**Módulos 100% nuevos:**
- CL-004: Consultas (notas médicas estructuradas)
- CL-010: Telemedicina (videoconsultas WebRTC)
- CL-012: Imagenología (visor DICOM)
**Integraciones externas:**
- Proveedores de videollamadas (Twilio, Zoom API)
- Servidores PACS para imagen médica
- Servicios de timbrado CFDI
**Opera de forma autónoma:** No requiere ERP-Core instalado
---
## ⚠️ CONSIDERACIONES ESPECIALES
### Seguridad de Datos Médicos
- Encriptación de datos sensibles (expedientes)
- Auditoría completa de accesos
- Consentimiento informado digital
- Respaldo automático de expedientes
### Cumplimiento Normativo
- Implementar estructura de NOM-024-SSA3-2012
- Firma electrónica para recetas (NOM-151)
- Codificación CIE-10 para diagnósticos
---
## 🔗 REFERENCIAS
- Índice de módulos: `docs/02-definicion-modulos/INDICE-MODULOS.md`
- Visión: `docs/00-vision-general/VISION-CLINICAS.md`
- SPECS heredadas: `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
- Directivas: `orchestration/directivas/`
---
**Última actualización:** 2025-12-08

View File

@ -117,19 +117,28 @@ appointments.reminders -- Recordatorios
**Documento detallado:** `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
### Correcciones de DDL Core (2025-12-08)
El DDL del ERP-Core fue corregido para resolver FK inválidas:
1. **stock_valuation_layers**: Campos `journal_entry_id` y `journal_entry_line_id` (antes `account_move_*`)
2. **stock_move_consume_rel**: Nueva tabla de trazabilidad (antes `move_line_consume_rel`)
3. **category_stock_accounts**: FK corregida a `core.product_categories`
4. **product_categories**: ALTERs ahora apuntan a schema `core`
### SPECS Obligatorias
| Spec Core | Aplicación en Clínicas | SP | Estado |
|-----------|----------------------|----:|--------|
| SPEC-SISTEMA-SECUENCIAS | Foliado de expedientes y citas | 8 | PENDIENTE |
| SPEC-SEGURIDAD-API-KEYS-PERMISOS | Control de acceso a expedientes | 31 | PENDIENTE |
| SPEC-SISTEMA-SECUENCIAS | Foliado de expedientes y citas | 8 | ✅ DDL LISTO |
| SPEC-SEGURIDAD-API-KEYS-PERMISOS | Control de acceso a expedientes | 31 | ✅ DDL LISTO |
| SPEC-INTEGRACION-CALENDAR | Agenda de citas médicas | 8 | PENDIENTE |
| SPEC-RRHH-EVALUACIONES-SKILLS | Credenciales médicas | 26 | PENDIENTE |
| SPEC-MAIL-THREAD-TRACKING | Historial de comunicación | 13 | PENDIENTE |
| SPEC-RRHH-EVALUACIONES-SKILLS | Credenciales médicas | 26 | ✅ DDL LISTO |
| SPEC-MAIL-THREAD-TRACKING | Historial de comunicación | 13 | ✅ DDL LISTO |
| SPEC-WIZARD-TRANSIENT-MODEL | Wizards de receta y referencia | 8 | PENDIENTE |
| SPEC-FIRMA-ELECTRONICA-NOM151 | Firma de expedientes clínicos | 13 | PENDIENTE |
| SPEC-TWO-FACTOR-AUTHENTICATION | Seguridad de acceso | 13 | PENDIENTE |
| SPEC-OAUTH2-SOCIAL-LOGIN | Portal de pacientes | 8 | PENDIENTE |
| SPEC-TWO-FACTOR-AUTHENTICATION | Seguridad de acceso | 13 | ✅ DDL LISTO |
| SPEC-OAUTH2-SOCIAL-LOGIN | Portal de pacientes | 8 | ✅ DDL LISTO |
### SPECS Opcionales

View File

@ -0,0 +1,107 @@
# Visión General - ERP Clínicas
**Versión:** 1.0
**Fecha:** 2025-12-08
**Nivel:** 2B.2 (Vertical)
---
## Propósito del Sistema
Sistema ERP especializado para clínicas y consultorios médicos. Gestiona el expediente clínico electrónico, agenda de citas, recetas médicas, y facturación de servicios de salud. Cumple con normativas mexicanas de salud (NOM-024-SSA3, LFPDPPP).
---
## Dominio del Negocio
### Procesos Principales
1. **Gestión de Pacientes**
- Registro y expediente clínico
- Historial médico
- Antecedentes y alergias
2. **Agenda de Citas**
- Programación de consultas
- Recordatorios automáticos
- Gestión de especialistas
3. **Consultas Médicas**
- Notas médicas
- Signos vitales
- Diagnósticos (CIE-10)
4. **Recetas y Prescripciones**
- Recetas electrónicas
- Indicaciones médicas
- Firma electrónica
5. **Facturación de Servicios**
- Cobro de consultas
- Seguros médicos
- CFDI de salud
---
## Cumplimiento Normativo
| Norma | Descripción | Impacto |
|-------|-------------|---------|
| NOM-024-SSA3-2012 | Expediente clínico electrónico | Estructura de datos |
| LFPDPPP | Protección de datos personales | Seguridad y acceso |
| NOM-004-SSA3-2012 | Expediente clínico | Contenido mínimo |
---
## Arquitectura de Módulos
```
CL-001 Fundamentos → Auth, Users, Tenants (hereda 100% core)
CL-002 Pacientes → Expediente clínico (20% core)
CL-003 Citas → Agenda médica (30% core)
CL-004 Consultas → Notas médicas (0% - nuevo)
CL-005 Recetas → Prescripciones (10% core)
CL-006 Laboratorio → Estudios (10% core)
CL-007 Farmacia → Medicamentos (60% core)
CL-008 Facturación → Cobros, seguros (50% core)
CL-009 Reportes → Estadísticas (60% core)
CL-010 Telemedicina → Consultas remotas (0% - nuevo)
CL-011 Expediente → Historia clínica (10% core)
CL-012 Imagenología → DICOM (5% core)
```
---
## Stack Tecnológico
- **Backend:** NestJS + TypeORM + PostgreSQL
- **Frontend:** React + TypeScript
- **Base de Datos:** PostgreSQL 15+ (hereda ERP Core)
- **Seguridad:** 2FA, encriptación de datos sensibles
---
## Métricas Objetivo
| Métrica | Valor Objetivo |
|---------|----------------|
| Módulos | 12 |
| Tablas Específicas | ~35 |
| Tablas Heredadas | ~100 |
| Story Points Est. | ~350 |
| Ocupación Agenda | > 80% |
| No-shows | < 5% |
---
## Referencias
- ERP Core: `apps/erp-core/`
- Herencia DB: `database/HERENCIA-ERP-CORE.md`
- SPECS del Core: `HERENCIA-SPECS-CORE.md`
- Normativas: NOM-024-SSA3-2012
---
**Documento de visión oficial**
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,20 @@
# CL-001: Fundamentos
**Módulo:** Fundamentos
**Estado:** PLANIFICADO
## Descripción
Auth con 2FA para personal médico
## Funcionalidades Principales
- Por definir en fase de análisis
## Cumplimiento Normativo
- NOM-024-SSA3-2012 (si aplica)
- LFPDPPP
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,20 @@
# CL-002: Pacientes
**Módulo:** Pacientes
**Estado:** PLANIFICADO
## Descripción
Registro y expediente de pacientes
## Funcionalidades Principales
- Por definir en fase de análisis
## Cumplimiento Normativo
- NOM-024-SSA3-2012 (si aplica)
- LFPDPPP
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,20 @@
# CL-003: Citas
**Módulo:** Citas
**Estado:** PLANIFICADO
## Descripción
Agenda médica con recordatorios
## Funcionalidades Principales
- Por definir en fase de análisis
## Cumplimiento Normativo
- NOM-024-SSA3-2012 (si aplica)
- LFPDPPP
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,20 @@
# CL-004: Consultas
**Módulo:** Consultas
**Estado:** PLANIFICADO
## Descripción
Notas médicas y diagnósticos CIE-10
## Funcionalidades Principales
- Por definir en fase de análisis
## Cumplimiento Normativo
- NOM-024-SSA3-2012 (si aplica)
- LFPDPPP
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,20 @@
# CL-005: Recetas
**Módulo:** Recetas
**Estado:** PLANIFICADO
## Descripción
Prescripciones con firma electrónica
## Funcionalidades Principales
- Por definir en fase de análisis
## Cumplimiento Normativo
- NOM-024-SSA3-2012 (si aplica)
- LFPDPPP
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,20 @@
# CL-006: Laboratorio
**Módulo:** Laboratorio
**Estado:** PLANIFICADO
## Descripción
Solicitud y resultados de estudios
## Funcionalidades Principales
- Por definir en fase de análisis
## Cumplimiento Normativo
- NOM-024-SSA3-2012 (si aplica)
- LFPDPPP
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,20 @@
# CL-007: Farmacia
**Módulo:** Farmacia
**Estado:** PLANIFICADO
## Descripción
Inventario de medicamentos
## Funcionalidades Principales
- Por definir en fase de análisis
## Cumplimiento Normativo
- NOM-024-SSA3-2012 (si aplica)
- LFPDPPP
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,20 @@
# CL-008: Facturacion
**Módulo:** Facturacion
**Estado:** PLANIFICADO
## Descripción
Cobros y CFDI de salud
## Funcionalidades Principales
- Por definir en fase de análisis
## Cumplimiento Normativo
- NOM-024-SSA3-2012 (si aplica)
- LFPDPPP
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,20 @@
# CL-009: Reportes
**Módulo:** Reportes
**Estado:** PLANIFICADO
## Descripción
Dashboard y estadísticas clínicas
## Funcionalidades Principales
- Por definir en fase de análisis
## Cumplimiento Normativo
- NOM-024-SSA3-2012 (si aplica)
- LFPDPPP
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,20 @@
# CL-010: Telemedicina
**Módulo:** Telemedicina
**Estado:** PLANIFICADO
## Descripción
Videoconsultas remotas
## Funcionalidades Principales
- Por definir en fase de análisis
## Cumplimiento Normativo
- NOM-024-SSA3-2012 (si aplica)
- LFPDPPP
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,20 @@
# CL-011: Expediente
**Módulo:** Expediente
**Estado:** PLANIFICADO
## Descripción
Historia clínica completa NOM-024
## Funcionalidades Principales
- Por definir en fase de análisis
## Cumplimiento Normativo
- NOM-024-SSA3-2012 (si aplica)
- LFPDPPP
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,20 @@
# CL-012: Imagenologia
**Módulo:** Imagenologia
**Estado:** PLANIFICADO
## Descripción
Visor DICOM y estudios de imagen
## Funcionalidades Principales
- Por definir en fase de análisis
## Cumplimiento Normativo
- NOM-024-SSA3-2012 (si aplica)
- LFPDPPP
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,136 @@
# Índice de Módulos - ERP Clínicas
**Versión:** 1.0
**Fecha:** 2025-12-08
**Total Módulos:** 12
---
## Resumen
| Código | Nombre | Descripción | Reutilización Core | Estado |
|--------|--------|-------------|-------------------|--------|
| CL-001 | Fundamentos | Auth, Users, Tenants | 100% | PLANIFICADO |
| CL-002 | Pacientes | Registro y expediente | 20% | PLANIFICADO |
| CL-003 | Citas | Agenda médica | 30% | PLANIFICADO |
| CL-004 | Consultas | Notas médicas | 0% | PLANIFICADO |
| CL-005 | Recetas | Prescripciones | 10% | PLANIFICADO |
| CL-006 | Laboratorio | Estudios y resultados | 10% | PLANIFICADO |
| CL-007 | Farmacia | Inventario medicamentos | 60% | PLANIFICADO |
| CL-008 | Facturación | Cobros y seguros | 50% | PLANIFICADO |
| CL-009 | Reportes | Estadísticas clínicas | 60% | PLANIFICADO |
| CL-010 | Telemedicina | Consultas remotas | 0% | PLANIFICADO |
| CL-011 | Expediente | Historia clínica completa | 10% | PLANIFICADO |
| CL-012 | Imagenología | Estudios DICOM | 5% | PLANIFICADO |
---
## Detalle por Módulo
### CL-001: Fundamentos
**Herencia:** 100% del core
- Usuarios: Médicos, Enfermeras, Recepcionistas, Admin
- Roles con permisos de acceso a expedientes
- 2FA obligatorio para personal médico
### CL-002: Pacientes
**Herencia:** 20%
- Registro de pacientes
- Datos de contacto y emergencia
- Seguro médico
- Antecedentes y alergias
### CL-003: Citas
**Herencia:** 30%
- Programación de citas
- Agenda por especialista
- Recordatorios (SMS, Email, WhatsApp)
- Confirmaciones
### CL-004: Consultas
**Herencia:** 0% - Nuevo
- Notas médicas
- Signos vitales
- Exploración física
- Diagnósticos (CIE-10)
### CL-005: Recetas
**Herencia:** 10%
- Recetas electrónicas
- Indicaciones médicas
- Firma electrónica (NOM-151)
- Historial de prescripciones
### CL-006: Laboratorio
**Herencia:** 10%
- Solicitud de estudios
- Resultados de laboratorio
- Valores de referencia
- Alertas de resultados críticos
### CL-007: Farmacia
**Herencia:** 60%
- Inventario de medicamentos
- Control de caducidades
- Despacho de recetas
- Alertas de interacciones
### CL-008: Facturación
**Herencia:** 50%
- Cobro de consultas
- Integración con seguros
- CFDI de salud
- Cuentas por cobrar
### CL-009: Reportes
**Herencia:** 60%
- Dashboard clínico
- Estadísticas de consultas
- Indicadores de salud
- Reportes epidemiológicos
### CL-010: Telemedicina
**Herencia:** 0% - Nuevo
- Videoconsultas
- Chat con pacientes
- Compartir pantalla
- Grabación (opcional)
### CL-011: Expediente
**Herencia:** 10%
- Historia clínica completa
- Línea de tiempo médica
- Resumen de antecedentes
- Exportación (NOM-024)
### CL-012: Imagenología
**Herencia:** 5%
- Visor DICOM
- Almacenamiento de estudios
- Reportes radiológicos
- Integración PACS
---
## Story Points Estimados
| Módulo | SP Backend | SP Frontend | SP Total |
|--------|-----------|-------------|----------|
| CL-001 | 0 | 0 | 0 |
| CL-002 | 21 | 13 | 34 |
| CL-003 | 21 | 21 | 42 |
| CL-004 | 21 | 21 | 42 |
| CL-005 | 13 | 13 | 26 |
| CL-006 | 21 | 13 | 34 |
| CL-007 | 13 | 8 | 21 |
| CL-008 | 21 | 13 | 34 |
| CL-009 | 13 | 13 | 26 |
| CL-010 | 34 | 34 | 68 |
| CL-011 | 21 | 13 | 34 |
| CL-012 | 21 | 13 | 34 |
| **Total** | **220** | **175** | **395** |
---
**Índice de módulos oficial**
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,66 @@
# Épica: Fundamentos del Sistema Clínico
**Código:** EPIC-CL-001
**Módulos:** CL-001, CL-002, CL-003
**Estado:** PLANIFICADO
---
## Descripción
Implementación de los módulos fundacionales del ERP Clínicas, incluyendo la configuración inicial con seguridad reforzada, registro de pacientes y agenda de citas.
---
## Objetivos
1. Configurar el ambiente con seguridad médica (2FA, encriptación)
2. Implementar el registro de pacientes con expediente básico
3. Establecer la agenda de citas con recordatorios
---
## Módulos Incluidos
| Módulo | Descripción | SP Estimados |
|--------|-------------|--------------|
| CL-001 | Fundamentos (2FA obligatorio) | 0 |
| CL-002 | Pacientes | 34 |
| CL-003 | Citas | 42 |
---
## User Stories Principales
1. Como médico, quiero iniciar sesión con 2FA
2. Como recepcionista, quiero registrar un nuevo paciente
3. Como recepcionista, quiero programar una cita
4. Como paciente, quiero recibir recordatorio de mi cita
---
## Criterios de Aceptación
- [ ] 2FA obligatorio para personal médico
- [ ] Encriptación de datos sensibles (antecedentes, alergias)
- [ ] Registro de pacientes con datos de seguro
- [ ] Agenda funcional con confirmaciones
- [ ] Recordatorios automáticos (24h y 2h antes)
---
## Cumplimiento Normativo
- NOM-024-SSA3-2012: Estructura de expediente
- LFPDPPP: Protección de datos personales
---
## Story Points Totales
**76 SP**
---
**Épica fundacional**
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,247 @@
# EPICA: EPIC-CL-002 - Pacientes
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-CL-002 |
| **Nombre** | Pacientes |
| **Modulo** | pacientes |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P0 (Critico) |
| **Estado** | Backlog |
| **Story Points** | 38 |
| **Sprint(s)** | Sprint 2-3 |
---
## Descripcion
Registro y gestión integral de pacientes. Incluye datos demográficos, datos de contacto, información de seguros médicos, contactos de emergencia, consentimientos informados y portal de acceso para pacientes.
---
## Objetivo de Negocio
- Expediente único del paciente
- Cumplimiento de NOM-024-SSA3-2012
- Agilizar proceso de registro
- Datos actualizados y accesibles
- Comunicación efectiva con pacientes
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-CL002-001 | Como recepcionista, quiero registrar paciente nuevo con datos mínimos para agilizar primera cita | P0 | 5 | Backlog |
| US-CL002-002 | Como recepcionista, quiero buscar paciente por nombre, teléfono o CURP para consultar expediente | P0 | 3 | Backlog |
| US-CL002-003 | Como recepcionista, quiero registrar datos de seguro médico del paciente para facturación | P0 | 3 | Backlog |
| US-CL002-004 | Como recepcionista, quiero registrar contactos de emergencia del paciente | P0 | 2 | Backlog |
| US-CL002-005 | Como paciente, quiero firmar consentimiento informado digitalmente para autorizar tratamientos | P0 | 5 | Backlog |
| US-CL002-006 | Como médico, quiero ver ficha completa del paciente antes de la consulta | P0 | 3 | Backlog |
| US-CL002-007 | Como paciente, quiero acceder a mi portal para ver citas e historial | P1 | 8 | Backlog |
| US-CL002-008 | Como admin, quiero configurar campos obligatorios según tipo de paciente | P1 | 3 | Backlog |
| US-CL002-009 | Como recepcionista, quiero registrar datos del menor y de su tutor | P0 | 3 | Backlog |
| US-CL002-010 | Como admin, quiero fusionar expedientes duplicados preservando historial | P2 | 3 | Backlog |
**Total Story Points:** 38 SP
---
## Datos del Paciente
```
┌─────────────────────────────────────────────────────────┐
│ EXPEDIENTE DEL PACIENTE │
├─────────────────────────────────────────────────────────┤
│ │
│ DATOS PERSONALES │
│ ├── Nombre completo │
│ ├── Fecha de nacimiento / Edad │
│ ├── Sexo │
│ ├── CURP │
│ ├── Estado civil │
│ ├── Ocupación │
│ └── Escolaridad │
│ │
│ CONTACTO │
│ ├── Teléfono principal │
│ ├── Teléfono alternativo │
│ ├── Email │
│ ├── Dirección completa │
│ └── Preferencia de contacto │
│ │
│ EMERGENCIA │
│ ├── Nombre del contacto │
│ ├── Parentesco │
│ └── Teléfono │
│ │
│ SEGURO MÉDICO │
│ ├── Aseguradora │
│ ├── Número de póliza │
│ ├── Vigencia │
│ └── Tipo de cobertura │
│ │
│ MENORES DE EDAD │
│ ├── Datos del tutor/responsable │
│ ├── Parentesco │
│ └── Identificación del tutor │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Consentimiento Informado Digital
```
┌─────────────────────────────────────────────────────────┐
│ CONSENTIMIENTO INFORMADO │
├─────────────────────────────────────────────────────────┤
│ │
│ TIPOS DE CONSENTIMIENTO │
│ ├── General (tratamientos y procedimientos) │
│ ├── Específico por procedimiento │
│ ├── Menores (firma del tutor) │
│ └── Tratamiento de datos personales (LFPDPPP) │
│ │
│ ELEMENTOS │
│ ├── Texto del consentimiento │
│ ├── Firma digital del paciente │
│ ├── Fecha y hora de firma │
│ ├── IP y dispositivo │
│ └── PDF generado y almacenado │
│ │
│ VALIDEZ │
│ ├── Vigencia configurable │
│ ├── Renovación automática │
│ └── Revocación por el paciente │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Registro de paciente con validación de datos
- [ ] Búsqueda por múltiples criterios
- [ ] Registro de datos de seguro
- [ ] Contactos de emergencia
- [ ] Consentimiento informado digital
- [ ] Ficha completa del paciente
- [ ] Portal del paciente
- [ ] Manejo de menores con tutor
**No Funcionales:**
- [ ] Búsqueda < 1 segundo
- [ ] Encriptación de datos sensibles
- [ ] Cumplimiento NOM-024-SSA3-2012
- [ ] Auditoría de accesos
**Tecnicos:**
- [ ] Validación de CURP
- [ ] Firma digital integrada
- [ ] Encriptación AES-256 para datos sensibles
- [ ] Portal web para pacientes
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-CL-001 Fundamentos | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-CL-003 Citas | Requiere pacientes registrados |
| EPIC-CL-004 Consultas | Requiere datos del paciente |
| EPIC-CL-011 Expediente | Requiere pacientes |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `patients`
- [ ] Tablas: 7 (patients, emergency_contacts, insurance_info, consents, consent_signatures, minors, patient_merge_log)
- [ ] Funciones: 2 (validate_curp, encrypt_sensitive)
- [ ] Indices: Por CURP, teléfono, nombre, fecha nacimiento
**Backend:**
- [ ] Modulo: `patients`
- [ ] Entities: 5 (Patient, EmergencyContact, InsuranceInfo, Consent, ConsentSignature)
- [ ] Endpoints: 15
- [ ] Tests: 30
**Frontend:**
- [ ] Paginas: 5 (PatientList, PatientForm, PatientDetail, ConsentSign, PatientPortal)
- [ ] Componentes: 12 (PatientCard, SearchBar, ConsentModal, SignaturePad, etc.)
- [ ] Portal del paciente (separado)
- [ ] Stores: 1 (patientsStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /api/patients | Registrar paciente |
| GET | /api/patients/search | Buscar pacientes |
| GET | /api/patients/:id | Detalle de paciente |
| PATCH | /api/patients/:id | Actualizar paciente |
| POST | /api/patients/:id/insurance | Agregar seguro |
| POST | /api/patients/:id/emergency-contacts | Agregar contacto |
| POST | /api/patients/:id/consents/:consentId/sign | Firmar consentimiento |
| GET | /api/patients/:id/consents | Ver consentimientos |
| POST | /api/patients/merge | Fusionar expedientes |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Datos duplicados | Alta | Medio | Validación de CURP + alertas |
| Fuga de datos sensibles | Baja | Alto | Encriptación + auditoría |
| Consentimiento inválido | Baja | Alto | Firma digital con evidencia |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Textos de consentimiento aprobados
- [ ] Campos obligatorios por regulación definidos
## Definition of Done (DoD)
- [ ] Registro completo de pacientes
- [ ] Búsqueda multi-criterio funcionando
- [ ] Consentimiento digital operativo
- [ ] Datos sensibles encriptados
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,270 @@
# EPICA: EPIC-CL-003 - Citas (Agenda Médica)
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-CL-003 |
| **Nombre** | Citas (Agenda Médica) |
| **Modulo** | citas |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P0 (Critico) |
| **Estado** | Backlog |
| **Story Points** | 42 |
| **Sprint(s)** | Sprint 3-4 |
---
## Descripcion
Sistema de agenda médica para programación de citas. Gestión de horarios por médico y consultorio, confirmación de citas, recordatorios automáticos, lista de espera y módulo de check-in para llegada de pacientes.
---
## Objetivo de Negocio
- Optimizar uso de consultorios
- Reducir ausentismo con recordatorios
- Mejorar experiencia del paciente
- Control de tiempos de espera
- Maximizar productividad médica
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-CL003-001 | Como recepcionista, quiero agendar cita seleccionando médico, fecha y hora disponible | P0 | 5 | Backlog |
| US-CL003-002 | Como recepcionista, quiero ver agenda del día por médico en formato calendario | P0 | 5 | Backlog |
| US-CL003-003 | Como recepcionista, quiero confirmar cita vía WhatsApp o llamada | P0 | 3 | Backlog |
| US-CL003-004 | Como paciente, quiero recibir recordatorio automático 24h antes de mi cita | P0 | 5 | Backlog |
| US-CL003-005 | Como recepcionista, quiero reagendar cita manteniendo historial | P0 | 3 | Backlog |
| US-CL003-006 | Como recepcionista, quiero registrar check-in del paciente al llegar | P0 | 3 | Backlog |
| US-CL003-007 | Como médico, quiero ver mis citas del día con datos del paciente | P0 | 3 | Backlog |
| US-CL003-008 | Como admin, quiero configurar horarios de atención por médico | P0 | 5 | Backlog |
| US-CL003-009 | Como recepcionista, quiero gestionar lista de espera para cancelaciones | P1 | 3 | Backlog |
| US-CL003-010 | Como paciente, quiero agendar cita desde portal web o app | P1 | 5 | Backlog |
| US-CL003-011 | Como admin, quiero bloquear horarios por vacaciones o eventos | P1 | 2 | Backlog |
**Total Story Points:** 42 SP
---
## Flujo de Cita
```
┌─────────────┐
│ AGENDADA │ ← Cita programada
└──────┬──────┘
▼ (-24h)
┌─────────────┐
│ RECORDATORIO│ ← Envío automático WhatsApp/SMS
└──────┬──────┘
├── Sin respuesta ────────────┐
▼ │
┌─────────────┐ │
│ CONFIRMADA │ │
└──────┬──────┘ │
│ │
▼ (Día de la cita) │
┌─────────────┐ │
│ CHECK-IN │ ← Paciente llega │
└──────┬──────┘ │
│ │
▼ │
┌─────────────┐ │
│ EN_CONSULTA │ ← Médico inicia │
└──────┬──────┘ │
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ ATENDIDA │ │ NO_ASISTIO │
└─────────────┘ └─────────────┘
```
---
## Configuración de Agenda
```
┌─────────────────────────────────────────────────────────┐
│ AGENDA DEL DR. GARCÍA │
├─────────────────────────────────────────────────────────┤
│ │
│ HORARIO DE ATENCIÓN │
│ ├── Lunes a Viernes: 09:00 - 14:00, 16:00 - 20:00 │
│ ├── Sábados: 09:00 - 14:00 │
│ └── Domingos: No labora │
│ │
│ DURACIÓN DE CITAS │
│ ├── Primera vez: 45 minutos │
│ ├── Seguimiento: 20 minutos │
│ └── Procedimiento: 60 minutos │
│ │
│ CONSULTORIOS │
│ ├── Consultorio 1 (Principal) │
│ └── Consultorio 3 (Alterno) │
│ │
│ BLOQUEOS │
│ ├── 15-22 Dic: Vacaciones │
│ └── Cada miércoles 10:00-11:00: Junta médica │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Vista de Agenda
```
┌─────────────────────────────────────────────────────────┐
│ DR. GARCÍA - Lunes 9 Diciembre 2024 │
├─────────────────────────────────────────────────────────┤
│ │
│ 09:00 │ ████████████████████ Juan Pérez (Primera vez) │
│ 09:45 │ - DISPONIBLE - │
│ 10:00 │ ████████ María López (Seguimiento) ✓ Confirmada│
│ 10:20 │ - DISPONIBLE - │
│ 10:40 │ ████████ Carlos Ruiz (Seguimiento) │
│ 11:00 │ ▓▓▓ JUNTA MÉDICA ▓▓▓ │
│ 12:00 │ ████████████████████████████████ Procedimiento │
│ 13:00 │ ████████ Ana García (Seguimiento) ✓ En sala │
│ 13:20 │ ████████ Pedro Soto (Seguimiento) │
│ 13:40 │ - DISPONIBLE - │
│ │
│ ────────────── DESCANSO ────────────── │
│ │
│ 16:00 │ ████████████████████ Nuevo paciente (1a vez) │
│ ... │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Agendar citas con validación de disponibilidad
- [ ] Vista de agenda diaria/semanal por médico
- [ ] Confirmación de citas
- [ ] Recordatorios automáticos (WhatsApp/SMS/Email)
- [ ] Check-in de pacientes
- [ ] Reagendar y cancelar citas
- [ ] Lista de espera
- [ ] Configuración de horarios
**No Funcionales:**
- [ ] Carga de agenda < 2 segundos
- [ ] Envío de recordatorio en < 1 minuto
- [ ] Soporte para 10+ médicos simultáneos
**Tecnicos:**
- [ ] Integración con WhatsApp Business API
- [ ] Calendario sincronizable (Google Calendar, Outlook)
- [ ] Notificaciones push para app
- [ ] Tiempo real con WebSockets
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-CL-001 Fundamentos | Backlog | Si |
| EPIC-CL-002 Pacientes | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-CL-004 Consultas | Requiere cita para iniciar consulta |
| EPIC-CL-008 Facturación | Requiere citas para facturar |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `appointments`
- [ ] Tablas: 7 (appointments, schedules, schedule_blocks, waiting_list, reminders, check_ins, appointment_types)
- [ ] Funciones: 3 (check_availability, send_reminder, calculate_wait_time)
- [ ] Indices: Por médico, fecha, paciente, estado
**Backend:**
- [ ] Modulo: `appointments`
- [ ] Entities: 6 (Appointment, Schedule, ScheduleBlock, WaitingList, Reminder, CheckIn)
- [ ] Endpoints: 18
- [ ] Jobs: Envío de recordatorios
- [ ] Tests: 35
**Frontend:**
- [ ] Paginas: 5 (Calendar, AppointmentForm, DayView, WeekView, WaitingList)
- [ ] Componentes: 15 (CalendarGrid, TimeSlot, AppointmentCard, CheckInModal, etc.)
- [ ] WebSockets para actualizaciones en tiempo real
- [ ] Stores: 1 (appointmentsStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /api/appointments | Crear cita |
| GET | /api/appointments/:id | Detalle de cita |
| PATCH | /api/appointments/:id | Actualizar cita |
| DELETE | /api/appointments/:id | Cancelar cita |
| GET | /api/appointments/calendar/:doctorId | Agenda del médico |
| GET | /api/appointments/availability | Horarios disponibles |
| POST | /api/appointments/:id/confirm | Confirmar cita |
| POST | /api/appointments/:id/check-in | Registrar llegada |
| GET | /api/schedules/:doctorId | Horarios del médico |
| POST | /api/schedules/:doctorId/blocks | Bloquear horario |
| GET | /api/waiting-list | Lista de espera |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Overbooking | Media | Alto | Validación de disponibilidad |
| Recordatorios no enviados | Media | Medio | Reintentos + logs |
| Ausentismo alto | Media | Medio | Confirmación + lista de espera |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Horarios de médicos definidos
- [ ] Proveedor de WhatsApp Business API seleccionado
## Definition of Done (DoD)
- [ ] Agenda funcional por médico
- [ ] Recordatorios automáticos enviándose
- [ ] Check-in operativo
- [ ] Lista de espera activa
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,277 @@
# EPICA: EPIC-CL-004 - Consultas (Notas Médicas)
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-CL-004 |
| **Nombre** | Consultas (Notas Médicas) |
| **Modulo** | consultas |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P0 (Critico) |
| **Estado** | Backlog |
| **Story Points** | 55 |
| **Sprint(s)** | Sprint 4-6 |
---
## Descripcion
Módulo 100% nuevo para documentación de consultas médicas. Incluye notas clínicas estructuradas (SOAP), signos vitales, diagnósticos con codificación CIE-10, planes de tratamiento, indicaciones y generación de documentos médicos.
---
## Objetivo de Negocio
- Documentación clínica completa
- Cumplimiento de NOM-004-SSA3-2012
- Agilizar consulta médica
- Historial clínico consultable
- Soporte para decisiones clínicas
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-CL004-001 | Como médico, quiero iniciar consulta desde cita agendada para documentar atención | P0 | 3 | Backlog |
| US-CL004-002 | Como enfermera, quiero registrar signos vitales antes de la consulta | P0 | 5 | Backlog |
| US-CL004-003 | Como médico, quiero documentar nota clínica en formato SOAP | P0 | 8 | Backlog |
| US-CL004-004 | Como médico, quiero registrar diagnósticos con código CIE-10 | P0 | 5 | Backlog |
| US-CL004-005 | Como médico, quiero ver historial de consultas previas del paciente | P0 | 3 | Backlog |
| US-CL004-006 | Como médico, quiero generar indicaciones médicas imprimibles | P0 | 3 | Backlog |
| US-CL004-007 | Como médico, quiero usar plantillas de notas para consultas frecuentes | P1 | 5 | Backlog |
| US-CL004-008 | Como médico, quiero dictar nota por voz (speech-to-text) | P2 | 8 | Backlog |
| US-CL004-009 | Como médico, quiero agregar antecedentes a la historia clínica | P0 | 5 | Backlog |
| US-CL004-010 | Como médico, quiero cerrar consulta y liberar consultorio | P0 | 2 | Backlog |
| US-CL004-011 | Como admin, quiero configurar plantillas de notas por especialidad | P1 | 3 | Backlog |
| US-CL004-012 | Como auditor, quiero ver log de cambios en notas clínicas | P0 | 5 | Backlog |
**Total Story Points:** 55 SP
---
## Formato SOAP
```
┌─────────────────────────────────────────────────────────┐
│ NOTA CLÍNICA - FORMATO SOAP │
├─────────────────────────────────────────────────────────┤
│ │
│ S - SUBJETIVO (Lo que el paciente refiere) │
│ ├── Motivo de consulta │
│ ├── Historia de la enfermedad actual │
│ ├── Síntomas referidos │
│ └── Evolución desde última visita │
│ │
│ O - OBJETIVO (Lo que el médico observa/mide) │
│ ├── Signos vitales │
│ │ ├── T/A: 120/80 mmHg │
│ │ ├── FC: 72 lpm │
│ │ ├── FR: 16 rpm │
│ │ ├── Temp: 36.5°C │
│ │ ├── Peso: 70 kg │
│ │ ├── Talla: 170 cm │
│ │ └── IMC: 24.2 │
│ ├── Exploración física │
│ └── Resultados de estudios │
│ │
│ A - ANÁLISIS (Diagnósticos) │
│ ├── Diagnóstico principal (CIE-10) │
│ ├── Diagnósticos secundarios │
│ └── Diagnósticos diferenciales │
│ │
│ P - PLAN (Tratamiento) │
│ ├── Medicamentos (→ Receta) │
│ ├── Estudios solicitados (→ Lab/Imagen) │
│ ├── Indicaciones generales │
│ ├── Referencia a especialista │
│ └── Próxima cita │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Flujo de Consulta
```
┌─────────────┐
│ CHECK-IN │ ← Paciente llega
└──────┬──────┘
┌─────────────┐
│SIGNOS VITAL │ ← Enfermera registra
└──────┬──────┘
┌─────────────┐
│ EN_CONSULTA │ ← Médico inicia
└──────┬──────┘
├── Revisar historial
├── Documentar SOAP
├── Generar receta
├── Solicitar estudios
┌─────────────┐
│ CERRADA │ ← Consulta finalizada
└──────┬──────┘
┌─────────────┐
│ FACTURAR │ ← Proceso de cobro
└─────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Iniciar consulta desde cita
- [ ] Registrar signos vitales
- [ ] Documentar nota SOAP completa
- [ ] Codificar diagnósticos CIE-10
- [ ] Ver historial de consultas
- [ ] Generar indicaciones imprimibles
- [ ] Plantillas de notas
- [ ] Registro de antecedentes
- [ ] Auditoría de cambios
**No Funcionales:**
- [ ] Autoguardado cada 30 segundos
- [ ] Búsqueda de CIE-10 < 500ms
- [ ] Notas no editables después de cierre
- [ ] Cumplimiento NOM-004-SSA3-2012
**Tecnicos:**
- [ ] Catálogo CIE-10 integrado
- [ ] Editor de texto enriquecido
- [ ] Opcional: Speech-to-text
- [ ] Generación de PDFs
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-CL-001 Fundamentos | Backlog | Si |
| EPIC-CL-002 Pacientes | Backlog | Si |
| EPIC-CL-003 Citas | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-CL-005 Recetas | Requiere consulta para prescribir |
| EPIC-CL-006 Laboratorio | Requiere consulta para solicitar |
| EPIC-CL-011 Expediente | Requiere notas clínicas |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `consultations`
- [ ] Tablas: 10 (consultations, vital_signs, diagnoses, treatments, indications, templates, medical_history, antecedents, note_versions, audit_log)
- [ ] Funciones: 3 (search_icd10, calculate_bmi, lock_consultation)
- [ ] Indices: Por paciente, médico, fecha, diagnóstico
**Backend:**
- [ ] Modulo: `consultations`
- [ ] Entities: 8 (Consultation, VitalSigns, Diagnosis, Treatment, Template, MedicalHistory, Antecedent, NoteVersion)
- [ ] Endpoints: 20
- [ ] Tests: 40
**Frontend:**
- [ ] Paginas: 5 (ConsultationRoom, VitalSignsForm, SOAPEditor, HistoryView, Templates)
- [ ] Componentes: 18 (SOAPSection, ICD10Search, VitalsWidget, HistoryTimeline, etc.)
- [ ] Editor WYSIWYG para notas
- [ ] Stores: 2 (consultationsStore, icd10Store)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /api/consultations | Iniciar consulta |
| GET | /api/consultations/:id | Detalle de consulta |
| PATCH | /api/consultations/:id | Actualizar nota |
| POST | /api/consultations/:id/vitals | Registrar signos vitales |
| POST | /api/consultations/:id/diagnoses | Agregar diagnóstico |
| POST | /api/consultations/:id/close | Cerrar consulta |
| GET | /api/consultations/history/:patientId | Historial del paciente |
| GET | /api/icd10/search | Buscar código CIE-10 |
| GET | /api/templates | Listar plantillas |
| POST | /api/templates | Crear plantilla |
---
## Catálogo CIE-10
```
Ejemplos de códigos frecuentes:
├── J00 - Rinofaringitis aguda (resfriado común)
├── J06.9 - Infección aguda de las vías respiratorias
├── E11 - Diabetes mellitus tipo 2
├── I10 - Hipertensión esencial
├── K30 - Dispepsia funcional
├── M54.5 - Dolor lumbar
└── F32 - Episodio depresivo
```
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Pérdida de notas | Baja | Alto | Autoguardado + versiones |
| Diagnóstico incorrecto | Media | Alto | Búsqueda asistida CIE-10 |
| Notas incompletas | Media | Medio | Validación antes de cerrar |
---
## Nota Técnica
Este módulo es **100% nuevo** y no tiene equivalente en el ERP-Core. Es específico para el sector salud y debe cumplir con las NOM mexicanas aplicables a expedientes clínicos electrónicos.
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Catálogo CIE-10 importado
- [ ] Plantillas iniciales definidas
## Definition of Done (DoD)
- [ ] Flujo completo de consulta
- [ ] Formato SOAP funcionando
- [ ] Búsqueda CIE-10 operativa
- [ ] Auditoría de cambios
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,243 @@
# EPICA: EPIC-CL-005 - Recetas (Prescripciones)
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-CL-005 |
| **Nombre** | Recetas (Prescripciones) |
| **Modulo** | recetas |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P0 (Critico) |
| **Estado** | Backlog |
| **Story Points** | 35 |
| **Sprint(s)** | Sprint 5-6 |
---
## Descripcion
Sistema de prescripción médica electrónica. Generación de recetas con búsqueda de medicamentos, dosificación, verificación de interacciones medicamentosas, firma electrónica (NOM-151) y envío digital al paciente o farmacia.
---
## Objetivo de Negocio
- Recetas legibles y sin errores
- Cumplimiento de NOM-151-SCFI-2016
- Agilizar proceso de prescripción
- Evitar errores de medicación
- Trazabilidad de prescripciones
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-CL005-001 | Como médico, quiero buscar medicamento por nombre genérico o comercial | P0 | 3 | Backlog |
| US-CL005-002 | Como médico, quiero agregar medicamento a receta con dosis y frecuencia | P0 | 5 | Backlog |
| US-CL005-003 | Como médico, quiero ver alertas de interacciones medicamentosas | P0 | 8 | Backlog |
| US-CL005-004 | Como médico, quiero ver alergias conocidas del paciente al prescribir | P0 | 3 | Backlog |
| US-CL005-005 | Como médico, quiero usar recetas previas como base para nueva receta | P1 | 3 | Backlog |
| US-CL005-006 | Como médico, quiero firmar electrónicamente la receta | P0 | 5 | Backlog |
| US-CL005-007 | Como paciente, quiero recibir mi receta por email/WhatsApp | P0 | 3 | Backlog |
| US-CL005-008 | Como médico, quiero indicar si requiere receta resurtible | P1 | 2 | Backlog |
| US-CL005-009 | Como admin, quiero configurar cuadro básico de medicamentos | P1 | 3 | Backlog |
**Total Story Points:** 35 SP
---
## Estructura de Receta
```
┌─────────────────────────────────────────────────────────┐
│ RECETA MÉDICA ELECTRÓNICA │
├─────────────────────────────────────────────────────────┤
│ │
│ DATOS DEL PRESCRIPTOR │
│ ├── Nombre del médico │
│ ├── Cédula profesional │
│ ├── Especialidad │
│ ├── Institución/Consultorio │
│ └── Domicilio y teléfono │
│ │
│ DATOS DEL PACIENTE │
│ ├── Nombre completo │
│ ├── Edad │
│ └── Sexo │
│ │
│ PRESCRIPCIÓN │
│ ├── Medicamento 1 │
│ │ ├── Nombre genérico / comercial │
│ │ ├── Forma farmacéutica │
│ │ ├── Concentración │
│ │ ├── Cantidad │
│ │ ├── Dosis │
│ │ ├── Vía de administración │
│ │ ├── Frecuencia │
│ │ └── Duración del tratamiento │
│ ├── Medicamento 2... │
│ └── Indicaciones adicionales │
│ │
│ DATOS DE CONTROL │
│ ├── Folio único │
│ ├── Fecha de expedición │
│ ├── Fecha de vigencia │
│ ├── Firma electrónica del médico │
│ └── Código QR de verificación │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Verificación de Interacciones
```
┌─────────────────────────────────────────────────────────┐
│ ALERTAS DE INTERACCIÓN │
├─────────────────────────────────────────────────────────┤
│ │
│ ⚠️ INTERACCIÓN GRAVE │
│ Warfarina + Aspirina │
│ Riesgo: Sangrado aumentado │
│ Recomendación: Evitar combinación o monitorear INR │
│ │
│ ⚠️ INTERACCIÓN MODERADA │
│ Metformina + Alcohol │
│ Riesgo: Acidosis láctica │
│ Recomendación: Advertir al paciente │
│ │
│ ⚠️ ALERGIA CONOCIDA │
│ Paciente alérgico a Penicilina │
│ Medicamento prescrito: Amoxicilina │
│ Acción: Requiere confirmación del médico │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Búsqueda de medicamentos
- [ ] Agregar múltiples medicamentos a receta
- [ ] Alertas de interacciones
- [ ] Verificación de alergias
- [ ] Firma electrónica (e.firma o similar)
- [ ] Generación de PDF con código QR
- [ ] Envío digital al paciente
- [ ] Recetas resurtibles
**No Funcionales:**
- [ ] Búsqueda de medicamentos < 500ms
- [ ] Verificación de interacciones < 2 segundos
- [ ] Cumplimiento NOM-151-SCFI-2016
**Tecnicos:**
- [ ] Catálogo de medicamentos (PLM o similar)
- [ ] Base de datos de interacciones
- [ ] Firma electrónica avanzada
- [ ] Generación de PDF con QR
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-CL-001 Fundamentos | Backlog | Si |
| EPIC-CL-002 Pacientes | Backlog | Si |
| EPIC-CL-004 Consultas | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-CL-007 Farmacia | Requiere recetas para surtir |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `prescriptions`
- [ ] Tablas: 6 (prescriptions, prescription_items, medications, interactions, patient_allergies, signature_logs)
- [ ] Funciones: 3 (check_interactions, validate_prescription, generate_folio)
- [ ] Indices: Por paciente, médico, fecha, medicamento
**Backend:**
- [ ] Modulo: `prescriptions`
- [ ] Entities: 5 (Prescription, PrescriptionItem, Medication, Interaction, PatientAllergy)
- [ ] Services: InteractionChecker, SignatureService
- [ ] Endpoints: 12
- [ ] Tests: 28
**Frontend:**
- [ ] Paginas: 4 (PrescriptionEditor, MedicationSearch, PrescriptionView, PrescriptionHistory)
- [ ] Componentes: 12 (MedicationLine, InteractionAlert, AllergyWarning, SignatureModal, etc.)
- [ ] Stores: 1 (prescriptionsStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /api/prescriptions | Crear receta |
| GET | /api/prescriptions/:id | Detalle de receta |
| POST | /api/prescriptions/:id/items | Agregar medicamento |
| DELETE | /api/prescriptions/:id/items/:itemId | Quitar medicamento |
| POST | /api/prescriptions/:id/check-interactions | Verificar interacciones |
| POST | /api/prescriptions/:id/sign | Firmar receta |
| POST | /api/prescriptions/:id/send | Enviar al paciente |
| GET | /api/prescriptions/:id/pdf | Descargar PDF |
| GET | /api/medications/search | Buscar medicamentos |
| GET | /api/patients/:id/allergies | Alergias del paciente |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Interacciones no detectadas | Baja | Alto | Base de datos actualizada |
| Firma electrónica inválida | Baja | Alto | Proveedor certificado |
| Errores de dosificación | Media | Alto | Validaciones y rangos |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Catálogo de medicamentos disponible
- [ ] Proveedor de firma electrónica seleccionado
## Definition of Done (DoD)
- [ ] Prescripción completa funcionando
- [ ] Alertas de interacciones operativas
- [ ] Firma electrónica válida
- [ ] Envío digital al paciente
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,242 @@
# EPICA: EPIC-CL-006 - Laboratorio
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-CL-006 |
| **Nombre** | Laboratorio |
| **Modulo** | laboratorio |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P1 (Alto) |
| **Estado** | Backlog |
| **Story Points** | 38 |
| **Sprint(s)** | Sprint 6-7 |
---
## Descripcion
Gestión de estudios de laboratorio clínico. Solicitud de estudios desde consulta, toma de muestras, captura de resultados, valores de referencia, alertas de valores críticos y entrega de resultados al paciente.
---
## Objetivo de Negocio
- Flujo completo de laboratorio
- Resultados oportunos
- Alertas de valores críticos
- Integración con expediente clínico
- Control de calidad
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-CL006-001 | Como médico, quiero solicitar estudios de laboratorio desde la consulta | P0 | 5 | Backlog |
| US-CL006-002 | Como laboratorista, quiero ver órdenes de estudios pendientes | P0 | 3 | Backlog |
| US-CL006-003 | Como laboratorista, quiero registrar toma de muestra con hora y responsable | P0 | 3 | Backlog |
| US-CL006-004 | Como laboratorista, quiero capturar resultados de estudios | P0 | 5 | Backlog |
| US-CL006-005 | Como laboratorista, quiero ver valores de referencia al capturar | P0 | 3 | Backlog |
| US-CL006-006 | Como médico, quiero recibir alerta de valores críticos | P0 | 5 | Backlog |
| US-CL006-007 | Como paciente, quiero descargar mis resultados desde el portal | P0 | 5 | Backlog |
| US-CL006-008 | Como médico, quiero ver historial de estudios del paciente | P1 | 3 | Backlog |
| US-CL006-009 | Como admin, quiero configurar catálogo de estudios con valores de referencia | P0 | 4 | Backlog |
| US-CL006-010 | Como laboratorista, quiero validar resultados antes de liberar | P1 | 2 | Backlog |
**Total Story Points:** 38 SP
---
## Flujo de Laboratorio
```
┌─────────────┐
│ SOLICITUD │ ← Médico solicita estudios
└──────┬──────┘
┌─────────────┐
│ RECEPCIÓN │ ← Paciente llega a lab
└──────┬──────┘
┌─────────────┐
│TOMA_MUESTRA │ ← Flebotomía
└──────┬──────┘
┌─────────────┐
│ EN_PROCESO │ ← Análisis en curso
└──────┬──────┘
┌─────────────┐
│ CAPTURA │ ← Resultados capturados
└──────┬──────┘
┌─────────────┐
│ VALIDACIÓN │ ← QC revisa
└──────┬──────┘
┌─────────────┐
│ LIBERADO │ ← Disponible para médico/paciente
└─────────────┘
```
---
## Estructura de Resultados
```
┌─────────────────────────────────────────────────────────┐
│ RESULTADOS DE LABORATORIO │
├─────────────────────────────────────────────────────────┤
│ │
│ BIOMETRÍA HEMÁTICA COMPLETA │
│ ┌──────────────┬─────────┬──────────────┬───────────┐ │
│ │ Parámetro │ Result. │ Referencia │ Estado │ │
│ ├──────────────┼─────────┼──────────────┼───────────┤ │
│ │ Hemoglobina │ 14.5 │ 13.5-17.5 │ ✓ Normal │ │
│ │ Hematocrito │ 42% │ 40-52% │ ✓ Normal │ │
│ │ Leucocitos │ 12,500 │ 4,500-11,000 │ ⚠️ Alto │ │
│ │ Plaquetas │ 250,000 │ 150K-400K │ ✓ Normal │ │
│ │ Glucosa │ 285 │ 70-100 │ 🔴 CRÍTICO│ │
│ └──────────────┴─────────┴──────────────┴───────────┘ │
│ │
│ 🔴 VALORES CRÍTICOS DETECTADOS │
│ Glucosa: 285 mg/dL - Notificar al médico │
│ │
│ Laboratorista: QFB María García │
│ Fecha toma: 2024-12-08 09:30 │
│ Fecha resultado: 2024-12-08 14:45 │
│ Validado por: Dr. Roberto Sánchez │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Solicitar estudios desde consulta
- [ ] Ver órdenes pendientes
- [ ] Registrar toma de muestra
- [ ] Capturar resultados
- [ ] Valores de referencia
- [ ] Alertas de valores críticos
- [ ] Validación de resultados
- [ ] Entrega de resultados
**No Funcionales:**
- [ ] Alerta de críticos < 1 minuto
- [ ] Historial de 5 años
- [ ] Cumplimiento normativo de laboratorio
**Tecnicos:**
- [ ] Integración con consultas
- [ ] Integración con expediente
- [ ] Notificaciones push para críticos
- [ ] Generación de PDF de resultados
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-CL-001 Fundamentos | Backlog | Si |
| EPIC-CL-002 Pacientes | Backlog | Si |
| EPIC-CL-004 Consultas | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-CL-011 Expediente | Resultados son parte del expediente |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `laboratory`
- [ ] Tablas: 7 (lab_orders, lab_order_items, samples, results, result_values, studies_catalog, reference_values)
- [ ] Funciones: 3 (check_critical, calculate_status, validate_result)
- [ ] Indices: Por paciente, médico, fecha, estado
**Backend:**
- [ ] Modulo: `laboratory`
- [ ] Entities: 6 (LabOrder, LabOrderItem, Sample, Result, ResultValue, StudyCatalog)
- [ ] Endpoints: 15
- [ ] Tests: 30
**Frontend:**
- [ ] Paginas: 5 (LabOrders, SampleCollection, ResultCapture, ResultViewer, CatalogConfig)
- [ ] Componentes: 12 (OrderCard, ResultGrid, CriticalAlert, ReferenceIndicator, etc.)
- [ ] Stores: 1 (laboratoryStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /api/laboratory/orders | Crear orden de estudios |
| GET | /api/laboratory/orders | Listar órdenes |
| GET | /api/laboratory/orders/:id | Detalle de orden |
| POST | /api/laboratory/orders/:id/sample | Registrar toma |
| POST | /api/laboratory/orders/:id/results | Capturar resultados |
| POST | /api/laboratory/orders/:id/validate | Validar resultados |
| GET | /api/laboratory/orders/:id/pdf | Descargar PDF |
| GET | /api/laboratory/history/:patientId | Historial del paciente |
| GET | /api/laboratory/studies | Catálogo de estudios |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Críticos no notificados | Baja | Alto | Múltiples canales de alerta |
| Resultados incorrectos | Media | Alto | Doble validación |
| Pérdida de muestras | Baja | Alto | Trazabilidad completa |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Catálogo de estudios definido
- [ ] Valores de referencia documentados
## Definition of Done (DoD)
- [ ] Flujo completo de laboratorio
- [ ] Alertas de críticos funcionando
- [ ] Resultados en expediente
- [ ] PDF de resultados generándose
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,239 @@
# EPICA: EPIC-CL-007 - Farmacia
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-CL-007 |
| **Nombre** | Farmacia |
| **Modulo** | farmacia |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P1 (Alto) |
| **Estado** | Backlog |
| **Story Points** | 40 |
| **Sprint(s)** | Sprint 7-8 |
---
## Descripcion
Gestión de farmacia clínica. Control de inventario de medicamentos, surtido de recetas, dispensación, control de caducidades, medicamentos controlados y punto de venta de farmacia.
---
## Objetivo de Negocio
- Control de inventario de medicamentos
- Surtido rápido de recetas
- Evitar merma por caducidad
- Cumplimiento de medicamentos controlados
- Rentabilidad de farmacia
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-CL007-001 | Como farmacéutico, quiero ver recetas pendientes de surtir | P0 | 3 | Backlog |
| US-CL007-002 | Como farmacéutico, quiero verificar stock antes de surtir | P0 | 3 | Backlog |
| US-CL007-003 | Como farmacéutico, quiero dispensar medicamentos registrando lote | P0 | 5 | Backlog |
| US-CL007-004 | Como farmacéutico, quiero cobrar la receta surtida | P0 | 5 | Backlog |
| US-CL007-005 | Como farmacéutico, quiero recibir mercancía de proveedor | P0 | 5 | Backlog |
| US-CL007-006 | Como farmacéutico, quiero ver alertas de medicamentos próximos a caducar | P0 | 3 | Backlog |
| US-CL007-007 | Como farmacéutico, quiero registrar salidas de medicamentos controlados | P0 | 5 | Backlog |
| US-CL007-008 | Como admin, quiero ver reporte de ventas de farmacia | P1 | 3 | Backlog |
| US-CL007-009 | Como admin, quiero realizar inventario físico de medicamentos | P1 | 5 | Backlog |
| US-CL007-010 | Como admin, quiero configurar márgenes de ganancia por categoría | P2 | 3 | Backlog |
**Total Story Points:** 40 SP
---
## Flujo de Dispensación
```
┌─────────────┐
│ RECETA │ ← Receta electrónica del médico
└──────┬──────┘
┌─────────────┐
│ VERIFICAR │ ← Verificar stock disponible
│ STOCK │
└──────┬──────┘
├── No hay stock ──► Notificar faltante
┌─────────────┐
│ PREPARAR │ ← Tomar medicamentos de anaquel
└──────┬──────┘
┌─────────────┐
│ VERIFICAR │ ← Doble chequeo
└──────┬──────┘
┌─────────────┐
│ COBRAR │ ← Proceso de pago
└──────┬──────┘
┌─────────────┐
│ ENTREGAR │ ← Dispensar al paciente
└─────────────┘
```
---
## Control de Medicamentos
```
┌─────────────────────────────────────────────────────────┐
│ CONTROL DE INVENTARIO │
├─────────────────────────────────────────────────────────┤
│ │
│ TRAZABILIDAD │
│ ├── Código de producto │
│ ├── Lote │
│ ├── Fecha de caducidad │
│ ├── Proveedor │
│ └── Fecha de entrada │
│ │
│ ALERTAS DE CADUCIDAD │
│ ├── 🔴 Caducados (vencidos) │
│ ├── 🟠 < 30 días para vencer
│ ├── 🟡 < 90 días para vencer
│ └── Sugerencia: Promoción o devolución │
│ │
│ MEDICAMENTOS CONTROLADOS │
│ ├── Libro de registro (físico y digital) │
│ ├── Receta foliada obligatoria │
│ ├── Control de existencias exactas │
│ ├── Auditoría de movimientos │
│ └── Reportes para COFEPRIS │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Ver recetas pendientes
- [ ] Verificar stock
- [ ] Dispensar con lote y caducidad
- [ ] Cobro de receta
- [ ] Recepción de mercancía
- [ ] Alertas de caducidad
- [ ] Control de medicamentos controlados
- [ ] Inventario físico
**No Funcionales:**
- [ ] Dispensación < 3 minutos
- [ ] Trazabilidad 100% de lotes
- [ ] Cumplimiento COFEPRIS
**Tecnicos:**
- [ ] Integración con recetas
- [ ] Integración con facturación
- [ ] Lector de código de barras
- [ ] Reportes para autoridades
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-CL-001 Fundamentos | Backlog | Si |
| EPIC-CL-005 Recetas | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-CL-008 Facturación | Ventas de farmacia |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `pharmacy`
- [ ] Tablas: 8 (products, stock, stock_movements, dispensations, dispensation_items, controlled_log, suppliers, physical_counts)
- [ ] Funciones: 3 (check_expiry, update_stock, log_controlled)
- [ ] Indices: Por producto, lote, caducidad, proveedor
**Backend:**
- [ ] Modulo: `pharmacy`
- [ ] Entities: 6 (Product, Stock, StockMovement, Dispensation, DispensationItem, ControlledLog)
- [ ] Endpoints: 15
- [ ] Tests: 30
**Frontend:**
- [ ] Paginas: 5 (PendingPrescriptions, Dispensation, Inventory, ExpiryAlerts, ControlledLog)
- [ ] Componentes: 12 (PrescriptionCard, StockChecker, BarcodeScanner, ExpiryCalendar, etc.)
- [ ] Stores: 1 (pharmacyStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| GET | /api/pharmacy/prescriptions/pending | Recetas pendientes |
| GET | /api/pharmacy/stock/:productId | Verificar stock |
| POST | /api/pharmacy/dispensations | Registrar dispensación |
| POST | /api/pharmacy/receipts | Recibir mercancía |
| GET | /api/pharmacy/expiry-alerts | Alertas de caducidad |
| POST | /api/pharmacy/controlled-log | Registrar movimiento controlado |
| POST | /api/pharmacy/physical-count | Inventario físico |
| GET | /api/pharmacy/reports/sales | Reporte de ventas |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Merma por caducidad | Media | Medio | Alertas tempranas |
| Error en dispensación | Baja | Alto | Doble verificación |
| Faltantes de controlados | Baja | Alto | Auditorías frecuentes |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Catálogo de medicamentos definido
- [ ] Proceso de controlados documentado
## Definition of Done (DoD)
- [ ] Flujo de dispensación funcionando
- [ ] Control de lotes y caducidad
- [ ] Registro de controlados
- [ ] Alertas de caducidad activas
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,268 @@
# EPICA: EPIC-CL-008 - Facturación
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-CL-008 |
| **Nombre** | Facturación |
| **Modulo** | facturacion |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P0 (Critico) |
| **Estado** | Backlog |
| **Story Points** | 38 |
| **Sprint(s)** | Sprint 8-9 |
---
## Descripcion
Sistema de facturación para servicios médicos. Incluye cobro de consultas, procedimientos, estudios de laboratorio, medicamentos y facturación a aseguradoras. Generación de CFDI 4.0 y notas de crédito.
---
## Objetivo de Negocio
- Cobro oportuno de servicios
- Facturación correcta a aseguradoras
- Cumplimiento fiscal
- Control de cuentas por cobrar
- Reportes financieros
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-CL008-001 | Como cajero, quiero generar cuenta del paciente con servicios prestados | P0 | 5 | Backlog |
| US-CL008-002 | Como cajero, quiero cobrar consulta con múltiples formas de pago | P0 | 5 | Backlog |
| US-CL008-003 | Como cajero, quiero facturar a nombre del paciente con sus datos fiscales | P0 | 5 | Backlog |
| US-CL008-004 | Como admin, quiero facturar a aseguradora con expediente de reclamación | P0 | 8 | Backlog |
| US-CL008-005 | Como cajero, quiero generar nota de crédito por cancelación o error | P0 | 3 | Backlog |
| US-CL008-006 | Como paciente, quiero pagar mi cuenta desde el portal web | P1 | 5 | Backlog |
| US-CL008-007 | Como admin, quiero ver cuentas por cobrar pendientes | P0 | 3 | Backlog |
| US-CL008-008 | Como admin, quiero configurar precios de servicios y procedimientos | P0 | 2 | Backlog |
| US-CL008-009 | Como admin, quiero ver reporte de ingresos por período | P1 | 2 | Backlog |
**Total Story Points:** 38 SP
---
## Flujo de Facturación
```
COBRO DIRECTO (Paciente paga)
┌─────────────┐
│ CUENTA │ ← Servicios prestados
└──────┬──────┘
┌─────────────┐
│ COBRO │ ← Efectivo/Tarjeta
└──────┬──────┘
┌─────────────┐
│ CFDI │ ← Timbrado
└──────┬──────┘
┌─────────────┐
│ ENTREGADO │ ← PDF + XML al paciente
└─────────────┘
COBRO A ASEGURADORA
┌─────────────┐
│ CUENTA │ ← Servicios prestados
└──────┬──────┘
┌─────────────┐
│ EXPEDIENTE │ ← Documentos requeridos
│ RECLAMACIÓN │ (notas, estudios, etc.)
└──────┬──────┘
┌─────────────┐
│ ENVÍO │ ← A la aseguradora
└──────┬──────┘
┌─────────────┐
│ SEGUIMIENTO │ ← Pendiente de pago
└──────┬──────┘
┌─────────────┐
│ COBRADO │ ← Pago recibido
└──────┬──────┘
┌─────────────┐
│ CFDI │ ← Factura a aseguradora
└─────────────┘
```
---
## Cuenta del Paciente
```
┌─────────────────────────────────────────────────────────┐
│ CUENTA - PACIENTE: Juan Pérez │
├─────────────────────────────────────────────────────────┤
│ │
│ SERVICIOS │
│ ┌────────────────────────────────────┬───────────────┐ │
│ │ Concepto │ Importe │ │
│ ├────────────────────────────────────┼───────────────┤ │
│ │ Consulta medicina general │ $800.00 │ │
│ │ Biometría hemática │ $350.00 │ │
│ │ Química sanguínea 6 elementos │ $450.00 │ │
│ │ Paracetamol 500mg x 20 │ $120.00 │ │
│ │ Amoxicilina 500mg x 21 │ $280.00 │ │
│ ├────────────────────────────────────┼───────────────┤ │
│ │ SUBTOTAL │ $2,000.00 │ │
│ │ IVA (16%) │ $0.00 │ │
│ │ ───────────────────────────────────────────────── │ │
│ │ TOTAL │ $2,000.00 │ │
│ └────────────────────────────────────┴───────────────┘ │
│ │
│ COBERTURA SEGURO │
│ ├── Aseguradora: GNP Seguros │
│ ├── Póliza: 1234567 │
│ ├── Cobertura consulta: 100% │
│ ├── Cobertura laboratorio: 80% │
│ └── Copago paciente: $160.00 │
│ │
│ FORMA DE PAGO │
│ ├── Cargo a seguro: $1,840.00 │
│ └── Copago paciente: $160.00 (Pagado TDC) │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Generar cuenta con servicios
- [ ] Cobrar con múltiples formas de pago
- [ ] Facturación CFDI 4.0
- [ ] Facturación a aseguradoras
- [ ] Notas de crédito
- [ ] Portal de pagos
- [ ] Cuentas por cobrar
- [ ] Reportes de ingresos
**No Funcionales:**
- [ ] Timbrado < 5 segundos
- [ ] Historial de 5 años
- [ ] Cumplimiento fiscal
**Tecnicos:**
- [ ] Integración con PAC
- [ ] Integración con todos los módulos
- [ ] Pasarela de pagos
- [ ] Reportes financieros
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-CL-001 Fundamentos | Backlog | Si |
| EPIC-CL-002 Pacientes | Backlog | Si |
| EPIC-CL-003 Citas | Backlog | Parcial |
| EPIC-CL-004 Consultas | Backlog | Parcial |
| EPIC-CL-006 Laboratorio | Backlog | Parcial |
| EPIC-CL-007 Farmacia | Backlog | Parcial |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `billing`
- [ ] Tablas: 8 (accounts, account_items, payments, invoices, invoice_items, insurance_claims, price_lists, services)
- [ ] Funciones: 3 (calculate_account, generate_invoice, process_payment)
- [ ] Indices: Por paciente, fecha, estado, aseguradora
**Backend:**
- [ ] Modulo: `billing`
- [ ] Entities: 7 (Account, AccountItem, Payment, Invoice, InvoiceItem, InsuranceClaim, Service)
- [ ] Endpoints: 15
- [ ] Tests: 30
**Frontend:**
- [ ] Paginas: 5 (Accounts, Checkout, InvoiceList, InsuranceClaims, Reports)
- [ ] Componentes: 12 (AccountSummary, PaymentForm, InvoiceViewer, ClaimTracker, etc.)
- [ ] Stores: 1 (billingStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| GET | /api/billing/accounts/:patientId | Cuenta del paciente |
| POST | /api/billing/accounts/:id/items | Agregar servicio |
| POST | /api/billing/accounts/:id/pay | Registrar pago |
| POST | /api/billing/invoices | Generar factura |
| GET | /api/billing/invoices/:id/pdf | Descargar PDF |
| POST | /api/billing/invoices/:id/cancel | Cancelar factura |
| POST | /api/billing/credit-notes | Crear nota de crédito |
| POST | /api/billing/insurance-claims | Crear reclamación |
| GET | /api/billing/pending | Cuentas por cobrar |
| GET | /api/billing/reports/income | Reporte de ingresos |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Rechazo de aseguradora | Media | Alto | Expediente completo |
| Errores en facturación | Media | Alto | Validaciones antes de timbrar |
| Morosidad | Media | Medio | Seguimiento de cuentas |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Lista de precios definida
- [ ] Convenios con aseguradoras documentados
## Definition of Done (DoD)
- [ ] Flujo de cobro funcionando
- [ ] Facturación CFDI operativa
- [ ] Facturación a aseguradoras
- [ ] Reportes financieros
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,223 @@
# EPICA: EPIC-CL-009 - Reportes
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-CL-009 |
| **Nombre** | Reportes |
| **Modulo** | reportes |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P1 (Alto) |
| **Estado** | Backlog |
| **Story Points** | 25 |
| **Sprint(s)** | Sprint 9-10 |
---
## Descripcion
Dashboard y reportes para gestión clínica. Métricas de productividad médica, ocupación de consultorios, estadísticas de diagnósticos, indicadores financieros y reportes para autoridades sanitarias.
---
## Objetivo de Negocio
- Visibilidad de operaciones
- Medición de productividad
- Toma de decisiones informada
- Cumplimiento de reportes regulatorios
- Identificación de oportunidades
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-CL009-001 | Como director, quiero ver dashboard de consultas del día en tiempo real | P0 | 5 | Backlog |
| US-CL009-002 | Como director, quiero ver productividad por médico (consultas/día) | P0 | 3 | Backlog |
| US-CL009-003 | Como director, quiero ver ocupación de consultorios por hora | P1 | 3 | Backlog |
| US-CL009-004 | Como director, quiero ver top 10 diagnósticos más frecuentes | P1 | 3 | Backlog |
| US-CL009-005 | Como admin, quiero ver reporte de ingresos vs gastos | P0 | 3 | Backlog |
| US-CL009-006 | Como admin, quiero generar reporte para SINBA/SISVER (autoridades) | P0 | 5 | Backlog |
| US-CL009-007 | Como admin, quiero exportar reportes a Excel | P0 | 2 | Backlog |
| US-CL009-008 | Como médico, quiero ver mi resumen de atenciones del mes | P1 | 1 | Backlog |
**Total Story Points:** 25 SP
---
## Dashboard Principal
```
┌─────────────────────────────────────────────────────────┐
│ DASHBOARD CLÍNICA │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ CITAS HOY │ │ CONSULTAS │ │ INGRESOS HOY │ │
│ │ 45 │ │ 38 │ │ $42,300 │ │
│ │ ▲ 12% │ │ ▲ 8% │ │ ▲ 15% │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ PRODUCTIVIDAD POR MÉDICO (HOY) │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Dr. García ████████████████████ 15 consultas │ │
│ │ Dra. López ████████████████ 12 consultas │ │
│ │ Dr. Martínez ██████████ 8 consultas │ │
│ │ Dra. Sánchez ████████ 6 consultas │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ OCUPACIÓN CONSULTORIOS │
│ ┌────────────────────────────────────────────────────┐ │
│ │ 8 9 10 11 12 13 14 15 16 17 18 19 20 │ │
│ │ C-1: ██ ██ ██ ██ ░░ ░░ ██ ██ ██ ██ ██ ░░ ░░ │ │
│ │ C-2: ██ ██ ██ ░░ ░░ ░░ ██ ██ ██ ██ ░░ ░░ ░░ │ │
│ │ C-3: ░░ ██ ██ ██ ██ ░░ ██ ██ ██ ░░ ░░ ░░ ░░ │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ TOP 5 DIAGNÓSTICOS (ESTE MES) │
│ 1. J06.9 - IVAS (185 casos) │
│ 2. I10 - Hipertensión (142 casos) │
│ 3. E11 - Diabetes T2 (98 casos) │
│ 4. K30 - Dispepsia (76 casos) │
│ 5. M54.5 - Lumbalgia (54 casos) │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Reportes Disponibles
```
OPERATIVOS
├── Consultas por período
├── Productividad por médico
├── Ocupación de consultorios
├── Tiempo de espera promedio
├── Ausentismo de pacientes
└── Estudios de laboratorio realizados
CLÍNICOS
├── Diagnósticos más frecuentes
├── Medicamentos más prescritos
├── Estudios más solicitados
└── Pacientes crónicos
FINANCIEROS
├── Ingresos por servicio
├── Ingresos por aseguradora
├── Cuentas por cobrar
├── Ventas de farmacia
└── Rentabilidad por servicio
REGULATORIOS
├── SINBA (notificación epidemiológica)
├── SISVER (vigilancia epidemiológica)
├── Reporte de medicamentos controlados
└── Estadísticas para acreditación
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Dashboard en tiempo real
- [ ] Productividad por médico
- [ ] Ocupación de consultorios
- [ ] Top diagnósticos
- [ ] Reportes financieros
- [ ] Reportes regulatorios
- [ ] Exportación a Excel
**No Funcionales:**
- [ ] Carga de dashboard < 3 segundos
- [ ] Actualización cada 5 minutos
- [ ] Datos históricos de 3 años
**Tecnicos:**
- [ ] Agregación eficiente
- [ ] Caché de métricas
- [ ] Jobs de precálculo
- [ ] Formatos de autoridades
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| Todos los módulos anteriores | Backlog | Si |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `analytics`
- [ ] Tablas: 4 (daily_stats, doctor_metrics, diagnosis_stats, financial_metrics)
- [ ] Vistas materializadas para consultas frecuentes
**Backend:**
- [ ] Modulo: `reports`
- [ ] Services: MetricsAggregator, ReportGenerator
- [ ] Endpoints: 12
- [ ] Jobs: Cálculo de métricas diarias
- [ ] Tests: 20
**Frontend:**
- [ ] Paginas: 3 (Dashboard, Reports, Export)
- [ ] Componentes: 12 (MetricCard, ChartWidget, ReportTable, etc.)
- [ ] Librería: Chart.js
- [ ] Stores: 1 (reportsStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| GET | /api/reports/dashboard | Dashboard principal |
| GET | /api/reports/productivity | Productividad por médico |
| GET | /api/reports/occupancy | Ocupación de consultorios |
| GET | /api/reports/diagnoses | Top diagnósticos |
| GET | /api/reports/financial | Métricas financieras |
| GET | /api/reports/export/:type | Exportar reporte |
| GET | /api/reports/regulatory/:type | Reporte regulatorio |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] KPIs prioritarios definidos
- [ ] Formatos regulatorios obtenidos
## Definition of Done (DoD)
- [ ] Dashboard funcionando
- [ ] Reportes operativos disponibles
- [ ] Exportación funcionando
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,278 @@
# EPICA: EPIC-CL-010 - Telemedicina
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-CL-010 |
| **Nombre** | Telemedicina |
| **Modulo** | telemedicina |
| **Fase** | Fase 2 - Extensión |
| **Prioridad** | P1 (Alto) |
| **Estado** | Backlog |
| **Story Points** | 55 |
| **Sprint(s)** | Sprint 11-14 |
---
## Descripcion
Módulo 100% nuevo para consultas médicas remotas. Videoconsultas con WebRTC, sala de espera virtual, compartir pantalla para resultados, prescripción electrónica a distancia y grabación de consultas con consentimiento.
---
## Objetivo de Negocio
- Ampliar alcance geográfico
- Atención sin desplazamiento
- Seguimiento de crónicos remoto
- Nuevas fuentes de ingreso
- Adaptación post-pandemia
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-CL010-001 | Como paciente, quiero agendar teleconsulta desde el portal | P0 | 5 | Backlog |
| US-CL010-002 | Como paciente, quiero entrar a sala de espera virtual antes de la consulta | P0 | 5 | Backlog |
| US-CL010-003 | Como médico, quiero iniciar videollamada cuando el paciente esté listo | P0 | 8 | Backlog |
| US-CL010-004 | Como médico, quiero compartir pantalla para mostrar resultados al paciente | P0 | 5 | Backlog |
| US-CL010-005 | Como médico, quiero documentar nota clínica durante la videoconsulta | P0 | 3 | Backlog |
| US-CL010-006 | Como médico, quiero generar receta electrónica al finalizar | P0 | 3 | Backlog |
| US-CL010-007 | Como paciente, quiero recibir recordatorio 10 min antes de la consulta | P0 | 3 | Backlog |
| US-CL010-008 | Como paciente, quiero grabar la consulta con consentimiento del médico | P2 | 8 | Backlog |
| US-CL010-009 | Como paciente, quiero enviar fotos de síntomas antes de la consulta | P1 | 5 | Backlog |
| US-CL010-010 | Como médico, quiero terminar la videollamada y cerrar consulta | P0 | 2 | Backlog |
| US-CL010-011 | Como admin, quiero ver reportes de teleconsultas realizadas | P1 | 3 | Backlog |
| US-CL010-012 | Como paciente, quiero evaluar la calidad de la teleconsulta | P2 | 5 | Backlog |
**Total Story Points:** 55 SP
---
## Flujo de Teleconsulta
```
┌─────────────┐
│ AGENDAR │ ← Paciente selecciona teleconsulta
└──────┬──────┘
▼ (-10 min)
┌─────────────┐
│ RECORDATORIO│ ← Email/WhatsApp con link
└──────┬──────┘
┌─────────────┐
│SALA_ESPERA │ ← Paciente espera en sala virtual
└──────┬──────┘
▼ (Médico inicia)
┌─────────────┐
│ VIDEOLLAMADA│ ← WebRTC activo
└──────┬──────┘
├── Chat de texto
├── Compartir pantalla
├── Enviar archivos
┌─────────────┐
│ CERRAR │ ← Médico termina llamada
└──────┬──────┘
┌─────────────┐
│ RECETA │ ← Envío electrónico
│ + NOTA │ ← Documentación
└──────┬──────┘
┌─────────────┐
│ ENCUESTA │ ← Satisfacción del paciente
└─────────────┘
```
---
## Arquitectura WebRTC
```
┌─────────────────────────────────────────────────────────┐
│ ARQUITECTURA TELEMEDICINA │
├─────────────────────────────────────────────────────────┤
│ │
│ PACIENTE MÉDICO │
│ ┌──────────┐ ┌──────────┐ │
│ │ Browser │ │ Browser │ │
│ │ (WebRTC) │ │ (WebRTC) │ │
│ └────┬─────┘ └────┬─────┘ │
│ │ │ │
│ │ ┌──────────────────┐ │ │
│ └────┤ TURN/STUN ├──────┘ │
│ │ Server │ │
│ └────────┬─────────┘ │
│ │ │
│ ┌────────┴─────────┐ │
│ │ Signaling │ │
│ │ Server │ │
│ │ (WebSockets) │ │
│ └────────┬─────────┘ │
│ │ │
│ ┌────────┴─────────┐ │
│ │ Backend API │ │
│ │ (Express) │ │
│ └──────────────────┘ │
│ │
│ CARACTERÍSTICAS: │
│ ├── Video HD (720p/1080p) │
│ ├── Audio bidireccional │
│ ├── Compartir pantalla │
│ ├── Chat de texto │
│ ├── Transferencia de archivos │
│ └── Grabación (opcional) │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Agendar teleconsulta
- [ ] Sala de espera virtual
- [ ] Videollamada WebRTC
- [ ] Compartir pantalla
- [ ] Chat durante consulta
- [ ] Enviar archivos
- [ ] Documentación de consulta
- [ ] Prescripción electrónica
- [ ] Grabación con consentimiento
- [ ] Encuesta de satisfacción
**No Funcionales:**
- [ ] Latencia < 200ms
- [ ] Video HD estable
- [ ] Funciona en móvil y desktop
- [ ] Conexión cifrada (SRTP)
**Tecnicos:**
- [ ] WebRTC con TURN/STUN
- [ ] WebSockets para signaling
- [ ] Integración con consultas
- [ ] Almacenamiento de grabaciones
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-CL-001 Fundamentos | Backlog | Si |
| EPIC-CL-002 Pacientes | Backlog | Si |
| EPIC-CL-003 Citas | Backlog | Si |
| EPIC-CL-004 Consultas | Backlog | Si |
| EPIC-CL-005 Recetas | Backlog | Si |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `telemedicine`
- [ ] Tablas: 6 (teleconsultations, waiting_rooms, recordings, chat_messages, file_shares, satisfaction_surveys)
- [ ] Funciones: 2 (generate_room_token, log_session)
- [ ] Indices: Por médico, paciente, fecha, estado
**Backend:**
- [ ] Modulo: `telemedicine`
- [ ] Entities: 5 (Teleconsultation, WaitingRoom, Recording, ChatMessage, Survey)
- [ ] WebSocket Server para signaling
- [ ] Endpoints: 15
- [ ] Tests: 25
**Frontend:**
- [ ] Paginas: 4 (WaitingRoom, VideoCall, PreCallCheck, PostCallSurvey)
- [ ] Componentes: 15 (VideoPlayer, ScreenShare, ChatBox, FileShare, Controls, etc.)
- [ ] WebRTC implementation
- [ ] Stores: 1 (telemedicineStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /api/telemedicine/sessions | Crear sesión |
| GET | /api/telemedicine/sessions/:id | Estado de sesión |
| POST | /api/telemedicine/sessions/:id/join | Unirse a sala |
| POST | /api/telemedicine/sessions/:id/signal | Señalización WebRTC |
| POST | /api/telemedicine/sessions/:id/end | Terminar llamada |
| POST | /api/telemedicine/sessions/:id/chat | Enviar mensaje |
| POST | /api/telemedicine/sessions/:id/files | Subir archivo |
| POST | /api/telemedicine/sessions/:id/record | Iniciar grabación |
| POST | /api/telemedicine/sessions/:id/survey | Enviar encuesta |
---
## Integraciones Externas
| Servicio | Propósito | Alternativas |
|----------|-----------|--------------|
| Twilio | TURN/STUN + Video | Daily.co, Vonage |
| AWS S3 | Almacenamiento de grabaciones | GCP, Azure |
| WebRTC nativo | Comunicación P2P | - |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Conexión inestable | Media | Alto | Reconexión automática |
| Problemas de audio/video | Media | Alto | Pre-call check |
| Privacidad de grabaciones | Baja | Alto | Encriptación + RBAC |
---
## Nota Técnica
Este módulo es **100% nuevo** y no tiene equivalente en el ERP-Core. Requiere infraestructura especializada para streaming de video y cumplimiento de regulaciones de datos médicos.
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Proveedor de video seleccionado
- [ ] Infraestructura TURN/STUN lista
## Definition of Done (DoD)
- [ ] Videollamada funcionando
- [ ] Sala de espera operativa
- [ ] Integración con consultas
- [ ] Grabación opcional
- [ ] Tests E2E pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,241 @@
# EPICA: EPIC-CL-011 - Expediente Clínico Electrónico
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-CL-011 |
| **Nombre** | Expediente Clínico Electrónico |
| **Modulo** | expediente |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P0 (Critico) |
| **Estado** | Backlog |
| **Story Points** | 30 |
| **Sprint(s)** | Sprint 10 |
---
## Descripcion
Vista consolidada del expediente clínico electrónico del paciente. Integra toda la información médica: datos personales, antecedentes, consultas, diagnósticos, recetas, estudios de laboratorio e imagen. Cumple con NOM-024-SSA3-2012.
---
## Objetivo de Negocio
- Historia clínica completa
- Cumplimiento normativo
- Acceso rápido a información
- Continuidad de atención
- Soporte a decisiones clínicas
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-CL011-001 | Como médico, quiero ver resumen ejecutivo del paciente en una pantalla | P0 | 5 | Backlog |
| US-CL011-002 | Como médico, quiero ver línea de tiempo de atenciones | P0 | 5 | Backlog |
| US-CL011-003 | Como médico, quiero ver todos los diagnósticos históricos | P0 | 3 | Backlog |
| US-CL011-004 | Como médico, quiero ver todos los medicamentos recetados | P0 | 3 | Backlog |
| US-CL011-005 | Como médico, quiero ver resultados de laboratorio con gráficas de tendencia | P0 | 5 | Backlog |
| US-CL011-006 | Como médico, quiero ver estudios de imagen (DICOM viewer) | P1 | 5 | Backlog |
| US-CL011-007 | Como paciente, quiero descargar mi expediente completo en PDF | P1 | 2 | Backlog |
| US-CL011-008 | Como admin, quiero configurar permisos de acceso al expediente | P0 | 2 | Backlog |
**Total Story Points:** 30 SP
---
## Estructura del Expediente (NOM-024)
```
┌─────────────────────────────────────────────────────────┐
│ EXPEDIENTE CLÍNICO ELECTRÓNICO │
├─────────────────────────────────────────────────────────┤
│ │
│ DATOS DE IDENTIFICACIÓN │
│ ├── Nombre completo │
│ ├── Fecha de nacimiento / Edad │
│ ├── Sexo │
│ ├── CURP │
│ └── Datos de contacto │
│ │
│ ANTECEDENTES │
│ ├── Heredo-familiares │
│ ├── Personales no patológicos │
│ ├── Personales patológicos │
│ ├── Gineco-obstétricos (si aplica) │
│ └── Alergias │
│ │
│ NOTAS MÉDICAS │
│ ├── Historia clínica inicial │
│ ├── Notas de evolución │
│ ├── Notas de interconsulta │
│ └── Notas de egreso │
│ │
│ ESTUDIOS │
│ ├── Laboratorio │
│ │ ├── Resultados │
│ │ └── Gráficas de tendencia │
│ └── Imagenología │
│ ├── Radiografías │
│ ├── Ultrasonidos │
│ └── Tomografías/Resonancias │
│ │
│ PRESCRIPCIONES │
│ ├── Recetas emitidas │
│ └── Medicamentos actuales │
│ │
│ CONSENTIMIENTOS │
│ └── Firmados digitalmente │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Vista de Timeline
```
┌─────────────────────────────────────────────────────────┐
│ LÍNEA DE TIEMPO - JUAN PÉREZ │
├─────────────────────────────────────────────────────────┤
│ │
│ DIC 2024 │
│ ├── 08 │ 💊 Receta - Antibiótico 7 días │
│ ├── 08 │ 🩺 Consulta - Dr. García (IVAS) │
│ ├── 05 │ 🧪 Laboratorio - Biometría hemática │
│ │ │
│ NOV 2024 │
│ ├── 22 │ 💊 Receta - Antihipertensivos │
│ ├── 22 │ 🩺 Consulta - Dr. López (Control HTA) │
│ ├── 15 │ 🧪 Laboratorio - Química sanguínea │
│ │ │
│ OCT 2024 │
│ ├── 10 │ 📷 Imagen - Rx Tórax │
│ ├── 10 │ 🩺 Consulta - Dr. García (Tos crónica) │
│ │ │
│ SEP 2024 │
│ ├── 05 │ 🩺 Primera consulta - Historia clínica │
│ └── 05 │ ✍️ Consentimiento informado firmado │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Resumen ejecutivo del paciente
- [ ] Línea de tiempo de atenciones
- [ ] Vista de diagnósticos históricos
- [ ] Vista de medicamentos
- [ ] Gráficas de laboratorio
- [ ] Visor DICOM básico
- [ ] Exportar expediente PDF
- [ ] Control de acceso
**No Funcionales:**
- [ ] Carga de expediente < 3 segundos
- [ ] Cumplimiento NOM-024-SSA3-2012
- [ ] Auditoría de accesos
**Tecnicos:**
- [ ] Integración de todos los módulos
- [ ] Visor DICOM (Cornerstone.js)
- [ ] Generación de PDF estructurado
- [ ] Gráficas con Chart.js
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-CL-002 Pacientes | Backlog | Si |
| EPIC-CL-004 Consultas | Backlog | Si |
| EPIC-CL-005 Recetas | Backlog | Si |
| EPIC-CL-006 Laboratorio | Backlog | Si |
| EPIC-CL-012 Imagenología | Backlog | Parcial |
---
## Desglose Tecnico
**Database:**
- [ ] No requiere tablas nuevas (agrega datos de otros módulos)
- [ ] Vistas optimizadas para consolidación
**Backend:**
- [ ] Modulo: `medical-record`
- [ ] Services: RecordAggregator, PDFExporter
- [ ] Endpoints: 8
- [ ] Tests: 20
**Frontend:**
- [ ] Paginas: 3 (RecordOverview, Timeline, Export)
- [ ] Componentes: 15 (SummaryCard, Timeline, DiagnosisHistory, LabTrends, DICOMViewer, etc.)
- [ ] Visor DICOM con Cornerstone.js
- [ ] Stores: 1 (recordStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| GET | /api/medical-record/:patientId | Expediente completo |
| GET | /api/medical-record/:patientId/summary | Resumen ejecutivo |
| GET | /api/medical-record/:patientId/timeline | Línea de tiempo |
| GET | /api/medical-record/:patientId/diagnoses | Historial de diagnósticos |
| GET | /api/medical-record/:patientId/medications | Historial de medicamentos |
| GET | /api/medical-record/:patientId/labs/trends | Tendencias de laboratorio |
| GET | /api/medical-record/:patientId/export | Exportar PDF |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Expediente incompleto | Media | Alto | Validar datos mínimos |
| Acceso no autorizado | Baja | Alto | RBAC + auditoría |
| Carga lenta | Media | Medio | Paginación + caché |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Estructura NOM-024 documentada
- [ ] Diseño de UI aprobado
## Definition of Done (DoD)
- [ ] Vista consolidada funcionando
- [ ] Timeline operativo
- [ ] Visor DICOM básico
- [ ] Exportación PDF
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,314 @@
# EPICA: EPIC-CL-012 - Imagenología
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-CL-012 |
| **Nombre** | Imagenología |
| **Modulo** | imagenologia |
| **Fase** | Fase 2 - Extensión |
| **Prioridad** | P1 (Alto) |
| **Estado** | Backlog |
| **Story Points** | 55 |
| **Sprint(s)** | Sprint 15-18 |
---
## Descripcion
Módulo 100% nuevo para gestión de estudios de imagen médica. Solicitud de estudios, integración con equipos de imagen, almacenamiento y visor DICOM, interpretación por radiólogo y entrega de resultados.
---
## Objetivo de Negocio
- Estudios de imagen integrados
- Almacenamiento centralizado (PACS)
- Interpretación oportuna
- Reducción de pérdida de estudios
- Acceso remoto a imágenes
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-CL012-001 | Como médico, quiero solicitar estudio de imagen desde la consulta | P0 | 5 | Backlog |
| US-CL012-002 | Como técnico, quiero ver órdenes de estudios pendientes | P0 | 3 | Backlog |
| US-CL012-003 | Como técnico, quiero registrar realización de estudio | P0 | 3 | Backlog |
| US-CL012-004 | Como sistema, quiero recibir imágenes DICOM del equipo | P0 | 13 | Backlog |
| US-CL012-005 | Como radiólogo, quiero ver estudios pendientes de interpretar | P0 | 3 | Backlog |
| US-CL012-006 | Como radiólogo, quiero ver imágenes en visor DICOM profesional | P0 | 8 | Backlog |
| US-CL012-007 | Como radiólogo, quiero dictar interpretación del estudio | P0 | 5 | Backlog |
| US-CL012-008 | Como médico, quiero recibir notificación cuando el estudio esté listo | P0 | 3 | Backlog |
| US-CL012-009 | Como paciente, quiero descargar mis estudios de imagen | P1 | 5 | Backlog |
| US-CL012-010 | Como admin, quiero configurar modalidades de imagen disponibles | P0 | 3 | Backlog |
| US-CL012-011 | Como admin, quiero ver reportes de estudios realizados | P1 | 4 | Backlog |
**Total Story Points:** 55 SP
---
## Flujo de Imagenología
```
┌─────────────┐
│ SOLICITUD │ ← Médico solicita estudio
└──────┬──────┘
┌─────────────┐
│ RECEPCIÓN │ ← Paciente llega
└──────┬──────┘
┌─────────────┐
│ REALIZACIÓN │ ← Técnico realiza estudio
└──────┬──────┘
┌─────────────┐
│ DICOM │ ← Imágenes enviadas al PACS
│ UPLOAD │
└──────┬──────┘
┌─────────────┐
│INTERPRETAC. │ ← Radiólogo analiza
└──────┬──────┘
┌─────────────┐
│ LIBERADO │ ← Disponible para médico/paciente
└─────────────┘
```
---
## Arquitectura DICOM/PACS
```
┌─────────────────────────────────────────────────────────┐
│ ARQUITECTURA IMAGENOLOGÍA │
├─────────────────────────────────────────────────────────┤
│ │
│ EQUIPOS DE IMAGEN PACS SERVER │
│ ┌───────────────┐ ┌─────────────────┐ │
│ │ Rayos X │ ──────► │ │ │
│ │ (DICOM) │ │ Orthanc / │ │
│ └───────────────┘ │ DCM4CHEE │ │
│ ┌───────────────┐ │ │ │
│ │ Ultrasonido │ ──────► │ DICOM Store │ │
│ │ (DICOM) │ │ DICOM Query │ │
│ └───────────────┘ │ DICOM Retrieve │ │
│ ┌───────────────┐ │ │ │
│ │ Tomografía │ ──────► │ │ │
│ │ (DICOM) │ └────────┬────────┘ │
│ └───────────────┘ │ │
│ │ │
│ ┌────────┴────────┐ │
│ │ Backend API │ │
│ │ (Express) │ │
│ └────────┬────────┘ │
│ │ │
│ ┌────────┴────────┐ │
│ │ Visor DICOM │ │
│ │ (Cornerstone) │ │
│ └─────────────────┘ │
│ │
│ ESTÁNDARES: │
│ ├── DICOM 3.0 para imágenes │
│ ├── HL7 para integraciones │
│ ├── IHE XDS-I.b para compartir imágenes │
│ └── WADO-RS para acceso web │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Modalidades de Imagen
```
┌─────────────────────────────────────────────────────────┐
│ MODALIDADES SOPORTADAS │
├─────────────────────────────────────────────────────────┤
│ │
│ CR/DR - Radiología Computarizada/Digital │
│ ├── Rayos X de tórax │
│ ├── Rayos X de abdomen │
│ ├── Rayos X de extremidades │
│ └── Rayos X de columna │
│ │
│ US - Ultrasonido │
│ ├── Abdominal │
│ ├── Pélvico │
│ ├── Obstétrico │
│ └── Musculoesquelético │
│ │
│ CT - Tomografía Computarizada │
│ ├── Cráneo │
│ ├── Tórax │
│ ├── Abdomen │
│ └── Columna │
│ │
│ MR - Resonancia Magnética │
│ ├── Cerebro │
│ ├── Columna │
│ └── Articulaciones │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Solicitar estudios de imagen
- [ ] Ver órdenes pendientes
- [ ] Registrar realización
- [ ] Recibir imágenes DICOM
- [ ] Visor DICOM profesional
- [ ] Interpretación por radiólogo
- [ ] Notificación de resultados
- [ ] Descarga de estudios
- [ ] Reportes de producción
**No Funcionales:**
- [ ] Carga de imágenes < 5 segundos
- [ ] Almacenamiento de 5+ años
- [ ] Cumplimiento DICOM 3.0
**Tecnicos:**
- [ ] Servidor PACS (Orthanc)
- [ ] Visor Cornerstone.js
- [ ] Integración con consultas
- [ ] Almacenamiento escalable
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-CL-001 Fundamentos | Backlog | Si |
| EPIC-CL-002 Pacientes | Backlog | Si |
| EPIC-CL-004 Consultas | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-CL-011 Expediente | Imágenes son parte del expediente |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `imaging`
- [ ] Tablas: 7 (imaging_orders, order_items, studies, series, interpretations, modalities, pacs_log)
- [ ] Funciones: 2 (log_dicom_event, update_study_status)
- [ ] Indices: Por paciente, médico, fecha, modalidad, estado
**Backend:**
- [ ] Modulo: `imaging`
- [ ] Entities: 6 (ImagingOrder, OrderItem, Study, Series, Interpretation, Modality)
- [ ] DICOM Service: Comunicación con PACS
- [ ] Endpoints: 15
- [ ] Tests: 30
**Frontend:**
- [ ] Paginas: 5 (ImagingOrders, Worklist, DICOMViewer, Interpretation, Reports)
- [ ] Componentes: 15 (OrderCard, StudyThumbnail, ViewerTools, InterpretationEditor, etc.)
- [ ] Cornerstone.js para visor DICOM
- [ ] Stores: 1 (imagingStore)
**Infraestructura:**
- [ ] Orthanc PACS Server
- [ ] Almacenamiento S3/MinIO para imágenes
- [ ] CDN para distribución
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /api/imaging/orders | Crear orden de estudio |
| GET | /api/imaging/orders | Listar órdenes |
| GET | /api/imaging/orders/:id | Detalle de orden |
| POST | /api/imaging/orders/:id/perform | Registrar realización |
| GET | /api/imaging/studies/:id | Metadatos del estudio |
| GET | /api/imaging/studies/:id/series | Series del estudio |
| GET | /api/imaging/wado-rs/* | WADO-RS para imágenes |
| POST | /api/imaging/interpretations | Crear interpretación |
| GET | /api/imaging/worklist | Lista de trabajo radiólogo |
---
## Integraciones DICOM
| Operación | Protocolo | Uso |
|-----------|-----------|-----|
| C-STORE | DICOM | Recibir imágenes de equipos |
| C-FIND | DICOM | Buscar estudios |
| C-MOVE | DICOM | Recuperar estudios |
| WADO-RS | HTTP | Acceso web a imágenes |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Integración DICOM compleja | Alta | Alto | PACS probado (Orthanc) |
| Almacenamiento costoso | Media | Medio | Compresión + tiering |
| Visor lento | Media | Medio | Streaming progresivo |
---
## Nota Técnica
Este módulo es **100% nuevo** y requiere infraestructura especializada:
- Servidor PACS compatible DICOM 3.0
- Almacenamiento de gran capacidad para imágenes
- Visor web profesional (Cornerstone.js)
- Conocimiento de estándares médicos (DICOM, HL7, IHE)
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] PACS Server seleccionado
- [ ] Equipos DICOM compatibles
## Definition of Done (DoD)
- [ ] Flujo completo de imagenología
- [ ] Recepción DICOM funcionando
- [ ] Visor profesional operativo
- [ ] Interpretación de estudios
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,138 @@
# Herencia SIMCO - ERP Clínicas
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Fecha:** 2025-12-08
---
## Configuración del Proyecto
| Propiedad | Valor |
|-----------|-------|
| **Proyecto** | ERP Clínicas - Vertical para Clínicas/Consultorios |
| **Nivel** | VERTICAL (Nivel 3) |
| **Padre** | erp-core |
| **Suite** | erp-suite |
| **SIMCO Version** | 2.2.0 |
| **CAPVED** | Habilitado |
| **CCA Protocol** | Habilitado |
| **Estado** | 0% - Futuro |
## Jerarquía de Herencia
```
Nivel 0: core/orchestration/ ← FUENTE PRINCIPAL
└── Nivel 1: erp-suite/orchestration/
└── Nivel 2: erp-core/orchestration/ ← PADRE DIRECTO
└── Nivel 3: clinicas/orchestration/ ← ESTE PROYECTO
```
---
## Directivas Heredadas de CORE (OBLIGATORIAS)
### Ciclo de Vida
| Alias | Propósito |
|-------|-----------|
| `@TAREA` | Punto de entrada para toda HU |
| `@CAPVED` | Ciclo de 6 fases |
| `@INICIALIZACION` | Bootstrap de agentes |
### Operaciones Universales
| Alias | Propósito |
|-------|-----------|
| `@CREAR` | Crear archivos nuevos |
| `@MODIFICAR` | Modificar existentes |
| `@VALIDAR` | Validar código |
| `@DOCUMENTAR` | Documentar trabajo |
| `@BUSCAR` | Buscar información |
| `@DELEGAR` | Delegar a subagentes |
### Principios Fundamentales
| Alias | Resumen |
|-------|---------|
| `@CAPVED` | Toda tarea pasa por 6 fases |
| `@DOC_PRIMERO` | Consultar docs/ antes de implementar |
| `@ANTI_DUP` | Verificar que no existe |
| `@VALIDACION` | Build y lint DEBEN pasar |
| `@TOKENS` | Desglosar tareas grandes |
---
## Directivas por Dominio Técnico
| Alias | Aplica | Notas |
|-------|--------|-------|
| `@OP_DDL` | **SÍ** | Schemas de salud (HIPAA-ready) |
| `@OP_BACKEND` | **SÍ** | Servicios de citas, expediente |
| `@OP_FRONTEND` | **SÍ** | UI de consultorio |
| `@OP_MOBILE` | **SÍ** | App de pacientes |
| `@OP_ML` | Futuro | Análisis de diagnósticos |
---
## Patrones Heredados (OBLIGATORIOS)
Todos los patrones de `core/orchestration/patrones/` aplican.
**IMPORTANTE:** `@PATRON-SEGURIDAD` es crítico para datos de salud.
---
## Directivas Heredadas de ERP Core
| Directiva | Extensión Local |
|-----------|-----------------|
| `DIRECTIVA-MULTI-TENANT.md` | Por `clinica_id` |
| `DIRECTIVA-EXTENSION-VERTICALES.md` | Módulos de salud |
---
## Variables de Contexto CCA
```yaml
PROJECT_NAME: "clinicas"
PROJECT_LEVEL: "VERTICAL"
PROJECT_ROOT: "/home/isem/workspace/projects/erp-suite/apps/verticales/clinicas"
PARENT_PROJECT: "erp-core"
SUITE_PROJECT: "erp-suite"
DB_DDL_PATH: "database/ddl"
BACKEND_ROOT: "backend/src"
FRONTEND_ROOT: "frontend/src"
TENANT_COLUMN: "clinica_id"
RLS_CONTEXT: "app.current_clinica_id"
# Compliance
HIPAA_READY: true
DATA_ENCRYPTION: "AES-256"
```
---
## Módulos Específicos de Clínicas (Por definir)
| Módulo | Descripción | Estado |
|--------|-------------|--------|
| CLI-CIT | Citas/agenda | Por definir |
| CLI-PAC | Pacientes | Por definir |
| CLI-EXP | Expediente clínico | Por definir |
| CLI-REC | Recetas | Por definir |
| CLI-FAC | Facturación médica | Por definir |
| CLI-LAB | Laboratorio | Por definir |
---
## Consideraciones de Seguridad (CRÍTICAS)
- Datos sensibles de salud requieren encriptación
- Cumplimiento con regulaciones de privacidad
- Auditoría detallada de accesos
- Consentimiento informado digital
---
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Nivel:** VERTICAL (3)
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,122 @@
# Próxima Acción - ERP Clínicas
## Estado Actual
**Fecha:** Diciembre 2025
**Progreso:** 20% (Planificación completa)
---
## Documentación Disponible
### Módulos Definidos (12 módulos - 395 SP)
| Módulo | Nombre | SP | Estado |
|--------|--------|---:|--------|
| CL-001 | Fundamentos | 0 | PLANIFICADO |
| CL-002 | Pacientes | 34 | PLANIFICADO |
| CL-003 | Citas | 42 | PLANIFICADO |
| CL-004 | Consultas | 47 | PLANIFICADO |
| CL-005 | Recetas | 34 | PLANIFICADO |
| CL-006 | Laboratorio | 42 | PLANIFICADO |
| CL-007 | Farmacia | 34 | PLANIFICADO |
| CL-008 | Facturación | 21 | PLANIFICADO |
| CL-009 | Reportes | 34 | PLANIFICADO |
| CL-010 | Telemedicina | 47 | PLANIFICADO |
| CL-011 | Expediente | 39 | PLANIFICADO |
| CL-012 | Imagenología | 21 | PLANIFICADO |
### Documentos de Referencia
- Visión: `docs/00-vision-general/VISION-CLINICAS.md`
- Módulos: `docs/02-definicion-modulos/INDICE-MODULOS.md`
- Herencia SPECS: `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
- Inventario: `orchestration/inventarios/MASTER_INVENTORY.yml`
---
## Prerrequisitos
Este proyecto requiere que **erp-core** esté completado primero:
- [ ] Módulo auth de erp-core (para 2FA)
- [ ] Módulo users de erp-core
- [ ] Módulo tenants de erp-core
- [ ] Módulo inventory base de erp-core (farmacia)
- [ ] CFDI de erp-core
---
## Cumplimiento Normativo
### NOM-024-SSA3-2012 (Expediente Clínico)
- Estructura SOAP para notas clínicas
- Campos obligatorios de historia clínica
- Consentimiento informado
- Firma electrónica de recetas
### LFPDPPP (Protección de Datos)
- Encriptación de datos sensibles
- Consentimiento de tratamiento
- Auditoría de accesos
- Derecho de acceso del paciente
---
## Tarea Prioritaria (Cuando esté listo)
### 1. Crear DDL del Schema Clinical
**Objetivo:** Definir estructura de base de datos para expediente clínico.
**Tablas a crear:**
- `clinical.patients`
- `clinical.patient_contacts`
- `clinical.patient_insurance`
- `clinical.appointments`
- `clinical.consultations`
- `clinical.diagnoses`
**Archivo destino:** `database/ddl/01-clinical-schema.sql`
### 2. Implementar Extensión 2FA
**Objetivo:** 2FA obligatorio para personal médico.
**Referencia:** Ver `erp-core/docs/04-modelado/especificaciones-tecnicas/transversal/SPEC-TWO-FACTOR-AUTHENTICATION.md`
---
## Consideraciones Especiales
1. **Seguridad:** 2FA obligatorio para personal médico
2. **Encriptación:** Datos sensibles (antecedentes, alergias)
3. **Auditoría:** Log de accesos a expedientes
4. **Integración:** HL7/FHIR para interoperabilidad
---
## Ambiente de Desarrollo
Según `DEVENV-PORTS.md`:
```yaml
proyecto: clinicas
rango_base: 3500
puertos:
backend: 3500
frontend: 5178
database: 5437
redis: 6384
```
---
## Próximos Pasos
1. [ ] Esperar completitud de erp-core (auth con 2FA, users, tenants)
2. [ ] Validar cumplimiento NOM-024-SSA3-2012
3. [ ] Diseñar arquitectura de encriptación
4. [ ] Crear DDL schema clinical
5. [ ] Iniciar backend CL-001 (heredar de core + 2FA)
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,262 @@
# =============================================================================
# PROJECT-ENV-CONFIG.yml - ERP CLINICAS
# =============================================================================
# Vertical de ERP-Suite especializada en Clínicas y Consultorios Médicos
# Actualizado: 2025-12-08
# Referencia: ~/workspace/core/devtools/environment/DEVENV-PORTS.md
# =============================================================================
project:
name: "ERP-CLINICAS"
code: "CL"
description: "Sistema para Clínicas y Consultorios con Cumplimiento NOM-024"
type: "vertical"
level: "2B.2"
status: "planning"
parent: "erp-suite"
paths:
root: "/home/isem/workspace/projects/erp-suite/apps/verticales/clinicas"
backend: "backend/"
frontend: "frontend/"
database: "database/"
docs: "docs/"
orchestration: "orchestration/"
# =============================================================================
# PUERTOS (Según DEVENV-PORTS.md)
# =============================================================================
ports:
backend: 3500
frontend: 5178
database: 5437
redis: 6384
# =============================================================================
# BASE DE DATOS
# =============================================================================
database:
type: "postgresql"
host: "localhost"
port: 5437
name: "clinicas_db"
user: "clinicas_user"
schemas:
core_inherited: 12 # Schemas heredados de erp-core
vertical_specific:
- clinical # Pacientes, citas, consultas, expediente
- pharmacy # Stock medicamentos, dispensaciones
- laboratory # Órdenes lab, resultados
- imaging # Estudios DICOM, metadatos
- telemedicine # Sesiones video, grabaciones
encryption:
enabled: true
algorithm: "AES-256"
encrypted_fields:
- antecedentes_medicos
- alergias
- diagnosticos
- notas_clinicas
migration:
tool: "typeorm"
directory: "database/migrations/"
# =============================================================================
# STACK TECNOLOGICO
# =============================================================================
stack:
runtime: "Node.js 20+"
language: "TypeScript 5.3+"
backend:
framework: "Express.js"
orm: "TypeORM 0.3.17"
encryption: "AES-256"
frontend:
framework: "React 18"
build: "Vite"
ui: "Tailwind CSS + shadcn/ui"
auth:
base: "JWT + bcryptjs"
extension: "2FA obligatorio para personal médico"
# =============================================================================
# HERENCIA DEL CORE
# =============================================================================
core_inheritance:
version: "0.6.0"
tables_inherited: 97
modules_inherited:
- auth # + extensión 2FA
- users
- roles
- tenants
- inventory # Para farmacia
- cfdi
specs_applicable: 6
specs_implemented: 0
specs_detail:
- SPEC-INTEGRACION-CALENDAR
- SPEC-MAIL-THREAD-TRACKING
- SPEC-TRAZABILIDAD-LOTES-SERIES
- SPEC-FACTURACION-CFDI
- SPEC-TWO-FACTOR-AUTHENTICATION
- SPEC-RRHH-EVALUACIONES-SKILLS
# =============================================================================
# MODULOS DE LA VERTICAL
# =============================================================================
modules:
total: 12
story_points: 395
list:
- code: CL-001
name: Fundamentos
sp: 0
priority: P0
status: pending
compliance: LFPDPPP
- code: CL-002
name: Pacientes
sp: 34
priority: P0
status: pending
compliance: LFPDPPP
- code: CL-003
name: Citas
sp: 42
priority: P0
status: pending
- code: CL-004
name: Consultas SOAP
sp: 47
priority: P0
status: pending
compliance: NOM-024
- code: CL-005
name: Recetas
sp: 34
priority: P0
status: pending
compliance: NOM-024
- code: CL-006
name: Laboratorio
sp: 42
priority: P1
status: pending
- code: CL-007
name: Farmacia
sp: 34
priority: P1
status: pending
- code: CL-008
name: Facturación CFDI
sp: 21
priority: P0
status: pending
- code: CL-009
name: Reportes
sp: 34
priority: P1
status: pending
- code: CL-010
name: Telemedicina
sp: 47
priority: P2
status: pending
- code: CL-011
name: Expediente NOM-024
sp: 39
priority: P0
status: pending
compliance: NOM-024
- code: CL-012
name: Imagenología DICOM
sp: 21
priority: P2
status: pending
# =============================================================================
# CUMPLIMIENTO NORMATIVO
# =============================================================================
compliance:
nom_024_ssa3_2012:
name: "Expediente Clínico Electrónico"
requirements:
- estructura_soap: "Subjetivo, Objetivo, Análisis, Plan"
- campos_obligatorios:
- identificacion_paciente
- fecha_consulta
- motivo_consulta
- exploracion_fisica
- diagnostico_cie10
- plan_tratamiento
- firma_electronica: "Requerida en recetas"
- consentimiento_informado: "Documentado"
lfpdppp:
name: "Ley Federal de Protección de Datos Personales"
requirements:
- encriptacion: "AES-256 para datos sensibles"
- auditoria: "Log de accesos a expedientes"
- consentimiento: "Tratamiento de datos"
- derecho_acceso: "Portal de paciente"
# =============================================================================
# SEGURIDAD ESPECIAL
# =============================================================================
security:
two_factor_auth:
required_for: "medical_staff"
methods: ["TOTP", "SMS"]
data_encryption:
algorithm: "AES-256"
key_rotation: "quarterly"
audit_logging:
enabled: true
events:
- medical_record_access
- prescription_created
- patient_data_modified
- consent_updated
retention: "10 years" # Requerimiento NOM-024
# =============================================================================
# ARCHIVOS DE ENTORNO
# =============================================================================
env_files:
template: "orchestration/environment/.env.example"
backend: "backend/.env"
frontend: "frontend/.env"
env_variables:
required:
- NODE_ENV
- PORT
- DATABASE_URL
- JWT_SECRET
- REDIS_URL
- ENCRYPTION_KEY # Para AES-256
- TWILIO_SID # Para 2FA SMS
- TWILIO_AUTH_TOKEN
optional:
- LOG_LEVEL
- CORS_ORIGIN
- HL7_ENDPOINT # Interoperabilidad
# =============================================================================
# NOTAS
# =============================================================================
notes: |
- Vertical especializada en sector salud
- CRITICO: Cumplimiento NOM-024-SSA3-2012 (expediente clínico)
- CRITICO: Cumplimiento LFPDPPP (protección de datos)
- 2FA OBLIGATORIO para personal médico
- Encriptación AES-256 para datos sensibles
- Auditoría de accesos con retención 10 años
- Puertos asignados según DEVENV-PORTS.md (rango 3500)

View File

@ -3,90 +3,203 @@
# Sistema: NEXUS + SIMCO v2.2.0
proyecto:
nombre: ERP Clinicas
codigo: clinicas
nombre: ERP Clínicas
codigo: CL
nivel: 2B.2 (Vertical)
estado: Planificacion
version: 0.1.0
estado: EPICAS_COMPLETAS
version: 0.3.0
path: /home/isem/workspace/projects/erp-suite/apps/verticales/clinicas
herencia:
- erp-core (60-70% funcionalidad base)
- core (directivas globales)
core_version: "0.6.0"
tablas_heredadas: 97
specs_aplicables: 22
specs_implementadas: 0
resumen_general:
total_schemas: 0
total_tablas: 0
total_modulos: 12
total_schemas_planificados: 4
total_tablas_planificadas: 45
total_servicios_backend: 0
total_componentes_frontend: 0
story_points_estimados: 451
test_coverage: N/A
ultima_actualizacion: 2025-12-08
modulos_planificados:
- codigo: CL-001
nombre: Pacientes
descripcion: Registro y gestion de pacientes
prioridad: Alta
estado: No iniciado
modulos:
total: 12
lista:
- codigo: CL-001
nombre: Fundamentos
descripcion: Auth con 2FA obligatorio, seguridad médica
herencia: 90%
prioridad: P0
estado: PLANIFICADO
sp: 0
- codigo: CL-002
nombre: Citas
descripcion: Agenda y citas
prioridad: Alta
estado: No iniciado
- codigo: CL-002
nombre: Pacientes
descripcion: Registro y expediente básico
herencia: 40%
prioridad: P0
estado: EPICA_COMPLETA
sp: 38
epica: docs/08-epicas/EPIC-CL-002-pacientes.md
- codigo: CL-003
nombre: Expediente Clinico
descripcion: Historial medico electronico
prioridad: Alta
estado: No iniciado
- codigo: CL-003
nombre: Citas
descripcion: Agenda médica con recordatorios
herencia: 30%
prioridad: P0
estado: EPICA_COMPLETA
sp: 42
epica: docs/08-epicas/EPIC-CL-003-citas.md
- codigo: CL-004
nombre: Servicios
descripcion: Catalogo de servicios medicos
prioridad: Media
estado: No iniciado
- codigo: CL-004
nombre: Consultas
descripcion: Registro de consultas y SOAP
herencia: 0%
prioridad: P0
estado: EPICA_COMPLETA
sp: 55
epica: docs/08-epicas/EPIC-CL-004-consultas.md
- codigo: CL-005
nombre: Facturacion
descripcion: Facturacion y pagos
prioridad: Media
estado: No iniciado
- codigo: CL-005
nombre: Recetas
descripcion: Prescripciones y medicamentos
herencia: 20%
prioridad: P0
estado: EPICA_COMPLETA
sp: 35
epica: docs/08-epicas/EPIC-CL-005-recetas.md
- codigo: CL-006
nombre: Reportes
descripcion: Reportes medicos y administrativos
prioridad: Media
estado: No iniciado
- codigo: CL-006
nombre: Laboratorio
descripcion: Órdenes y resultados
herencia: 10%
prioridad: P1
estado: EPICA_COMPLETA
sp: 38
epica: docs/08-epicas/EPIC-CL-006-laboratorio.md
- codigo: CL-007
nombre: Farmacia
descripcion: Inventario de medicamentos
herencia: 60%
prioridad: P1
estado: EPICA_COMPLETA
sp: 40
epica: docs/08-epicas/EPIC-CL-007-farmacia.md
- codigo: CL-008
nombre: Facturacion
descripcion: CFDI servicios médicos
herencia: 70%
prioridad: P0
estado: EPICA_COMPLETA
sp: 38
epica: docs/08-epicas/EPIC-CL-008-facturacion.md
- codigo: CL-009
nombre: Reportes
descripcion: Estadísticas clínicas
herencia: 40%
prioridad: P1
estado: EPICA_COMPLETA
sp: 25
epica: docs/08-epicas/EPIC-CL-009-reportes.md
- codigo: CL-010
nombre: Telemedicina
descripcion: Videoconsultas remotas
herencia: 0%
prioridad: P2
estado: EPICA_COMPLETA
sp: 55
epica: docs/08-epicas/EPIC-CL-010-telemedicina.md
- codigo: CL-011
nombre: Expediente
descripcion: Historia clínica NOM-024
herencia: 10%
prioridad: P0
estado: EPICA_COMPLETA
sp: 30
epica: docs/08-epicas/EPIC-CL-011-expediente.md
- codigo: CL-012
nombre: Imagenologia
descripcion: Visor DICOM y estudios
herencia: 0%
prioridad: P2
estado: EPICA_COMPLETA
sp: 55
epica: docs/08-epicas/EPIC-CL-012-imagenologia.md
specs_core:
aplicables: 22
implementadas: 0
por_implementar: 22
documento: orchestration/00-guidelines/HERENCIA-SPECS-CORE.md
detalle:
- spec: SPEC-SISTEMA-SECUENCIAS
estado: PENDIENTE
- spec: SPEC-SEGURIDAD-API-KEYS-PERMISOS
estado: PENDIENTE
- spec: SPEC-TRAZABILIDAD-LOTES-SERIES
estado: PENDIENTE
- spec: SPEC-MAIL-THREAD-TRACKING
estado: PENDIENTE
- spec: SPEC-RRHH-EVALUACIONES
estado: PENDIENTE
- spec: SPEC-INTEGRACION-CALENDAR
estado: PENDIENTE
- spec: SPEC-WIZARD-TRANSIENT-MODEL
estado: PENDIENTE
- spec: SPEC-FACTURACION-CFDI
estado: PENDIENTE
capas:
database:
inventario: DATABASE_INVENTORY.yml
total_objetos: 0
estado: No iniciado
schemas_planificados: [clinical, pharmacy, laboratory, imaging]
tablas_planificadas: 45
estado: PLANIFICADO
backend:
inventario: BACKEND_INVENTORY.yml
total_objetos: 0
estado: No iniciado
modulos_planificados: 12
estado: PLANIFICADO
frontend:
inventario: FRONTEND_INVENTORY.yml
total_objetos: 0
estado: No iniciado
paginas_planificadas: 25
estado: PLANIFICADO
dependencias_core:
- auth (de erp-core)
- users (de erp-core)
- roles (de erp-core)
- catalogs (de erp-core)
obligatorias:
- auth (MGN-001)
- users (MGN-002)
- roles (MGN-003)
- tenants (MGN-004)
opcionales:
- catalogs (MGN-005)
- financial (MGN-010)
- inventory (MGN-011)
- cfdi (MGN-016)
- calendar (MGN-020)
consideraciones_especiales:
- Cumplimiento de normativa de datos de salud
- Expediente clinico electronico (NOM-024)
- Proteccion de datos sensibles
- Cumplimiento NOM-024-SSA3-2012
- LFPDPPP - Protección datos personales de salud
- 2FA obligatorio para personal médico
- Encriptación de datos sensibles (antecedentes, alergias)
- Integración HL7/FHIR para interoperabilidad
- Firma electrónica de recetas
referencias:
docs: docs/
vision: docs/00-vision-general/VISION-CLINICAS.md
modulos: docs/02-definicion-modulos/INDICE-MODULOS.md
orchestration: orchestration/
contexto: orchestration/00-guidelines/CONTEXTO-PROYECTO.md
herencia: orchestration/00-guidelines/HERENCIA-DIRECTIVAS.md
herencia_specs: orchestration/00-guidelines/HERENCIA-SPECS-CORE.md
herencia_db: database/HERENCIA-ERP-CORE.md

View File

@ -1,63 +1,514 @@
# =============================================================================
# TRACEABILITY MATRIX - ERP Clínicas (Vertical)
# =============================================================================
# Generado: 2025-12-08
# Sistema: NEXUS + SIMCO v2.2.0
# Propósito: Matriz de trazabilidad Módulos -> SPECS -> Componentes
# =============================================================================
proyecto:
nombre: ERP Clinicas
nivel: 2B.2 (Vertical)
trazabilidad:
CL-001:
nombre: Pacientes
database: [patients, patient_contacts, patient_insurance]
backend: [PatientService]
frontend: [PatientList, PatientForm, PatientDetail, PatientSearch]
CL-002:
nombre: Citas
database: [appointments, appointment_slots, doctors, specialties]
backend: [AppointmentService, DoctorService]
frontend: [AppointmentCalendar, AppointmentForm, DoctorScheduleView]
specs_core: [SPEC-INTEGRACION-CALENDAR.md]
CL-003:
nombre: Expediente Clinico
database: [medical_records, consultations, diagnoses, prescriptions, vital_signs]
backend: [MedicalRecordService]
frontend: [MedicalRecordView, ConsultationForm, PrescriptionForm]
seguridad: ENCRIPTADO
normativa: NOM-024-SSA3-2012
CL-004:
nombre: Servicios
database: [medical_services, service_prices]
backend: [MedicalServiceCatalogService]
frontend: [ServiceCatalog, ServicePriceList]
CL-005:
nombre: Facturacion
database: [invoices]
backend: [MedicalInvoiceService]
frontend: [MedicalInvoiceForm, InvoiceList]
CL-006:
nombre: Reportes
database: []
backend: [MedicalReportService]
frontend: [AppointmentReport, RevenueReport, PatientStatistics]
herencia_specs:
- spec: SPEC-RRHH-EVALUACIONES-SKILLS.md
modulos: [CL-002]
- spec: SPEC-INTEGRACION-CALENDAR.md
modulos: [CL-002]
- spec: SPEC-TWO-FACTOR-AUTHENTICATION.md
modulos: [CL-001, CL-003]
metadata:
proyecto: ERP Clínicas
codigo: CL
version: 1.0.0
fecha_actualizacion: 2025-12-08
base_core: erp-core v0.6.0
normativa: NOM-024-SSA3-2012, LFPDPPP
# =============================================================================
# RESUMEN GLOBAL
# =============================================================================
resumen:
modulos: 6
tablas_planificadas: 15
servicios_planificados: 7
componentes_planificados: 18
estado: PLANIFICACION
modulos_total: 12
modulos_documentados: 12
story_points_total: 395
specs_core_aplicables: 22
specs_implementadas: 0
cobertura_specs: 0%
estado: PLANIFICACION_COMPLETA
# =============================================================================
# TRAZABILIDAD POR MÓDULO
# =============================================================================
trazabilidad:
# ---------------------------------------------------------------------------
# CL-001: Fundamentos (90% herencia + 2FA obligatorio)
# ---------------------------------------------------------------------------
CL-001:
nombre: Fundamentos
herencia: 90%
prioridad: P0
sp: 0
extiende:
- MGN-001 (auth)
- MGN-002 (users)
- MGN-003 (roles)
- MGN-004 (tenants)
database:
heredadas: [auth.users, auth.sessions, auth.roles, tenants.tenants]
extensiones:
- auth.two_factor_configs
- auth.medical_certifications
backend:
heredados: [AuthService, UserService, RoleService, TenantService]
extensiones:
- TwoFactorService
- MedicalAuthService
frontend:
heredados: [LoginForm, UserProfile, RoleSelector]
extensiones:
- TwoFactorSetup
- TwoFactorVerify
specs_core:
- SPEC-SISTEMA-SECUENCIAS
- SPEC-SEGURIDAD-API-KEYS-PERMISOS
seguridad:
- 2FA_obligatorio_personal_medico
- encriptacion_datos_sensibles
# ---------------------------------------------------------------------------
# CL-002: Pacientes
# ---------------------------------------------------------------------------
CL-002:
nombre: Pacientes
herencia: 40%
prioridad: P0
sp: 34
database:
tablas:
- clinical.patients
- clinical.patient_contacts
- clinical.patient_insurance
- clinical.patient_allergies
- clinical.emergency_contacts
backend:
servicios:
- PatientService
- PatientSearchService
- InsuranceService
frontend:
componentes:
- PatientList
- PatientForm
- PatientDetail
- PatientSearch
- InsuranceCard
- AllergyBadge
specs_core:
- SPEC-MAIL-THREAD-TRACKING (comunicación pacientes)
seguridad:
- datos_encriptados: [allergies, medical_history]
- consentimiento_requerido: true
# ---------------------------------------------------------------------------
# CL-003: Citas
# ---------------------------------------------------------------------------
CL-003:
nombre: Citas
herencia: 30%
prioridad: P0
sp: 42
database:
tablas:
- clinical.appointments
- clinical.appointment_slots
- clinical.doctors
- clinical.specialties
- clinical.appointment_reminders
backend:
servicios:
- AppointmentService
- DoctorService
- ScheduleService
- ReminderService
frontend:
componentes:
- AppointmentCalendar
- AppointmentForm
- DoctorScheduleView
- SlotSelector
- ReminderConfig
- AppointmentConfirmation
specs_core:
- SPEC-INTEGRACION-CALENDAR (Google Calendar, Outlook)
# ---------------------------------------------------------------------------
# CL-004: Consultas
# ---------------------------------------------------------------------------
CL-004:
nombre: Consultas
herencia: 0%
prioridad: P0
sp: 47
database:
tablas:
- clinical.consultations
- clinical.vital_signs
- clinical.diagnoses
- clinical.icd10_codes
- clinical.consultation_notes
backend:
servicios:
- ConsultationService
- VitalSignsService
- DiagnosisService
- ICD10Service
frontend:
componentes:
- ConsultationForm
- SOAPNote
- VitalSignsCapture
- DiagnosisSearch
- ICD10Selector
- ConsultationHistory
specs_core: []
normativa:
- NOM-024-SSA3-2012 (estructura SOAP)
# ---------------------------------------------------------------------------
# CL-005: Recetas
# ---------------------------------------------------------------------------
CL-005:
nombre: Recetas
herencia: 20%
prioridad: P0
sp: 34
database:
tablas:
- clinical.prescriptions
- clinical.prescription_items
- clinical.medications
- clinical.drug_interactions
backend:
servicios:
- PrescriptionService
- MedicationService
- InteractionChecker
- PrescriptionPrintService
frontend:
componentes:
- PrescriptionForm
- MedicationSearch
- DosageCalculator
- InteractionAlert
- PrescriptionPrint
specs_core:
- SPEC-WIZARD-TRANSIENT-MODEL (asistente receta)
caracteristicas:
- firma_electronica: true
- validacion_interacciones: true
# ---------------------------------------------------------------------------
# CL-006: Laboratorio
# ---------------------------------------------------------------------------
CL-006:
nombre: Laboratorio
herencia: 10%
prioridad: P1
sp: 42
database:
tablas:
- laboratory.lab_orders
- laboratory.lab_tests
- laboratory.test_results
- laboratory.reference_ranges
- laboratory.test_panels
backend:
servicios:
- LabOrderService
- TestResultService
- ReferenceRangeService
frontend:
componentes:
- LabOrderForm
- TestSelector
- ResultsCapture
- ResultsViewer
- AbnormalHighlight
- TrendChart
specs_core:
- SPEC-TRAZABILIDAD-LOTES-SERIES (muestras)
# ---------------------------------------------------------------------------
# CL-007: Farmacia
# ---------------------------------------------------------------------------
CL-007:
nombre: Farmacia
herencia: 60%
prioridad: P1
sp: 34
database:
tablas:
- pharmacy.pharmacy_stock
- pharmacy.medication_lots
- pharmacy.dispensations
- pharmacy.controlled_substances
backend:
servicios:
- PharmacyStockService
- DispensationService
- ControlledSubstanceService
frontend:
componentes:
- PharmacyStock
- DispensationForm
- LotSelector
- ExpirationAlert
- ControlledLog
specs_core:
- SPEC-VALORACION-INVENTARIO
- SPEC-TRAZABILIDAD-LOTES-SERIES
- SPEC-INVENTARIOS-CICLICOS
caracteristicas:
- control_caducidades: true
- sustancias_controladas: true
# ---------------------------------------------------------------------------
# CL-008: Facturación
# ---------------------------------------------------------------------------
CL-008:
nombre: Facturacion
herencia: 70%
prioridad: P0
sp: 21
database:
tablas:
- invoicing.medical_invoices
- invoicing.insurance_claims
- invoicing.service_charges
backend:
servicios:
- MedicalInvoiceService
- InsuranceClaimService
- CFDIService
frontend:
componentes:
- MedicalInvoiceForm
- InvoiceList
- InsuranceClaimForm
- PaymentCapture
specs_core:
- SPEC-FACTURACION-CFDI (servicios médicos)
# ---------------------------------------------------------------------------
# CL-009: Reportes
# ---------------------------------------------------------------------------
CL-009:
nombre: Reportes
herencia: 40%
prioridad: P1
sp: 34
database:
tablas: []
backend:
servicios:
- MedicalReportService
- StatisticsService
- ExportService
frontend:
componentes:
- AppointmentReport
- RevenueReport
- PatientStatistics
- DoctorProductivity
- DiagnosisDistribution
specs_core: []
# ---------------------------------------------------------------------------
# CL-010: Telemedicina
# ---------------------------------------------------------------------------
CL-010:
nombre: Telemedicina
herencia: 0%
prioridad: P2
sp: 47
database:
tablas:
- telemedicine.video_sessions
- telemedicine.session_recordings
- telemedicine.waiting_room
backend:
servicios:
- VideoSessionService
- WaitingRoomService
- RecordingService
frontend:
componentes:
- VideoConsultation
- WaitingRoom
- VirtualExamRoom
- ScreenShare
- ChatPanel
specs_core: []
caracteristicas:
- encriptacion_e2e: true
- grabacion_opcional: true
# ---------------------------------------------------------------------------
# CL-011: Expediente Clínico
# ---------------------------------------------------------------------------
CL-011:
nombre: Expediente
herencia: 10%
prioridad: P0
sp: 39
database:
tablas:
- clinical.medical_records
- clinical.clinical_notes
- clinical.attachments
- clinical.consent_forms
- clinical.record_access_log
backend:
servicios:
- MedicalRecordService
- ClinicalNoteService
- AttachmentService
- ConsentService
- AuditService
frontend:
componentes:
- MedicalRecordView
- TimelineView
- NoteEditor
- AttachmentViewer
- ConsentCapture
- AccessLog
specs_core:
- SPEC-MAIL-THREAD-TRACKING (notas clínicas)
normativa:
- NOM-024-SSA3-2012 (estructura expediente)
seguridad:
- encriptacion_completa: true
- auditoria_accesos: true
# ---------------------------------------------------------------------------
# CL-012: Imagenología
# ---------------------------------------------------------------------------
CL-012:
nombre: Imagenologia
herencia: 0%
prioridad: P2
sp: 21
database:
tablas:
- imaging.imaging_studies
- imaging.dicom_metadata
- imaging.study_reports
backend:
servicios:
- ImagingStudyService
- DICOMService
- ReportService
frontend:
componentes:
- DICOMViewer
- StudyList
- ReportEditor
- ImageAnnotation
specs_core: []
caracteristicas:
- dicom_viewer: true
- integracion_pacs: true
# =============================================================================
# REFERENCIAS CRUZADAS CON ERP-CORE
# =============================================================================
referencias_core:
specs_implementadas: []
specs_pendientes:
- spec: SPEC-SISTEMA-SECUENCIAS
modulos: [CL-001, CL-003, CL-004]
prioridad: P0
estado: PENDIENTE
- spec: SPEC-SEGURIDAD-API-KEYS-PERMISOS
modulos: [CL-001]
prioridad: P0
estado: PENDIENTE
adaptacion: "Permisos por especialidad médica"
- spec: SPEC-INTEGRACION-CALENDAR
modulos: [CL-003]
prioridad: P0
estado: PENDIENTE
adaptacion: "Sincronización agenda médica"
- spec: SPEC-TRAZABILIDAD-LOTES-SERIES
modulos: [CL-006, CL-007]
prioridad: P1
estado: PENDIENTE
adaptacion: "Trazabilidad muestras y medicamentos"
- spec: SPEC-MAIL-THREAD-TRACKING
modulos: [CL-002, CL-011]
prioridad: P1
estado: PENDIENTE
adaptacion: "Comunicación segura pacientes"
modulos_extendidos:
- core: MGN-001 (auth)
vertical: CL-001
tipo: extension_2fa_obligatorio
- core: MGN-011 (inventory)
vertical: CL-007
tipo: extension_farmacia
- core: MGN-016 (cfdi)
vertical: CL-008
tipo: extension_servicios_medicos
# =============================================================================
# CUMPLIMIENTO NORMATIVO
# =============================================================================
cumplimiento_normativo:
NOM-024-SSA3-2012:
descripcion: "Expediente clínico electrónico"
modulos_afectados: [CL-004, CL-011]
requisitos:
- estructura_soap: CL-004
- historia_clinica: CL-011
- consentimiento_informado: CL-011
- firma_electronica: CL-005
LFPDPPP:
descripcion: "Protección de datos personales"
modulos_afectados: [CL-002, CL-011]
requisitos:
- encriptacion_datos_sensibles: true
- consentimiento_tratamiento: true
- derecho_acceso: true
- auditoria_accesos: true
# =============================================================================
# VALIDACIONES
# =============================================================================
validaciones:
modulos_huerfanos: 0
specs_sin_modulo: 0
alertas:
- tipo: implementacion_pendiente
mensaje: "0% de código implementado - fase planificación"
- tipo: seguridad_critica
modulo: CL-001
mensaje: "2FA obligatorio para personal médico"
- tipo: normativa
modulos: [CL-004, CL-011]
mensaje: "Requiere validación NOM-024-SSA3-2012"
- tipo: encriptacion
modulos: [CL-002, CL-011]
mensaje: "Datos sensibles requieren encriptación"
# =============================================================================
# METADATA
# =============================================================================
metadata_documento:
creado_por: Claude-Code
fecha_creacion: 2025-12-08
ultima_actualizacion: 2025-12-08
version_documento: 1.0.0

View File

@ -0,0 +1,182 @@
# Prompt: Clínicas Backend Agent
## Identidad
Eres un agente especializado en desarrollo backend para ERP Clínicas. Tu expertise está en Node.js, Express, TypeScript, TypeORM y PostgreSQL, con conocimiento específico del dominio de salud y cumplimiento normativo mexicano (NOM-024-SSA3-2012, LFPDPPP).
## Contexto del Proyecto
```yaml
proyecto: ERP Clínicas
codigo: CL
tipo: Vertical de ERP-Suite
nivel: 2B.2
stack:
runtime: Node.js 20+
framework: Express.js
lenguaje: TypeScript 5.3+
orm: TypeORM 0.3.17
database: PostgreSQL 15+
auth: JWT + bcryptjs + 2FA (heredado + extendido)
encriptacion: AES-256 para datos sensibles
paths:
vertical: /home/isem/workspace/projects/erp-suite/apps/verticales/clinicas/
backend: /home/isem/workspace/projects/erp-suite/apps/verticales/clinicas/backend/
docs: /home/isem/workspace/projects/erp-suite/apps/verticales/clinicas/docs/
core: /home/isem/workspace/projects/erp-suite/apps/erp-core/
directivas: orchestration/directivas/
puertos:
backend: 3500
frontend: 5178
database: 5437
```
## Herencia del Core
Este proyecto HEREDA del ERP-Core:
- Módulos: auth (+ 2FA), users, roles, tenants, inventory, cfdi
- SPECS: Ver `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
- Base de datos: 97 tablas heredadas
**REGLA:** Extender, NUNCA modificar el core.
## Módulos de la Vertical
| Módulo | Descripción | Prioridad | Normativa |
|--------|-------------|-----------|-----------|
| CL-001 | Fundamentos (+ 2FA) | P0 | LFPDPPP |
| CL-002 | Pacientes | P0 | LFPDPPP |
| CL-003 | Citas | P0 | - |
| CL-004 | Consultas (SOAP) | P0 | NOM-024 |
| CL-005 | Recetas | P0 | NOM-024 |
| CL-006 | Laboratorio | P1 | - |
| CL-007 | Farmacia | P1 | - |
| CL-008 | Facturación CFDI | P0 | - |
| CL-009 | Reportes | P1 | - |
| CL-010 | Telemedicina | P2 | - |
| CL-011 | Expediente NOM-024 | P0 | NOM-024 |
| CL-012 | Imagenología DICOM | P2 | - |
## Directivas Obligatorias
### 1. Multi-Tenant (Heredada)
```
OBLIGATORIO: Toda operación debe filtrar por tenant_id.
Ver: core/orchestration/directivas/DIRECTIVA-MULTI-TENANT.md
```
### 2. Expediente Clínico
```
ESPECÍFICO: Cumplimiento NOM-024-SSA3-2012.
Ver: directivas/DIRECTIVA-EXPEDIENTE-CLINICO.md
```
### 3. Gestión de Citas
```
ESPECÍFICO: Agenda médica, recordatorios.
Ver: directivas/DIRECTIVA-GESTION-CITAS.md
```
## Cumplimiento Normativo
### NOM-024-SSA3-2012 (Expediente Clínico)
```yaml
requisitos:
- estructura_soap: Subjetivo, Objetivo, Análisis, Plan
- campos_obligatorios:
- identificacion_paciente
- fecha_consulta
- motivo_consulta
- exploracion_fisica
- diagnostico_cie10
- plan_tratamiento
- firma_electronica: En recetas
- consentimiento_informado: Documentado
```
### LFPDPPP (Protección de Datos)
```yaml
requisitos:
- encriptacion: AES-256 para datos sensibles
- campos_encriptados:
- antecedentes_medicos
- alergias
- diagnosticos
- notas_clinicas
- auditoria: Log de accesos a expedientes
- consentimiento: Tratamiento de datos
```
## Schemas de Base de Datos
```yaml
schemas_especificos:
- clinical: Pacientes, citas, consultas, expediente
- pharmacy: Stock medicamentos, dispensaciones
- laboratory: Órdenes lab, resultados
- imaging: Estudios DICOM, metadatos
- telemedicine: Sesiones video, grabaciones
```
## SPECS del Core Aplicables
- SPEC-INTEGRACION-CALENDAR (agenda médica)
- SPEC-MAIL-THREAD-TRACKING (comunicación pacientes)
- SPEC-TRAZABILIDAD-LOTES-SERIES (muestras, medicamentos)
- SPEC-FACTURACION-CFDI (servicios médicos)
- SPEC-TWO-FACTOR-AUTHENTICATION (2FA obligatorio)
- SPEC-RRHH-EVALUACIONES-SKILLS (certificaciones médicas)
## Seguridad Especial
### 2FA Obligatorio
```typescript
// Personal médico REQUIERE 2FA
// Implementar en extensión de auth
@UseGuards(TwoFactorGuard)
export class MedicalController { }
```
### Encriptación de Datos Sensibles
```typescript
// Usar decorador para campos sensibles
@EncryptedColumn()
antecedentes_medicos: string;
@EncryptedColumn()
alergias: string;
```
### Auditoría de Accesos
```typescript
// Log automático de accesos a expediente
@AuditAccess('medical_record')
async getMedicalRecord(patientId: string) { }
```
## Flujo de Trabajo
```
1. Leer especificación del módulo en docs/02-definicion-modulos/
2. Verificar cumplimiento normativo (NOM-024, LFPDPPP)
3. Verificar SPECS aplicables en HERENCIA-SPECS-CORE.md
4. Revisar DDL existente en database/
5. Implementar con encriptación y auditoría
6. Actualizar TRAZA-TAREAS-BACKEND.md
7. Actualizar BACKEND_INVENTORY.yml
```
## Referencias
- Inventario: `orchestration/inventarios/MASTER_INVENTORY.yml`
- Trazabilidad: `orchestration/inventarios/TRACEABILITY_MATRIX.yml`
- Herencia: `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
- NOM-024: Normativa expediente clínico electrónico
- LFPDPPP: Ley Federal de Protección de Datos Personales
---
**Versión:** 1.0.0
**Sistema:** SIMCO v2.2.0

View File

@ -1,26 +1,140 @@
# ESTADO DEL PROYECTO
# ESTADO DEL PROYECTO - ERP Construcción
**Proyecto:** erp-construccion
**Proyecto:** ERP Construcción (Proyecto Independiente)
**Estado:** 🚧 En desarrollo
**Progreso:** 35%
**Última actualización:** 2025-11-24
**Última actualización:** 2025-12-08
---
## 📊 RESUMEN
## 📊 RESUMEN EJECUTIVO
- **Fase actual:** Desarrollo inicial
- **Módulos completados:** 4
- **Módulos en desarrollo:** 2
- **Módulos pendientes:** 12
| Área | Implementado | Documentado | Estado |
|------|-------------|-------------|--------|
| **DDL/Schemas** | 3 schemas, 33 tablas | 7 schemas, 65 tablas | 50% |
| **Backend** | 4 módulos, 11 entidades | 18 módulos | 22% |
| **Frontend** | Estructura base | 18 módulos | 5% |
| **Documentación** | - | 449 archivos MD | 100% |
---
## 🗄️ BASE DE DATOS
### Schemas Implementados (DDL)
| Schema | Tablas | ENUMs | Archivo DDL |
|--------|--------|-------|-------------|
| `construction` | 2 | - | `01-construction-schema-ddl.sql` |
| `hr` | 3 | - | `02-hr-schema-ddl.sql` |
| `hse` | 28 | 67 | `03-hse-schema-ddl.sql` |
| **Total** | **33** | **67** | |
### Schemas Pendientes de Implementar
- `estimates` - Presupuestos y estimaciones (8 tablas documentadas)
- `infonavit` - Integración INFONAVIT (8 tablas documentadas)
- `inventory-ext` - Extensión inventario (4 tablas documentadas)
- `purchase-ext` - Extensión compras (5 tablas documentadas)
---
## 💻 BACKEND
### Módulos con Código
```
backend/src/modules/
├── construction/ ✅ Entidades + Services + Controllers
│ ├── proyecto.entity.ts
│ └── fraccionamiento.entity.ts
├── hr/ ✅ Entidades básicas
│ ├── employee.entity.ts
│ ├── puesto.entity.ts
│ └── employee-fraccionamiento.entity.ts
├── hse/ ✅ Entidades básicas
│ ├── incidente.entity.ts
│ ├── incidente-involucrado.entity.ts
│ ├── incidente-accion.entity.ts
│ └── capacitacion.entity.ts
└── core/ ✅ Base multi-tenant
├── user.entity.ts
└── tenant.entity.ts
```
### Pendientes
- 14 módulos MAI sin código backend
- 3 módulos MAE sin código backend
- Services y Controllers para hr, hse
---
## 📋 MÓDULOS (18 Total)
### Fase 1 - MAI (14 módulos)
| Código | Nombre | DDL | Backend | Docs |
|--------|--------|:---:|:-------:|:----:|
| MAI-001 | Fundamentos | - | ✅ | ✅ |
| MAI-002 | Proyectos y Estructura | ✅ | ✅ | ✅ |
| MAI-003 | Presupuestos y Costos | ⏳ | ❌ | ✅ |
| MAI-004 | Compras e Inventarios | ⏳ | ❌ | ✅ |
| MAI-005 | Control de Obra | ⏳ | ❌ | ✅ |
| MAI-006 | Reportes y Analytics | - | ❌ | ✅ |
| MAI-007 | RRHH y Asistencias | ✅ | ✅ | ✅ |
| MAI-008 | Estimaciones | ⏳ | ❌ | ✅ |
| MAI-009 | Calidad y Postventa | ⏳ | ❌ | ✅ |
| MAI-010 | CRM Derechohabientes | ⏳ | ❌ | ✅ |
| MAI-011 | INFONAVIT | ⏳ | ❌ | ✅ |
| MAI-012 | Contratos | ⏳ | ❌ | ✅ |
| MAI-013 | Administración | - | ❌ | ✅ |
| MAI-018 | Preconstrucción | ⏳ | ❌ | ✅ |
### Fase 2 - MAE (3 módulos)
| Código | Nombre | DDL | Backend | Docs |
|--------|--------|:---:|:-------:|:----:|
| MAE-014 | Finanzas y Controlling | ⏳ | ❌ | ✅ |
| MAE-015 | Activos y Maquinaria | ⏳ | ❌ | ✅ |
| MAE-016 | Gestión Documental | ⏳ | ❌ | ✅ |
### Fase 3 - MAA (1 módulo)
| Código | Nombre | DDL | Backend | Docs |
|--------|--------|:---:|:-------:|:----:|
| MAA-017 | Seguridad HSE | ✅ | ✅ | ✅ |
**Leyenda:** ✅ Implementado | ⏳ Pendiente | ❌ No iniciado | - No aplica
---
## 🎯 PRÓXIMOS PASOS
1. Completar módulos en desarrollo
2. Iniciar testing de módulos completados
3. Documentar APIs
4. Preparar siguiente iteración
### Inmediato
1. Implementar DDL de `estimates` schema
2. Implementar DDL de `infonavit` schema
3. Completar services/controllers de `hr` y `hse`
### Corto Plazo
4. Implementar backend de MAI-003 (Presupuestos)
5. Implementar backend de MAI-005 (Control de Obra)
6. Testing de módulos existentes
---
## 📁 ARCHIVOS CLAVE
- **DDL:** `database/schemas/*.sql`
- **Backend:** `backend/src/modules/`
- **Docs:** `docs/02-definicion-modulos/`
- **Inventario:** `orchestration/inventarios/MASTER_INVENTORY.yml`
---
## 📈 MÉTRICAS
| Métrica | Valor |
|---------|-------|
| Archivos MD | 449 |
| Requerimientos (RF) | 87 |
| Especificaciones (ET) | 78 |
| User Stories | 149 |
| Story Points | 692 |
| ADRs | 12 |
---
**Última actualización:** 2025-12-08

View File

@ -1,66 +1,69 @@
# Herencia de Base de Datos - ERP Core -> Construcción
# Referencia de Base de Datos - ERP Construcción
**Fecha:** 2025-12-08
**Versión:** 1.0
**Vertical:** Construcción
**Nivel:** 2B.2
**Versión:** 1.1
**Proyecto:** ERP Construcción
**Nivel:** 2B.2 (Proyecto Independiente)
---
## RESUMEN
La vertical de Construcción hereda los schemas base del ERP Core y extiende con schemas específicos del dominio.
ERP Construcción es un **proyecto independiente** que implementa y adapta patrones del ERP-Core para el dominio de construcción de vivienda. No es una extensión del core, sino un sistema autónomo que:
**Ubicación DDL Core:** `apps/erp-core/database/ddl/`
1. **Implementa** schemas propios basados en patrones del core
2. **Adapta** estructuras de datos al dominio de construcción
3. **Reutiliza** código y patrones donde tiene sentido
4. **Opera independientemente** del ERP-Core
**DDL de Referencia (Core):** `apps/erp-core/database/ddl/`
**DDL Propio:** `database/schemas/`
---
## ARQUITECTURA DE HERENCIA
## ARQUITECTURA DEL PROYECTO
```
┌─────────────────────────────────────────────────────────────────┐
│ ERP CORE (Base) │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ auth │ │ core │ │financial│ │inventory│ │ purchase │ │
│ │ 26 tbl │ │ 12 tbl │ │ 15 tbl │ │ 15 tbl │ │ 8 tbl │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ projects│ │ hr │ │ sales │ │analytics│ │ system │ │
│ │ 5 tbl │ │ 6 tbl │ │ 6 tbl │ │ 5 tbl │ │ 10 tbl │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ TOTAL: 124 tablas base │
│ ERP CORE (Referencia) │
│ Patrones, specs y estructuras reutilizables │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ auth │ │ core │ │inventory│ │ financial│ │
│ │ patrones│ │ patrones│ │ patrones│ │ patrones │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────────────────────────┘
HEREDA
│ REFERENCIA / FORK
┌─────────────────────────────────────────────────────────────────┐
│ CONSTRUCCIÓN (Extensiones) │
│ ERP CONSTRUCCIÓN (Proyecto Independiente) │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │construccion │ │ hr │ │ hse │ │
│ │construction │ │ hr │ │ hse │ │
│ │ 2 tbl │ │ 3 tbl │ │ 28 tbl │ │
│ │ (proyectos) │ │ (empleados) │ │ (seguridad) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ EXTENSIONES: 33 tablas │
│ │
│ Schemas propios: 3 | Tablas propias: 33 │
│ Opera de forma INDEPENDIENTE │
└─────────────────────────────────────────────────────────────────┘
```
---
## SCHEMAS HEREDADOS DEL CORE
## PATRONES REUTILIZADOS DEL CORE
| Schema | Tablas | Uso en Construcción |
|--------|--------|---------------------|
| `auth` | 26 | Autenticación, usuarios, roles, permisos, MFA, OAuth |
| `core` | 12 | Partners (contratistas), catálogos, monedas, UoM |
| `financial` | 15 | Cuentas contables, pólizas, facturas de proveedores |
| `inventory` | 15 | Materiales de construcción, almacenes de obra |
| `purchase` | 8 | Órdenes de compra de materiales |
| `projects` | 5 | Base para proyectos de construcción |
| `hr` | 6 | Base para empleados (extendido con hr específico) |
| `analytics` | 5 | Centros de costo por proyecto |
| `system` | 10 | Mensajes, notificaciones, actividades |
Los siguientes patrones del ERP-Core fueron **adaptados e implementados** en este proyecto:
**Total heredado:** 102 tablas
| Patrón del Core | Adaptación en Construcción |
|-----------------|---------------------------|
| `auth.*` | Implementación propia de autenticación multi-tenant |
| `core.partners` | Contratistas, proveedores, clientes |
| `inventory.*` | Materiales de construcción, almacenes de obra |
| `projects.*` | Obras, fraccionamientos, etapas |
| `hr.*` | Personal de obra, cuadrillas, asistencias |
**Nota:** Este proyecto NO depende del ERP-Core para ejecutarse. Implementa sus propios schemas basados en los patrones de referencia.
---
@ -155,12 +158,38 @@ psql $DATABASE_URL -f schemas/03-hse-schema-ddl.sql
| Spec Core | Aplicación en Construcción | Estado |
|-----------|---------------------------|--------|
| SPEC-VALORACION-INVENTARIO | Materiales de construcción | PENDIENTE |
| SPEC-TRAZABILIDAD-LOTES-SERIES | Lotes de concreto, acero | PENDIENTE |
| SPEC-VALORACION-INVENTARIO | Materiales de construcción | ✅ DDL LISTO |
| SPEC-TRAZABILIDAD-LOTES-SERIES | Lotes de concreto, acero | ✅ DDL LISTO |
| SPEC-PROYECTOS-DEPENDENCIAS-BURNDOWN | Partidas de obra | PENDIENTE |
| SPEC-MAIL-THREAD-TRACKING | Historial de presupuestos | PENDIENTE |
| SPEC-WIZARD-TRANSIENT-MODEL | Asistentes de estimaciones | PENDIENTE |
### Correcciones de DDL Core (2025-12-08)
El DDL del ERP-Core fue corregido para resolver FK inválidas:
1. **stock_valuation_layers**: Campos `journal_entry_id` y `journal_entry_line_id` (antes `account_move_*`)
2. **stock_move_consume_rel**: Nueva tabla de trazabilidad (antes `move_line_consume_rel`)
3. **category_stock_accounts**: FK corregida a `core.product_categories`
4. **product_categories**: ALTERs ahora apuntan a schema `core`
Estas correcciones permiten que el DDL de inventory se ejecute correctamente.
### Correcciones de DDL Construcción (2025-12-08)
El DDL de la vertical Construcción fue corregido para alinearse con ERP-Core:
| Archivo | Correcciones | Detalle |
|---------|--------------|---------|
| `01-construction-schema-ddl.sql` | 4 FK | `core.tenants``auth.tenants`, `core.users``auth.users` |
| `02-hr-schema-ddl.sql` | 4 FK | Referencias corregidas a `auth.*` |
| `03-hse-schema-ddl.sql` | 42 FK | Todas las referencias corregidas |
| **Total** | **50 FK** | Ahora usa `auth.tenants` y `auth.users` correctamente |
**Verificaciones de prerequisitos actualizadas:**
- Los DDL ahora validan que `auth.tenants` y `auth.users` existan antes de crear tablas
- ERP-Core debe estar instalado antes de ejecutar DDL de Construcción
---
## MAPEO DE NOMENCLATURA
@ -205,11 +234,38 @@ GROUP BY schemaname;
---
## SPECS DEL CORE APLICABLES
Según el [MAPEO-SPECS-VERTICALES.md](../../../../erp-core/docs/04-modelado/MAPEO-SPECS-VERTICALES.md):
| Categoría | Total | Obligatorias | Opcionales | No Aplican |
|-----------|-------|--------------|------------|------------|
| **Construcción** | 30 | 22 | 4 | 4 |
### SPECS Críticas para Construcción
| SPEC | Aplicación | Estado DDL |
|------|------------|------------|
| SPEC-VALORACION-INVENTARIO | Costeo de materiales | ✅ DDL LISTO |
| SPEC-TRAZABILIDAD-LOTES-SERIES | Lotes de concreto, acero | ✅ DDL LISTO |
| SPEC-PROYECTOS-DEPENDENCIAS-BURNDOWN | Partidas de obra | PENDIENTE |
| SPEC-PRESUPUESTOS-REVISIONES | Control presupuestal | PENDIENTE |
| SPEC-RRHH-EVALUACIONES-SKILLS | Personal de obra | PENDIENTE |
### SPECS No Aplicables
- `SPEC-INTEGRACION-CALENDAR` - Sin necesidad de calendario externo
- `SPEC-OAUTH2-SOCIAL-LOGIN` - Opcional, no crítico
- `SPEC-INVENTARIOS-CICLICOS` - Opcional para construcción
- `SPEC-CONSOLIDACION-FINANCIERA` - Opcional para construcción
---
## REFERENCIAS
- ERP Core DDL: `apps/erp-core/database/ddl/`
- ERP Core README: `apps/erp-core/database/README.md`
- HERENCIA-SPECS-ERP-CORE.md: `orchestration/00-guidelines/`
- MAPEO-SPECS-VERTICALES: `apps/erp-core/docs/04-modelado/MAPEO-SPECS-VERTICALES.md`
- DATABASE_INVENTORY.yml: `orchestration/inventarios/`
---

View File

@ -8,11 +8,17 @@
-- Este archivo es parte de la fuente de verdad DDL.
-- ============================================================================
-- Verificar que init-database.sql se ejecuto
-- Verificar que ERP-Core esta instalado
DO $$
BEGIN
IF NOT EXISTS (SELECT 1 FROM pg_namespace WHERE nspname = 'core') THEN
RAISE EXCEPTION 'Schema core no existe. Ejecutar primero init-scripts/01-init-database.sql';
IF NOT EXISTS (SELECT 1 FROM pg_namespace WHERE nspname = 'auth') THEN
RAISE EXCEPTION 'Schema auth no existe. Ejecutar primero ERP-Core DDL';
END IF;
IF NOT EXISTS (SELECT 1 FROM pg_tables WHERE schemaname = 'auth' AND tablename = 'tenants') THEN
RAISE EXCEPTION 'Tabla auth.tenants no existe. ERP-Core debe estar instalado';
END IF;
IF NOT EXISTS (SELECT 1 FROM pg_tables WHERE schemaname = 'auth' AND tablename = 'users') THEN
RAISE EXCEPTION 'Tabla auth.users no existe. ERP-Core debe estar instalado';
END IF;
END $$;
@ -29,7 +35,7 @@ SET search_path TO construction, core, core_shared, public;
-- Tabla: Proyectos (desarrollo inmobiliario)
CREATE TABLE IF NOT EXISTS construction.proyectos (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
codigo VARCHAR(20) NOT NULL,
nombre VARCHAR(200) NOT NULL,
descripcion TEXT,
@ -41,7 +47,7 @@ CREATE TABLE IF NOT EXISTS construction.proyectos (
estado_proyecto VARCHAR(20) NOT NULL DEFAULT 'activo',
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
created_by UUID REFERENCES core.users(id),
created_by UUID REFERENCES auth.users(id),
CONSTRAINT uq_proyectos_codigo UNIQUE (tenant_id, codigo)
);
@ -49,7 +55,7 @@ CREATE TABLE IF NOT EXISTS construction.proyectos (
-- Tabla: Fraccionamientos (obras dentro de un proyecto)
CREATE TABLE IF NOT EXISTS construction.fraccionamientos (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
proyecto_id UUID NOT NULL REFERENCES construction.proyectos(id),
codigo VARCHAR(20) NOT NULL,
nombre VARCHAR(200) NOT NULL,
@ -61,7 +67,7 @@ CREATE TABLE IF NOT EXISTS construction.fraccionamientos (
estado VARCHAR(20) NOT NULL DEFAULT 'activo',
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
created_by UUID REFERENCES core.users(id),
created_by UUID REFERENCES auth.users(id),
CONSTRAINT uq_fraccionamientos_codigo UNIQUE (tenant_id, codigo)
);

View File

@ -11,8 +11,11 @@
-- Verificar prerequisitos
DO $$
BEGIN
IF NOT EXISTS (SELECT 1 FROM pg_namespace WHERE nspname = 'core') THEN
RAISE EXCEPTION 'Schema core no existe. Ejecutar primero init-scripts/01-init-database.sql';
IF NOT EXISTS (SELECT 1 FROM pg_namespace WHERE nspname = 'auth') THEN
RAISE EXCEPTION 'Schema auth no existe. ERP-Core debe estar instalado';
END IF;
IF NOT EXISTS (SELECT 1 FROM pg_tables WHERE schemaname = 'auth' AND tablename = 'tenants') THEN
RAISE EXCEPTION 'Tabla auth.tenants no existe. ERP-Core debe estar instalado';
END IF;
IF NOT EXISTS (SELECT 1 FROM pg_namespace WHERE nspname = 'construction') THEN
RAISE EXCEPTION 'Schema construction no existe. Ejecutar primero 01-construction-schema-ddl.sql';
@ -32,7 +35,7 @@ SET search_path TO hr, construction, core, core_shared, public;
-- Tabla: Empleados
CREATE TABLE IF NOT EXISTS hr.employees (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
codigo VARCHAR(20) NOT NULL,
nombre VARCHAR(100) NOT NULL,
apellido_paterno VARCHAR(100) NOT NULL,
@ -55,7 +58,7 @@ CREATE TABLE IF NOT EXISTS hr.employees (
foto_url VARCHAR(500),
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
created_by UUID REFERENCES core.users(id),
created_by UUID REFERENCES auth.users(id),
CONSTRAINT uq_employees_codigo UNIQUE (tenant_id, codigo),
CONSTRAINT uq_employees_curp UNIQUE (tenant_id, curp)
@ -64,7 +67,7 @@ CREATE TABLE IF NOT EXISTS hr.employees (
-- Tabla: Puestos
CREATE TABLE IF NOT EXISTS hr.puestos (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
codigo VARCHAR(20) NOT NULL,
nombre VARCHAR(100) NOT NULL,
descripcion TEXT,
@ -85,7 +88,7 @@ ALTER TABLE hr.employees
-- Tabla: Asignacion de empleados a obras
CREATE TABLE IF NOT EXISTS hr.employee_fraccionamientos (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
employee_id UUID NOT NULL REFERENCES hr.employees(id),
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
fecha_inicio DATE NOT NULL,

View File

@ -113,7 +113,7 @@ CREATE TYPE hse.tipo_alerta_indicador AS ENUM ('meta_superada', 'tendencia_negat
-- Tabla: Incidentes
CREATE TABLE hse.incidentes (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
folio VARCHAR(20) NOT NULL,
fecha_hora TIMESTAMPTZ NOT NULL,
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
@ -127,7 +127,7 @@ CREATE TABLE hse.incidentes (
estado hse.estado_incidente NOT NULL DEFAULT 'abierto',
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
created_by UUID REFERENCES core.users(id),
created_by UUID REFERENCES auth.users(id),
CONSTRAINT uq_incidentes_folio UNIQUE (tenant_id, folio)
);
@ -184,7 +184,7 @@ CREATE TABLE hse.incidente_evidencias (
descripcion VARCHAR(200),
ubicacion_geo GEOMETRY(Point, 4326),
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
created_by UUID REFERENCES core.users(id)
created_by UUID REFERENCES auth.users(id)
);
-- ============================================================================
@ -194,7 +194,7 @@ CREATE TABLE hse.incidente_evidencias (
-- Tabla: Catalogo de capacitaciones
CREATE TABLE hse.capacitaciones (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
codigo VARCHAR(20) NOT NULL,
nombre VARCHAR(200) NOT NULL,
descripcion TEXT,
@ -215,7 +215,7 @@ CREATE TABLE hse.capacitaciones (
-- Tabla: Matriz de capacitacion por puesto
CREATE TABLE hse.capacitacion_matriz (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
puesto_id UUID NOT NULL,
capacitacion_id UUID NOT NULL REFERENCES hse.capacitaciones(id),
es_obligatoria BOOLEAN NOT NULL DEFAULT true,
@ -226,7 +226,7 @@ CREATE TABLE hse.capacitacion_matriz (
-- Tabla: Instructores
CREATE TABLE hse.instructores (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
nombre VARCHAR(200) NOT NULL,
registro_stps VARCHAR(50),
especialidades TEXT,
@ -242,7 +242,7 @@ CREATE TABLE hse.instructores (
-- Tabla: Sesiones de capacitacion
CREATE TABLE hse.capacitacion_sesiones (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
capacitacion_id UUID NOT NULL REFERENCES hse.capacitaciones(id),
fraccionamiento_id UUID REFERENCES construction.fraccionamientos(id),
instructor_id UUID REFERENCES hse.instructores(id),
@ -275,7 +275,7 @@ CREATE TABLE hse.capacitacion_asistentes (
-- Tabla: Constancias DC-3
CREATE TABLE hse.constancias_dc3 (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
folio VARCHAR(30) NOT NULL,
asistente_id UUID NOT NULL REFERENCES hse.capacitacion_asistentes(id),
employee_id UUID NOT NULL REFERENCES hr.employees(id),
@ -295,7 +295,7 @@ CREATE TABLE hse.constancias_dc3 (
-- Tabla: Tipos de inspeccion
CREATE TABLE hse.tipos_inspeccion (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
codigo VARCHAR(20) NOT NULL,
nombre VARCHAR(200) NOT NULL,
descripcion TEXT,
@ -326,7 +326,7 @@ CREATE TABLE hse.checklist_items (
-- Tabla: Programa de inspecciones
CREATE TABLE hse.programa_inspecciones (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
tipo_inspeccion_id UUID NOT NULL REFERENCES hse.tipos_inspeccion(id),
inspector_id UUID REFERENCES hr.employees(id),
@ -342,7 +342,7 @@ CREATE TABLE hse.programa_inspecciones (
-- Tabla: Inspecciones ejecutadas
CREATE TABLE hse.inspecciones (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
programa_id UUID REFERENCES hse.programa_inspecciones(id),
tipo_inspeccion_id UUID NOT NULL REFERENCES hse.tipos_inspeccion(id),
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
@ -376,7 +376,7 @@ CREATE TABLE hse.inspeccion_evaluaciones (
-- Tabla: Hallazgos de inspeccion
CREATE TABLE hse.hallazgos (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
inspeccion_id UUID NOT NULL REFERENCES hse.inspecciones(id),
evaluacion_id UUID REFERENCES hse.inspeccion_evaluaciones(id),
folio VARCHAR(20) NOT NULL,
@ -407,7 +407,7 @@ CREATE TABLE hse.hallazgo_evidencias (
descripcion VARCHAR(200),
ubicacion_geo GEOMETRY(Point, 4326),
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
created_by UUID REFERENCES core.users(id)
created_by UUID REFERENCES auth.users(id)
);
-- ============================================================================
@ -417,7 +417,7 @@ CREATE TABLE hse.hallazgo_evidencias (
-- Tabla: Catalogo de EPP
CREATE TABLE hse.epp_catalogo (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
codigo VARCHAR(20) NOT NULL,
nombre VARCHAR(200) NOT NULL,
categoria hse.categoria_epp NOT NULL,
@ -440,7 +440,7 @@ CREATE TABLE hse.epp_catalogo (
-- Tabla: Matriz EPP por puesto
CREATE TABLE hse.epp_matriz_puesto (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
puesto_id UUID NOT NULL,
epp_id UUID NOT NULL REFERENCES hse.epp_catalogo(id),
es_obligatorio BOOLEAN NOT NULL DEFAULT true,
@ -452,7 +452,7 @@ CREATE TABLE hse.epp_matriz_puesto (
-- Tabla: Asignaciones de EPP
CREATE TABLE hse.epp_asignaciones (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
employee_id UUID NOT NULL REFERENCES hr.employees(id),
epp_id UUID NOT NULL REFERENCES hse.epp_catalogo(id),
fraccionamiento_id UUID REFERENCES construction.fraccionamientos(id),
@ -467,7 +467,7 @@ CREATE TABLE hse.epp_asignaciones (
costo_unitario DECIMAL(10,2),
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
created_by UUID REFERENCES core.users(id)
created_by UUID REFERENCES auth.users(id)
);
-- Tabla: Inspecciones de EPP
@ -499,7 +499,7 @@ CREATE TABLE hse.epp_bajas (
-- Tabla: Inventario de EPP
CREATE TABLE hse.epp_inventario (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
epp_id UUID NOT NULL REFERENCES hse.epp_catalogo(id),
almacen_id UUID,
cantidad_disponible INTEGER NOT NULL DEFAULT 0,
@ -513,7 +513,7 @@ CREATE TABLE hse.epp_inventario (
-- Tabla: Movimientos de EPP
CREATE TABLE hse.epp_movimientos (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
epp_id UUID NOT NULL REFERENCES hse.epp_catalogo(id),
almacen_origen_id UUID,
almacen_destino_id UUID,
@ -522,7 +522,7 @@ CREATE TABLE hse.epp_movimientos (
referencia VARCHAR(100),
observaciones TEXT,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
created_by UUID REFERENCES core.users(id)
created_by UUID REFERENCES auth.users(id)
);
-- ============================================================================
@ -559,7 +559,7 @@ CREATE TABLE hse.norma_requisitos (
-- Tabla: Cumplimiento por obra
CREATE TABLE hse.cumplimiento_obra (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
norma_id UUID NOT NULL REFERENCES hse.normas_stps(id),
requisito_id UUID REFERENCES hse.norma_requisitos(id),
@ -576,7 +576,7 @@ CREATE TABLE hse.cumplimiento_obra (
-- Tabla: Comisiones de seguridad e higiene
CREATE TABLE hse.comision_seguridad (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
fecha_constitucion DATE NOT NULL,
numero_acta VARCHAR(50),
@ -619,7 +619,7 @@ CREATE TABLE hse.comision_recorridos (
-- Tabla: Programa de seguridad anual
CREATE TABLE hse.programa_seguridad (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
anio INTEGER NOT NULL,
objetivo_general TEXT,
@ -651,7 +651,7 @@ CREATE TABLE hse.programa_actividades (
-- Tabla: Documentos STPS emitidos
CREATE TABLE hse.documentos_stps (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
tipo hse.tipo_documento_stps NOT NULL,
folio VARCHAR(30) NOT NULL,
fraccionamiento_id UUID REFERENCES construction.fraccionamientos(id),
@ -662,7 +662,7 @@ CREATE TABLE hse.documentos_stps (
documento_url VARCHAR(500),
firmado BOOLEAN NOT NULL DEFAULT false,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
created_by UUID REFERENCES core.users(id),
created_by UUID REFERENCES auth.users(id),
CONSTRAINT uq_documentos_stps_folio UNIQUE (tenant_id, tipo, folio)
);
@ -670,7 +670,7 @@ CREATE TABLE hse.documentos_stps (
-- Tabla: Auditorias
CREATE TABLE hse.auditorias (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
tipo hse.tipo_auditoria NOT NULL,
fecha_programada DATE NOT NULL,
@ -706,7 +706,7 @@ CREATE TABLE hse.residuos_catalogo (
-- Tabla: Generacion de residuos
CREATE TABLE hse.residuos_generacion (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
residuo_id UUID NOT NULL REFERENCES hse.residuos_catalogo(id),
fecha_generacion DATE NOT NULL,
@ -719,13 +719,13 @@ CREATE TABLE hse.residuos_generacion (
ubicacion_geo GEOMETRY(Point, 4326),
estado hse.estado_residuo NOT NULL DEFAULT 'almacenado',
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
created_by UUID REFERENCES core.users(id)
created_by UUID REFERENCES auth.users(id)
);
-- Tabla: Almacenes temporales
CREATE TABLE hse.almacen_temporal (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
nombre VARCHAR(100) NOT NULL,
ubicacion VARCHAR(200),
@ -740,7 +740,7 @@ CREATE TABLE hse.almacen_temporal (
-- Tabla: Proveedores ambientales
CREATE TABLE hse.proveedores_ambientales (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
razon_social VARCHAR(300) NOT NULL,
rfc VARCHAR(13),
tipo hse.tipo_proveedor_ambiental NOT NULL,
@ -759,7 +759,7 @@ CREATE TABLE hse.proveedores_ambientales (
-- Tabla: Manifiestos de residuos
CREATE TABLE hse.manifiestos_residuos (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
folio VARCHAR(30) NOT NULL,
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
transportista_id UUID NOT NULL REFERENCES hse.proveedores_ambientales(id),
@ -790,7 +790,7 @@ CREATE TABLE hse.manifiesto_detalle (
-- Tabla: Impacto ambiental
CREATE TABLE hse.impacto_ambiental (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
aspecto VARCHAR(200) NOT NULL,
tipo_impacto hse.tipo_impacto NOT NULL,
@ -807,7 +807,7 @@ CREATE TABLE hse.impacto_ambiental (
-- Tabla: Quejas ambientales
CREATE TABLE hse.quejas_ambientales (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
fecha_queja TIMESTAMPTZ NOT NULL,
origen hse.origen_queja NOT NULL,
@ -829,7 +829,7 @@ CREATE TABLE hse.quejas_ambientales (
-- Tabla: Tipos de permiso de trabajo
CREATE TABLE hse.tipos_permiso_trabajo (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
codigo VARCHAR(20) NOT NULL,
nombre VARCHAR(200) NOT NULL,
descripcion TEXT,
@ -848,7 +848,7 @@ CREATE TABLE hse.tipos_permiso_trabajo (
-- Tabla: Permisos de trabajo
CREATE TABLE hse.permisos_trabajo (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
folio VARCHAR(30) NOT NULL,
tipo_permiso_id UUID NOT NULL REFERENCES hse.tipos_permiso_trabajo(id),
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
@ -944,7 +944,7 @@ CREATE TABLE hse.permiso_documentos (
nombre VARCHAR(200) NOT NULL,
archivo_url VARCHAR(500) NOT NULL,
fecha_subida TIMESTAMPTZ NOT NULL DEFAULT NOW(),
subido_por UUID REFERENCES core.users(id)
subido_por UUID REFERENCES auth.users(id)
);
-- ============================================================================
@ -954,7 +954,7 @@ CREATE TABLE hse.permiso_documentos (
-- Tabla: Configuracion de indicadores
CREATE TABLE hse.indicadores_config (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
codigo VARCHAR(20) NOT NULL,
nombre VARCHAR(200) NOT NULL,
descripcion TEXT,
@ -986,7 +986,7 @@ CREATE TABLE hse.indicadores_meta_obra (
-- Tabla: Valores calculados de indicadores
CREATE TABLE hse.indicadores_valores (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
indicador_id UUID NOT NULL REFERENCES hse.indicadores_config(id),
fraccionamiento_id UUID REFERENCES construction.fraccionamientos(id),
periodo_tipo hse.periodo_tipo NOT NULL,
@ -1002,7 +1002,7 @@ CREATE TABLE hse.indicadores_valores (
-- Tabla: Horas trabajadas
CREATE TABLE hse.horas_trabajadas (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
fecha DATE NOT NULL,
horas_totales DECIMAL(12,2) NOT NULL,
@ -1017,7 +1017,7 @@ CREATE TABLE hse.horas_trabajadas (
-- Tabla: Dias sin accidente
CREATE TABLE hse.dias_sin_accidente (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
fraccionamiento_id UUID NOT NULL REFERENCES construction.fraccionamientos(id),
fecha_inicio_conteo DATE NOT NULL,
dias_acumulados INTEGER NOT NULL DEFAULT 0,
@ -1031,7 +1031,7 @@ CREATE TABLE hse.dias_sin_accidente (
-- Tabla: Reportes programados
CREATE TABLE hse.reportes_programados (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
nombre VARCHAR(200) NOT NULL,
tipo_reporte hse.tipo_reporte_hse NOT NULL,
indicadores UUID[],
@ -1048,7 +1048,7 @@ CREATE TABLE hse.reportes_programados (
-- Tabla: Alertas de indicadores
CREATE TABLE hse.alertas_indicadores (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
tenant_id UUID NOT NULL REFERENCES core.tenants(id),
tenant_id UUID NOT NULL REFERENCES auth.tenants(id),
indicador_id UUID NOT NULL REFERENCES hse.indicadores_config(id),
fraccionamiento_id UUID REFERENCES construction.fraccionamientos(id),
tipo_alerta hse.tipo_alerta_indicador NOT NULL,

View File

@ -0,0 +1,280 @@
# Herencia SIMCO - ERP Construcción
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Fecha:** 2025-12-08
---
## Configuración del Proyecto
| Propiedad | Valor |
|-----------|-------|
| **Proyecto** | ERP Construcción - Vertical para Constructoras |
| **Nivel** | VERTICAL (Nivel 3) |
| **Padre** | erp-core |
| **Suite** | erp-suite |
| **SIMCO Version** | 2.2.0 |
| **CAPVED** | Habilitado |
| **CCA Protocol** | Habilitado |
## Jerarquía de Herencia
```
Nivel 0: core/orchestration/ ← FUENTE PRINCIPAL (76 docs)
└── Nivel 1: erp-suite/orchestration/
└── Nivel 2: erp-core/orchestration/ ← PADRE DIRECTO
└── Nivel 3: construccion/orchestration/ ← ESTE PROYECTO
```
**Regla:** Las directivas de nivel inferior pueden EXTENDER las superiores, nunca REDUCIRLAS.
**Estado del Proyecto:** 35% completado (vertical más avanzada)
---
## Directivas Heredadas de CORE (OBLIGATORIAS)
Ubicación: `core/orchestration/`
### 1. Ciclo de Vida - USAR SIEMPRE
| Alias | Archivo | Propósito |
|-------|---------|-----------|
| `@TAREA` | `directivas/simco/SIMCO-TAREA.md` | Punto de entrada para toda HU |
| `@CAPVED` | `directivas/principios/PRINCIPIO-CAPVED.md` | Ciclo de 6 fases |
| `@INICIALIZACION` | `directivas/simco/SIMCO-INICIALIZACION.md` | Bootstrap de agentes |
### 2. Operaciones Universales
| Alias | Archivo | Propósito |
|-------|---------|-----------|
| `@CREAR` | `SIMCO-CREAR.md` | Crear archivos nuevos |
| `@MODIFICAR` | `SIMCO-MODIFICAR.md` | Modificar existentes |
| `@VALIDAR` | `SIMCO-VALIDAR.md` | Validar código |
| `@DOCUMENTAR` | `SIMCO-DOCUMENTAR.md` | Documentar trabajo |
| `@BUSCAR` | `SIMCO-BUSCAR.md` | Buscar información |
| `@DELEGAR` | `SIMCO-DELEGACION.md` | Delegar a subagentes |
### 3. Catálogo de Funcionalidades
| Alias | Archivo | Propósito |
|-------|---------|-----------|
| `@CATALOG` | `catalog/` | Funcionalidades reutilizables |
| `@CATALOG_INDEX` | `catalog/CATALOG-INDEX.yml` | Índice |
| `@REUTILIZAR` | `SIMCO-REUTILIZAR.md` | Antes de implementar |
| `@CONTRIBUIR` | `SIMCO-CONTRIBUIR-CATALOGO.md` | Después de crear |
### 4. Principios Fundamentales (5)
| Alias | Resumen |
|-------|---------|
| `@CAPVED` | Toda tarea pasa por 6 fases |
| `@DOC_PRIMERO` | Consultar docs/ antes de implementar |
| `@ANTI_DUP` | Verificar que no existe antes de crear |
| `@VALIDACION` | Build y lint DEBEN pasar |
| `@TOKENS` | Desglosar tareas grandes |
---
## Directivas por Dominio Técnico
| Alias | Aplica | Notas |
|-------|--------|-------|
| `@OP_DDL` | **SÍ** | 7 schemas de construcción |
| `@OP_BACKEND` | **SÍ** | Servicios específicos |
| `@OP_FRONTEND` | **SÍ** | UI de construcción |
| `@OP_MOBILE` | **SÍ** | App de campo |
| `@OP_ML` | NO | - |
---
## Patrones Heredados (OBLIGATORIOS)
| Patrón | Uso en Construcción |
|--------|---------------------|
| `MAPEO-TIPOS-DDL-TYPESCRIPT.md` | 7 schemas ↔ Entities |
| `PATRON-VALIDACION.md` | DTOs de proyectos, obras |
| `PATRON-EXCEPTION-HANDLING.md` | Errores de construcción |
| `PATRON-TESTING.md` | Tests de módulos MAI-* |
| `PATRON-LOGGING.md` | Trazabilidad de obras |
| `PATRON-SEGURIDAD.md` | RLS por constructora |
| `PATRON-TRANSACCIONES.md` | Operaciones de presupuesto |
| `ANTIPATRONES.md` | Evitar siempre |
| `NOMENCLATURA-UNIFICADA.md` | Consistencia |
---
## Directivas Heredadas de ERP Core (Nivel 2)
Ubicación: `erp-core/orchestration/`
| Directiva | Propósito | Extensión Local |
|-----------|-----------|-----------------|
| `DIRECTIVA-MULTI-TENANT.md` | RLS por tenant | Por `constructora_id` |
| `DIRECTIVA-EXTENSION-VERTICALES.md` | Cómo extender | 15 módulos MAI-* |
| `DIRECTIVA-PATRONES-ODOO.md` | Patrones ERP | Adaptados a construcción |
---
## Directivas Específicas de Construcción
Ubicación: `./directivas/`
| Directiva Local | Extiende | Propósito |
|-----------------|----------|-----------|
| `DIRECTIVA-PROYECTOS-OBRA.md` | `@OP_DDL` | Gestión de proyectos/obras |
| `DIRECTIVA-PRESUPUESTOS.md` | `@OP_BACKEND` | Estimaciones y costos |
| `DIRECTIVA-AVANCES-OBRA.md` | `@OP_BACKEND` | Registro de avances |
| `DIRECTIVA-INFONAVIT.md` | `@OP_BACKEND` | Integración INFONAVIT |
---
## Variables de Contexto CCA
```yaml
# Variables para resolver en ALIASES y templates
PROJECT_NAME: "construccion"
PROJECT_LEVEL: "VERTICAL"
PROJECT_ROOT: "/home/isem/workspace/projects/erp-suite/apps/verticales/construccion"
PARENT_PROJECT: "erp-core"
SUITE_PROJECT: "erp-suite"
# Rutas específicas
DB_DDL_PATH: "database/ddl"
BACKEND_ROOT: "backend/src"
FRONTEND_ROOT: "frontend/src"
DOCS_ROOT: "../../../../docs/verticales/construccion"
# Documentación extensa (403+ archivos)
DOCS_FASE_1: "../../../../docs/verticales/construccion/01-fase-alcance-inicial"
DOCS_FASE_2: "../../../../docs/verticales/construccion/02-fase-enterprise"
DOCS_SCHEMAS: "../../../../docs/verticales/construccion/02-modelado/database-design"
# Stack
BACKEND_FRAMEWORK: "Express.js"
ORM: "TypeORM"
FRONTEND_FRAMEWORK: "React"
# Inventarios
MASTER_INVENTORY: "orchestration/inventarios/MASTER_INVENTORY.yml"
DATABASE_INVENTORY: "orchestration/inventarios/DATABASE_INVENTORY.yml"
BACKEND_INVENTORY: "orchestration/inventarios/BACKEND_INVENTORY.yml"
FRONTEND_INVENTORY: "orchestration/inventarios/FRONTEND_INVENTORY.yml"
# Multi-tenant específico
TENANT_COLUMN: "constructora_id"
RLS_CONTEXT: "app.current_constructora_id"
```
---
## Schemas de Base de Datos (7)
| Schema | Descripción | Módulos |
|--------|-------------|---------|
| `auth_management` | Autenticación (hereda core) | MAI-AUTH |
| `project_management` | Proyectos, desarrollos, fases | MAI-PRJ, MAI-DEV |
| `financial_management` | Presupuestos, estimaciones | MAI-FIN |
| `purchasing_management` | Compras, proveedores | MAI-PUR |
| `construction_management` | Avances, recursos, materiales | MAI-CON |
| `quality_management` | Inspecciones, calidad | MAI-QUA |
| `infonavit_management` | Integración INFONAVIT | MAI-INF |
---
## Módulos MAI-* (15)
| Módulo | Descripción | Estado |
|--------|-------------|--------|
| MAI-AUTH | Autenticación | Hereda core |
| MAI-USR | Usuarios | Hereda core |
| MAI-PRJ | Proyectos | 60% |
| MAI-DEV | Desarrollos | 40% |
| MAI-LOT | Lotes | 30% |
| MAI-CLI | Clientes | 50% |
| MAI-FIN | Finanzas | 20% |
| MAI-PUR | Compras | 10% |
| MAI-CON | Construcción | 30% |
| MAI-QUA | Calidad | 10% |
| MAI-INV | Inventarios | 10% |
| MAI-RPT | Reportes | 5% |
| MAI-NOT | Notificaciones | 0% |
| MAI-AUD | Auditoría | Hereda core |
| MAI-INF | INFONAVIT | 0% |
---
## Flujo de Trabajo para Desarrollo
```yaml
# PASO 1: Cargar contexto (CCA)
CARGAR:
- @TAREA
- @CAPVED
- @INICIALIZACION
- ../../erp-core/HERENCIA-SIMCO.md
- ../../../erp-suite/HERENCIA-SIMCO.md
# PASO 2: Verificar documentación existente
VERIFICAR_DOCS:
- docs/verticales/construccion/ # 403+ archivos
- @DOC_PRIMERO
# PASO 3: Verificar catálogo
VERIFICAR_CATALOGO:
- @CATALOG_INDEX
- @REUTILIZAR
# PASO 4: Seleccionar operación
OPERACION:
- @OP_DDL # 7 schemas
- @OP_BACKEND # Servicios MAI-*
- @OP_FRONTEND # UI construcción
# PASO 5: Aplicar patrones
PATRONES:
- @PATRON-VALIDACION
- @PATRON-SEGURIDAD # Multi-tenant obligatorio
# PASO 6: Validar impactos
IMPACTOS:
- @IMPACTO-CAMBIOS-DDL
- @MATRIZ-DEPENDENCIAS
# PASO 7: Documentar
CIERRE:
- @DOCUMENTAR
- Actualizar docs/verticales/construccion/
```
---
## Documentación Crítica (403+ archivos)
**OBLIGATORIO:** Validar contra documentación antes de implementar.
| Ruta | Contenido | Archivos |
|------|-----------|----------|
| `01-fase-alcance-inicial/` | Specs de módulos MAI-* | ~200 |
| `02-fase-enterprise/` | Épicas MAE-* | ~50 |
| `02-modelado/database-design/` | Schemas SQL | ~100 |
---
## Mapeo: Directivas Antiguas → SIMCO
| Directiva Antigua | Reemplazada Por | Alias |
|-------------------|-----------------|-------|
| `DIRECTIVA-FLUJO-5-FASES.md` | `SIMCO-TAREA.md` + `PRINCIPIO-CAPVED.md` | @TAREA, @CAPVED |
| `DIRECTIVA-VALIDACION-DOCUMENTACION.md` | `PRINCIPIO-DOC-PRIMERO.md` | @DOC_PRIMERO |
| `POLITICAS-MODULARIZACION.md` | `ANTIPATRONES.md` | @ANTIPATRONES |
| `DIRECTIVA-DISENO-BASE-DATOS.md` | `SIMCO-DDL.md` | @OP_DDL |
---
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Nivel:** VERTICAL (3)
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,127 @@
# =============================================================================
# PROJECT-ENV-CONFIG.yml - ERP CONSTRUCCION
# =============================================================================
# Vertical de ERP-Suite especializada en Administración de Obra
# Actualizado: 2025-12-08
# Referencia: ~/workspace/core/devtools/environment/DEVENV-PORTS.md
# =============================================================================
project:
name: "ERP-CONSTRUCCION"
code: "CON"
description: "Sistema de Administración de Obra y Proyectos de Construcción"
type: "vertical"
level: "2B.2"
status: "development"
parent: "erp-suite"
paths:
root: "/home/isem/workspace/projects/erp-suite/apps/verticales/construccion"
backend: "backend/"
frontend: "frontend/"
database: "database/"
docs: "docs/"
orchestration: "orchestration/"
# =============================================================================
# PUERTOS (Según DEVENV-PORTS.md)
# =============================================================================
ports:
backend: 3100
frontend: 5174
database: 5433
redis: 6380
# =============================================================================
# BASE DE DATOS
# =============================================================================
database:
type: "postgresql"
host: "localhost"
port: 5433
name: "construccion_db"
user: "construccion_user"
schemas:
core_inherited: 12 # Schemas heredados de erp-core
vertical_specific:
- construction # Proyectos, presupuestos
- progress # Avances, valuaciones
- contracts # Contratos, estimaciones
migration:
tool: "typeorm"
directory: "database/migrations/"
# =============================================================================
# STACK TECNOLOGICO
# =============================================================================
stack:
runtime: "Node.js 20+"
language: "TypeScript 5.3+"
backend:
framework: "Express.js"
orm: "TypeORM 0.3.17"
frontend:
framework: "React 18"
build: "Vite"
ui: "Tailwind CSS + shadcn/ui"
# =============================================================================
# HERENCIA DEL CORE
# =============================================================================
core_inheritance:
version: "0.6.0"
tables_inherited: 97
modules_inherited:
- auth
- users
- roles
- tenants
- inventory
- sales
- cfdi
specs_applicable: 18
specs_implemented: 0
# =============================================================================
# ARCHIVOS DE ENTORNO
# =============================================================================
env_files:
template: "orchestration/environment/.env.example"
backend: "backend/.env"
frontend: "frontend/.env"
env_variables:
required:
- NODE_ENV
- PORT
- DATABASE_URL
- JWT_SECRET
- REDIS_URL
optional:
- LOG_LEVEL
- CORS_ORIGIN
- RATE_LIMIT_MAX
# =============================================================================
# DOCKER
# =============================================================================
docker:
compose_file: "docker-compose.yml"
services:
- backend
- frontend
- postgres
- redis
# =============================================================================
# NOTAS
# =============================================================================
notes: |
- Vertical especializada en industria de la construcción
- Hereda auth, users, roles, tenants del erp-core
- Implementa módulos específicos: proyectos, presupuestos, avances
- Puertos asignados según DEVENV-PORTS.md (rango 3100)
- Requiere erp-core funcionando para módulos heredados

View File

@ -1421,15 +1421,40 @@ schemas_deprecados:
- assets_management: "usar 'assets' (pendiente)"
- documents_management: "usar 'documents' (pendiente)"
# =============================================================================
# VALIDACION DDL (2025-12-08)
# =============================================================================
validacion_ddl:
fecha: "2025-12-08"
estado: "✅ CORREGIDO"
total_correcciones: 50
archivos_corregidos:
- archivo: "schemas/01-construction-schema-ddl.sql"
correcciones: 4
detalle: "core.tenants → auth.tenants, core.users → auth.users"
- archivo: "schemas/02-hr-schema-ddl.sql"
correcciones: 4
detalle: "core.tenants → auth.tenants, core.users → auth.users"
- archivo: "schemas/03-hse-schema-ddl.sql"
correcciones: 42
detalle: "Todas las FK corregidas a auth.*"
verificaciones_prerequisitos:
- "DDL verifica existencia de auth.tenants"
- "DDL verifica existencia de auth.users"
- "ERP-Core debe estar instalado antes de ejecutar DDL"
compatible_erp_core: true
# =============================================================================
# METADATA
# =============================================================================
metadata:
creado_por: Requirements-Analyst
fecha_creacion: 2025-12-06
ultima_actualizacion: 2025-12-06
version_documento: 1.1.0
ultima_actualizacion: 2025-12-08
version_documento: 1.2.0
cambios_version:
- "1.2.0: Validacion DDL - 50 FK corregidas a auth.* (2025-12-08)"
- "1.2.0: Verificaciones de prerequisitos actualizadas"
- "1.1.0: Nomenclatura unificada segun NAMING-CONVENTIONS.md"
- "1.1.0: Alineacion con DDL files reales"
- "1.1.0: Schemas deprecados documentados"

View File

@ -57,7 +57,8 @@ metricas:
fase_2_mae: 3
fase_3_maa: 1
documentados: 18 # Todos documentados incluyendo MAA-017
implementados: 0
ddl_implementado: 3 # construction, hr, hse
backend_parcial: 4 # construction, hr, hse, core (entidades básicas)
requerimientos:
total_rf: 87 # +8 de MAA-017
@ -76,13 +77,22 @@ metricas:
story_points: 692 # +42 de MAA-017
database:
# Conteo real basado en DDL files (actualizado 2025-12-06)
schemas: 7 # core, core_shared, construction, hr, hse, estimates, infonavit
tablas: 65 # 2 core + 2 construction + 3 hr + 58 hse
enums: 89 # 22 base + 67 HSE
funciones: 13 # 12 base + 1 hse
triggers: 15 # 5 base + 10 HSE
rls_policies: 65 # 1 por tabla con tenant_id
# Conteo real basado en DDL files (actualizado 2025-12-08)
schemas_implementados: 3 # construction, hr, hse
schemas_pendientes: 4 # estimates, infonavit, inventory-ext, purchase-ext
tablas_implementadas: 33 # 2 construction + 3 hr + 28 hse
tablas_documentadas: 65 # Total en documentación
enums: 89 # 22 base + 67 HSE
funciones: 13
triggers: 15
rls_policies: 33 # 1 por tabla implementada
backend:
# Estado actual del código TypeScript
entidades_implementadas: 11 # proyecto, fraccionamiento, employee, puesto, employee_fracc, incidente, etc.
modulos_con_codigo: 4 # construction, hr, hse, core
servicios: 2 # proyecto.service, fraccionamiento.service
controllers: 2 # proyecto.controller, fraccionamiento.controller
adrs:
total: 12
@ -756,15 +766,38 @@ proxima_accion:
- Migracion DDL inicial
- Configuracion multi-tenant
# =============================================================================
# VALIDACION DDL (2025-12-08)
# =============================================================================
validacion_ddl:
fecha: "2025-12-08"
estado: "✅ CORREGIDO"
compatible_erp_core: true
total_correcciones: 50
archivos_corregidos:
- archivo: "01-construction-schema-ddl.sql"
correcciones: 4
- archivo: "02-hr-schema-ddl.sql"
correcciones: 4
- archivo: "03-hse-schema-ddl.sql"
correcciones: 42
correcciones_aplicadas:
- "core.tenants → auth.tenants"
- "core.users → auth.users"
- "Verificaciones de prerequisitos actualizadas"
nota: "DDL ahora compatible con ERP-Core. Requiere ERP-Core instalado."
# =============================================================================
# METADATA
# =============================================================================
metadata:
creado_por: Requirements-Analyst
fecha_creacion: 2025-12-06
ultima_actualizacion: 2025-12-06
version_documento: 1.1.0
ultima_actualizacion: 2025-12-08
version_documento: 1.2.0
cambios_version:
- "1.2.0: Validacion DDL completada - 50 FK corregidas (2025-12-08)"
- "1.2.0: Prerequisitos DDL actualizados para ERP-Core"
- "1.1.0: Nomenclatura de schemas unificada segun NAMING-CONVENTIONS.md"
- "1.1.0: Conteos corregidos segun DDL files reales"
- "1.1.0: Tablas mapeadas por modulo"

View File

@ -503,6 +503,56 @@ validaciones:
# REFERENCIAS CRUZADAS CON ERP-CORE
# =============================================================================
referencias_core:
specs_aplicables: 27
specs_implementadas: 0
specs_pendientes:
- spec: SPEC-SISTEMA-SECUENCIAS
modulos: [MAI-001, MAI-002, MAI-003]
prioridad: P0
estado: PENDIENTE
- spec: SPEC-VALORACION-INVENTARIO
modulos: [MAI-004]
prioridad: P0
estado: PENDIENTE
adaptacion: "Valorización de materiales de construcción"
- spec: SPEC-TRAZABILIDAD-LOTES-SERIES
modulos: [MAI-004, MAI-009]
prioridad: P0
estado: PENDIENTE
adaptacion: "Trazabilidad de materiales por obra"
- spec: SPEC-PROYECTOS-DEPENDENCIAS-BURNDOWN
modulos: [MAI-002, MAI-005]
prioridad: P0
estado: PENDIENTE
adaptacion: "Control de avance de obra con burndown"
- spec: SPEC-MAIL-THREAD-TRACKING
modulos: [MAI-010, MAI-012]
prioridad: P1
estado: PENDIENTE
adaptacion: "Comunicación con derechohabientes y subcontratistas"
- spec: SPEC-RRHH-EVALUACIONES-SKILLS
modulos: [MAI-007]
prioridad: P1
estado: PENDIENTE
adaptacion: "Evaluación de cuadrillas y personal de obra"
- spec: SPEC-WIZARD-TRANSIENT-MODEL
modulos: [MAI-008]
prioridad: P1
estado: PENDIENTE
adaptacion: "Asistente de estimaciones"
- spec: SPEC-FACTURACION-CFDI
modulos: [MAI-008]
prioridad: P0
estado: PENDIENTE
modulos_extendidos:
- core: MGN-001
vertical: MAI-001
@ -520,6 +570,14 @@ referencias_core:
vertical: MAE-014
tipo: extension_financiera
- core: MGN-011
vertical: MAI-004
tipo: extension_inventario_obra
- core: MGN-014
vertical: MAI-007
tipo: extension_rrhh_obra
# =============================================================================
# METADATA
# =============================================================================

View File

@ -0,0 +1,208 @@
# Prompt: Construcción Backend Agent
## Identidad
Eres un agente especializado en desarrollo backend para ERP Construcción. Tu expertise está en Node.js, Express, TypeScript, TypeORM y PostgreSQL, con conocimiento específico del dominio de construcción de vivienda, fraccionamientos y administración de obra.
## Contexto del Proyecto
```yaml
proyecto: ERP Construcción
codigo: CON
tipo: Vertical de ERP-Suite
nivel: 2B.2
stack:
runtime: Node.js 20+
framework: Express.js
lenguaje: TypeScript 5.3+
orm: TypeORM 0.3.17
database: PostgreSQL 15+
auth: JWT + bcryptjs (heredado de core)
paths:
vertical: /home/isem/workspace/projects/erp-suite/apps/verticales/construccion/
backend: /home/isem/workspace/projects/erp-suite/apps/verticales/construccion/backend/
docs: /home/isem/workspace/projects/erp-suite/apps/verticales/construccion/docs/
core: /home/isem/workspace/projects/erp-suite/apps/erp-core/
directivas: orchestration/directivas/
puertos:
backend: 3100
frontend: 5174
database: 5433
redis: 6380
```
## Herencia del Core
Este proyecto HEREDA del ERP-Core:
- Módulos: auth, users, roles, tenants, inventory, sales, cfdi
- SPECS: Ver `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
- Base de datos: 97 tablas heredadas
**REGLA:** Extender, NUNCA modificar el core.
## Módulos de la Vertical
### Fase 1: Alcance Inicial (15 módulos)
| Módulo | Descripción | Prioridad |
|--------|-------------|-----------|
| MAI-001 | Fundamentos | P0 |
| MAI-002 | Proyectos/Estructura | P0 |
| MAI-003 | Presupuestos/Costos | P0 |
| MAI-004 | Compras/Inventarios | P0 |
| MAI-005 | Control Obra/Avances | P0 |
| MAI-006 | Reportes/Analytics | P1 |
| MAI-007 | RRHH/Asistencias | P1 |
| MAI-008 | Valuaciones/Estimaciones | P0 |
| MAI-009 | Integraciones INFONAVIT | P1 |
| MAI-010 | App Móvil Residentes | P2 |
### Fase 2: Enterprise (3 épicas)
| Épica | Descripción | SP |
|-------|-------------|---:|
| MAE-014 | Finanzas | 80 |
| MAE-015 | Activos | 70 |
| MAE-016 | DMS | 60 |
## Directivas Obligatorias
### 1. Multi-Tenant (Heredada)
```
OBLIGATORIO: Toda operación debe filtrar por tenant_id.
Ver: core/orchestration/directivas/DIRECTIVA-MULTI-TENANT.md
```
### 2. Proyectos de Construcción
```
ESPECÍFICO: Gestión de fraccionamientos, manzanas, lotes, prototipos.
Ver: directivas/DIRECTIVA-PROYECTOS-CONSTRUCCION.md
```
### 3. Control de Avances
```
ESPECÍFICO: Captura de avances físicos, curva S, valuaciones.
Ver: directivas/DIRECTIVA-CONTROL-AVANCES.md
```
## Estructura de Módulo
```
backend/src/modules/{nombre}/
├── {nombre}.module.ts
├── {nombre}.controller.ts
├── {nombre}.service.ts
├── {nombre}.entity.ts
├── dto/
│ ├── create-{nombre}.dto.ts
│ └── update-{nombre}.dto.ts
└── __tests__/
└── {nombre}.service.spec.ts
```
## Schemas de Base de Datos
```yaml
schemas_especificos:
- construction: Proyectos, fraccionamientos, manzanas, lotes
- progress: Avances físicos, curva S, valuaciones
- contracts: Contratos, estimaciones, pagos
- hr: Personal de obra, cuadrillas, asistencias
```
## SPECS del Core Aplicables
- SPEC-VALORACION-INVENTARIO (materiales de construcción)
- SPEC-TRAZABILIDAD-LOTES-SERIES (materiales con lote)
- SPEC-PROYECTOS-DEPENDENCIAS-BURNDOWN (control de obra)
- SPEC-MAIL-THREAD-TRACKING (comunicación con clientes/contratistas)
- SPEC-RRHH-EVALUACIONES-SKILLS (personal de obra)
- SPEC-FACTURACION-CFDI (estimaciones, valuaciones)
## Dominio Específico
### Estructura Jerárquica de Obra
```yaml
jerarquia:
- proyecto: Desarrollo inmobiliario completo
- fraccionamiento: Subdivisión del proyecto
- manzana: Agrupación de lotes
- lote: Unidad vendible/construible
- prototipo: Modelo de vivienda asignado al lote
```
### Estados de Proyecto
```yaml
estados_proyecto:
- PLANEACION: Proyecto en etapa de planeación
- EN_OBRA: Construcción activa
- PREVENTA: Vendiendo viviendas
- ENTREGA: Entregando viviendas terminadas
- CERRADO: Proyecto finalizado
```
### Control de Avances
```typescript
// Curva S: Programado vs Real
interface CurvaS {
semana: number;
programado_acumulado: number; // %
real_acumulado: number; // %
desviacion: number; // % (real - programado)
}
// Valuación de obra
interface Valuacion {
numero: number;
periodo_inicio: Date;
periodo_fin: Date;
monto_ejecutado: number;
retencion: number; // 5% típico
amortizacion_anticipo: number;
neto_a_pagar: number;
}
```
## Integraciones Requeridas
### INFONAVIT
```yaml
integraciones_infonavit:
- SHF: Sistema Hipotecario Federal
- SNIIV: Sistema Nacional de Información e Indicadores de Vivienda
- Validación ROC: Registro de Oferentes de Vivienda
```
### IMSS (Obra)
```yaml
integraciones_imss:
- SIROC: Sistema de Reportes de Obra de Construcción
- IDSE: Movimientos de personal
```
## Flujo de Trabajo
```
1. Leer especificación del módulo en docs/02-definicion-modulos/
2. Verificar SPECS aplicables en HERENCIA-SPECS-CORE.md
3. Revisar DDL existente en database/
4. Implementar siguiendo estructura de módulo
5. Actualizar TRAZA-TAREAS-BACKEND.md
6. Actualizar BACKEND_INVENTORY.yml
```
## Referencias
- Inventario: `orchestration/inventarios/MASTER_INVENTORY.yml`
- Trazabilidad: `orchestration/inventarios/TRACEABILITY_MATRIX.yml`
- Herencia: `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
- Core directivas: `/home/isem/workspace/core/orchestration/directivas/`
- Documentación Fase 1: `docs/01-fase-alcance-inicial/`
- Documentación Fase 2: `docs/08-epicas/`
---
**Versión:** 1.0.0
**Sistema:** SIMCO v2.2.0

View File

@ -1,20 +1,21 @@
# ESTADO DEL PROYECTO
# ESTADO DEL PROYECTO - ERP Mecánicas Diesel
**Proyecto:** ERP Mecanicas Diesel
**Estado:** Documentacion COMPLETA (MVP)
**Proyecto:** ERP Mecánicas Diesel (Proyecto Independiente)
**Estado:** Documentación COMPLETA (MVP) - DDL IMPLEMENTADO
**Progreso:** 95%
**Ultima actualizacion:** 2025-12-06
**Última actualización:** 2025-12-08
---
## RESUMEN
- **Fase actual:** Documentacion completa - Listo para desarrollo
- **Epicas documentadas:** 6/6 (MVP completo)
- **Modulos documentados:** 6/6 (MVP completo)
- **Tipo:** Proyecto independiente que adapta patrones del ERP-Core
- **Fase actual:** Documentación completa + DDL - Listo para desarrollo backend/frontend
- **Épicas documentadas:** 6/6 (MVP completo)
- **Módulos documentados:** 6/6 (MVP completo)
- **Story Points totales:** 241 SP
- **Historias de usuario:** 55 historias detalladas (100% cobertura)
- **Schemas de BD:** 4/4 completos
- **Schemas de BD:** 4/4 DDL implementados (43 tablas)
---
@ -186,13 +187,19 @@ docs/03-modelo-datos/
---
## DEPENDENCIAS
## ARQUITECTURA
**Requiere (bloqueante):**
- erp-core: MGN-001, MGN-002, MGN-003, MGN-004, MGN-005, MGN-011
**Tipo:** Proyecto Independiente (fork conceptual del ERP-Core)
**Patrones reutilizados del ERP-Core:**
- Multi-tenancy con RLS
- Estructura de autenticación
- Patrones de inventario
**Opera de forma autónoma:** No requiere ERP-Core instalado
**Referencia:**
- Vertical Construccion (patrones de documentacion aplicados)
- Vertical Construcción (patrones de documentación aplicados)
---

View File

@ -1,66 +1,69 @@
# Herencia de Base de Datos - ERP Core -> Mecánicas Diesel
# Referencia de Base de Datos - ERP Mecánicas Diesel
**Fecha:** 2025-12-08
**Versión:** 1.0
**Vertical:** Mecánicas Diesel
**Nivel:** 2B.2
**Versión:** 1.1
**Proyecto:** ERP Mecánicas Diesel
**Nivel:** 2B.2 (Proyecto Independiente)
---
## RESUMEN
La vertical de Mecánicas Diesel hereda los schemas base del ERP Core y extiende con schemas específicos del dominio de taller mecánico.
ERP Mecánicas Diesel es un **proyecto independiente** que implementa y adapta patrones del ERP-Core para el dominio de talleres de reparación de motores diesel. No es una extensión del core, sino un sistema autónomo que:
**Ubicación DDL Core:** `apps/erp-core/database/ddl/`
1. **Implementa** schemas propios para gestión de órdenes de servicio
2. **Adapta** estructuras de inventario para refacciones especializadas
3. **Reutiliza** patrones de autenticación y multi-tenancy
4. **Opera independientemente** como sistema completo
**DDL de Referencia (Core):** `apps/erp-core/database/ddl/`
**DDL Propio:** `database/init/`
---
## ARQUITECTURA DE HERENCIA
## ARQUITECTURA DEL PROYECTO
```
┌─────────────────────────────────────────────────────────────────┐
│ ERP CORE (Base) │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ auth │ │ core │ │financial│ │inventory│ │ purchase │ │
│ │ 26 tbl │ │ 12 tbl │ │ 15 tbl │ │ 15 tbl │ │ 8 tbl │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ sales │ │analytics│ │ system │ │
│ │ 6 tbl │ │ 5 tbl │ │ 10 tbl │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ TOTAL: 97 tablas heredadas │
│ ERP CORE (Referencia) │
│ Patrones, specs y estructuras reutilizables │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ auth │ │ core │ │inventory│ │ sales │ │
│ │ patrones│ │ patrones│ │ patrones│ │ patrones │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────────────────────────┘
HEREDA
│ REFERENCIA / FORK
┌─────────────────────────────────────────────────────────────────┐
│ MECÁNICAS DIESEL (Extensiones) │
│ ERP MECÁNICAS DIESEL (Proyecto Independiente) │
│ │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ service_ │ │ parts_ │ │ vehicle_ │ │
│ │ management │ │ management │ │ management │ │
│ │ 10+ tbl │ │ 12+ tbl │ │ 8+ tbl │ │
│ │ 18 tbl │ │ 12 tbl │ │ 8 tbl │ │
│ │ (órdenes) │ │ (refacciones) │ │ (vehículos) │ │
│ └───────────────┘ └───────────────┘ └───────────────┘ │
│ EXTENSIONES: 30+ tablas │
│ │
│ Schemas propios: 3 | Tablas propias: 38 │
│ Opera de forma INDEPENDIENTE │
└─────────────────────────────────────────────────────────────────┘
```
---
## SCHEMAS HEREDADOS DEL CORE
## PATRONES REUTILIZADOS DEL CORE
| Schema | Tablas | Uso en Mecánicas Diesel |
|--------|--------|-------------------------|
| `auth` | 26 | Autenticación, usuarios, roles, permisos |
| `core` | 12 | Partners (clientes, flotas), catálogos |
| `financial` | 15 | Facturas, cuentas contables |
| `inventory` | 15 | Base para refacciones, stock |
| `purchase` | 8 | Compras de refacciones |
| `sales` | 6 | Cotizaciones, órdenes de venta |
| `analytics` | 5 | Centros de costo |
| `system` | 10 | Mensajes, notificaciones |
Los siguientes patrones del ERP-Core fueron **adaptados e implementados** en este proyecto:
**Total heredado:** 97 tablas
| Patrón del Core | Adaptación en Mecánicas Diesel |
|-----------------|-------------------------------|
| `auth.*` | Multi-tenancy con RLS propio |
| `core.partners` | Clientes, flotas de vehículos |
| `inventory.*` | Refacciones, partes OEM, stock |
| `sales.*` | Cotizaciones, órdenes de servicio |
**Nota:** Este proyecto NO depende del ERP-Core para ejecutarse. Implementa sus propios schemas y puede operar de forma completamente standalone.
---
@ -168,12 +171,60 @@ psql $DATABASE_URL -f init/06-seed-data.sql
| Spec Core | Aplicación en Mecánicas | Estado |
|-----------|------------------------|--------|
| SPEC-VALORACION-INVENTARIO | Costeo de refacciones | PENDIENTE |
| SPEC-TRAZABILIDAD-LOTES-SERIES | Garantías de partes | PENDIENTE |
| SPEC-INVENTARIOS-CICLICOS | Conteos de refacciones | PENDIENTE |
| SPEC-VALORACION-INVENTARIO | Costeo de refacciones | ✅ DDL LISTO |
| SPEC-TRAZABILIDAD-LOTES-SERIES | Garantías de partes | ✅ DDL LISTO |
| SPEC-INVENTARIOS-CICLICOS | Conteos de refacciones | ✅ DDL LISTO |
| SPEC-MAIL-THREAD-TRACKING | Historial de órdenes | PENDIENTE |
| SPEC-TAREAS-RECURRENTES | Mantenimientos preventivos | PENDIENTE |
### Correcciones de DDL Core (2025-12-08)
El DDL del ERP-Core fue corregido para resolver FK inválidas:
1. **stock_valuation_layers**: Campos `journal_entry_id` y `journal_entry_line_id` (antes `account_move_*`)
2. **stock_move_consume_rel**: Nueva tabla de trazabilidad (antes `move_line_consume_rel`)
3. **category_stock_accounts**: FK corregida a `core.product_categories`
4. **product_categories**: ALTERs ahora apuntan a schema `core`
Estas correcciones permiten que el DDL de inventory se ejecute correctamente y habilitan:
- Valoración FIFO/AVCO de refacciones
- Trazabilidad de lotes y números de serie (garantías)
- Conteos cíclicos de inventario con clasificación ABC
### Validación DDL Mecánicas-Diesel (2025-12-08)
**Estado:** ✅ VÁLIDO - Compatible con ERP-Core
| Archivo | Líneas | Tablas | Estado |
|---------|--------|--------|--------|
| `init/00-extensions.sql` | 14 | 0 | ✅ Válido |
| `init/01-create-schemas.sql` | 30 | 0 | ✅ Válido |
| `init/02-rls-functions.sql` | 106 | 0 | ✅ Válido |
| `init/03-service-management-tables.sql` | 567 | ~18 | ✅ Válido |
| `init/04-parts-management-tables.sql` | 398 | ~12 | ✅ Válido |
| `init/05-vehicle-management-tables.sql` | 365 | ~8 | ✅ Válido |
**Enfoque de FK:** Este proyecto usa **referencias comentadas** en lugar de FK explícitas:
```sql
-- Usa columnas sin FK explícitas:
tenant_id UUID NOT NULL, -- Referencia conceptual: auth.tenants
customer_id UUID NOT NULL, -- Referencia conceptual: core.partners
assigned_to UUID, -- Referencia conceptual: auth.users
```
**Ventajas:**
- ✅ No depende del schema específico de ERP-Core
- ✅ Puede operar standalone o integrado
- ✅ Sin discrepancias con cambios en auth/core
**Desventajas:**
- ⚠️ No hay integridad referencial a nivel de BD
- ⚠️ La integridad debe garantizarse a nivel de aplicación
**Recomendación para integración completa:**
Si se requiere integridad referencial estricta, agregar FK explícitas a `auth.tenants` y `auth.users` (no `core.*`).
---
## MAPEO DE NOMENCLATURA
@ -232,11 +283,39 @@ GROUP BY schemaname;
---
## SPECS DEL CORE APLICABLES
Según el [MAPEO-SPECS-VERTICALES.md](../../../../erp-core/docs/04-modelado/MAPEO-SPECS-VERTICALES.md):
| Categoría | Total | Obligatorias | Opcionales | No Aplican |
|-----------|-------|--------------|------------|------------|
| **Mecánicas-Diesel** | 30 | 23 | 2 | 5 |
### SPECS Críticas para Mecánicas-Diesel
| SPEC | Aplicación | Estado DDL |
|------|------------|------------|
| SPEC-VALORACION-INVENTARIO | Costeo de refacciones | ✅ DDL LISTO |
| SPEC-TRAZABILIDAD-LOTES-SERIES | Garantías de partes | ✅ DDL LISTO |
| SPEC-INVENTARIOS-CICLICOS | Conteos de refacciones | ✅ DDL LISTO |
| SPEC-PRICING-RULES | Precios por tipo de servicio | PENDIENTE |
| SPEC-MAIL-THREAD-TRACKING | Historial de órdenes | PENDIENTE |
### SPECS No Aplicables
- `SPEC-INTEGRACION-CALENDAR` - No requiere calendario externo
- `SPEC-PROYECTOS-DEPENDENCIAS-BURNDOWN` - No aplica a taller mecánico
- `SPEC-FIRMA-ELECTRONICA-NOM151` - Opcional
- `SPEC-OAUTH2-SOCIAL-LOGIN` - Opcional
- `SPEC-CONSOLIDACION-FINANCIERA` - Opcional
---
## REFERENCIAS
- ERP Core DDL: `apps/erp-core/database/ddl/`
- ERP Core README: `apps/erp-core/database/README.md`
- HERENCIA-SPECS-ERP-CORE.md: `orchestration/00-guidelines/`
- MAPEO-SPECS-VERTICALES: `apps/erp-core/docs/04-modelado/MAPEO-SPECS-VERTICALES.md`
- DATABASE_INVENTORY.yml: `orchestration/inventarios/`
---

View File

@ -0,0 +1,122 @@
# Herencia SIMCO - ERP Mecánicas Diesel
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Fecha:** 2025-12-08
---
## Configuración del Proyecto
| Propiedad | Valor |
|-----------|-------|
| **Proyecto** | ERP Mecánicas Diesel - Vertical para Talleres |
| **Nivel** | VERTICAL (Nivel 3) |
| **Padre** | erp-core |
| **Suite** | erp-suite |
| **SIMCO Version** | 2.2.0 |
| **CAPVED** | Habilitado |
| **CCA Protocol** | Habilitado |
| **Estado** | 0% - Por iniciar |
## Jerarquía de Herencia
```
Nivel 0: core/orchestration/ ← FUENTE PRINCIPAL
└── Nivel 1: erp-suite/orchestration/
└── Nivel 2: erp-core/orchestration/ ← PADRE DIRECTO
└── Nivel 3: mecanicas-diesel/orchestration/ ← ESTE PROYECTO
```
---
## Directivas Heredadas de CORE (OBLIGATORIAS)
### Ciclo de Vida
| Alias | Propósito |
|-------|-----------|
| `@TAREA` | Punto de entrada para toda HU |
| `@CAPVED` | Ciclo de 6 fases |
| `@INICIALIZACION` | Bootstrap de agentes |
### Operaciones Universales
| Alias | Propósito |
|-------|-----------|
| `@CREAR` | Crear archivos nuevos |
| `@MODIFICAR` | Modificar existentes |
| `@VALIDAR` | Validar código |
| `@DOCUMENTAR` | Documentar trabajo |
| `@BUSCAR` | Buscar información |
| `@DELEGAR` | Delegar a subagentes |
### Principios Fundamentales
| Alias | Resumen |
|-------|---------|
| `@CAPVED` | Toda tarea pasa por 6 fases |
| `@DOC_PRIMERO` | Consultar docs/ antes de implementar |
| `@ANTI_DUP` | Verificar que no existe |
| `@VALIDACION` | Build y lint DEBEN pasar |
| `@TOKENS` | Desglosar tareas grandes |
---
## Directivas por Dominio Técnico
| Alias | Aplica | Notas |
|-------|--------|-------|
| `@OP_DDL` | **SÍ** | Schemas de taller |
| `@OP_BACKEND` | **SÍ** | Servicios de OT, diagnóstico |
| `@OP_FRONTEND` | **SÍ** | UI de taller |
| `@OP_MOBILE` | **SÍ** | App de técnicos |
| `@OP_ML` | Futuro | Diagnóstico predictivo |
---
## Patrones Heredados (OBLIGATORIOS)
Todos los patrones de `core/orchestration/patrones/` aplican.
---
## Directivas Heredadas de ERP Core
| Directiva | Extensión Local |
|-----------|-----------------|
| `DIRECTIVA-MULTI-TENANT.md` | Por `taller_id` |
| `DIRECTIVA-EXTENSION-VERTICALES.md` | Módulos de taller |
---
## Variables de Contexto CCA
```yaml
PROJECT_NAME: "mecanicas-diesel"
PROJECT_LEVEL: "VERTICAL"
PROJECT_ROOT: "/home/isem/workspace/projects/erp-suite/apps/verticales/mecanicas-diesel"
PARENT_PROJECT: "erp-core"
SUITE_PROJECT: "erp-suite"
DB_DDL_PATH: "database/ddl"
BACKEND_ROOT: "backend/src"
FRONTEND_ROOT: "frontend/src"
TENANT_COLUMN: "taller_id"
RLS_CONTEXT: "app.current_taller_id"
```
---
## Módulos Específicos de Mecánicas (Por definir)
| Módulo | Descripción | Estado |
|--------|-------------|--------|
| MEC-OT | Órdenes de trabajo | Por definir |
| MEC-DIA | Diagnóstico | Por definir |
| MEC-REP | Refacciones | Por definir |
| MEC-VEH | Vehículos/clientes | Por definir |
| MEC-TEC | Técnicos | Por definir |
---
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Nivel:** VERTICAL (3)
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,177 @@
# =============================================================================
# PROJECT-ENV-CONFIG.yml - ERP MECANICAS DIESEL
# =============================================================================
# Vertical de ERP-Suite especializada en Talleres Mecánicos Diesel
# Actualizado: 2025-12-08
# Referencia: ~/workspace/core/devtools/environment/DEVENV-PORTS.md
# =============================================================================
project:
name: "ERP-MECANICAS-DIESEL"
code: "MMD"
description: "Sistema para Talleres Mecánicos Especializados en Vehículos Diesel"
type: "vertical"
level: "2B.2"
status: "development"
parent: "erp-suite"
paths:
root: "/home/isem/workspace/projects/erp-suite/apps/verticales/mecanicas-diesel"
backend: "backend/"
frontend: "frontend/"
database: "database/"
docs: "docs/"
orchestration: "orchestration/"
# =============================================================================
# PUERTOS (Según DEVENV-PORTS.md)
# =============================================================================
ports:
backend: 3300
frontend: 5176
database: 5435
redis: 6382
# =============================================================================
# BASE DE DATOS
# =============================================================================
database:
type: "postgresql"
host: "localhost"
port: 5435
name: "mecanicas_diesel_db"
user: "mecanicas_user"
schemas:
core_inherited: 12 # Schemas heredados de erp-core
vertical_specific:
- service_management # Órdenes trabajo, técnicos
- parts_management # Refacciones, compatibilidad
- vehicle_management # Vehículos, marcas, modelos
migration:
tool: "typeorm"
directory: "database/migrations/"
# =============================================================================
# STACK TECNOLOGICO
# =============================================================================
stack:
runtime: "Node.js 20+"
language: "TypeScript 5.3+"
backend:
framework: "Express.js"
orm: "TypeORM 0.3.17"
frontend:
framework: "React 18"
build: "Vite"
ui: "Tailwind CSS + shadcn/ui"
# =============================================================================
# HERENCIA DEL CORE
# =============================================================================
core_inheritance:
version: "0.6.0"
tables_inherited: 97
modules_inherited:
- auth
- users
- roles
- tenants
- inventory
- sales
specs_applicable: 6
specs_implemented: 0
specs_detail:
- SPEC-VALORACION-INVENTARIO
- SPEC-TRAZABILIDAD-LOTES-SERIES
- SPEC-PRICING-RULES
- SPEC-INVENTARIOS-CICLICOS
- SPEC-FACTURACION-CFDI
- SPEC-MAIL-THREAD-TRACKING
# =============================================================================
# MODULOS DE LA VERTICAL
# =============================================================================
modules:
total: 5
story_points: 186
list:
- code: MMD-001
name: Fundamentos
sp: 42
priority: P0
status: pending
- code: MMD-002
name: Órdenes de Trabajo
sp: 55
priority: P0
status: pending
- code: MMD-003
name: Inventario Refacciones
sp: 42
priority: P0
status: pending
- code: MMD-004
name: Cotizaciones
sp: 26
priority: P0
status: pending
- code: MMD-005
name: Facturación
sp: 21
priority: P0
status: pending
# =============================================================================
# DOMINIO ESPECIFICO
# =============================================================================
domain:
work_order_states:
- RECIBIDO
- DIAGNOSTICO
- PRESUPUESTO
- APROBADO
- EN_PROCESO
- COMPLETADO
- ENTREGADO
part_compatibility:
description: "Matriz de compatibilidad marca/modelo/año"
fields:
- partId
- vehicleBrandId
- vehicleModelId
- yearFrom
- yearTo
# =============================================================================
# ARCHIVOS DE ENTORNO
# =============================================================================
env_files:
template: "orchestration/environment/.env.example"
backend: "backend/.env"
frontend: "frontend/.env"
docker_compose: "docker-compose.yml"
env_variables:
required:
- NODE_ENV
- PORT
- DATABASE_URL
- JWT_SECRET
- REDIS_URL
optional:
- LOG_LEVEL
- CORS_ORIGIN
# =============================================================================
# NOTAS
# =============================================================================
notes: |
- Vertical especializada en talleres mecánicos diesel
- Flujo de órdenes de trabajo con 7 estados
- Matriz de compatibilidad de refacciones por vehículo
- Integración con CFDI para facturación de servicios
- Puertos asignados según DEVENV-PORTS.md (rango 3300)

View File

@ -107,19 +107,42 @@ catalogo_motores:
estado_implementacion:
ddl_archivos:
existentes:
- archivo: "ddl/01-create-schemas.sql"
lineas: ~500
estado: EXISTE
- archivo: "ddl/02-tables.sql"
lineas: ~1000
estado: EXISTE
total_lineas_sql: 1561
- archivo: "init/00-extensions.sql"
lineas: 14
estado: VALIDO
- archivo: "init/01-create-schemas.sql"
lineas: 30
estado: VALIDO
- archivo: "init/02-rls-functions.sql"
lineas: 106
estado: VALIDO
- archivo: "init/03-service-management-tables.sql"
lineas: 567
tablas: 18
estado: VALIDO
- archivo: "init/04-parts-management-tables.sql"
lineas: 398
tablas: 12
estado: VALIDO
- archivo: "init/05-vehicle-management-tables.sql"
lineas: 365
tablas: 8
estado: VALIDO
total_lineas_sql: 1480
database:
tablas_core_heredadas: 97
tablas_especificas_ddl: "30+ (en archivos DDL)"
tablas_especificas_ddl: 38
schemas_especificos: 3
estado: "DDL DEFINIDO - PENDIENTE CARGA"
estado: "DDL_VALIDADO"
validacion_ddl:
fecha: "2025-12-08"
estado: "✅ VÁLIDO"
discrepancias: 0
enfoque_fk: "referencias_comentadas"
compatible_erp_core: true
nota: "Sin FK explícitas a auth.* - puede operar standalone"
backend:
porcentaje: "0%"

View File

@ -6,21 +6,49 @@ proyecto:
nombre: ERP Mecanicas Diesel
codigo: mecanicas-diesel
nivel: 2B.2 (Vertical)
estado: Planificacion
version: 0.1.0
estado: DDL_IMPLEMENTADO
version: 0.2.0
path: /home/isem/workspace/projects/erp-suite/apps/verticales/mecanicas-diesel
herencia:
- erp-core (60-70% funcionalidad base)
- core (directivas globales)
resumen_general:
total_schemas: 0
total_tablas: 0
total_schemas: 3
total_tablas: 38
total_servicios_backend: 0
total_componentes_frontend: 0
test_coverage: N/A
ultima_actualizacion: 2025-12-08
# =============================================================================
# VALIDACION DDL (2025-12-08)
# =============================================================================
validacion_ddl:
fecha: "2025-12-08"
estado: "✅ VÁLIDO"
compatible_erp_core: true
total_archivos_ddl: 6
total_lineas_sql: 1480
archivos_validados:
- archivo: "init/00-extensions.sql"
estado: VALIDO
- archivo: "init/01-create-schemas.sql"
estado: VALIDO
- archivo: "init/02-rls-functions.sql"
estado: VALIDO
- archivo: "init/03-service-management-tables.sql"
tablas: 18
estado: VALIDO
- archivo: "init/04-parts-management-tables.sql"
tablas: 12
estado: VALIDO
- archivo: "init/05-vehicle-management-tables.sql"
tablas: 8
estado: VALIDO
enfoque_fk: "referencias_comentadas"
nota: "Sin FK explícitas a auth.* - compatible standalone y con ERP-Core"
modulos_planificados:
- codigo: MD-001
nombre: Ordenes de Trabajo
@ -79,3 +107,17 @@ referencias:
orchestration: orchestration/
contexto: orchestration/00-guidelines/CONTEXTO-PROYECTO.md
herencia: orchestration/00-guidelines/HERENCIA-DIRECTIVAS.md
herencia_erp_core: database/HERENCIA-ERP-CORE.md
# =============================================================================
# METADATA
# =============================================================================
metadata:
creado_por: Requirements-Analyst
fecha_creacion: 2025-12-08
ultima_actualizacion: 2025-12-08
version_documento: 0.2.0
cambios_version:
- "0.2.0: Validacion DDL completada (2025-12-08)"
- "0.2.0: Estado actualizado a DDL_IMPLEMENTADO"
- "0.2.0: Conteos de schemas/tablas actualizados"

View File

@ -38,10 +38,67 @@ trazabilidad:
backend: [InvoiceService]
frontend: [InvoiceGenerator]
# =============================================================================
# REFERENCIAS CRUZADAS CON ERP-CORE
# =============================================================================
referencias_core:
specs_aplicables: 25
specs_implementadas: 0
specs_pendientes:
- spec: SPEC-SISTEMA-SECUENCIAS
modulos: [MMD-001, MMD-002]
prioridad: P0
estado: PENDIENTE
- spec: SPEC-VALORACION-INVENTARIO
modulos: [MMD-003]
prioridad: P0
estado: PENDIENTE
adaptacion: "Valorización de refacciones"
- spec: SPEC-TRAZABILIDAD-LOTES-SERIES
modulos: [MMD-003]
prioridad: P0
estado: PENDIENTE
adaptacion: "Trazabilidad de refacciones por número de serie"
- spec: SPEC-PRICING-RULES
modulos: [MMD-004]
prioridad: P0
estado: PENDIENTE
adaptacion: "Precios por tipo de servicio y vehículo"
- spec: SPEC-MAIL-THREAD-TRACKING
modulos: [MMD-002, MMD-004]
prioridad: P1
estado: PENDIENTE
adaptacion: "Comunicación con clientes sobre órdenes"
- spec: SPEC-FACTURACION-CFDI
modulos: [MMD-005]
prioridad: P0
estado: PENDIENTE
modulos_extendidos:
- core: MGN-001 (auth)
vertical: MMD-001
tipo: herencia_directa
- core: MGN-011 (inventory)
vertical: MMD-003
tipo: extension_refacciones
- core: MGN-013 (sales)
vertical: MMD-004
tipo: extension_cotizaciones
resumen:
modulos: 5
tablas_planificadas: 11
servicios_planificados: 6
componentes_planificados: 15
specs_core_aplicables: 25
specs_implementadas: 0
estado: PLANIFICACION
ultima_actualizacion: 2025-12-08

View File

@ -0,0 +1,154 @@
# Prompt: Mecánicas Diesel Backend Agent
## Identidad
Eres un agente especializado en desarrollo backend para ERP Mecánicas Diesel. Tu expertise está en Node.js, Express, TypeScript, TypeORM y PostgreSQL, con conocimiento específico del dominio de talleres mecánicos especializados en vehículos diesel.
## Contexto del Proyecto
```yaml
proyecto: ERP Mecánicas Diesel
codigo: MMD
tipo: Vertical de ERP-Suite
nivel: 2B.2
stack:
runtime: Node.js 20+
framework: Express.js
lenguaje: TypeScript 5.3+
orm: TypeORM 0.3.17
database: PostgreSQL 15+
auth: JWT + bcryptjs (heredado de core)
paths:
vertical: /home/isem/workspace/projects/erp-suite/apps/verticales/mecanicas-diesel/
backend: /home/isem/workspace/projects/erp-suite/apps/verticales/mecanicas-diesel/backend/
docs: /home/isem/workspace/projects/erp-suite/apps/verticales/mecanicas-diesel/docs/
core: /home/isem/workspace/projects/erp-suite/apps/erp-core/
directivas: orchestration/directivas/
puertos:
backend: 3300
frontend: 5176
database: 5435
```
## Herencia del Core
Este proyecto HEREDA del ERP-Core:
- Módulos: auth, users, roles, tenants, inventory, sales
- SPECS: Ver `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
- Base de datos: 97 tablas heredadas
**REGLA:** Extender, NUNCA modificar el core.
## Módulos de la Vertical
| Módulo | Descripción | SP | Prioridad |
|--------|-------------|---:|-----------|
| MMD-001 | Fundamentos | 42 | P0 |
| MMD-002 | Órdenes de Trabajo | 55 | P0 |
| MMD-003 | Inventario Refacciones | 42 | P0 |
| MMD-004 | Cotizaciones | 26 | P0 |
| MMD-005 | Facturación | 21 | P0 |
## Directivas Obligatorias
### 1. Multi-Tenant (Heredada)
```
OBLIGATORIO: Toda operación debe filtrar por tenant_id.
Ver: core/orchestration/directivas/DIRECTIVA-MULTI-TENANT.md
```
### 2. Órdenes de Trabajo
```
ESPECÍFICO: Flujo de órdenes de servicio.
Ver: directivas/DIRECTIVA-ORDENES-TRABAJO.md
```
### 3. Inventario Refacciones
```
ESPECÍFICO: Control de refacciones y compatibilidad.
Ver: directivas/DIRECTIVA-INVENTARIO-REFACCIONES.md
```
## Estructura de Módulo
```
backend/src/modules/{nombre}/
├── {nombre}.module.ts
├── {nombre}.controller.ts
├── {nombre}.service.ts
├── {nombre}.entity.ts
├── dto/
│ ├── create-{nombre}.dto.ts
│ └── update-{nombre}.dto.ts
└── __tests__/
└── {nombre}.service.spec.ts
```
## Schemas de Base de Datos
```yaml
schemas_especificos:
- service_management: Órdenes trabajo, técnicos
- parts_management: Refacciones, compatibilidad
- vehicle_management: Vehículos, marcas, modelos
```
## SPECS del Core Aplicables
- SPEC-VALORACION-INVENTARIO (refacciones)
- SPEC-TRAZABILIDAD-LOTES-SERIES (números de serie)
- SPEC-PRICING-RULES (precios por servicio/vehículo)
- SPEC-INVENTARIOS-CICLICOS (conteos de refacciones)
- SPEC-FACTURACION-CFDI (servicios mecánicos)
- SPEC-MAIL-THREAD-TRACKING (comunicación clientes)
## Dominio Específico
### Órdenes de Trabajo
```yaml
estados_orden:
- RECIBIDO: Vehículo recibido en taller
- DIAGNOSTICO: En diagnóstico
- PRESUPUESTO: Cotización enviada
- APROBADO: Cliente aprobó
- EN_PROCESO: En reparación
- COMPLETADO: Reparación terminada
- ENTREGADO: Vehículo entregado
```
### Compatibilidad de Refacciones
```typescript
// Matriz de compatibilidad marca/modelo/año
interface PartCompatibility {
partId: string;
vehicleBrandId: string;
vehicleModelId: string;
yearFrom: number;
yearTo: number;
}
```
## Flujo de Trabajo
```
1. Leer especificación del módulo en docs/02-definicion-modulos/
2. Verificar SPECS aplicables en HERENCIA-SPECS-CORE.md
3. Revisar DDL existente en database/
4. Implementar siguiendo estructura de módulo
5. Actualizar TRAZA-TAREAS-BACKEND.md
6. Actualizar BACKEND_INVENTORY.yml
```
## Referencias
- Inventario: `orchestration/inventarios/MASTER_INVENTORY.yml`
- Trazabilidad: `orchestration/inventarios/TRACEABILITY_MATRIX.yml`
- Herencia: `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
- Core directivas: `/home/isem/workspace/core/orchestration/directivas/`
---
**Versión:** 1.0.0
**Sistema:** SIMCO v2.2.0

View File

@ -0,0 +1,129 @@
# ===========================================
# RETAIL / POS - Variables de Entorno
# ===========================================
# Copiar este archivo a .env y configurar valores
# Puertos según DEVENV-PORTS.md
# -------------------------------------------
# BASE DE DATOS POSTGRESQL
# -------------------------------------------
DB_HOST=localhost
DB_PORT=5436
DB_NAME=retail_db
DB_USER=retail_user
DB_PASSWORD=retail_secret_2025
# URL de conexion completa
DATABASE_URL=postgresql://${DB_USER}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_NAME}
# -------------------------------------------
# SCHEMAS DE BASE DE DATOS
# -------------------------------------------
# Schemas heredados de erp-core
DB_SCHEMA_AUTH=auth
DB_SCHEMA_CORE=core
DB_SCHEMA_INVENTORY=inventory
DB_SCHEMA_SALES=sales
# Schemas propios de retail
DB_SCHEMA_POS=pos
DB_SCHEMA_LOYALTY=loyalty
DB_SCHEMA_PRICING=pricing
DB_SCHEMA_ECOMMERCE=ecommerce
# -------------------------------------------
# APLICACION
# -------------------------------------------
APP_NAME=retail
APP_ENV=development
APP_PORT=3400
APP_URL=http://localhost:3400
# -------------------------------------------
# FRONTEND
# -------------------------------------------
FRONTEND_PORT=5177
FRONTEND_URL=http://localhost:5177
# -------------------------------------------
# AUTENTICACION JWT
# -------------------------------------------
JWT_SECRET=your_jwt_secret_here_change_in_production
JWT_EXPIRES_IN=24h
JWT_REFRESH_EXPIRES_IN=7d
# -------------------------------------------
# MULTI-TENANT
# -------------------------------------------
TENANT_ID_HEADER=X-Tenant-ID
TENANT_ID_PARAM=tenant_id
# -------------------------------------------
# ALMACENAMIENTO DE ARCHIVOS
# -------------------------------------------
STORAGE_TYPE=local
STORAGE_PATH=./uploads
# -------------------------------------------
# NOTIFICACIONES
# -------------------------------------------
# Email (SMTP)
SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
SMTP_USER=
SMTP_PASSWORD=
SMTP_FROM=noreply@retail-erp.com
# WhatsApp (Twilio)
TWILIO_ACCOUNT_SID=
TWILIO_AUTH_TOKEN=
TWILIO_WHATSAPP_FROM=
# -------------------------------------------
# FACTURACION ELECTRONICA (SAT)
# -------------------------------------------
SAT_ENVIRONMENT=sandbox
SAT_RFC=
SAT_CER_PATH=./certs/csd.cer
SAT_KEY_PATH=./certs/csd.key
SAT_KEY_PASSWORD=
# -------------------------------------------
# LOGGING
# -------------------------------------------
LOG_LEVEL=debug
LOG_FORMAT=json
# -------------------------------------------
# REDIS (Cache y Colas)
# -------------------------------------------
REDIS_HOST=localhost
REDIS_PORT=6383
REDIS_PASSWORD=
# -------------------------------------------
# CORS
# -------------------------------------------
CORS_ORIGIN=http://localhost:5177,http://localhost:3400
# -------------------------------------------
# PUNTO DE VENTA (POS) - Específico
# -------------------------------------------
# Modo offline
POS_OFFLINE_ENABLED=true
POS_SYNC_INTERVAL_SECONDS=30
POS_LOCAL_STORAGE=indexeddb
# Impresoras térmicas
POS_PRINTER_PROTOCOL=escpos
POS_PRINTER_WIDTH=80
# Caja
POS_CASH_DRAWER_AUTO_OPEN=true
POS_REQUIRE_CASH_COUNT_CLOSE=true
# -------------------------------------------
# ECOMMERCE (Opcional)
# -------------------------------------------
ECOMMERCE_ENABLED=false
ECOMMERCE_WEBHOOK_SECRET=

View File

@ -0,0 +1,156 @@
# ESTADO DEL PROYECTO - ERP Retail
**Proyecto:** ERP Retail (Proyecto Independiente)
**Estado:** 📋 En planificación
**Progreso:** 25%
**Última actualización:** 2025-12-08
---
## 📊 RESUMEN EJECUTIVO
| Área | Estado | Descripción |
|------|--------|-------------|
| **Documentación** | 🟡 Inicial | 10 módulos definidos, estructura base |
| **DDL/Schemas** | ❌ No iniciado | Pendiente diseño de BD |
| **Backend** | ❌ No iniciado | Pendiente desarrollo |
| **Frontend** | ❌ No iniciado | Pendiente desarrollo |
---
## 📋 MÓDULOS DEFINIDOS (10)
| Código | Nombre | Descripción | Reutilización | Estado |
|--------|--------|-------------|---------------|--------|
| RT-001 | Fundamentos | Auth, Users, Tenants | 100% core | PLANIFICADO |
| RT-002 | POS | Punto de venta | 20% core | PLANIFICADO |
| RT-003 | Inventario | Stock multi-sucursal | 60% core | PLANIFICADO |
| RT-004 | Compras | Reabastecimiento | 80% core | PLANIFICADO |
| RT-005 | Clientes | Programa fidelidad | 40% core | PLANIFICADO |
| RT-006 | Precios | Promociones y descuentos | 30% core | PLANIFICADO |
| RT-007 | Caja | Arqueos y cortes | 10% core | PLANIFICADO |
| RT-008 | Reportes | Dashboard de ventas | 70% core | PLANIFICADO |
| RT-009 | E-commerce | Tienda online | 20% core | PLANIFICADO |
| RT-010 | Facturación | CFDI 4.0 | 60% core | PLANIFICADO |
**Story Points Estimados:** 353 SP (detallado en épicas)
---
## 🏪 DOMINIO DE NEGOCIO
### Modelo de Negocio
- Cadena de tiendas minoristas
- Multi-sucursal
- Inventario centralizado y distribuido
- Programa de lealtad
### Proceso Principal
```
Cliente → POS → Pago → Factura → Actualización Inventario
Programa de Puntos
```
### Características Específicas
- Venta rápida en mostrador (POS)
- Operación offline (PWA)
- Múltiples formas de pago
- Transferencias entre sucursales
- Promociones y cupones
- Integración e-commerce
---
## 📁 ESTRUCTURA DE DOCUMENTACIÓN
```
docs/
├── 00-vision-general/
│ └── VISION-RETAIL.md ✅
├── 02-definicion-modulos/
│ ├── INDICE-MODULOS.md ✅
│ ├── RT-001-fundamentos/README.md ✅
│ ├── RT-002-pos/README.md ✅
│ ├── RT-003-inventario/README.md ✅
│ ├── RT-004-compras/README.md ✅
│ ├── RT-005-clientes/README.md ✅
│ ├── RT-006-precios/README.md ✅
│ ├── RT-007-caja/README.md ✅
│ ├── RT-008-reportes/README.md ✅
│ ├── RT-009-ecommerce/README.md ✅
│ └── RT-010-facturacion/README.md ✅
└── 08-epicas/
└── EPIC-RT-001-fundamentos.md ✅
```
---
## 🎯 PRÓXIMOS PASOS
### Fase 1: Documentación Detallada
1. [ ] Crear épicas completas (EPIC-RT-002 a 010)
2. [ ] Documentar User Stories por módulo
3. [ ] Definir requerimientos funcionales (RF)
4. [ ] Crear especificaciones técnicas (ET)
### Fase 2: Diseño de Base de Datos
5. [ ] Diseñar schemas de BD
6. [ ] Implementar DDL
7. [ ] Documentar modelo de datos
### Fase 3: Desarrollo
8. [ ] Implementar backend (TypeScript/Express)
9. [ ] Implementar frontend POS (React PWA)
10. [ ] Testing
---
## 📈 MÉTRICAS
| Métrica | Valor |
|---------|-------|
| Módulos definidos | 10 |
| Épicas creadas | 10/10 ✅ |
| User Stories | 0 (pendiente) |
| Story Points | 353 |
| Archivos MD | 29 |
| Archivos SQL | 0 |
| Archivos TS | 0 |
---
## 🏗️ ARQUITECTURA
**Tipo:** Proyecto Independiente (fork conceptual del ERP-Core)
**Patrones a reutilizar del ERP-Core:**
- Multi-tenancy con RLS (para franquicias)
- Estructura de autenticación
- Patrones de inventario
- Sistema de compras
- Reportes y analytics
**Módulos 100% nuevos:**
- RT-002: POS (punto de venta con PWA)
- RT-007: Caja (arqueos y movimientos)
**Características técnicas:**
- PWA para operación offline
- Sincronización bidireccional
- Integración con hardware (impresoras, cajas)
**Opera de forma autónoma:** No requiere ERP-Core instalado
---
## 🔗 REFERENCIAS
- Índice de módulos: `docs/02-definicion-modulos/INDICE-MODULOS.md`
- Visión: `docs/00-vision-general/VISION-RETAIL.md`
- SPECS heredadas: `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
- Directivas: `orchestration/directivas/`
---
**Última actualización:** 2025-12-08

View File

@ -114,16 +114,25 @@ pricing.price_history -- Historial de precios
**Documento detallado:** `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
### Correcciones de DDL Core (2025-12-08)
El DDL del ERP-Core fue corregido para resolver FK inválidas:
1. **stock_valuation_layers**: Campos `journal_entry_id` y `journal_entry_line_id` (antes `account_move_*`)
2. **stock_move_consume_rel**: Nueva tabla de trazabilidad (antes `move_line_consume_rel`)
3. **category_stock_accounts**: FK corregida a `core.product_categories`
4. **product_categories**: ALTERs ahora apuntan a schema `core`
### SPECS Obligatorias
| Spec Core | Aplicación en Retail | SP | Estado |
|-----------|---------------------|----:|--------|
| SPEC-SISTEMA-SECUENCIAS | Foliado de tickets y facturas | 8 | PENDIENTE |
| SPEC-VALORACION-INVENTARIO | Costeo de mercancía | 21 | PENDIENTE |
| SPEC-SEGURIDAD-API-KEYS-PERMISOS | Control de acceso por sucursal | 31 | PENDIENTE |
| SPEC-SISTEMA-SECUENCIAS | Foliado de tickets y facturas | 8 | ✅ DDL LISTO |
| SPEC-VALORACION-INVENTARIO | Costeo de mercancía | 21 | ✅ DDL LISTO |
| SPEC-SEGURIDAD-API-KEYS-PERMISOS | Control de acceso por sucursal | 31 | ✅ DDL LISTO |
| SPEC-PRICING-RULES | Precios y promociones | 8 | PENDIENTE |
| SPEC-INVENTARIOS-CICLICOS | Conteos en sucursales | 13 | PENDIENTE |
| SPEC-TRAZABILIDAD-LOTES-SERIES | Productos con lote/serie | 13 | PENDIENTE |
| SPEC-INVENTARIOS-CICLICOS | Conteos en sucursales | 13 | ✅ DDL LISTO |
| SPEC-TRAZABILIDAD-LOTES-SERIES | Productos con lote/serie | 13 | ✅ DDL LISTO |
| SPEC-MAIL-THREAD-TRACKING | Comunicación con clientes | 13 | PENDIENTE |
| SPEC-WIZARD-TRANSIENT-MODEL | Wizards de cierre de caja | 8 | PENDIENTE |

View File

@ -0,0 +1,16 @@
# RT-001: Fundamentos
**Módulo:** Fundamentos
**Estado:** PLANIFICADO
## Descripción
Autenticación y usuarios por sucursal
## Funcionalidades Principales
- Por definir en fase de análisis
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,16 @@
# RT-002: Pos
**Módulo:** Pos
**Estado:** PLANIFICADO
## Descripción
Punto de venta con operación offline
## Funcionalidades Principales
- Por definir en fase de análisis
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,16 @@
# RT-003: Inventario
**Módulo:** Inventario
**Estado:** PLANIFICADO
## Descripción
Stock multi-sucursal y transferencias
## Funcionalidades Principales
- Por definir en fase de análisis
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,16 @@
# RT-004: Compras
**Módulo:** Compras
**Estado:** PLANIFICADO
## Descripción
Reabastecimiento centralizado
## Funcionalidades Principales
- Por definir en fase de análisis
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,16 @@
# RT-005: Clientes
**Módulo:** Clientes
**Estado:** PLANIFICADO
## Descripción
Programa de fidelidad y puntos
## Funcionalidades Principales
- Por definir en fase de análisis
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,16 @@
# RT-006: Precios
**Módulo:** Precios
**Estado:** PLANIFICADO
## Descripción
Promociones, descuentos y cupones
## Funcionalidades Principales
- Por definir en fase de análisis
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,16 @@
# RT-007: Caja
**Módulo:** Caja
**Estado:** PLANIFICADO
## Descripción
Sesiones, arqueos y cortes de caja
## Funcionalidades Principales
- Por definir en fase de análisis
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,16 @@
# RT-008: Reportes
**Módulo:** Reportes
**Estado:** PLANIFICADO
## Descripción
Dashboard de ventas y métricas
## Funcionalidades Principales
- Por definir en fase de análisis
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,16 @@
# RT-009: Ecommerce
**Módulo:** Ecommerce
**Estado:** PLANIFICADO
## Descripción
Tienda online y carrito
## Funcionalidades Principales
- Por definir en fase de análisis
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,16 @@
# RT-010: Facturacion
**Módulo:** Facturacion
**Estado:** PLANIFICADO
## Descripción
CFDI 4.0 y timbrado
## Funcionalidades Principales
- Por definir en fase de análisis
## SPECS Aplicables
- Ver HERENCIA-SPECS-CORE.md
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,58 @@
# Épica: Fundamentos del Sistema Retail
**Código:** EPIC-RT-001
**Módulos:** RT-001, RT-002, RT-007
**Estado:** PLANIFICADO
---
## Descripción
Implementación de los módulos fundacionales del ERP Retail, incluyendo la configuración inicial, el punto de venta básico y la gestión de caja.
---
## Objetivos
1. Configurar el ambiente heredando del ERP Core
2. Implementar el POS básico con venta rápida
3. Establecer la gestión de sesiones de caja
---
## Módulos Incluidos
| Módulo | Descripción | SP Estimados |
|--------|-------------|--------------|
| RT-001 | Fundamentos | 0 |
| RT-002 | POS | 55 |
| RT-007 | Caja | 34 |
---
## User Stories Principales
1. Como cajero, quiero abrir mi sesión de caja con un fondo inicial
2. Como cajero, quiero registrar ventas rápidamente
3. Como cajero, quiero aceptar múltiples formas de pago
4. Como supervisor, quiero cerrar caja y generar el corte
---
## Criterios de Aceptación
- [ ] Sistema de autenticación por sucursal funcional
- [ ] POS operativo con venta básica
- [ ] Apertura y cierre de caja implementados
- [ ] Tiempo de transacción < 30 segundos
---
## Story Points Totales
**89 SP**
---
**Épica fundacional**
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,251 @@
# EPICA: EPIC-RT-002 - Punto de Venta (POS)
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-RT-002 |
| **Nombre** | Punto de Venta (POS) |
| **Modulo** | pos |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P0 (Critico) |
| **Estado** | Backlog |
| **Story Points** | 55 |
| **Sprint(s)** | Sprint 2-4 |
---
## Descripcion
Sistema de punto de venta optimizado para retail. PWA que funciona offline, permite ventas rápidas con escaneo de código de barras, múltiples formas de pago, integración con programa de lealtad y sincronización automática con inventario central.
---
## Objetivo de Negocio
- Ventas rápidas (< 30 segundos por transacción)
- Operación sin interrupciones (offline)
- Control en tiempo real de ventas
- Experiencia fluida para cajeros
- Integración omnicanal
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-RT002-001 | Como cajero, quiero escanear código de barras para agregar productos rápidamente | P0 | 5 | Backlog |
| US-RT002-002 | Como cajero, quiero buscar producto por nombre si no tiene código de barras | P0 | 3 | Backlog |
| US-RT002-003 | Como cajero, quiero ver carrito de compra con totales en tiempo real | P0 | 3 | Backlog |
| US-RT002-004 | Como cajero, quiero aplicar descuento porcentual o monto fijo a la venta | P0 | 3 | Backlog |
| US-RT002-005 | Como cajero, quiero registrar pago en efectivo con cálculo de cambio | P0 | 3 | Backlog |
| US-RT002-006 | Como cajero, quiero registrar pago con tarjeta (terminal integrada) | P0 | 8 | Backlog |
| US-RT002-007 | Como cajero, quiero registrar pagos mixtos (parte efectivo, parte tarjeta) | P0 | 5 | Backlog |
| US-RT002-008 | Como cajero, quiero imprimir ticket de venta automáticamente | P0 | 3 | Backlog |
| US-RT002-009 | Como cajero, quiero que el POS funcione sin internet para no perder ventas | P0 | 8 | Backlog |
| US-RT002-010 | Como supervisor, quiero autorizar descuentos mayores al límite del cajero | P1 | 3 | Backlog |
| US-RT002-011 | Como cajero, quiero consultar puntos de cliente y aplicar canje | P1 | 5 | Backlog |
| US-RT002-012 | Como cajero, quiero cancelar venta parcial o totalmente | P1 | 3 | Backlog |
| US-RT002-013 | Como admin, quiero configurar impresoras y terminales de pago | P0 | 3 | Backlog |
**Total Story Points:** 55 SP
---
## Flujo de Venta
```
┌─────────────┐
│ INICIO │ ← Cajero listo
└──────┬──────┘
┌─────────────┐
│ ESCANER │ ← Agregar productos
└──────┬──────┘
┌─────────────┐
│ CARRITO │ ← Revisar y aplicar descuentos
└──────┬──────┘
┌─────────────┐
│ PAGO │ ← Efectivo/Tarjeta/Mixto
└──────┬──────┘
┌─────────────┐
│ TICKET │ ← Imprimir comprobante
└──────┬──────┘
┌─────────────┐
│ COMPLETADO │ ← Venta registrada
└─────────────┘
```
---
## Modos de Operación
```
┌─────────────────────────────────────────────────────────┐
│ MODOS DEL POS │
├─────────────────────────────────────────────────────────┤
│ │
│ ONLINE │
│ ├── Sincronización en tiempo real │
│ ├── Validación de stock central │
│ ├── Procesamiento de pagos con tarjeta │
│ └── Consulta de puntos de lealtad │
│ │
│ OFFLINE (PWA) │
│ ├── Catálogo de productos en cache │
│ ├── Ventas en cola para sincronizar │
│ ├── Solo pagos en efectivo │
│ ├── Cálculo local de puntos │
│ └── Sincronización automática al reconectar │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Escaneo de código de barras (cámara o lector USB)
- [ ] Búsqueda de productos por nombre/SKU
- [ ] Carrito con totales en tiempo real
- [ ] Descuentos (porcentuales y fijos)
- [ ] Pagos: efectivo, tarjeta, mixtos
- [ ] Impresión de tickets
- [ ] Modo offline con sincronización
- [ ] Consulta y canje de puntos
**No Funcionales:**
- [ ] Agregar producto < 500ms
- [ ] Cierre de venta < 3 segundos
- [ ] PWA instalable en tablet/PC
- [ ] Funcionamiento offline 24+ horas
**Tecnicos:**
- [ ] Service Workers para offline
- [ ] IndexedDB para almacenamiento local
- [ ] Integración con impresoras ESC/POS
- [ ] Integración con terminales de pago
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-RT-001 Fundamentos | Backlog | Si |
| EPIC-RT-003 Inventario | Backlog | Si |
| EPIC-RT-006 Precios | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-RT-007 Caja | Requiere ventas para arqueo |
| EPIC-RT-008 Reportes | Requiere datos de ventas |
| EPIC-RT-010 Facturacion | Requiere ventas completadas |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `pos`
- [ ] Tablas: 7 (sales, sale_items, payments, terminals, printers, offline_queue, sessions)
- [ ] Funciones: 3 (calculate_totals, apply_discount, sync_offline)
- [ ] Indices: Por fecha, cajero, terminal, ticket
**Backend:**
- [ ] Modulo: `pos`
- [ ] Entities: 6 (Sale, SaleItem, Payment, Terminal, Printer, OfflineSale)
- [ ] Endpoints: 15
- [ ] Tests: 35
**Frontend (PWA):**
- [ ] Paginas: 4 (POSMain, ProductSearch, Payment, Config)
- [ ] Componentes: 20 (Cart, ProductCard, PaymentModal, Scanner, etc.)
- [ ] Stores: 2 (posStore, offlineStore)
- [ ] Service Workers: Offline + Sync
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /api/pos/sales | Crear venta |
| GET | /api/pos/sales/:id | Detalle de venta |
| POST | /api/pos/sales/:id/items | Agregar item |
| DELETE | /api/pos/sales/:id/items/:itemId | Quitar item |
| POST | /api/pos/sales/:id/discount | Aplicar descuento |
| POST | /api/pos/sales/:id/pay | Registrar pago |
| POST | /api/pos/sales/:id/complete | Cerrar venta |
| POST | /api/pos/sales/:id/cancel | Cancelar venta |
| POST | /api/pos/sync | Sincronizar ventas offline |
| GET | /api/pos/products/search | Buscar productos |
| GET | /api/pos/products/:barcode | Buscar por código |
---
## Integraciones de Hardware
| Dispositivo | Protocolo | Notas |
|-------------|-----------|-------|
| Lector código barras | USB HID / WebSerial | Actúa como teclado |
| Impresora tickets | ESC/POS | USB o red |
| Terminal bancaria | API propietaria | Depende del proveedor |
| Cajón de dinero | Pulso via impresora | RJ-11 conectado a impresora |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Fallas de sincronización | Media | Alto | Cola de reintentos + alertas |
| Hardware incompatible | Media | Medio | Lista de dispositivos probados |
| Pérdida de datos offline | Baja | Alto | Respaldo en múltiples stores |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Diseño de UI aprobado
- [ ] Hardware de prueba disponible
## Definition of Done (DoD)
- [ ] Flujo de venta completo funcionando
- [ ] Modo offline operativo
- [ ] Integración con impresora/lector
- [ ] Tests de integración pasando
- [ ] PWA instalable y funcional
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,226 @@
# EPICA: EPIC-RT-003 - Inventario Multi-Sucursal
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-RT-003 |
| **Nombre** | Inventario Multi-Sucursal |
| **Modulo** | inventario |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P0 (Critico) |
| **Estado** | Backlog |
| **Story Points** | 42 |
| **Sprint(s)** | Sprint 3-4 |
---
## Descripcion
Gestión de inventario para cadenas de tiendas minoristas. Control de stock por sucursal, transferencias entre tiendas, recepción de mercancía, ajustes de inventario y alertas de reabastecimiento. Sincronización en tiempo real con todos los POS.
---
## Objetivo de Negocio
- Visibilidad de stock en todas las sucursales
- Evitar quiebres de stock
- Optimizar distribución de inventario
- Reducir sobre-stock y obsoletos
- Trazabilidad completa de movimientos
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-RT003-001 | Como gerente de tienda, quiero consultar stock de productos en mi sucursal | P0 | 3 | Backlog |
| US-RT003-002 | Como gerente de tienda, quiero ver stock de otras sucursales para transferencias | P0 | 3 | Backlog |
| US-RT003-003 | Como almacenista, quiero recibir mercancía de proveedor con validación de orden de compra | P0 | 5 | Backlog |
| US-RT003-004 | Como almacenista, quiero solicitar transferencia de otra sucursal para cubrir faltantes | P0 | 5 | Backlog |
| US-RT003-005 | Como almacenista, quiero confirmar recepción de transferencia para actualizar stock | P0 | 3 | Backlog |
| US-RT003-006 | Como gerente de tienda, quiero realizar ajuste de inventario con motivo documentado | P0 | 5 | Backlog |
| US-RT003-007 | Como gerente regional, quiero ver alertas de stock bajo por sucursal | P0 | 3 | Backlog |
| US-RT003-008 | Como gerente regional, quiero ver kardex de movimientos de un producto | P1 | 3 | Backlog |
| US-RT003-009 | Como gerente de tienda, quiero realizar inventario físico con conteo ciego | P1 | 5 | Backlog |
| US-RT003-010 | Como admin, quiero configurar stock mínimo y máximo por producto/sucursal | P0 | 3 | Backlog |
| US-RT003-011 | Como gerente regional, quiero ver valorización de inventario por sucursal | P1 | 4 | Backlog |
**Total Story Points:** 42 SP
---
## Tipos de Movimiento
```
ENTRADA
├── Compra a proveedor
├── Transferencia recibida
├── Devolución de cliente
└── Ajuste positivo
SALIDA
├── Venta POS
├── Transferencia enviada
├── Merma/Robo
├── Ajuste negativo
└── Devolución a proveedor
RESERVA
├── Apartado de cliente
└── Pedido e-commerce
```
---
## Flujo de Transferencia
```
SUCURSAL ORIGEN SUCURSAL DESTINO
│ │
▼ │
┌─────────────┐ │
│ SOLICITUD │ ◄────────────────────────┘
└──────┬──────┘ (crea solicitud)
┌─────────────┐
│ APROBADA │ ← Gerente origen aprueba
└──────┬──────┘
┌─────────────┐
│ EN_TRANSITO│ ← Mercancía en camino
└──────┬──────┘
┌─────────────┐
│ RECIBIDA │ ← Destino confirma recepción
└─────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Consultar stock por producto y sucursal
- [ ] Recibir mercancía con validación de OC
- [ ] Crear y aprobar transferencias
- [ ] Ajustes de inventario con motivo
- [ ] Alertas de stock bajo
- [ ] Kardex de movimientos
- [ ] Inventario físico con conteo ciego
- [ ] Valorización por sucursal
**No Funcionales:**
- [ ] Consulta de stock < 500ms
- [ ] Sincronización con POS < 5 segundos
- [ ] Historial de 2 años de movimientos
**Tecnicos:**
- [ ] Integración con módulo POS
- [ ] Integración con módulo Compras
- [ ] Eventos de stock para e-commerce
- [ ] Reportes de inventario
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-RT-001 Fundamentos | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-RT-002 POS | Requiere stock para vender |
| EPIC-RT-004 Compras | Requiere control de entradas |
| EPIC-RT-009 E-commerce | Requiere disponibilidad de stock |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `inventory`
- [ ] Tablas: 8 (stock, stock_movements, transfers, transfer_items, adjustments, counts, locations, alerts)
- [ ] Funciones: 4 (update_stock, create_movement, check_alerts, valuate_stock)
- [ ] Indices: Por producto, sucursal, fecha, tipo
**Backend:**
- [ ] Modulo: `inventory`
- [ ] Entities: 7 (Stock, StockMovement, Transfer, TransferItem, Adjustment, PhysicalCount, Alert)
- [ ] Endpoints: 18
- [ ] Tests: 35
**Frontend:**
- [ ] Paginas: 6 (StockList, Movements, Transfers, Adjustments, PhysicalCount, Alerts)
- [ ] Componentes: 15 (StockCard, MovementForm, TransferModal, CountSheet, etc.)
- [ ] Stores: 1 (inventoryStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| GET | /api/inventory/stock | Consultar stock (filtros) |
| GET | /api/inventory/stock/:productId | Stock de producto en todas las sucursales |
| POST | /api/inventory/receipts | Recibir mercancía |
| POST | /api/inventory/transfers | Crear transferencia |
| PATCH | /api/inventory/transfers/:id | Actualizar estado |
| POST | /api/inventory/adjustments | Crear ajuste |
| GET | /api/inventory/kardex/:productId | Kardex de producto |
| POST | /api/inventory/counts | Iniciar inventario físico |
| POST | /api/inventory/counts/:id/items | Registrar conteo |
| POST | /api/inventory/counts/:id/close | Cerrar y ajustar |
| GET | /api/inventory/alerts | Ver alertas de stock |
| GET | /api/inventory/valuation | Valorización |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Desincronización con POS | Media | Alto | Eventos en tiempo real |
| Transferencias perdidas | Baja | Alto | Estados y confirmaciones |
| Diferencias de inventario | Alta | Medio | Inventarios frecuentes |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Motivos de ajuste definidos
- [ ] Proceso de transferencias aprobado
## Definition of Done (DoD)
- [ ] Flujo de transferencias funcionando
- [ ] Sincronización con POS operativa
- [ ] Inventario físico completo
- [ ] Alertas de stock activas
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,228 @@
# EPICA: EPIC-RT-004 - Compras y Reabastecimiento
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-RT-004 |
| **Nombre** | Compras y Reabastecimiento |
| **Modulo** | compras |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P0 (Critico) |
| **Estado** | Backlog |
| **Story Points** | 38 |
| **Sprint(s)** | Sprint 5-6 |
---
## Descripcion
Gestión de compras a proveedores para reabastecimiento de tiendas. Incluye sugerencias automáticas de compra basadas en stock mínimo, gestión de órdenes de compra, recepción de mercancía y evaluación de proveedores.
---
## Objetivo de Negocio
- Evitar quiebres de stock
- Optimizar niveles de inventario
- Negociar mejores condiciones con proveedores
- Automatizar proceso de reabastecimiento
- Control de costos de compra
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-RT004-001 | Como comprador, quiero ver sugerencias de compra basadas en stock mínimo | P0 | 5 | Backlog |
| US-RT004-002 | Como comprador, quiero crear orden de compra desde sugerencias | P0 | 5 | Backlog |
| US-RT004-003 | Como comprador, quiero agregar productos manualmente a orden de compra | P0 | 3 | Backlog |
| US-RT004-004 | Como comprador, quiero enviar orden de compra al proveedor por email | P0 | 3 | Backlog |
| US-RT004-005 | Como almacenista, quiero recibir mercancía validando contra orden de compra | P0 | 5 | Backlog |
| US-RT004-006 | Como almacenista, quiero registrar diferencias en recepción (faltantes/sobrantes) | P0 | 3 | Backlog |
| US-RT004-007 | Como comprador, quiero gestionar catálogo de proveedores con datos de contacto | P0 | 3 | Backlog |
| US-RT004-008 | Como comprador, quiero ver historial de compras por proveedor | P1 | 3 | Backlog |
| US-RT004-009 | Como gerente, quiero ver métricas de cumplimiento de proveedores | P1 | 5 | Backlog |
| US-RT004-010 | Como admin, quiero configurar lead times por proveedor para sugerencias | P2 | 3 | Backlog |
**Total Story Points:** 38 SP
---
## Flujo de Orden de Compra
```
┌─────────────┐
│ BORRADOR │ ← OC siendo creada
└──────┬──────┘
┌─────────────┐
│ CONFIRMADA │ ← Aprobada internamente
└──────┬──────┘
┌─────────────┐
│ ENVIADA │ ← Enviada al proveedor
└──────┬──────┘
├──────────────┐
▼ ▼
┌─────────────┐ ┌─────────────┐
│ RECIB_PARC │ │ RECIBIDA │
│ (parcial) │ │ (completa) │
└──────┬──────┘ └──────┬──────┘
│ │
▼ ▼
┌─────────────────────────┐
│ CERRADA │
└─────────────────────────┘
```
---
## Algoritmo de Sugerencias
```
┌─────────────────────────────────────────────────────────┐
│ CÁLCULO DE SUGERENCIA DE COMPRA │
├─────────────────────────────────────────────────────────┤
│ │
│ PARA CADA PRODUCTO: │
│ │
│ stock_actual = consultar_stock(producto, sucursal) │
│ stock_minimo = producto.stock_minimo │
│ stock_maximo = producto.stock_maximo │
│ ventas_diarias = promedio_ventas(producto, 30_dias) │
│ lead_time = proveedor.lead_time_dias │
│ │
│ punto_reorden = stock_minimo + (ventas_diarias * lead_time)
│ │
│ SI stock_actual <= punto_reorden: │
│ cantidad_sugerida = stock_maximo - stock_actual │
│ CREAR_SUGERENCIA(producto, cantidad_sugerida) │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Sugerencias automáticas de compra
- [ ] Crear OC desde sugerencias
- [ ] Agregar productos manualmente
- [ ] Enviar OC por email
- [ ] Recibir mercancía con validación
- [ ] Registrar diferencias
- [ ] Catálogo de proveedores
- [ ] Métricas de cumplimiento
**No Funcionales:**
- [ ] Cálculo de sugerencias < 30 segundos (todos los productos)
- [ ] Historial de 2 años de OC
- [ ] Soporte para 50+ proveedores
**Tecnicos:**
- [ ] Integración con módulo Inventario
- [ ] Envío de emails con PDF adjunto
- [ ] Job programado para sugerencias
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-RT-001 Fundamentos | Backlog | Si |
| EPIC-RT-003 Inventario | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-RT-003 Inventario | Recepciones actualizan stock |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `purchases`
- [ ] Tablas: 7 (purchase_orders, po_items, suppliers, supplier_products, receipts, receipt_items, suggestions)
- [ ] Funciones: 3 (calculate_suggestions, validate_receipt, evaluate_supplier)
- [ ] Indices: Por proveedor, fecha, estado
**Backend:**
- [ ] Modulo: `purchases`
- [ ] Entities: 6 (PurchaseOrder, POItem, Supplier, SupplierProduct, Receipt, Suggestion)
- [ ] Endpoints: 15
- [ ] Tests: 30
**Frontend:**
- [ ] Paginas: 5 (Suggestions, PurchaseOrders, PODetail, Suppliers, Receipts)
- [ ] Componentes: 12 (SuggestionCard, POForm, SupplierSelector, ReceiptValidator, etc.)
- [ ] Stores: 1 (purchasesStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| GET | /api/purchases/suggestions | Ver sugerencias de compra |
| POST | /api/purchases/orders | Crear orden de compra |
| GET | /api/purchases/orders/:id | Detalle de OC |
| PATCH | /api/purchases/orders/:id | Actualizar OC |
| POST | /api/purchases/orders/:id/send | Enviar a proveedor |
| POST | /api/purchases/receipts | Registrar recepción |
| GET | /api/purchases/suppliers | Listar proveedores |
| POST | /api/purchases/suppliers | Crear proveedor |
| GET | /api/purchases/suppliers/:id/metrics | Métricas de proveedor |
| POST | /api/purchases/calculate-suggestions | Recalcular sugerencias |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Sugerencias incorrectas | Media | Alto | Validación manual antes de OC |
| Proveedor no cumple | Media | Alto | Proveedores alternativos |
| Recepciones incompletas | Media | Medio | Flujo de diferencias |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Catálogo inicial de proveedores
- [ ] Lead times definidos
## Definition of Done (DoD)
- [ ] Sugerencias de compra funcionando
- [ ] Flujo completo de OC operativo
- [ ] Recepción con validación
- [ ] Métricas de proveedores
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,236 @@
# EPICA: EPIC-RT-005 - Clientes y Programa de Lealtad
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-RT-005 |
| **Nombre** | Clientes y Programa de Lealtad |
| **Modulo** | clientes |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P1 (Alto) |
| **Estado** | Backlog |
| **Story Points** | 34 |
| **Sprint(s)** | Sprint 4-5 |
---
## Descripcion
Gestión de clientes y programa de fidelización. Registro de clientes, acumulación y canje de puntos, niveles de membresía, historial de compras y comunicación personalizada. Integración con POS para experiencia fluida en punto de venta.
---
## Objetivo de Negocio
- Aumentar frecuencia de compra
- Incrementar ticket promedio
- Reducir rotación de clientes
- Conocer mejor al cliente
- Marketing personalizado
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-RT005-001 | Como cajero, quiero registrar cliente rápidamente con datos mínimos | P0 | 3 | Backlog |
| US-RT005-002 | Como cajero, quiero buscar cliente por teléfono o email para asociar venta | P0 | 3 | Backlog |
| US-RT005-003 | Como cliente, quiero acumular puntos automáticamente por mis compras | P0 | 5 | Backlog |
| US-RT005-004 | Como cajero, quiero consultar puntos del cliente en el POS | P0 | 2 | Backlog |
| US-RT005-005 | Como cajero, quiero aplicar canje de puntos como descuento en venta | P0 | 5 | Backlog |
| US-RT005-006 | Como cliente, quiero ver mi historial de compras y puntos en app/web | P1 | 5 | Backlog |
| US-RT005-007 | Como marketing, quiero segmentar clientes por nivel de compra | P1 | 3 | Backlog |
| US-RT005-008 | Como marketing, quiero enviar promociones por email a segmentos | P1 | 3 | Backlog |
| US-RT005-009 | Como admin, quiero configurar reglas de acumulación de puntos | P0 | 3 | Backlog |
| US-RT005-010 | Como admin, quiero configurar niveles de membresía con beneficios | P2 | 2 | Backlog |
**Total Story Points:** 34 SP
---
## Programa de Puntos
```
┌─────────────────────────────────────────────────────────┐
│ PROGRAMA DE LEALTAD │
├─────────────────────────────────────────────────────────┤
│ │
│ ACUMULACIÓN │
│ ├── 1 punto por cada $10 de compra (configurable) │
│ ├── Puntos extra en productos promocionales │
│ ├── Bonificación por cumpleaños │
│ └── Multiplicadores por nivel │
│ │
│ CANJE │
│ ├── 100 puntos = $10 de descuento (configurable) │
│ ├── Mínimo de puntos para canjear │
│ ├── Máximo de descuento por transacción │
│ └── Productos excluidos de canje │
│ │
│ NIVELES DE MEMBRESÍA │
│ ├── BRONCE: 0-999 puntos/año → 1x puntos │
│ ├── PLATA: 1000-4999 puntos/año → 1.5x puntos │
│ ├── ORO: 5000+ puntos/año → 2x puntos │
│ └── Beneficios adicionales por nivel │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Flujo de Puntos en Venta
```
┌─────────────┐
│ BUSCAR CLI │ ← Por teléfono o email
└──────┬──────┘
┌─────────────┐
│ VER PUNTOS │ ← Saldo disponible
└──────┬──────┘
┌─────────────┐
│ VENTA │ ← Agregar productos
└──────┬──────┘
┌─────────────┐
│ ¿CANJEAR? │ ─── Si ──► Aplicar descuento
└──────┬──────┘
│ No
┌─────────────┐
│ PAGO │ ← Cerrar venta
└──────┬──────┘
┌─────────────┐
│ + PUNTOS │ ← Acumulación automática
└─────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Registro rápido de cliente
- [ ] Búsqueda por teléfono/email
- [ ] Acumulación automática de puntos
- [ ] Canje de puntos en POS
- [ ] Historial de cliente
- [ ] Niveles de membresía
- [ ] Segmentación de clientes
- [ ] Comunicación por email
**No Funcionales:**
- [ ] Búsqueda de cliente < 500ms
- [ ] Cálculo de puntos en tiempo real
- [ ] Historial de 3 años
**Tecnicos:**
- [ ] Integración con módulo POS
- [ ] Integración con e-commerce
- [ ] Servicio de email marketing
- [ ] API para app de cliente
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-RT-001 Fundamentos | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-RT-002 POS | Integración de puntos |
| EPIC-RT-009 E-commerce | Cuenta de cliente |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `customers`
- [ ] Tablas: 7 (customers, points_transactions, membership_levels, segments, campaigns, communications, preferences)
- [ ] Funciones: 3 (calculate_points, apply_redemption, update_level)
- [ ] Indices: Por teléfono, email, nivel, puntos
**Backend:**
- [ ] Modulo: `customers`
- [ ] Entities: 6 (Customer, PointsTransaction, MembershipLevel, Segment, Campaign)
- [ ] Endpoints: 14
- [ ] Tests: 28
**Frontend:**
- [ ] Paginas: 5 (CustomerList, CustomerDetail, Segments, Campaigns, Config)
- [ ] Componentes: 12 (CustomerSearch, PointsDisplay, RedemptionModal, etc.)
- [ ] Stores: 1 (customersStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /api/customers | Crear cliente |
| GET | /api/customers/search | Buscar por teléfono/email |
| GET | /api/customers/:id | Detalle de cliente |
| GET | /api/customers/:id/points | Saldo de puntos |
| GET | /api/customers/:id/history | Historial de compras |
| POST | /api/customers/:id/earn | Acumular puntos |
| POST | /api/customers/:id/redeem | Canjear puntos |
| GET | /api/customers/segments | Listar segmentos |
| POST | /api/customers/campaigns | Crear campaña |
| POST | /api/customers/campaigns/:id/send | Enviar comunicación |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Fraude de puntos | Media | Alto | Auditoría + límites de canje |
| Clientes duplicados | Alta | Medio | Validación de teléfono/email |
| Baja adopción | Media | Medio | Capacitación a cajeros |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Reglas de puntos definidas
- [ ] Niveles de membresía aprobados
## Definition of Done (DoD)
- [ ] Programa de puntos funcionando
- [ ] Integración con POS operativa
- [ ] Niveles de membresía activos
- [ ] Segmentación de clientes
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,241 @@
# EPICA: EPIC-RT-006 - Precios y Promociones
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-RT-006 |
| **Nombre** | Precios y Promociones |
| **Modulo** | precios |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P0 (Critico) |
| **Estado** | Backlog |
| **Story Points** | 36 |
| **Sprint(s)** | Sprint 3-4 |
---
## Descripcion
Gestión de precios y promociones para retail. Listas de precios por sucursal/canal, promociones temporales, descuentos por volumen, cupones y ofertas especiales. Motor de reglas para aplicación automática en POS y e-commerce.
---
## Objetivo de Negocio
- Flexibilidad en estrategia de precios
- Promociones efectivas y controladas
- Incrementar ventas con ofertas
- Competir en diferentes canales
- Medir ROI de promociones
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-RT006-001 | Como pricing, quiero definir precio base de producto para tener referencia | P0 | 2 | Backlog |
| US-RT006-002 | Como pricing, quiero crear listas de precios por canal (tienda, online) | P0 | 5 | Backlog |
| US-RT006-003 | Como pricing, quiero crear promoción de descuento porcentual temporal | P0 | 5 | Backlog |
| US-RT006-004 | Como pricing, quiero crear promoción 2x1 o 3x2 para productos seleccionados | P0 | 5 | Backlog |
| US-RT006-005 | Como pricing, quiero crear descuento por volumen (> 10 unidades = 15% off) | P0 | 3 | Backlog |
| US-RT006-006 | Como marketing, quiero generar cupones de descuento con código único | P0 | 5 | Backlog |
| US-RT006-007 | Como cajero, quiero que el POS aplique promociones automáticamente | P0 | 5 | Backlog |
| US-RT006-008 | Como cajero, quiero escanear cupón para aplicar descuento | P0 | 3 | Backlog |
| US-RT006-009 | Como gerente, quiero ver reportes de uso de promociones | P1 | 3 | Backlog |
**Total Story Points:** 36 SP
---
## Tipos de Promociones
```
┌─────────────────────────────────────────────────────────┐
│ TIPOS DE PROMOCIONES │
├─────────────────────────────────────────────────────────┤
│ │
│ DESCUENTO PORCENTUAL │
│ ├── Aplica X% de descuento │
│ ├── Sobre productos seleccionados o categoría │
│ └── Período de vigencia │
│ │
│ DESCUENTO MONTO FIJO │
│ ├── Aplica $X de descuento │
│ ├── Requiere mínimo de compra │
│ └── Por producto o total de venta │
│ │
│ NxM (ej: 3x2) │
│ ├── Compra N productos, paga M │
│ ├── Mismo producto o mezcla │
│ └── El más barato gratis o porcentaje │
│ │
│ DESCUENTO POR VOLUMEN │
│ ├── Escalas de cantidad │
│ ├── > 5 unidades = 5% off │
│ └── > 10 unidades = 10% off │
│ │
│ CUPÓN │
│ ├── Código único o genérico │
│ ├── Un uso o múltiples usos │
│ └── Límite de usos totales │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Motor de Reglas
```
┌─────────────────────────────────────────────────────────┐
│ EVALUACIÓN DE PRECIO │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. Obtener precio base del producto │
│ │
│ 2. Aplicar lista de precios del canal │
│ └── Si existe precio específico, usarlo │
│ │
│ 3. Evaluar promociones activas │
│ ├── Ordenar por prioridad │
│ ├── Verificar condiciones (fechas, productos) │
│ └── Aplicar la mejor promoción (no acumulables) │
│ │
│ 4. Evaluar descuento por volumen │
│ └── Si cantidad supera umbral, aplicar │
│ │
│ 5. Evaluar cupón (si se proporciona) │
│ ├── Validar código │
│ ├── Verificar vigencia y usos │
│ └── Aplicar si es compatible │
│ │
│ 6. Retornar precio final con detalle de descuentos │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Definir precio base de productos
- [ ] Crear listas de precios por canal
- [ ] Crear promociones temporales
- [ ] Promociones NxM
- [ ] Descuentos por volumen
- [ ] Generar y validar cupones
- [ ] Aplicación automática en POS
- [ ] Reportes de uso
**No Funcionales:**
- [ ] Cálculo de precio < 100ms
- [ ] Soporte para 100+ promociones activas
- [ ] Historial de 1 año de promociones
**Tecnicos:**
- [ ] Motor de reglas flexible
- [ ] Integración con POS
- [ ] Integración con e-commerce
- [ ] Cache de promociones activas
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-RT-001 Fundamentos | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-RT-002 POS | Requiere precios para vender |
| EPIC-RT-009 E-commerce | Requiere precios online |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `pricing`
- [ ] Tablas: 8 (price_lists, prices, promotions, promotion_products, volume_discounts, coupons, coupon_usages, promo_logs)
- [ ] Funciones: 3 (calculate_price, validate_coupon, apply_promotion)
- [ ] Indices: Por producto, canal, fecha vigencia
**Backend:**
- [ ] Modulo: `pricing`
- [ ] Entities: 6 (PriceList, Price, Promotion, VolumeDiscount, Coupon, CouponUsage)
- [ ] Services: PricingEngine (motor de reglas)
- [ ] Endpoints: 15
- [ ] Tests: 35
**Frontend:**
- [ ] Paginas: 5 (PriceLists, Promotions, Coupons, Reports, Config)
- [ ] Componentes: 12 (PriceEditor, PromotionBuilder, CouponGenerator, etc.)
- [ ] Stores: 1 (pricingStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| GET | /api/pricing/products/:id | Obtener precio de producto |
| POST | /api/pricing/calculate | Calcular precio con promociones |
| GET | /api/pricing/lists | Listar listas de precios |
| POST | /api/pricing/lists | Crear lista de precios |
| GET | /api/pricing/promotions | Listar promociones |
| POST | /api/pricing/promotions | Crear promoción |
| PATCH | /api/pricing/promotions/:id | Actualizar promoción |
| POST | /api/pricing/coupons | Generar cupón |
| POST | /api/pricing/coupons/validate | Validar cupón |
| POST | /api/pricing/coupons/redeem | Usar cupón |
| GET | /api/pricing/reports/usage | Reporte de uso |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Promociones conflictivas | Media | Alto | Prioridades + no acumulable |
| Cupones fraudulentos | Baja | Medio | Códigos únicos + límites |
| Precios incorrectos | Media | Alto | Validación antes de activar |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Tipos de promociones definidos
- [ ] Reglas de compatibilidad claras
## Definition of Done (DoD)
- [ ] Motor de precios funcionando
- [ ] Promociones aplicándose en POS
- [ ] Cupones generándose y validándose
- [ ] Reportes de uso disponibles
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,245 @@
# EPICA: EPIC-RT-007 - Caja (Arqueos y Cortes)
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-RT-007 |
| **Nombre** | Caja (Arqueos y Cortes) |
| **Modulo** | caja |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P0 (Critico) |
| **Estado** | Backlog |
| **Story Points** | 28 |
| **Sprint(s)** | Sprint 5-6 |
---
## Descripcion
Módulo 100% nuevo para control de efectivo en tiendas. Gestión de fondos de caja, arqueos, cortes de caja, movimientos de efectivo (retiros, depósitos) y conciliación con ventas. Control de diferencias y auditoría.
---
## Objetivo de Negocio
- Control preciso de efectivo
- Prevenir faltantes y robos
- Conciliación diaria de ventas
- Auditoría de movimientos
- Responsabilidad por cajero
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-RT007-001 | Como supervisor, quiero abrir caja con fondo inicial para comenzar turno | P0 | 3 | Backlog |
| US-RT007-002 | Como cajero, quiero registrar retiro de efectivo (para depósito) | P0 | 3 | Backlog |
| US-RT007-003 | Como cajero, quiero registrar ingreso de efectivo (cambio) | P0 | 2 | Backlog |
| US-RT007-004 | Como cajero, quiero realizar arqueo parcial sin cerrar caja | P0 | 3 | Backlog |
| US-RT007-005 | Como cajero, quiero realizar corte de caja al final del turno | P0 | 5 | Backlog |
| US-RT007-006 | Como cajero, quiero declarar efectivo contado por denominación | P0 | 3 | Backlog |
| US-RT007-007 | Como supervisor, quiero aprobar corte con diferencias | P0 | 3 | Backlog |
| US-RT007-008 | Como gerente, quiero ver reporte de diferencias por cajero | P1 | 3 | Backlog |
| US-RT007-009 | Como admin, quiero configurar tolerancia de diferencias | P2 | 2 | Backlog |
| US-RT007-010 | Como auditor, quiero ver historial completo de movimientos de caja | P1 | 1 | Backlog |
**Total Story Points:** 28 SP
---
## Flujo de Caja
```
┌─────────────┐
│ CERRADA │ ← Estado inicial
└──────┬──────┘
▼ (Apertura con fondo)
┌─────────────┐
│ ABIERTA │ ◄──────────┐
└──────┬──────┘ │
│ │
▼ │
┌─────────────┐ │
│ OPERANDO │────────────┤
│ │ Ventas │
│ + Ventas │ Retiros │
│ - Retiros │ Ingresos │
│ + Ingresos │ │
└──────┬──────┘ │
│ │
▼ (Corte) │
┌─────────────┐ │
│ CORTE │ │
│ - Conteo │ │
│ - Diferenc │ │
└──────┬──────┘ │
│ │
├──── Si OK ────────┘ (Nueva apertura)
▼ (Cierre)
┌─────────────┐
│ CERRADA │
└─────────────┘
```
---
## Conteo por Denominación
```
┌─────────────────────────────────────────────────────────┐
│ DECLARACIÓN DE EFECTIVO │
├─────────────────────────────────────────────────────────┤
│ │
│ BILLETES MONEDAS │
│ ┌────────┬─────┬──────────┐ ┌────────┬─────┬─────┐ │
│ │ Denom. │ Cant│ Total │ │ Denom. │ Cant│Total│ │
│ ├────────┼─────┼──────────┤ ├────────┼─────┼─────┤ │
│ │ $1000 │ 3 │ $3,000 │ │ $20 │ 5 │$100 │ │
│ │ $500 │ 5 │ $2,500 │ │ $10 │ 8 │ $80 │ │
│ │ $200 │ 8 │ $1,600 │ │ $5 │ 10 │ $50 │ │
│ │ $100 │ 12 │ $1,200 │ │ $2 │ 15 │ $30 │ │
│ │ $50 │ 10 │ $500 │ │ $1 │ 20 │ $20 │ │
│ │ $20 │ 15 │ $300 │ │ $0.50 │ 10 │ $5 │ │
│ └────────┴─────┴──────────┘ └────────┴─────┴─────┘ │
│ │
│ TOTAL BILLETES: $9,100 │
│ TOTAL MONEDAS: $285 │
│ ───────────────────────── │
│ TOTAL DECLARADO: $9,385 │
│ │
│ ESPERADO (sistema): $9,400 │
│ DIFERENCIA: -$15 │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Apertura de caja con fondo
- [ ] Retiros e ingresos de efectivo
- [ ] Arqueos parciales
- [ ] Corte de caja con conteo
- [ ] Declaración por denominación
- [ ] Cálculo de diferencias
- [ ] Aprobación de cortes con diferencias
- [ ] Reportes de diferencias
**No Funcionales:**
- [ ] Operación < 3 clicks
- [ ] Historial de 1 año
- [ ] Auditoría completa
**Tecnicos:**
- [ ] Integración con módulo POS (ventas en efectivo)
- [ ] Bloqueo de caja durante corte
- [ ] Firmas/autorizaciones de supervisores
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-RT-001 Fundamentos | Backlog | Si |
| EPIC-RT-002 POS | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-RT-008 Reportes | Datos de caja para reportes |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `cash_register`
- [ ] Tablas: 6 (cash_sessions, cash_movements, cash_counts, count_denominations, cut_approvals, audit_log)
- [ ] Funciones: 3 (calculate_expected, calculate_difference, validate_cut)
- [ ] Indices: Por caja, cajero, fecha, estado
**Backend:**
- [ ] Modulo: `cash-register`
- [ ] Entities: 5 (CashSession, CashMovement, CashCount, CountDenomination, CutApproval)
- [ ] Endpoints: 12
- [ ] Tests: 25
**Frontend:**
- [ ] Paginas: 4 (CashDashboard, OpenClose, CashCount, Reports)
- [ ] Componentes: 10 (DenominationCounter, MovementForm, DifferenceAlert, etc.)
- [ ] Stores: 1 (cashStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /api/cash/sessions/open | Abrir caja |
| POST | /api/cash/sessions/:id/close | Cerrar caja |
| GET | /api/cash/sessions/current | Sesión actual |
| POST | /api/cash/movements | Registrar movimiento |
| POST | /api/cash/counts | Registrar arqueo |
| POST | /api/cash/counts/:id/denominations | Agregar denominaciones |
| POST | /api/cash/counts/:id/submit | Enviar para aprobación |
| POST | /api/cash/counts/:id/approve | Aprobar corte |
| GET | /api/cash/reports/differences | Reporte de diferencias |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Faltantes de efectivo | Media | Alto | Arqueos frecuentes |
| Manipulación de cortes | Baja | Alto | Doble aprobación |
| Errores de conteo | Media | Medio | Conteo por denominación |
---
## Nota Técnica
Este módulo es **100% nuevo** y no tiene equivalente en el ERP-Core. Es específico para operaciones de retail con manejo de efectivo.
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Denominaciones locales definidas
- [ ] Tolerancias de diferencia aprobadas
## Definition of Done (DoD)
- [ ] Flujo de apertura/cierre funcionando
- [ ] Conteo por denominación operativo
- [ ] Cálculo de diferencias correcto
- [ ] Reportes de auditoría
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,256 @@
# EPICA: EPIC-RT-008 - Reportes y Dashboard
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-RT-008 |
| **Nombre** | Reportes y Dashboard |
| **Modulo** | reportes |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P1 (Alto) |
| **Estado** | Backlog |
| **Story Points** | 30 |
| **Sprint(s)** | Sprint 7-8 |
---
## Descripcion
Dashboard ejecutivo y reportes operativos para retail. Visualización de ventas en tiempo real, comparativos por sucursal, análisis de productos, tendencias y KPIs clave. Exportación a Excel/PDF para análisis offline.
---
## Objetivo de Negocio
- Visibilidad en tiempo real de operaciones
- Toma de decisiones basada en datos
- Identificar oportunidades y problemas
- Comparar rendimiento entre sucursales
- Medir efectividad de promociones
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-RT008-001 | Como gerente general, quiero ver dashboard de ventas del día por sucursal | P0 | 5 | Backlog |
| US-RT008-002 | Como gerente general, quiero comparar ventas vs mismo día semana anterior | P0 | 3 | Backlog |
| US-RT008-003 | Como gerente de tienda, quiero ver ranking de productos más vendidos | P0 | 3 | Backlog |
| US-RT008-004 | Como gerente de tienda, quiero ver reporte de ventas por hora del día | P1 | 3 | Backlog |
| US-RT008-005 | Como gerente regional, quiero comparar rendimiento entre sucursales | P0 | 5 | Backlog |
| US-RT008-006 | Como comprador, quiero ver productos con baja rotación | P1 | 3 | Backlog |
| US-RT008-007 | Como marketing, quiero ver efectividad de promociones activas | P1 | 3 | Backlog |
| US-RT008-008 | Como gerente, quiero exportar reportes a Excel para análisis | P0 | 3 | Backlog |
| US-RT008-009 | Como admin, quiero configurar dashboards personalizados | P2 | 2 | Backlog |
**Total Story Points:** 30 SP
---
## KPIs Principales
```
┌─────────────────────────────────────────────────────────┐
│ DASHBOARD DE VENTAS │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ VENTAS HOY │ │ TRANSACCIONES│ │ TICKET PROM. │ │
│ │ $45,230 │ │ 127 │ │ $356 │ │
│ │ ▲ 12% │ │ ▲ 8% │ │ ▲ 4% │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ CLIENTES │ │ PUNTOS USADOS│ │ DEVOLUCIONES │ │
│ │ 89 │ │ 2,350 │ │ $450 │ │
│ │ ▲ 15% │ │ ▲ 22% │ │ ▼ 5% │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ VENTAS POR HORA │
│ ┌────────────────────────────────────────────────────┐ │
│ │ ▄▄ │ │
│ │ ████ ▄▄▄▄ ▄▄▄▄ │ │
│ │ ██████ ████████ ▄▄▄▄ ████████ ▄▄ │ │
│ │ ████████ ████████████████████ ████████████████ │ │
│ │ ──────────────────────────────────────────────────│ │
│ │ 08 09 10 11 12 13 14 15 16 17 18 19 20 21 │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ TOP 5 PRODUCTOS │
│ ┌────────────────────────────────────────────────────┐ │
│ │ 1. Producto A ████████████████████ $8,500 (18.8%) │ │
│ │ 2. Producto B ██████████████ $6,200 (13.7%) │ │
│ │ 3. Producto C ███████████ $5,100 (11.3%) │ │
│ │ 4. Producto D ████████ $3,800 (8.4%) │ │
│ │ 5. Producto E ██████ $2,900 (6.4%) │ │
│ └────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Reportes Disponibles
```
┌─────────────────────────────────────────────────────────┐
│ CATÁLOGO DE REPORTES │
├─────────────────────────────────────────────────────────┤
│ │
│ VENTAS │
│ ├── Ventas diarias por sucursal │
│ ├── Ventas por hora │
│ ├── Ventas por categoría │
│ ├── Ventas por cajero │
│ └── Comparativo periodo anterior │
│ │
│ PRODUCTOS │
│ ├── Ranking de productos │
│ ├── Productos sin movimiento │
│ ├── Análisis ABC │
│ └── Margen por producto │
│ │
│ INVENTARIO │
│ ├── Stock actual por sucursal │
│ ├── Alertas de stock bajo │
│ ├── Transferencias pendientes │
│ └── Valorización de inventario │
│ │
│ CLIENTES │
│ ├── Clientes nuevos vs recurrentes │
│ ├── Top clientes por compra │
│ ├── Uso de programa de puntos │
│ └── Segmentación de clientes │
│ │
│ PROMOCIONES │
│ ├── Uso de promociones activas │
│ ├── Cupones redimidos │
│ └── ROI de promociones │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Dashboard en tiempo real
- [ ] Comparativos con período anterior
- [ ] Filtros por sucursal, fecha, categoría
- [ ] Ranking de productos
- [ ] Comparativo entre sucursales
- [ ] Análisis de promociones
- [ ] Exportación Excel/PDF
- [ ] Dashboards personalizables
**No Funcionales:**
- [ ] Carga de dashboard < 3 segundos
- [ ] Actualización cada 5 minutos
- [ ] Datos históricos de 2 años
**Tecnicos:**
- [ ] Agregación eficiente de datos
- [ ] Caché de métricas frecuentes
- [ ] Jobs de precálculo nocturno
- [ ] Gráficos responsivos
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-RT-001 Fundamentos | Backlog | Si |
| EPIC-RT-002 POS | Backlog | Si |
| EPIC-RT-003 Inventario | Backlog | Si |
| EPIC-RT-005 Clientes | Backlog | Si |
| EPIC-RT-006 Precios | Backlog | Si |
| EPIC-RT-007 Caja | Backlog | Si |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `analytics`
- [ ] Tablas: 5 (daily_sales, hourly_metrics, product_metrics, store_metrics, custom_dashboards)
- [ ] Vistas materializadas para reportes frecuentes
- [ ] Indices optimizados para consultas analíticas
**Backend:**
- [ ] Modulo: `reports`
- [ ] Services: MetricsService, ReportGenerator
- [ ] Endpoints: 15
- [ ] Jobs: Precálculo de métricas
- [ ] Tests: 25
**Frontend:**
- [ ] Paginas: 4 (Dashboard, Reports, DashboardBuilder, Export)
- [ ] Componentes: 15 (ChartCard, MetricWidget, FilterBar, DataTable, etc.)
- [ ] Librería: Chart.js o Recharts
- [ ] Stores: 1 (reportsStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| GET | /api/reports/dashboard | Dashboard principal |
| GET | /api/reports/sales | Reporte de ventas |
| GET | /api/reports/products/ranking | Ranking de productos |
| GET | /api/reports/products/slow-moving | Productos sin rotación |
| GET | /api/reports/stores/comparison | Comparativo de sucursales |
| GET | /api/reports/customers/analysis | Análisis de clientes |
| GET | /api/reports/promotions/effectiveness | Efectividad de promociones |
| GET | /api/reports/export/:reportId | Exportar a Excel |
| GET | /api/reports/export/:reportId/pdf | Exportar a PDF |
| POST | /api/reports/custom-dashboards | Crear dashboard |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Consultas lentas | Media | Alto | Vistas materializadas + índices |
| Datos incorrectos | Baja | Alto | Validación de fuentes |
| Sobrecarga de BD | Media | Medio | Réplica de lectura |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] KPIs prioritarios definidos
- [ ] Diseño de dashboards aprobado
## Definition of Done (DoD)
- [ ] Dashboard principal funcionando
- [ ] Reportes operativos disponibles
- [ ] Exportación Excel/PDF operativa
- [ ] Performance aceptable
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,261 @@
# EPICA: EPIC-RT-009 - E-commerce
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-RT-009 |
| **Nombre** | E-commerce |
| **Modulo** | ecommerce |
| **Fase** | Fase 2 - Extensión |
| **Prioridad** | P1 (Alto) |
| **Estado** | Backlog |
| **Story Points** | 55 |
| **Sprint(s)** | Sprint 9-12 |
---
## Descripcion
Tienda online integrada con el sistema de retail. Catálogo de productos sincronizado, stock en tiempo real, carrito de compras, checkout con múltiples formas de pago, integración con programa de lealtad y opciones de entrega (envío o pickup en tienda).
---
## Objetivo de Negocio
- Canal de ventas adicional 24/7
- Experiencia omnicanal consistente
- Incrementar alcance geográfico
- Aprovechar inventario existente
- Programa de lealtad unificado
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-RT009-001 | Como cliente, quiero navegar catálogo de productos con filtros | P0 | 5 | Backlog |
| US-RT009-002 | Como cliente, quiero ver disponibilidad de stock en tiempo real | P0 | 5 | Backlog |
| US-RT009-003 | Como cliente, quiero agregar productos al carrito | P0 | 3 | Backlog |
| US-RT009-004 | Como cliente, quiero ingresar o crear cuenta para comprar | P0 | 5 | Backlog |
| US-RT009-005 | Como cliente, quiero pagar con tarjeta de crédito/débito | P0 | 8 | Backlog |
| US-RT009-006 | Como cliente, quiero elegir entre envío a domicilio o pickup en tienda | P0 | 5 | Backlog |
| US-RT009-007 | Como cliente, quiero usar mis puntos de lealtad como descuento | P1 | 5 | Backlog |
| US-RT009-008 | Como cliente, quiero ver historial de mis pedidos | P1 | 3 | Backlog |
| US-RT009-009 | Como admin, quiero gestionar pedidos online desde el backoffice | P0 | 5 | Backlog |
| US-RT009-010 | Como admin, quiero configurar zonas de envío y costos | P0 | 3 | Backlog |
| US-RT009-011 | Como marketing, quiero crear banners y promociones para la tienda | P1 | 3 | Backlog |
| US-RT009-012 | Como cliente, quiero recibir notificaciones del estado de mi pedido | P1 | 5 | Backlog |
**Total Story Points:** 55 SP
---
## Flujo de Compra
```
┌─────────────┐
│ CATÁLOGO │ ← Cliente navega productos
└──────┬──────┘
┌─────────────┐
│ CARRITO │ ← Agrega productos
└──────┬──────┘
┌─────────────┐
│ CUENTA │ ← Login o registro
└──────┬──────┘
┌─────────────┐
│ ENVÍO │ ← Domicilio o pickup
└──────┬──────┘
┌─────────────┐
│ PAGO │ ← Tarjeta + puntos
└──────┬──────┘
┌─────────────┐
│ CONFIRMADO │ ← Email de confirmación
└─────────────┘
```
---
## Estados de Pedido
```
┌─────────────┐
│ PENDIENTE │ ← Pedido creado, pago pendiente
└──────┬──────┘
┌─────────────┐
│ PAGADO │ ← Pago confirmado
└──────┬──────┘
├── Si envío ──────────────────┐
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ PREPARANDO │ │ EN_ENVÍO │
│ (pickup) │ │ │
└──────┬──────┘ └──────┬──────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│LISTO_PICKUP │ │ ENTREGADO │
└──────┬──────┘ └─────────────┘
┌─────────────┐
│ RECOGIDO │
└─────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Catálogo de productos con búsqueda y filtros
- [ ] Stock en tiempo real desde inventario
- [ ] Carrito persistente
- [ ] Registro/login de clientes
- [ ] Checkout con tarjeta de crédito
- [ ] Envío a domicilio y pickup
- [ ] Integración con puntos de lealtad
- [ ] Gestión de pedidos en backoffice
- [ ] Notificaciones de estado
**No Funcionales:**
- [ ] Tiempo de carga < 3 segundos
- [ ] SEO optimizado
- [ ] Responsive (mobile-first)
- [ ] Pasarela de pago segura (PCI-DSS)
**Tecnicos:**
- [ ] Integración con inventario multi-sucursal
- [ ] Integración con programa de lealtad
- [ ] Pasarela de pago (Stripe/Conekta)
- [ ] Servicio de envíos (ej: Fedex, DHL API)
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-RT-001 Fundamentos | Backlog | Si |
| EPIC-RT-003 Inventario | Backlog | Si |
| EPIC-RT-005 Clientes | Backlog | Si |
| EPIC-RT-006 Precios | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-RT-010 Facturacion | Requiere pedidos para facturar |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `ecommerce`
- [ ] Tablas: 10 (orders, order_items, carts, cart_items, shipping_zones, addresses, payments, banners, categories_web, product_images)
- [ ] Funciones: 3 (calculate_shipping, validate_stock, process_payment)
- [ ] Indices: Por cliente, estado, fecha
**Backend:**
- [ ] Modulo: `ecommerce`
- [ ] Entities: 8 (Order, OrderItem, Cart, CartItem, ShippingZone, Address, Payment, Banner)
- [ ] Endpoints: 25
- [ ] Tests: 45
**Frontend (Web):**
- [ ] Paginas: 10 (Home, Category, Product, Cart, Checkout, Account, Orders, etc.)
- [ ] Componentes: 25 (ProductCard, CartDrawer, CheckoutForm, OrderTracker, etc.)
- [ ] SEO: Meta tags, sitemap, schema.org
- [ ] Framework: Next.js recomendado
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| GET | /api/shop/products | Listar productos |
| GET | /api/shop/products/:id | Detalle de producto |
| GET | /api/shop/categories | Categorías |
| POST | /api/shop/cart | Crear/obtener carrito |
| POST | /api/shop/cart/items | Agregar al carrito |
| DELETE | /api/shop/cart/items/:id | Quitar del carrito |
| POST | /api/shop/checkout | Iniciar checkout |
| POST | /api/shop/orders | Crear pedido |
| GET | /api/shop/orders/:id | Detalle de pedido |
| POST | /api/shop/payments | Procesar pago |
| GET | /api/shop/shipping/zones | Zonas de envío |
| POST | /api/shop/shipping/calculate | Calcular envío |
---
## Integraciones Externas
| Servicio | Propósito | Notas |
|----------|-----------|-------|
| Stripe / Conekta | Pagos con tarjeta | PCI-DSS compliant |
| Fedex / DHL / Estafeta | Cálculo de envío | APIs de cotización |
| SendGrid / Mailgun | Emails transaccionales | Confirmación, tracking |
| Google Analytics | Tracking de conversión | E-commerce enhanced |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Stock desincronizado | Media | Alto | Eventos en tiempo real |
| Fraude con tarjetas | Media | Alto | 3DS + validaciones |
| Problemas de envío | Media | Medio | Múltiples proveedores |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Diseño de UI aprobado
- [ ] Pasarela de pago seleccionada
- [ ] Proveedores de envío definidos
## Definition of Done (DoD)
- [ ] Tienda online funcional
- [ ] Checkout completo con pago
- [ ] Integración con inventario
- [ ] Programa de lealtad integrado
- [ ] Tests E2E pasando
- [ ] SEO implementado
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,292 @@
# EPICA: EPIC-RT-010 - Facturación CFDI
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-RT-010 |
| **Nombre** | Facturación CFDI |
| **Modulo** | facturacion |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P0 (Critico) |
| **Estado** | Backlog |
| **Story Points** | 35 |
| **Sprint(s)** | Sprint 6-7 |
---
## Descripcion
Generación de comprobantes fiscales digitales (CFDI 4.0) para ventas en tienda y online. Incluye facturación a público en general, facturación a cliente con RFC, notas de crédito, cancelaciones y portal de autofactura para clientes.
---
## Objetivo de Negocio
- Cumplimiento fiscal obligatorio
- Facturación inmediata en POS
- Autofactura para clientes
- Control de notas de crédito
- Reportes fiscales
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-RT010-001 | Como cajero, quiero generar factura inmediata al cerrar venta si el cliente la solicita | P0 | 5 | Backlog |
| US-RT010-002 | Como cajero, quiero generar factura a público en general para ventas sin RFC | P0 | 3 | Backlog |
| US-RT010-003 | Como cliente, quiero autofacturar desde portal web usando mi ticket | P0 | 8 | Backlog |
| US-RT010-004 | Como contador, quiero generar nota de crédito por devolución | P0 | 5 | Backlog |
| US-RT010-005 | Como contador, quiero cancelar CFDI con motivo de cancelación | P0 | 3 | Backlog |
| US-RT010-006 | Como cliente, quiero recibir mi factura PDF y XML por email | P0 | 3 | Backlog |
| US-RT010-007 | Como contador, quiero ver reporte de CFDIs emitidos por período | P0 | 3 | Backlog |
| US-RT010-008 | Como admin, quiero configurar datos fiscales de la empresa | P0 | 2 | Backlog |
| US-RT010-009 | Como contador, quiero regenerar PDF de factura existente | P1 | 2 | Backlog |
| US-RT010-010 | Como admin, quiero validar RFC del cliente contra SAT (opcional) | P2 | 1 | Backlog |
**Total Story Points:** 35 SP
---
## CFDI 4.0 - Elementos Clave
```
┌─────────────────────────────────────────────────────────┐
│ ESTRUCTURA CFDI 4.0 │
├─────────────────────────────────────────────────────────┤
│ │
│ EMISOR │
│ ├── RFC de la empresa │
│ ├── Nombre o razón social │
│ ├── Régimen fiscal │
│ └── Código postal del domicilio fiscal │
│ │
│ RECEPTOR │
│ ├── RFC del cliente (o XAXX010101000 para público) │
│ ├── Nombre o razón social │
│ ├── Régimen fiscal │
│ ├── Código postal del domicilio fiscal │
│ └── Uso del CFDI (G03 - Gastos en general) │
│ │
│ CONCEPTOS │
│ ├── Clave de producto/servicio SAT │
│ ├── Descripción │
│ ├── Cantidad y unidad │
│ ├── Valor unitario │
│ ├── Importe │
│ └── Impuestos (IVA, IEPS si aplica) │
│ │
│ COMPLEMENTOS │
│ └── Pago (si es PPD - Pago en Parcialidades) │
│ │
│ TIMBRE FISCAL DIGITAL (TFD) │
│ ├── UUID (folio fiscal) │
│ ├── Fecha de timbrado │
│ ├── Sello del SAT │
│ └── Sello del emisor │
│ │
└─────────────────────────────────────────────────────────┘
```
---
## Flujo de Facturación
```
FACTURACIÓN INMEDIATA (POS)
┌─────────────┐
│ VENTA │ ← Cajero cierra venta
└──────┬──────┘
┌─────────────┐
│ ¿FACTURA? │ ─── No ──► Ticket simple
└──────┬──────┘
│ Si
┌─────────────┐
│ DATOS RFC │ ← Captura RFC y datos fiscales
└──────┬──────┘
┌─────────────┐
│ TIMBRADO │ ← PAC genera UUID
└──────┬──────┘
┌─────────────┐
│ PDF + XML │ ← Envío por email
└─────────────┘
AUTOFACTURA (Portal)
┌─────────────┐
│ PORTAL │ ← Cliente ingresa
└──────┬──────┘
┌─────────────┐
│ TICKET │ ← Ingresa folio del ticket
└──────┬──────┘
┌─────────────┐
│ DATOS RFC │ ← Ingresa sus datos fiscales
└──────┬──────┘
┌─────────────┐
│ TIMBRADO │ ← PAC genera UUID
└──────┬──────┘
┌─────────────┐
│ DESCARGA │ ← PDF + XML disponibles
└─────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Facturación inmediata en POS
- [ ] Factura a público en general
- [ ] Portal de autofactura
- [ ] Notas de crédito por devolución
- [ ] Cancelación de CFDIs
- [ ] Envío por email
- [ ] Reportes de CFDIs
- [ ] Configuración de datos fiscales
**No Funcionales:**
- [ ] Timbrado < 5 segundos
- [ ] Alta disponibilidad del PAC
- [ ] Almacenamiento de XMLs por 5 años
**Tecnicos:**
- [ ] Integración con PAC (Finkok, Facturama, etc.)
- [ ] Generación de XML CFDI 4.0
- [ ] Generación de PDF personalizado
- [ ] Validación de RFC vs lista negra SAT
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-RT-001 Fundamentos | Backlog | Si |
| EPIC-RT-002 POS | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| Reportes fiscales | Requiere CFDIs emitidos |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `invoicing`
- [ ] Tablas: 6 (invoices, invoice_items, cancellations, fiscal_data, xml_storage, pac_logs)
- [ ] Funciones: 2 (generate_xml, validate_rfc)
- [ ] Indices: Por UUID, fecha, RFC
**Backend:**
- [ ] Modulo: `invoicing`
- [ ] Entities: 4 (Invoice, InvoiceItem, Cancellation, FiscalData)
- [ ] Services: PACService, XMLGenerator, PDFGenerator
- [ ] Endpoints: 12
- [ ] Tests: 28
**Frontend:**
- [ ] Paginas: 4 (InvoiceList, InvoiceDetail, SelfService, Config)
- [ ] Componentes: 10 (InvoiceForm, RFCInput, PDFViewer, etc.)
- [ ] Portal público de autofactura
- [ ] Stores: 1 (invoicingStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /api/invoices | Crear y timbrar factura |
| GET | /api/invoices/:id | Detalle de factura |
| GET | /api/invoices/:id/pdf | Descargar PDF |
| GET | /api/invoices/:id/xml | Descargar XML |
| POST | /api/invoices/:id/send | Enviar por email |
| POST | /api/invoices/:id/cancel | Cancelar factura |
| POST | /api/invoices/credit-note | Crear nota de crédito |
| GET | /api/invoices/report | Reporte de CFDIs |
| POST | /api/invoices/self-service | Autofactura (público) |
| POST | /api/invoices/validate-rfc | Validar RFC |
---
## PAC (Proveedor Autorizado de Certificación)
| PAC | Notas |
|-----|-------|
| Finkok | Popular, buena documentación |
| Facturama | API REST moderna |
| SW Sapien | Económico para alto volumen |
| Facturify | Fácil integración |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Caída del PAC | Baja | Alto | PAC de respaldo |
| Cambios normativos | Media | Alto | Monitoreo de actualizaciones |
| XMLs corruptos | Baja | Alto | Validación antes de timbrar |
---
## Nota Técnica
La facturación electrónica en México (CFDI) es obligatoria y debe cumplir con los lineamientos del SAT. El sistema debe estar preparado para actualizaciones normativas frecuentes.
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] PAC seleccionado y contratado
- [ ] Certificados de sello digital (CSD) disponibles
- [ ] Catálogo de productos con claves SAT
## Definition of Done (DoD)
- [ ] Facturación inmediata funcionando
- [ ] Portal de autofactura operativo
- [ ] Notas de crédito y cancelaciones
- [ ] Integración con PAC estable
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,122 @@
# Herencia SIMCO - ERP Retail
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Fecha:** 2025-12-08
---
## Configuración del Proyecto
| Propiedad | Valor |
|-----------|-------|
| **Proyecto** | ERP Retail - Vertical para Comercios |
| **Nivel** | VERTICAL (Nivel 3) |
| **Padre** | erp-core |
| **Suite** | erp-suite |
| **SIMCO Version** | 2.2.0 |
| **CAPVED** | Habilitado |
| **CCA Protocol** | Habilitado |
| **Estado** | 0% - Futuro |
## Jerarquía de Herencia
```
Nivel 0: core/orchestration/ ← FUENTE PRINCIPAL
└── Nivel 1: erp-suite/orchestration/
└── Nivel 2: erp-core/orchestration/ ← PADRE DIRECTO
└── Nivel 3: retail/orchestration/ ← ESTE PROYECTO
```
---
## Directivas Heredadas de CORE (OBLIGATORIAS)
### Ciclo de Vida
| Alias | Propósito |
|-------|-----------|
| `@TAREA` | Punto de entrada para toda HU |
| `@CAPVED` | Ciclo de 6 fases |
| `@INICIALIZACION` | Bootstrap de agentes |
### Operaciones Universales
| Alias | Propósito |
|-------|-----------|
| `@CREAR` | Crear archivos nuevos |
| `@MODIFICAR` | Modificar existentes |
| `@VALIDAR` | Validar código |
| `@DOCUMENTAR` | Documentar trabajo |
| `@BUSCAR` | Buscar información |
| `@DELEGAR` | Delegar a subagentes |
### Principios Fundamentales
| Alias | Resumen |
|-------|---------|
| `@CAPVED` | Toda tarea pasa por 6 fases |
| `@DOC_PRIMERO` | Consultar docs/ antes de implementar |
| `@ANTI_DUP` | Verificar que no existe |
| `@VALIDACION` | Build y lint DEBEN pasar |
| `@TOKENS` | Desglosar tareas grandes |
---
## Directivas por Dominio Técnico
| Alias | Aplica | Notas |
|-------|--------|-------|
| `@OP_DDL` | **SÍ** | Schemas de comercio |
| `@OP_BACKEND` | **SÍ** | Servicios POS, inventario |
| `@OP_FRONTEND` | **SÍ** | UI de punto de venta |
| `@OP_MOBILE` | **SÍ** | App de ventas |
| `@OP_ML` | Futuro | Predicción de demanda |
---
## Patrones Heredados (OBLIGATORIOS)
Todos los patrones de `core/orchestration/patrones/` aplican.
---
## Directivas Heredadas de ERP Core
| Directiva | Extensión Local |
|-----------|-----------------|
| `DIRECTIVA-MULTI-TENANT.md` | Por `comercio_id` |
| `DIRECTIVA-EXTENSION-VERTICALES.md` | Módulos de retail |
---
## Variables de Contexto CCA
```yaml
PROJECT_NAME: "retail"
PROJECT_LEVEL: "VERTICAL"
PROJECT_ROOT: "/home/isem/workspace/projects/erp-suite/apps/verticales/retail"
PARENT_PROJECT: "erp-core"
SUITE_PROJECT: "erp-suite"
DB_DDL_PATH: "database/ddl"
BACKEND_ROOT: "backend/src"
FRONTEND_ROOT: "frontend/src"
TENANT_COLUMN: "comercio_id"
RLS_CONTEXT: "app.current_comercio_id"
```
---
## Módulos Específicos de Retail (Por definir)
| Módulo | Descripción | Estado |
|--------|-------------|--------|
| RET-POS | Punto de venta | Por definir |
| RET-INV | Inventario | Por definir |
| RET-PRO | Productos | Por definir |
| RET-CLI | Clientes/fidelización | Por definir |
| RET-REP | Reportes de ventas | Por definir |
---
**Sistema:** SIMCO v2.2.0 + CAPVED + CCA Protocol
**Nivel:** VERTICAL (3)
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,105 @@
# Próxima Acción - ERP Retail / POS
## Estado Actual
**Fecha:** Diciembre 2025
**Progreso:** 20% (Planificación completa)
---
## Documentación Disponible
### Módulos Definidos (10 módulos - 322 SP)
| Módulo | Nombre | SP | Estado |
|--------|--------|---:|--------|
| RT-001 | Fundamentos | 0 | PLANIFICADO |
| RT-002 | POS | 55 | PLANIFICADO |
| RT-003 | Inventario | 34 | PLANIFICADO |
| RT-004 | Compras | 21 | PLANIFICADO |
| RT-005 | Clientes | 34 | PLANIFICADO |
| RT-006 | Precios | 42 | PLANIFICADO |
| RT-007 | Caja | 34 | PLANIFICADO |
| RT-008 | Reportes | 34 | PLANIFICADO |
| RT-009 | E-commerce | 47 | PLANIFICADO |
| RT-010 | Facturación | 21 | PLANIFICADO |
### Documentos de Referencia
- Visión: `docs/00-vision-general/VISION-RETAIL.md`
- Módulos: `docs/02-definicion-modulos/INDICE-MODULOS.md`
- Herencia SPECS: `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
- Inventario: `orchestration/inventarios/MASTER_INVENTORY.yml`
---
## Prerrequisitos
Este proyecto requiere que **erp-core** esté completado primero:
- [ ] Módulo auth de erp-core
- [ ] Módulo users de erp-core
- [ ] Módulo tenants de erp-core
- [ ] Módulo inventory base de erp-core
- [ ] Módulo sales base de erp-core
- [ ] CFDI de erp-core
---
## Tarea Prioritaria (Cuando esté listo)
### 1. Crear DDL del Schema POS
**Objetivo:** Definir estructura de base de datos para terminal punto de venta.
**Tablas a crear:**
- `pos.pos_sessions`
- `pos.pos_orders`
- `pos.pos_order_lines`
- `pos.cash_registers`
- `pos.cash_movements`
- `pos.cash_closings`
**Archivo destino:** `database/ddl/01-pos-schema.sql`
### 2. Implementar SPEC-PRICING-RULES
**Objetivo:** Motor de precios y promociones.
**Referencia:** Ver `erp-core/docs/04-modelado/especificaciones-tecnicas/transversal/SPEC-PRICING-RULES.md`
---
## Consideraciones Especiales
1. **Modo Offline:** RT-002 (POS) requiere funcionamiento offline-first
2. **Hardware:** Integración con impresoras térmicas y scanners
3. **Multi-sucursal:** Inventarios independientes por sucursal
4. **CFDI 4.0:** Con complementos de pago
---
## Ambiente de Desarrollo
Según `DEVENV-PORTS.md`:
```yaml
proyecto: retail
rango_base: 3400
puertos:
backend: 3400
frontend: 5177
database: 5436
redis: 6383
```
---
## Próximos Pasos
1. [ ] Esperar completitud de erp-core (auth, users, tenants, inventory)
2. [ ] Crear DDL schema POS
3. [ ] Crear DDL schema loyalty
4. [ ] Iniciar backend RT-001 (heredar de core)
5. [ ] Implementar RT-002 (POS - crítico)
---
**Última actualización:** 2025-12-08

View File

@ -0,0 +1,206 @@
# =============================================================================
# PROJECT-ENV-CONFIG.yml - ERP RETAIL / POS
# =============================================================================
# Vertical de ERP-Suite especializada en Comercio Minorista y Punto de Venta
# Actualizado: 2025-12-08
# Referencia: ~/workspace/core/devtools/environment/DEVENV-PORTS.md
# =============================================================================
project:
name: "ERP-RETAIL"
code: "RT"
description: "Sistema de Punto de Venta y Comercio Minorista"
type: "vertical"
level: "2B.2"
status: "planning"
parent: "erp-suite"
paths:
root: "/home/isem/workspace/projects/erp-suite/apps/verticales/retail"
backend: "backend/"
frontend: "frontend/"
database: "database/"
docs: "docs/"
orchestration: "orchestration/"
# =============================================================================
# PUERTOS (Según DEVENV-PORTS.md)
# =============================================================================
ports:
backend: 3400
frontend: 5177
database: 5436
redis: 6383
# =============================================================================
# BASE DE DATOS
# =============================================================================
database:
type: "postgresql"
host: "localhost"
port: 5436
name: "retail_db"
user: "retail_user"
schemas:
core_inherited: 12 # Schemas heredados de erp-core
vertical_specific:
- pos # Sesiones, órdenes, pagos, cierres
- loyalty # Tarjetas, puntos, recompensas
- pricing # Listas, promociones, cupones
- ecommerce # Pedidos online, carritos
migration:
tool: "typeorm"
directory: "database/migrations/"
# =============================================================================
# STACK TECNOLOGICO
# =============================================================================
stack:
runtime: "Node.js 20+"
language: "TypeScript 5.3+"
backend:
framework: "Express.js"
orm: "TypeORM 0.3.17"
frontend:
framework: "React 18"
build: "Vite"
ui: "Tailwind CSS + shadcn/ui"
pwa:
enabled: true
offline_support: true
# =============================================================================
# HERENCIA DEL CORE
# =============================================================================
core_inheritance:
version: "0.6.0"
tables_inherited: 97
modules_inherited:
- auth
- users
- roles
- tenants
- inventory
- sales
- cfdi
specs_applicable: 5
specs_implemented: 0
specs_detail:
- SPEC-PRICING-RULES
- SPEC-INVENTARIOS-CICLICOS
- SPEC-TRAZABILIDAD-LOTES-SERIES
- SPEC-FACTURACION-CFDI
- SPEC-VALORACION-INVENTARIO
# =============================================================================
# MODULOS DE LA VERTICAL
# =============================================================================
modules:
total: 10
story_points: 322
list:
- code: RT-001
name: Fundamentos
sp: 0
priority: P0
status: pending
notes: "100% heredado del core"
- code: RT-002
name: POS Terminal
sp: 55
priority: P0
status: pending
notes: "OFFLINE-FIRST critical"
- code: RT-003
name: Inventario Multi-Sucursal
sp: 42
priority: P0
status: pending
- code: RT-004
name: Compras
sp: 34
priority: P0
status: pending
- code: RT-005
name: Clientes/CRM
sp: 34
priority: P0
status: pending
- code: RT-006
name: Precios/Promociones
sp: 42
priority: P0
status: pending
- code: RT-007
name: Caja
sp: 34
priority: P0
status: pending
- code: RT-008
name: Reportes
sp: 21
priority: P1
status: pending
- code: RT-009
name: E-commerce
sp: 39
priority: P2
status: pending
- code: RT-010
name: Facturación CFDI
sp: 21
priority: P0
status: pending
# =============================================================================
# CONSIDERACIONES ESPECIALES
# =============================================================================
special_requirements:
offline_first:
enabled: true
sync_strategy: "queue-based"
local_storage: "IndexedDB"
conflict_resolution: "server-wins"
hardware_integration:
thermal_printers:
protocol: "ESC/POS"
connection: ["USB", "Bluetooth", "Network"]
barcode_scanners:
connection: ["USB", "Bluetooth"]
cash_drawers:
trigger: "automatic"
# =============================================================================
# ARCHIVOS DE ENTORNO
# =============================================================================
env_files:
template: "orchestration/environment/.env.example"
backend: "backend/.env"
frontend: "frontend/.env"
env_variables:
required:
- NODE_ENV
- PORT
- DATABASE_URL
- JWT_SECRET
- REDIS_URL
optional:
- LOG_LEVEL
- CORS_ORIGIN
- OFFLINE_SYNC_INTERVAL
# =============================================================================
# NOTAS
# =============================================================================
notes: |
- Vertical especializada en retail y punto de venta
- CRITICO: POS debe funcionar OFFLINE-FIRST
- Sincronización cuando recupere conexión
- Soporte para impresoras térmicas ESC/POS
- Integración con scanners de código de barras
- Puertos asignados según DEVENV-PORTS.md (rango 3400)

View File

@ -4,97 +4,183 @@
proyecto:
nombre: ERP Retail / Punto de Venta
codigo: retail
codigo: RT
nivel: 2B.2 (Vertical)
estado: Planificacion
version: 0.1.0
estado: EPICAS_COMPLETAS
version: 0.3.0
path: /home/isem/workspace/projects/erp-suite/apps/verticales/retail
herencia:
- erp-core (60-70% funcionalidad base)
- core (directivas globales)
core_version: "0.6.0"
tablas_heredadas: 97
specs_aplicables: 26
specs_implementadas: 0
resumen_general:
total_schemas: 0
total_tablas: 0
total_modulos: 10
total_schemas_planificados: 3
total_tablas_planificadas: 35
total_servicios_backend: 0
total_componentes_frontend: 0
story_points_estimados: 353
test_coverage: N/A
ultima_actualizacion: 2025-12-08
modulos_planificados:
- codigo: RT-001
nombre: Punto de Venta
descripcion: Terminal de venta (POS)
prioridad: Alta
estado: No iniciado
modulos:
total: 10
lista:
- codigo: RT-001
nombre: Fundamentos
descripcion: Auth, Users, Tenants (hereda 100% core)
herencia: 100%
prioridad: P0
estado: PLANIFICADO
sp: 0
- codigo: RT-002
nombre: Inventario
descripcion: Control de inventario multi-sucursal
prioridad: Alta
estado: No iniciado
- codigo: RT-002
nombre: POS
descripcion: Terminal punto de venta
herencia: 0%
prioridad: P0
estado: EPICA_COMPLETA
sp: 55
epica: docs/08-epicas/EPIC-RT-002-pos.md
- codigo: RT-003
nombre: Productos
descripcion: Catalogo de productos
prioridad: Alta
estado: No iniciado
- codigo: RT-003
nombre: Inventario
descripcion: Stock multi-sucursal
herencia: 70%
prioridad: P0
estado: EPICA_COMPLETA
sp: 42
epica: docs/08-epicas/EPIC-RT-003-inventario.md
- codigo: RT-004
nombre: Clientes
descripcion: Gestion de clientes y fidelizacion
prioridad: Media
estado: No iniciado
- codigo: RT-004
nombre: Compras
descripcion: Órdenes de compra y recepción
herencia: 60%
prioridad: P0
estado: EPICA_COMPLETA
sp: 38
epica: docs/08-epicas/EPIC-RT-004-compras.md
- codigo: RT-005
nombre: Proveedores
descripcion: Gestion de proveedores
prioridad: Media
estado: No iniciado
- codigo: RT-005
nombre: Clientes
descripcion: CRM y fidelización
herencia: 50%
prioridad: P0
estado: EPICA_COMPLETA
sp: 34
epica: docs/08-epicas/EPIC-RT-005-clientes.md
- codigo: RT-006
nombre: Reportes
descripcion: Reportes de ventas y analitica
prioridad: Media
estado: No iniciado
- codigo: RT-006
nombre: Precios
descripcion: Promociones y descuentos
herencia: 40%
prioridad: P0
estado: EPICA_COMPLETA
sp: 36
epica: docs/08-epicas/EPIC-RT-006-precios.md
- codigo: RT-007
nombre: Facturacion
descripcion: Facturacion electronica CFDI
prioridad: Alta
estado: No iniciado
- codigo: RT-007
nombre: Caja
descripcion: Arqueos y cortes
herencia: 0%
prioridad: P0
estado: EPICA_COMPLETA
sp: 28
epica: docs/08-epicas/EPIC-RT-007-caja.md
- codigo: RT-008
nombre: Reportes
descripcion: Dashboards de ventas
herencia: 40%
prioridad: P1
estado: EPICA_COMPLETA
sp: 30
epica: docs/08-epicas/EPIC-RT-008-reportes.md
- codigo: RT-009
nombre: E-commerce
descripcion: Tienda online integrada
herencia: 20%
prioridad: P2
estado: EPICA_COMPLETA
sp: 55
epica: docs/08-epicas/EPIC-RT-009-ecommerce.md
- codigo: RT-010
nombre: Facturacion
descripcion: CFDI 4.0 y complementos
herencia: 80%
prioridad: P0
estado: EPICA_COMPLETA
sp: 35
epica: docs/08-epicas/EPIC-RT-010-facturacion.md
specs_core:
aplicables: 26
implementadas: 0
por_implementar: 26
documento: orchestration/00-guidelines/HERENCIA-SPECS-CORE.md
detalle:
- spec: SPEC-SISTEMA-SECUENCIAS
estado: PENDIENTE
- spec: SPEC-VALORACION-INVENTARIO
estado: PENDIENTE
- spec: SPEC-SEGURIDAD-API-KEYS-PERMISOS
estado: PENDIENTE
- spec: SPEC-TRAZABILIDAD-LOTES-SERIES
estado: PENDIENTE
- spec: SPEC-PRICING-RULES
estado: PENDIENTE
- spec: SPEC-INVENTARIOS-CICLICOS
estado: PENDIENTE
- spec: SPEC-FACTURACION-CFDI
estado: PENDIENTE
- spec: SPEC-INTEGRACION-BANCARIA
estado: PENDIENTE
capas:
database:
inventario: DATABASE_INVENTORY.yml
total_objetos: 0
estado: No iniciado
schemas_planificados: [pos, loyalty, pricing]
tablas_planificadas: 35
estado: PLANIFICADO
backend:
inventario: BACKEND_INVENTORY.yml
total_objetos: 0
estado: No iniciado
modulos_planificados: 10
estado: PLANIFICADO
frontend:
inventario: FRONTEND_INVENTORY.yml
total_objetos: 0
estado: No iniciado
paginas_planificadas: 20
estado: PLANIFICADO
dependencias_core:
- auth (de erp-core)
- users (de erp-core)
- roles (de erp-core)
- catalogs (de erp-core)
- financial (de erp-core)
obligatorias:
- auth (MGN-001)
- users (MGN-002)
- roles (MGN-003)
- tenants (MGN-004)
opcionales:
- catalogs (MGN-005)
- financial (MGN-010)
- inventory (MGN-011)
- sales (MGN-013)
- cfdi (MGN-016)
consideraciones_especiales:
- Operacion offline del POS
- Sincronizacion multi-sucursal
- Integracion con hardware (impresoras, lectores)
- CFDI 4.0
- Operación offline del POS con sincronización
- Multi-sucursal con inventarios independientes
- Integración hardware (impresoras térmicas, lectores)
- CFDI 4.0 con complementos de pago
- Promociones y reglas de precios complejas
referencias:
docs: docs/
vision: docs/00-vision-general/VISION-RETAIL.md
modulos: docs/02-definicion-modulos/INDICE-MODULOS.md
orchestration: orchestration/
contexto: orchestration/00-guidelines/CONTEXTO-PROYECTO.md
herencia: orchestration/00-guidelines/HERENCIA-DIRECTIVAS.md
herencia_specs: orchestration/00-guidelines/HERENCIA-SPECS-CORE.md
herencia_db: database/HERENCIA-ERP-CORE.md

View File

@ -1,69 +1,400 @@
# =============================================================================
# TRACEABILITY MATRIX - ERP Retail/POS (Vertical)
# =============================================================================
# Generado: 2025-12-08
# Sistema: NEXUS + SIMCO v2.2.0
# Propósito: Matriz de trazabilidad Módulos -> SPECS -> Componentes
# =============================================================================
proyecto:
nombre: ERP Retail / Punto de Venta
nivel: 2B.2 (Vertical)
trazabilidad:
RT-001:
nombre: Punto de Venta
database: [pos_sessions, pos_orders, pos_order_lines, cash_registers, cash_movements, cash_closings]
backend: [POSSessionService, POSOrderService, CashRegisterService]
frontend: [POSTerminal, ProductSearch, BarcodeScanner, PaymentModal, CashDrawer, ReceiptPrinter, CashClosingForm]
critico: true
RT-002:
nombre: Inventario Multi-Sucursal
database: [branches, branch_stock, stock_transfers]
backend: [BranchService, StockTransferService]
frontend: [BranchSelector, StockDashboard, TransferForm]
specs_core: [SPEC-INVENTARIOS-CICLICOS.md]
RT-003:
nombre: Productos
database: [products, product_barcodes, promotions]
backend: [RetailProductService, PromotionService]
frontend: [ProductCatalog, PromotionManager]
specs_core: [SPEC-PRICING-RULES.md]
RT-004:
nombre: Clientes
database: [customers, loyalty_cards, loyalty_transactions]
backend: [RetailCustomerService]
frontend: [CustomerLookup, LoyaltyCard]
RT-005:
nombre: Proveedores
database: [suppliers, purchase_orders]
backend: []
frontend: []
RT-006:
nombre: Reportes
database: []
backend: []
frontend: [SalesReport, InventoryReport]
RT-007:
nombre: Facturacion CFDI
database: [invoices]
backend: [RetailInvoiceService]
frontend: []
herencia_specs:
- spec: SPEC-PRICING-RULES.md
modulos: [RT-003]
- spec: SPEC-INVENTARIOS-CICLICOS.md
modulos: [RT-002]
- spec: SPEC-TRAZABILIDAD-LOTES-SERIES.md
modulos: [RT-003]
metadata:
proyecto: ERP Retail / Punto de Venta
codigo: RT
version: 1.0.0
fecha_actualizacion: 2025-12-08
base_core: erp-core v0.6.0
# =============================================================================
# RESUMEN GLOBAL
# =============================================================================
resumen:
modulos: 7
tablas_planificadas: 18
servicios_planificados: 9
componentes_planificados: 16
estado: PLANIFICACION
modulos_total: 10
modulos_documentados: 10
story_points_total: 322
specs_core_aplicables: 26
specs_implementadas: 0
cobertura_specs: 0%
estado: PLANIFICACION_COMPLETA
# =============================================================================
# TRAZABILIDAD POR MÓDULO
# =============================================================================
trazabilidad:
# ---------------------------------------------------------------------------
# RT-001: Fundamentos (100% herencia core)
# ---------------------------------------------------------------------------
RT-001:
nombre: Fundamentos
herencia: 100%
prioridad: P0
sp: 0
extiende:
- MGN-001 (auth)
- MGN-002 (users)
- MGN-003 (roles)
- MGN-004 (tenants)
database:
heredadas: [auth.users, auth.sessions, auth.roles, tenants.tenants]
extensiones: []
backend:
heredados: [AuthService, UserService, RoleService, TenantService]
extensiones: []
frontend:
heredados: [LoginForm, UserProfile, RoleSelector]
extensiones: []
specs_core:
- SPEC-SISTEMA-SECUENCIAS
- SPEC-SEGURIDAD-API-KEYS-PERMISOS
# ---------------------------------------------------------------------------
# RT-002: POS (Terminal Punto de Venta)
# ---------------------------------------------------------------------------
RT-002:
nombre: POS
herencia: 0%
prioridad: P0
sp: 55
critico: true
database:
tablas:
- pos.pos_sessions
- pos.pos_orders
- pos.pos_order_lines
- pos.payment_methods
- pos.payment_transactions
backend:
servicios:
- POSSessionService
- POSOrderService
- PaymentService
- OfflineSyncService
frontend:
componentes:
- POSTerminal
- ProductSearch
- BarcodeScanner
- PaymentModal
- QuickButtons
- OrderSummary
- CustomerDisplay
specs_core: []
caracteristicas:
- offline_first: true
- hardware_integration: [printer, scanner, cash_drawer]
# ---------------------------------------------------------------------------
# RT-003: Inventario Multi-Sucursal
# ---------------------------------------------------------------------------
RT-003:
nombre: Inventario
herencia: 70%
prioridad: P0
sp: 34
database:
tablas:
- inventory.branches
- inventory.branch_stock
- inventory.stock_transfers
- inventory.transfer_lines
backend:
servicios:
- BranchService
- BranchStockService
- StockTransferService
frontend:
componentes:
- BranchSelector
- StockDashboard
- TransferForm
- StockAlertPanel
- MultiBranchView
specs_core:
- SPEC-VALORACION-INVENTARIO
- SPEC-INVENTARIOS-CICLICOS
- SPEC-TRAZABILIDAD-LOTES-SERIES
# ---------------------------------------------------------------------------
# RT-004: Compras
# ---------------------------------------------------------------------------
RT-004:
nombre: Compras
herencia: 60%
prioridad: P0
sp: 21
database:
tablas:
- purchasing.purchase_orders
- purchasing.purchase_order_lines
- purchasing.goods_receipts
backend:
servicios:
- PurchaseOrderService
- GoodsReceiptService
- SupplierService
frontend:
componentes:
- PurchaseOrderForm
- PurchaseOrderList
- GoodsReceiptForm
- SupplierSelector
specs_core:
- SPEC-SISTEMA-SECUENCIAS
# ---------------------------------------------------------------------------
# RT-005: Clientes (CRM + Fidelización)
# ---------------------------------------------------------------------------
RT-005:
nombre: Clientes
herencia: 50%
prioridad: P0
sp: 34
database:
tablas:
- crm.retail_customers
- loyalty.loyalty_cards
- loyalty.loyalty_transactions
- loyalty.reward_tiers
backend:
servicios:
- RetailCustomerService
- LoyaltyCardService
- RewardService
frontend:
componentes:
- CustomerLookup
- CustomerForm
- LoyaltyCardView
- PointsHistory
- RewardCatalog
specs_core:
- SPEC-MAIL-THREAD-TRACKING (comunicación clientes)
# ---------------------------------------------------------------------------
# RT-006: Precios y Promociones
# ---------------------------------------------------------------------------
RT-006:
nombre: Precios
herencia: 40%
prioridad: P0
sp: 42
database:
tablas:
- pricing.price_lists
- pricing.promotions
- pricing.promotion_rules
- pricing.discount_coupons
backend:
servicios:
- PriceListService
- PromotionEngine
- CouponService
- PriceCalculator
frontend:
componentes:
- PriceListManager
- PromotionBuilder
- PromotionCalendar
- CouponGenerator
- DiscountPreview
specs_core:
- SPEC-PRICING-RULES (motor de promociones)
# ---------------------------------------------------------------------------
# RT-007: Caja (Arqueos y Cortes)
# ---------------------------------------------------------------------------
RT-007:
nombre: Caja
herencia: 30%
prioridad: P0
sp: 34
database:
tablas:
- pos.cash_registers
- pos.cash_movements
- pos.cash_closings
- pos.denomination_counts
backend:
servicios:
- CashRegisterService
- CashClosingService
- CashReportService
frontend:
componentes:
- CashDrawer
- CashClosingForm
- DenominationCounter
- CashMovementLog
- ClosingReport
specs_core:
- SPEC-WIZARD-TRANSIENT-MODEL (asistente cierre)
# ---------------------------------------------------------------------------
# RT-008: Reportes y Dashboards
# ---------------------------------------------------------------------------
RT-008:
nombre: Reportes
herencia: 40%
prioridad: P1
sp: 34
database:
tablas: []
backend:
servicios:
- SalesReportService
- InventoryReportService
- AnalyticsService
frontend:
componentes:
- SalesDashboard
- SalesReport
- InventoryReport
- TopProductsChart
- SalesTrendChart
- BranchComparison
specs_core: []
# ---------------------------------------------------------------------------
# RT-009: E-commerce
# ---------------------------------------------------------------------------
RT-009:
nombre: E-commerce
herencia: 20%
prioridad: P2
sp: 47
database:
tablas:
- ecommerce.online_orders
- ecommerce.shopping_carts
- ecommerce.product_catalog
- ecommerce.shipping_methods
backend:
servicios:
- OnlineOrderService
- CartService
- CatalogSyncService
- ShippingService
frontend:
componentes:
- OnlineOrderManager
- CatalogEditor
- ShippingConfigurator
- OrderFulfillment
specs_core:
- SPEC-MAIL-THREAD-TRACKING (notificaciones pedidos)
# ---------------------------------------------------------------------------
# RT-010: Facturación CFDI
# ---------------------------------------------------------------------------
RT-010:
nombre: Facturacion
herencia: 80%
prioridad: P0
sp: 21
database:
tablas:
- invoicing.retail_invoices
- invoicing.invoice_complements
backend:
servicios:
- RetailInvoiceService
- CFDIService
- ComplementService
frontend:
componentes:
- InvoiceGenerator
- InvoiceList
- CFDIViewer
- ComplementForm
specs_core:
- SPEC-FACTURACION-CFDI
- SPEC-INTEGRACION-BANCARIA (complementos pago)
# =============================================================================
# REFERENCIAS CRUZADAS CON ERP-CORE
# =============================================================================
referencias_core:
specs_implementadas: []
specs_pendientes:
- spec: SPEC-SISTEMA-SECUENCIAS
modulos: [RT-001, RT-002, RT-004]
prioridad: P0
estado: PENDIENTE
- spec: SPEC-VALORACION-INVENTARIO
modulos: [RT-003]
prioridad: P0
estado: PENDIENTE
adaptacion: "Valorización multi-sucursal con costo promedio"
- spec: SPEC-INVENTARIOS-CICLICOS
modulos: [RT-003]
prioridad: P1
estado: PENDIENTE
adaptacion: "Conteos por sucursal"
- spec: SPEC-PRICING-RULES
modulos: [RT-006]
prioridad: P0
estado: PENDIENTE
adaptacion: "Promociones, combos, descuentos por volumen"
- spec: SPEC-FACTURACION-CFDI
modulos: [RT-010]
prioridad: P0
estado: PENDIENTE
adaptacion: "CFDI 4.0 con complementos de pago"
modulos_extendidos:
- core: MGN-001 (auth)
vertical: RT-001
tipo: herencia_directa
- core: MGN-011 (inventory)
vertical: RT-003
tipo: extension_multi_sucursal
- core: MGN-013 (sales)
vertical: RT-002
tipo: extension_pos
- core: MGN-016 (cfdi)
vertical: RT-010
tipo: extension_retail
# =============================================================================
# VALIDACIONES
# =============================================================================
validaciones:
modulos_huerfanos: 0
specs_sin_modulo: 0
alertas:
- tipo: implementacion_pendiente
mensaje: "0% de código implementado - fase planificación"
- tipo: modulo_critico
modulo: RT-002
mensaje: "POS es crítico - requiere modo offline"
- tipo: integracion_hardware
modulo: RT-002
mensaje: "Requiere integración con impresoras térmicas, scanners"
# =============================================================================
# METADATA
# =============================================================================
metadata_documento:
creado_por: Claude-Code
fecha_creacion: 2025-12-08
ultima_actualizacion: 2025-12-08
version_documento: 1.0.0

View File

@ -0,0 +1,150 @@
# Prompt: Retail Backend Agent
## Identidad
Eres un agente especializado en desarrollo backend para ERP Retail/POS. Tu expertise está en Node.js, Express, TypeScript, TypeORM y PostgreSQL, con conocimiento específico de sistemas punto de venta y comercio minorista.
## Contexto del Proyecto
```yaml
proyecto: ERP Retail / Punto de Venta
codigo: RT
tipo: Vertical de ERP-Suite
nivel: 2B.2
stack:
runtime: Node.js 20+
framework: Express.js
lenguaje: TypeScript 5.3+
orm: TypeORM 0.3.17
database: PostgreSQL 15+
auth: JWT + bcryptjs (heredado de core)
paths:
vertical: /home/isem/workspace/projects/erp-suite/apps/verticales/retail/
backend: /home/isem/workspace/projects/erp-suite/apps/verticales/retail/backend/
docs: /home/isem/workspace/projects/erp-suite/apps/verticales/retail/docs/
core: /home/isem/workspace/projects/erp-suite/apps/erp-core/
directivas: orchestration/directivas/
puertos:
backend: 3400
frontend: 5177
database: 5436
```
## Herencia del Core
Este proyecto HEREDA del ERP-Core:
- Módulos: auth, users, roles, tenants, inventory, sales, cfdi
- SPECS: Ver `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
- Base de datos: 97 tablas heredadas
**REGLA:** Extender, NUNCA modificar el core.
## Módulos de la Vertical
| Módulo | Descripción | Prioridad | Crítico |
|--------|-------------|-----------|---------|
| RT-001 | Fundamentos (100% core) | P0 | - |
| RT-002 | POS (terminal venta) | P0 | OFFLINE-FIRST |
| RT-003 | Inventario multi-sucursal | P0 | - |
| RT-004 | Compras | P0 | - |
| RT-005 | Clientes/CRM | P0 | - |
| RT-006 | Precios/Promociones | P0 | - |
| RT-007 | Caja (arqueos/cortes) | P0 | - |
| RT-008 | Reportes | P1 | - |
| RT-009 | E-commerce | P2 | - |
| RT-010 | Facturación CFDI | P0 | - |
## Directivas Obligatorias
### 1. Multi-Tenant (Heredada)
```
OBLIGATORIO: Toda operación debe filtrar por tenant_id.
Ver: core/orchestration/directivas/DIRECTIVA-MULTI-TENANT.md
```
### 2. Punto de Venta
```
ESPECÍFICO: Operación offline-first, sincronización.
Ver: directivas/DIRECTIVA-PUNTO-VENTA.md
```
### 3. Inventario Multi-Sucursal
```
ESPECÍFICO: Stock independiente por sucursal.
Ver: directivas/DIRECTIVA-INVENTARIO-SUCURSALES.md
```
## Estructura de Módulo
```
backend/src/modules/{nombre}/
├── {nombre}.module.ts
├── {nombre}.controller.ts
├── {nombre}.service.ts
├── {nombre}.entity.ts
├── dto/
│ ├── create-{nombre}.dto.ts
│ └── update-{nombre}.dto.ts
└── __tests__/
└── {nombre}.service.spec.ts
```
## Schemas de Base de Datos
```yaml
schemas_especificos:
- pos: Sesiones, órdenes, pagos, cierres
- loyalty: Tarjetas, puntos, recompensas
- pricing: Listas, promociones, cupones
- ecommerce: Pedidos online, carritos
```
## SPECS del Core Aplicables
- SPEC-PRICING-RULES (promociones, combos, descuentos)
- SPEC-INVENTARIOS-CICLICOS (conteos por sucursal)
- SPEC-TRAZABILIDAD-LOTES-SERIES (productos perecederos)
- SPEC-FACTURACION-CFDI (CFDI 4.0 + complementos)
- SPEC-VALORACION-INVENTARIO (costo promedio)
## Consideraciones Especiales
### Modo Offline (RT-002)
```typescript
// El POS debe funcionar sin conexión
// Sincronización cuando recupere conexión
// LocalStorage/IndexedDB para datos temporales
```
### Integración Hardware
```yaml
hardware_soportado:
- impresoras_termicas: ESC/POS
- scanners: Código de barras USB/Bluetooth
- cash_drawer: Apertura automática
```
## Flujo de Trabajo
```
1. Leer especificación del módulo en docs/02-definicion-modulos/
2. Verificar SPECS aplicables en HERENCIA-SPECS-CORE.md
3. Revisar DDL existente en database/
4. Implementar siguiendo estructura de módulo
5. Actualizar TRAZA-TAREAS-BACKEND.md
6. Actualizar BACKEND_INVENTORY.yml
```
## Referencias
- Inventario: `orchestration/inventarios/MASTER_INVENTORY.yml`
- Trazabilidad: `orchestration/inventarios/TRACEABILITY_MATRIX.yml`
- Herencia: `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
- Core directivas: `/home/isem/workspace/core/orchestration/directivas/`
---
**Versión:** 1.0.0
**Sistema:** SIMCO v2.2.0

View File

@ -0,0 +1,118 @@
# ===========================================
# VIDRIO TEMPLADO - Variables de Entorno
# ===========================================
# Copiar este archivo a .env y configurar valores
# Puertos según DEVENV-PORTS.md
# -------------------------------------------
# BASE DE DATOS POSTGRESQL
# -------------------------------------------
DB_HOST=localhost
DB_PORT=5434
DB_NAME=vidrio_templado_db
DB_USER=vidrio_user
DB_PASSWORD=vidrio_secret_2025
# URL de conexion completa
DATABASE_URL=postgresql://${DB_USER}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_NAME}
# -------------------------------------------
# SCHEMAS DE BASE DE DATOS
# -------------------------------------------
# Schemas heredados de erp-core
DB_SCHEMA_AUTH=auth
DB_SCHEMA_CORE=core
DB_SCHEMA_INVENTORY=inventory
# Schemas propios de vidrio-templado
DB_SCHEMA_GLASS=glass
DB_SCHEMA_PRODUCTION=production
DB_SCHEMA_QUALITY=quality
DB_SCHEMA_LOGISTICS=logistics
# -------------------------------------------
# APLICACION
# -------------------------------------------
APP_NAME=vidrio-templado
APP_ENV=development
APP_PORT=3200
APP_URL=http://localhost:3200
# -------------------------------------------
# FRONTEND
# -------------------------------------------
FRONTEND_PORT=5175
FRONTEND_URL=http://localhost:5175
# -------------------------------------------
# AUTENTICACION JWT
# -------------------------------------------
JWT_SECRET=your_jwt_secret_here_change_in_production
JWT_EXPIRES_IN=24h
JWT_REFRESH_EXPIRES_IN=7d
# -------------------------------------------
# MULTI-TENANT
# -------------------------------------------
TENANT_ID_HEADER=X-Tenant-ID
TENANT_ID_PARAM=tenant_id
# -------------------------------------------
# ALMACENAMIENTO DE ARCHIVOS
# -------------------------------------------
STORAGE_TYPE=local
STORAGE_PATH=./uploads
# Para S3:
# STORAGE_TYPE=s3
# AWS_ACCESS_KEY_ID=
# AWS_SECRET_ACCESS_KEY=
# AWS_REGION=us-east-1
# AWS_S3_BUCKET=vidrio-templado-files
# -------------------------------------------
# NOTIFICACIONES
# -------------------------------------------
# Email (SMTP)
SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
SMTP_USER=
SMTP_PASSWORD=
SMTP_FROM=noreply@vidrio-templado.com
# -------------------------------------------
# FACTURACION ELECTRONICA (SAT)
# -------------------------------------------
SAT_ENVIRONMENT=sandbox
SAT_RFC=
SAT_CER_PATH=./certs/csd.cer
SAT_KEY_PATH=./certs/csd.key
SAT_KEY_PASSWORD=
# -------------------------------------------
# LOGGING
# -------------------------------------------
LOG_LEVEL=debug
LOG_FORMAT=json
# -------------------------------------------
# REDIS (Cache y Colas)
# -------------------------------------------
REDIS_HOST=localhost
REDIS_PORT=6381
REDIS_PASSWORD=
# -------------------------------------------
# CORS
# -------------------------------------------
CORS_ORIGIN=http://localhost:5175,http://localhost:3200
# -------------------------------------------
# PRODUCCION (Específico de Vidrio)
# -------------------------------------------
# Nesting/Optimización de corte
NESTING_ALGORITHM=guillotine
NESTING_MAX_WASTE_PERCENT=15
# Control de hornos
FURNACE_DEFAULT_TEMP_CELSIUS=620
FURNACE_ALARM_THRESHOLD=50

View File

@ -1,27 +1,144 @@
# ESTADO DEL PROYECTO
# ESTADO DEL PROYECTO - ERP Vidrio Templado
**Proyecto:** erp-vidrio-templado
**Proyecto:** ERP Vidrio Templado (Proyecto Independiente)
**Estado:** 📋 En planificación
**Progreso:** 0%
**Última actualización:** 2025-11-24
**Progreso:** 25%
**Última actualización:** 2025-12-08
---
## 📊 RESUMEN
## 📊 RESUMEN EJECUTIVO
- **Fase actual:** Análisis y planificación
- **Módulos completados:** 0
- **Módulos en desarrollo:** 0
- **Módulos pendientes:** TBD
| Área | Estado | Descripción |
|------|--------|-------------|
| **Documentación** | 🟡 Inicial | 8 módulos definidos, estructura base |
| **DDL/Schemas** | ❌ No iniciado | Pendiente diseño de BD |
| **Backend** | ❌ No iniciado | Pendiente desarrollo |
| **Frontend** | ❌ No iniciado | Pendiente desarrollo |
---
## 📋 MÓDULOS DEFINIDOS (8)
| Código | Nombre | Descripción | Reutilización | Estado |
|--------|--------|-------------|---------------|--------|
| VT-001 | Fundamentos | Auth, Users, Tenants | 100% core | PLANIFICADO |
| VT-002 | Cotizaciones | Cotizador por m² | 30% core | PLANIFICADO |
| VT-003 | Producción | Órdenes de producción | 20% core | PLANIFICADO |
| VT-004 | Inventario | Stock vidrio/MP | 70% core | PLANIFICADO |
| VT-005 | Corte | Optimización nesting | 0% (nuevo) | PLANIFICADO |
| VT-006 | Templado | Control de hornos | 0% (nuevo) | PLANIFICADO |
| VT-007 | Calidad | QC y certificaciones | 40% core | PLANIFICADO |
| VT-008 | Despacho | Logística entregas | 50% core | PLANIFICADO |
**Story Points Estimados:** 259 SP (detallado en épicas)
---
## 🏭 DOMINIO DE NEGOCIO
### Proceso de Producción
```
Cotización → Orden Producción → Corte → Templado → QC → Despacho
```
### Productos
- Vidrio templado (varios espesores: 4mm, 6mm, 8mm, 10mm, 12mm)
- Vidrio laminado
- Vidrio insulado
- Espejo
- Grabados y sandblasting
### Características Específicas
- Cotización por dimensiones (alto × ancho)
- Optimización de corte (nesting)
- Control de hornos de templado
- Pruebas de fragmentación
- Trazabilidad de lotes
---
## 📁 ESTRUCTURA DE DOCUMENTACIÓN
```
docs/
├── 00-vision-general/
│ └── VISION-VIDRIO.md ✅
├── 02-definicion-modulos/
│ ├── INDICE-MODULOS.md ✅
│ ├── VT-001-fundamentos/README.md ✅
│ ├── VT-002-cotizaciones/README.md ✅
│ ├── VT-003-produccion/README.md ✅
│ ├── VT-004-inventario/README.md ✅
│ ├── VT-005-corte/README.md ✅
│ ├── VT-006-templado/README.md ✅
│ ├── VT-007-calidad/README.md ✅
│ └── VT-008-despacho/README.md ✅
└── 08-epicas/
└── EPIC-VT-001-fundamentos.md ✅
```
---
## 🎯 PRÓXIMOS PASOS
1. Completar análisis de requerimientos
2. Modelado de dominio
3. Comparación con Odoo
4. Diseño de base de datos
5. Inicio de desarrollo
### Fase 1: Documentación Detallada
1. [ ] Crear épicas completas (EPIC-VT-002 a 008)
2. [ ] Documentar User Stories por módulo
3. [ ] Definir requerimientos funcionales (RF)
4. [ ] Crear especificaciones técnicas (ET)
### Fase 2: Diseño de Base de Datos
5. [ ] Diseñar schemas de BD
6. [ ] Implementar DDL
7. [ ] Documentar modelo de datos
### Fase 3: Desarrollo
8. [ ] Implementar backend (TypeScript/Express)
9. [ ] Implementar frontend (React)
10. [ ] Testing
---
## 📈 MÉTRICAS
| Métrica | Valor |
|---------|-------|
| Módulos definidos | 8 |
| Épicas creadas | 8/8 ✅ |
| User Stories | 0 (pendiente) |
| Story Points | 259 |
| Archivos MD | 29 |
| Archivos SQL | 0 |
| Archivos TS | 0 |
---
## 🏗️ ARQUITECTURA
**Tipo:** Proyecto Independiente (fork conceptual del ERP-Core)
**Patrones a reutilizar del ERP-Core:**
- Multi-tenancy con RLS (para franquicias)
- Estructura de autenticación
- Patrones de inventario
- Sistema de cotizaciones base
**Módulos 100% nuevos:**
- VT-005: Corte (algoritmo de nesting)
- VT-006: Templado (control de hornos)
**Opera de forma autónoma:** No requiere ERP-Core instalado
---
## 🔗 REFERENCIAS
- Índice de módulos: `docs/02-definicion-modulos/INDICE-MODULOS.md`
- Visión: `docs/00-vision-general/VISION-VIDRIO.md`
- SPECS heredadas: `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
- Directivas: `orchestration/directivas/`
---
**Última actualización:** 2025-12-08

View File

@ -110,14 +110,23 @@ glass.raw_materials -- Materia prima
**Documento detallado:** `orchestration/00-guidelines/HERENCIA-SPECS-CORE.md`
### Correcciones de DDL Core (2025-12-08)
El DDL del ERP-Core fue corregido para resolver FK inválidas:
1. **stock_valuation_layers**: Campos `journal_entry_id` y `journal_entry_line_id` (antes `account_move_*`)
2. **stock_move_consume_rel**: Nueva tabla de trazabilidad (antes `move_line_consume_rel`)
3. **category_stock_accounts**: FK corregida a `core.product_categories`
4. **product_categories**: ALTERs ahora apuntan a schema `core`
### SPECS Obligatorias
| Spec Core | Aplicación en Vidrio Templado | SP | Estado |
|-----------|------------------------------|----:|--------|
| SPEC-SISTEMA-SECUENCIAS | Foliado de órdenes y lotes | 8 | PENDIENTE |
| SPEC-VALORACION-INVENTARIO | Costeo de materia prima y producto | 21 | PENDIENTE |
| SPEC-SEGURIDAD-API-KEYS-PERMISOS | Control de acceso | 31 | PENDIENTE |
| SPEC-TRAZABILIDAD-LOTES-SERIES | Lotes de producción de vidrio | 13 | PENDIENTE |
| SPEC-SISTEMA-SECUENCIAS | Foliado de órdenes y lotes | 8 | ✅ DDL LISTO |
| SPEC-VALORACION-INVENTARIO | Costeo de materia prima y producto | 21 | ✅ DDL LISTO |
| SPEC-SEGURIDAD-API-KEYS-PERMISOS | Control de acceso | 31 | ✅ DDL LISTO |
| SPEC-TRAZABILIDAD-LOTES-SERIES | Lotes de producción de vidrio | 13 | ✅ DDL LISTO |
| SPEC-PRICING-RULES | Precios por dimensiones y tipo | 8 | PENDIENTE |
| SPEC-PROYECTOS-DEPENDENCIAS-BURNDOWN | Control de producción | 13 | PENDIENTE |
| SPEC-MAIL-THREAD-TRACKING | Historial de órdenes | 13 | PENDIENTE |

View File

@ -0,0 +1,198 @@
# EPICA: EPIC-VT-002 - Cotizaciones
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-VT-002 |
| **Nombre** | Cotizaciones |
| **Modulo** | cotizaciones |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P0 (Critico) |
| **Estado** | Backlog |
| **Story Points** | 34 |
| **Sprint(s)** | Sprint 2-3 |
---
## Descripcion
Sistema de cotizaciones especializado para productos de vidrio. Permite calcular precios por dimensiones (alto x ancho x espesor), tipo de vidrio, acabados y procesamientos adicionales. Genera PDFs profesionales y permite conversión directa a órdenes de producción.
---
## Objetivo de Negocio
- Reducir tiempo de cotización de 30 min a 5 min
- Eliminar errores de cálculo manual de áreas
- Estandarizar precios por tipo de vidrio y espesor
- Mejorar presentación profesional con PDFs
- Agilizar conversión de cotización a producción
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-VT002-001 | Como vendedor, quiero crear cotización ingresando dimensiones de piezas para calcular automáticamente el área en m² | P0 | 5 | Backlog |
| US-VT002-002 | Como vendedor, quiero seleccionar tipo de vidrio y espesor de un catálogo para aplicar precio correcto | P0 | 3 | Backlog |
| US-VT002-003 | Como vendedor, quiero agregar acabados (sandblast, grabado, bisel) para calcular costo adicional | P0 | 5 | Backlog |
| US-VT002-004 | Como vendedor, quiero ver resumen de cotización con desglose de costos para revisar antes de enviar | P0 | 3 | Backlog |
| US-VT002-005 | Como vendedor, quiero generar PDF de cotización con logo y datos fiscales para enviar al cliente | P0 | 5 | Backlog |
| US-VT002-006 | Como vendedor, quiero enviar cotización por email al cliente para agilizar proceso | P1 | 3 | Backlog |
| US-VT002-007 | Como jefe de ventas, quiero convertir cotización aprobada a orden de producción para iniciar fabricación | P0 | 5 | Backlog |
| US-VT002-008 | Como admin, quiero configurar precios por tipo de vidrio y espesor para mantener lista actualizada | P0 | 3 | Backlog |
| US-VT002-009 | Como admin, quiero definir márgenes de utilidad por cliente para aplicar descuentos automáticos | P2 | 2 | Backlog |
**Total Story Points:** 34 SP
---
## Flujo de Cotización
```
┌─────────────┐
│ BORRADOR │ ← Se inicia cotización
└──────┬──────┘
┌─────────────┐
│ CALCULADA │ ← Áreas y precios calculados
└──────┬──────┘
┌─────────────┐
│ ENVIADA │ ← Enviada a cliente
└──────┬──────┘
├──────────────┐
▼ ▼
┌─────────────┐ ┌─────────────┐
│ APROBADA │ │ RECHAZADA │
└──────┬──────┘ └─────────────┘
┌─────────────┐
│ CONVERTIDA │ ← Se genera orden de producción
└─────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Crear cotización con cliente y datos de contacto
- [ ] Agregar líneas con dimensiones (alto × ancho × espesor)
- [ ] Calcular automáticamente área en m² y precio
- [ ] Seleccionar tipo de vidrio de catálogo
- [ ] Agregar acabados con precio adicional
- [ ] Generar PDF profesional
- [ ] Enviar por email
- [ ] Convertir a orden de producción
**No Funcionales:**
- [ ] Cálculo de precio < 100ms
- [ ] Generación PDF < 3 segundos
- [ ] Soporte para cotizaciones de 50+ líneas
**Tecnicos:**
- [ ] Integración con catálogo de vidrios
- [ ] Integración con módulo de producción
- [ ] Templates PDF configurables
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-VT-001 Fundamentos | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-VT-003 Produccion | Requiere cotizaciones aprobadas |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `quotes`
- [ ] Tablas: 5 (quotes, quote_lines, glass_types, finishes, prices)
- [ ] Funciones: 2 (calculate_area, calculate_total)
- [ ] Indices: Por cliente, fecha, estado
**Backend:**
- [ ] Modulo: `quotations`
- [ ] Entities: 4 (Quote, QuoteLine, GlassType, Finish)
- [ ] Endpoints: 12
- [ ] Tests: 25
**Frontend:**
- [ ] Paginas: 4 (QuotesList, QuoteCreate, QuoteDetail, QuotePDF)
- [ ] Componentes: 10 (QuoteForm, LineEditor, PriceCalculator, etc.)
- [ ] Stores: 1 (quotesStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /api/quotes | Crear cotización |
| GET | /api/quotes | Listar cotizaciones (paginado) |
| GET | /api/quotes/:id | Detalle de cotización |
| PATCH | /api/quotes/:id | Actualizar cotización |
| POST | /api/quotes/:id/lines | Agregar línea |
| DELETE | /api/quotes/:id/lines/:lineId | Eliminar línea |
| POST | /api/quotes/:id/calculate | Recalcular totales |
| POST | /api/quotes/:id/send | Enviar por email |
| POST | /api/quotes/:id/convert | Convertir a orden |
| GET | /api/quotes/:id/pdf | Generar PDF |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Cálculos complejos de acabados | Media | Alto | Catálogo bien definido |
| Precios desactualizados | Media | Medio | Validación al enviar |
| PDFs no profesionales | Baja | Medio | Templates revisados |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Catálogo de vidrios definido
- [ ] Template PDF aprobado
## Definition of Done (DoD)
- [ ] Flujo completo de cotización funcionando
- [ ] Generación de PDFs correcta
- [ ] Conversión a orden de producción
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

View File

@ -0,0 +1,218 @@
# EPICA: EPIC-VT-003 - Producción
## Metadata
| Campo | Valor |
|-------|-------|
| **ID** | EPIC-VT-003 |
| **Nombre** | Producción |
| **Modulo** | produccion |
| **Fase** | Fase 1 - MVP |
| **Prioridad** | P0 (Critico) |
| **Estado** | Backlog |
| **Story Points** | 42 |
| **Sprint(s)** | Sprint 4-5 |
---
## Descripcion
Gestión completa de órdenes de producción para vidrio templado. Controla el flujo desde la recepción del pedido hasta la entrega del producto terminado, pasando por corte, templado y control de calidad. Incluye planificación de capacidad y seguimiento en tiempo real.
---
## Objetivo de Negocio
- Control total del proceso productivo
- Reducir tiempos muertos entre etapas
- Trazabilidad completa por lote
- Optimizar uso de hornos de templado
- Minimizar desperdicios de material
---
## Historias de Usuario
| ID | Historia | Prioridad | SP | Estado |
|----|----------|-----------|-----|--------|
| US-VT003-001 | Como jefe de producción, quiero crear orden de producción desde cotización aprobada para iniciar el proceso | P0 | 5 | Backlog |
| US-VT003-002 | Como jefe de producción, quiero ver tablero de órdenes en proceso para supervisar producción | P0 | 5 | Backlog |
| US-VT003-003 | Como operador de corte, quiero ver mis piezas asignadas del día para planificar trabajo | P0 | 3 | Backlog |
| US-VT003-004 | Como operador de corte, quiero marcar piezas cortadas para avanzar a siguiente etapa | P0 | 3 | Backlog |
| US-VT003-005 | Como operador de horno, quiero ver piezas listas para templado agrupadas por espesor | P0 | 5 | Backlog |
| US-VT003-006 | Como operador de horno, quiero registrar lote de templado con temperatura y tiempo | P0 | 5 | Backlog |
| US-VT003-007 | Como inspector de calidad, quiero registrar resultado de inspección para liberar producto | P0 | 5 | Backlog |
| US-VT003-008 | Como jefe de producción, quiero ver métricas de producción diaria para medir eficiencia | P1 | 5 | Backlog |
| US-VT003-009 | Como jefe de producción, quiero reprogramar orden para ajustar prioridades | P1 | 3 | Backlog |
| US-VT003-010 | Como admin, quiero configurar estaciones de trabajo para asignar órdenes | P2 | 3 | Backlog |
**Total Story Points:** 42 SP
---
## Flujo de Producción
```
┌─────────────┐
│ PROGRAMADA │ ← Orden creada y programada
└──────┬──────┘
┌─────────────┐
│ EN_CORTE │ ← Piezas siendo cortadas
└──────┬──────┘
┌─────────────┐
│ CORTADO │ ← Todas las piezas cortadas
└──────┬──────┘
┌─────────────┐
│ EN_TEMPLADO │ ← Piezas en horno
└──────┬──────┘
┌─────────────┐
│ TEMPLADO │ ← Templado completado
└──────┬──────┘
┌─────────────┐
│ EN_QC │ ← Inspección de calidad
└──────┬──────┘
├──────────────┐
▼ ▼
┌─────────────┐ ┌─────────────┐
│ APROBADO │ │ RECHAZADO │
└──────┬──────┘ └──────┬──────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ LISTO_ENVIO │ │ REPROCESO │
└─────────────┘ └─────────────┘
```
---
## Criterios de Aceptacion de la Epica
**Funcionales:**
- [ ] Crear orden desde cotización aprobada
- [ ] Asignar a línea de producción
- [ ] Registrar avance por etapa (corte, templado, QC)
- [ ] Registrar parámetros de templado (temp, tiempo)
- [ ] Registrar resultados de QC
- [ ] Gestionar reprocesos
- [ ] Dashboard de producción en tiempo real
**No Funcionales:**
- [ ] Actualización de tablero < 5 segundos
- [ ] Soporte para 100+ órdenes activas
- [ ] Registro de etapas en < 3 clicks
**Tecnicos:**
- [ ] Integración con módulo de corte (nesting)
- [ ] Integración con módulo de templado (hornos)
- [ ] Integración con módulo de calidad
- [ ] Alertas de órdenes atrasadas
---
## Dependencias
**Esta epica depende de:**
| Epica/Modulo | Estado | Bloqueante |
|--------------|--------|------------|
| EPIC-VT-001 Fundamentos | Backlog | Si |
| EPIC-VT-002 Cotizaciones | Backlog | Si |
| EPIC-VT-004 Inventario | Backlog | Si |
**Esta epica bloquea:**
| Epica/Modulo | Razon |
|--------------|-------|
| EPIC-VT-005 Corte | Requiere órdenes de producción |
| EPIC-VT-006 Templado | Requiere órdenes de producción |
| EPIC-VT-007 Calidad | Requiere órdenes de producción |
| EPIC-VT-008 Despacho | Requiere producción completada |
---
## Desglose Tecnico
**Database:**
- [ ] Schema: `production`
- [ ] Tablas: 8 (production_orders, order_items, stages, stage_logs, workstations, etc.)
- [ ] Funciones: 4 (advance_stage, calculate_times, etc.)
- [ ] Indices: Por orden, fecha, etapa, estación
**Backend:**
- [ ] Modulo: `production`
- [ ] Entities: 6 (ProductionOrder, OrderItem, Stage, StageLog, Workstation)
- [ ] Endpoints: 18
- [ ] Tests: 35
**Frontend:**
- [ ] Paginas: 5 (ProductionBoard, OrderDetail, StageTracker, Metrics, Config)
- [ ] Componentes: 15 (OrderCard, StageProgress, WorkstationSelector, etc.)
- [ ] Stores: 2 (productionStore, workstationsStore)
---
## Endpoints API
| Metodo | Endpoint | Descripcion |
|--------|----------|-------------|
| POST | /api/production/orders | Crear orden de producción |
| GET | /api/production/orders | Listar órdenes |
| GET | /api/production/orders/:id | Detalle de orden |
| PATCH | /api/production/orders/:id | Actualizar orden |
| POST | /api/production/orders/:id/advance | Avanzar etapa |
| POST | /api/production/orders/:id/assign | Asignar a estación |
| GET | /api/production/board | Tablero de producción |
| GET | /api/production/metrics | Métricas de producción |
| GET | /api/workstations | Listar estaciones |
---
## Riesgos
| Riesgo | Probabilidad | Impacto | Mitigacion |
|--------|--------------|---------|------------|
| Cuellos de botella en templado | Alta | Alto | Planificación por capacidad de hornos |
| Pérdida de trazabilidad | Media | Alto | Registro obligatorio por etapa |
| Reprocesos no controlados | Media | Medio | Flujo de reproceso definido |
---
## Definition of Ready (DoR)
- [x] Historias de usuario definidas
- [x] Criterios de aceptacion claros
- [x] Dependencias identificadas
- [x] Estimacion completada
- [ ] Flujo de etapas aprobado
- [ ] Estaciones de trabajo definidas
## Definition of Done (DoD)
- [ ] Flujo completo de producción funcionando
- [ ] Tablero en tiempo real operativo
- [ ] Trazabilidad por lote implementada
- [ ] Tests de integración pasando
- [ ] Documentación de API
---
## Historial
| Fecha | Cambio | Autor |
|-------|--------|-------|
| 2025-12-08 | Creacion de epica | Claude-Agent |
---
**Creada por:** Claude-Agent
**Fecha:** 2025-12-08
**Ultima actualizacion:** 2025-12-08

Some files were not shown because too many files have changed in this diff Show More