- Prefijo v2: MCH - TRACEABILITY-MASTER.yml creado - Listo para integracion como submodulo Workspace: v2.0.0 | SIMCO: v4.0.0
9.5 KiB
Plan Detallado FASE 2 - Integracion y Pruebas
Fecha: 2026-01-06 Ejecutor: PERFIL_ORQUESTADOR Basado en: ANALISIS-FASE1-2026-01-06.md
Objetivo de FASE 2
Conectar todos los componentes implementados (Backend, Frontend, WhatsApp Service, MCP Server, Database) en un sistema funcional e integrado.
1. TAREAS IDENTIFICADAS
1.1 Bloque A: Integracion Backend-Database (CRITICO)
| ID | Tarea | Prioridad | Esfuerzo | Dependencias |
|---|---|---|---|---|
| A1 | Configurar TypeORM con conexion PostgreSQL | P0 | 2h | Database creada |
| A2 | Sincronizar entidades con schemas existentes | P0 | 4h | A1 |
| A3 | Configurar RLS middleware en NestJS | P0 | 3h | A2 |
| A4 | Crear migration base desde schemas | P1 | 2h | A2 |
| A5 | Actualizar puerto backend a 3141 | P0 | 0.5h | - |
| A6 | Verificar conexion con seeds existentes | P0 | 1h | A1-A3 |
Entregable Bloque A: Backend conectado a PostgreSQL con aislamiento multi-tenant
1.2 Bloque B: Integracion Frontend-Backend
| ID | Tarea | Prioridad | Esfuerzo | Dependencias |
|---|---|---|---|---|
| B1 | Configurar proxy Vite -> Backend (3141) | P0 | 0.5h | A5 |
| B2 | Actualizar api.ts con baseURL correcta | P0 | 0.5h | B1 |
| B3 | Implementar autenticacion en frontend | P0 | 3h | A1 |
| B4 | Conectar Dashboard con API real | P1 | 2h | B3 |
| B5 | Conectar Products con API real | P1 | 2h | B3 |
| B6 | Conectar Orders con API real | P1 | 2h | B3 |
| B7 | Conectar Customers con API real | P1 | 2h | B3 |
| B8 | Conectar Fiado con API real | P1 | 2h | B3 |
| B9 | Conectar Inventory con API real | P1 | 2h | B3 |
| B10 | Conectar Settings con API real | P2 | 1h | B3 |
Entregable Bloque B: Frontend funcional con datos reales
1.3 Bloque C: Integracion WhatsApp Service
| ID | Tarea | Prioridad | Esfuerzo | Dependencias |
|---|---|---|---|---|
| C1 | Configurar BACKEND_API_URL en WhatsApp Service | P0 | 0.5h | A5 |
| C2 | Implementar fetch de productos desde backend | P1 | 2h | A6, C1 |
| C3 | Implementar fetch de categorias desde backend | P1 | 1h | A6, C1 |
| C4 | Implementar fetch de ordenes desde backend | P1 | 2h | A6, C1 |
| C5 | Implementar fetch de fiado desde backend | P1 | 2h | A6, C1 |
| C6 | Implementar creacion de ordenes via backend | P1 | 3h | C4 |
| C7 | Actualizar puerto WhatsApp Service a 3143 | P0 | 0.5h | - |
Entregable Bloque C: WhatsApp Service conectado al backend
1.4 Bloque D: Integracion MCP Server
| ID | Tarea | Prioridad | Esfuerzo | Dependencias |
|---|---|---|---|---|
| D1 | Actualizar BACKEND_URL en MCP Server | P0 | 0.5h | A5 |
| D2 | Probar todos los tools con backend real | P1 | 3h | A6, D1 |
| D3 | Ajustar endpoints si hay discrepancias | P1 | 2h | D2 |
| D4 | Documentar tools disponibles | P2 | 1h | D3 |
Entregable Bloque D: MCP Server operativo con backend
1.5 Bloque E: Pruebas de Integracion
| ID | Tarea | Prioridad | Esfuerzo | Dependencias |
|---|---|---|---|---|
| E1 | Test flujo registro tenant | P0 | 1h | B3 |
| E2 | Test flujo login/logout | P0 | 1h | B3 |
| E3 | Test flujo crear producto | P1 | 1h | B5 |
| E4 | Test flujo crear venta (POS) | P1 | 2h | B5 |
| E5 | Test flujo crear pedido | P1 | 1h | B6 |
| E6 | Test flujo fiado | P1 | 2h | B8 |
| E7 | Test flujo WhatsApp -> Pedido | P1 | 2h | C6 |
| E8 | Test flujo MCP tools | P1 | 2h | D2 |
Entregable Bloque E: Sistema validado end-to-end
2. ORDEN DE EJECUCION
Fase 2.1: Preparacion (Dia 1)
A5 (Puerto backend) ────────────────────────┐
│
C7 (Puerto WhatsApp) ───────────────────────┼───┐
│ │
D1 (URL MCP) ───────────────────────────────┘ │
│
B1 (Proxy Vite) ────────────────────────────────┘
Fase 2.2: Backend-Database (Dia 1-2)
A1 (TypeORM config) ──► A2 (Sync entities) ──► A3 (RLS middleware)
│
▼
A6 (Verificar seeds)
│
▼
A4 (Migrations) [opcional]
Fase 2.3: Frontend Integration (Dia 2-3)
B2 (api.ts) ──► B3 (Auth) ──┬──► B4 (Dashboard)
├──► B5 (Products)
├──► B6 (Orders)
├──► B7 (Customers)
├──► B8 (Fiado)
├──► B9 (Inventory)
└──► B10 (Settings)
Fase 2.4: Services Integration (Dia 3-4)
C1 (Config) ──► C2 (Products) ──► C6 (Create orders)
│
├──► C3 (Categories)
├──► C4 (Orders)
└──► C5 (Fiado)
D1 (Config) ──► D2 (Test tools) ──► D3 (Ajustes)
Fase 2.5: Testing (Dia 4-5)
E1 (Registro) ──► E2 (Login) ──► E3 (Producto) ──► E4 (Venta)
│
├──► E5 (Pedido)
└──► E6 (Fiado)
E7 (WhatsApp flow) ─────────────────────────────────────────►
E8 (MCP tools) ─────────────────────────────────────────────►
3. DETALLE DE TAREAS CRITICAS
3.1 Tarea A1: Configurar TypeORM
Archivo: apps/backend/src/app.module.ts
Configuracion requerida:
TypeOrmModule.forRoot({
type: 'postgres',
host: process.env.DB_HOST || 'localhost',
port: parseInt(process.env.DB_PORT || '5432'),
username: process.env.DB_USER || 'michangarrito_dev',
password: process.env.DB_PASSWORD || 'MCh_dev_2025_secure',
database: process.env.DB_NAME || 'michangarrito_dev',
entities: [__dirname + '/**/*.entity{.ts,.js}'],
synchronize: false, // IMPORTANTE: No auto-sync
logging: process.env.NODE_ENV === 'development',
})
Variables .env:
DB_HOST=localhost
DB_PORT=5432
DB_NAME=michangarrito_dev
DB_USER=michangarrito_dev
DB_PASSWORD=MCh_dev_2025_secure
3.2 Tarea A3: RLS Middleware
Archivo nuevo: apps/backend/src/common/middleware/tenant.middleware.ts
Funcion: Establecer app.current_tenant en cada request
Flujo:
- Extraer tenantId del JWT token
- Ejecutar
SET app.current_tenant = 'uuid' - Continuar con el request
3.3 Tarea B3: Autenticacion Frontend
Archivos a modificar:
apps/frontend/src/lib/api.ts- Agregar interceptor authapps/frontend/src/App.tsx- Agregar rutas protegidas- Nuevo:
apps/frontend/src/pages/Login.tsx - Nuevo:
apps/frontend/src/contexts/AuthContext.tsx
Flujo:
- Login -> POST /auth/login -> JWT
- Guardar token en localStorage
- Interceptor agrega Bearer token
- Proteger rutas con AuthContext
4. CRITERIOS DE ACEPTACION
4.1 Bloque A (Backend-Database)
- Backend inicia sin errores en puerto 3141
- Conexion a PostgreSQL exitosa
- Query a tenants retorna datos de seeds
- RLS activo: queries filtran por tenant_id
4.2 Bloque B (Frontend)
- Login funciona con credenciales de prueba
- Dashboard muestra estadisticas reales
- CRUD productos funcional
- Lista de ordenes con datos reales
- Lista de clientes con datos reales
4.3 Bloque C (WhatsApp)
- Webhook responde correctamente
- Mensaje "hola" muestra menu
- Consulta de productos funciona
- Creacion de pedido funciona
4.4 Bloque D (MCP)
- list_products retorna datos reales
- create_order crea pedido en DB
- get_fiado_balance consulta datos reales
4.5 Bloque E (Tests)
- Flujo completo registro -> login -> crear producto -> venta
- Flujo WhatsApp -> pedido -> confirmacion
- Sin errores 500 en consola
5. RIESGOS Y MITIGACIONES
| Riesgo | Probabilidad | Mitigacion |
|---|---|---|
| Mismatch entidades-schemas | Alta | Revisar uno por uno con DDL |
| Timeout PostgreSQL | Baja | Configurar pool connections |
| CORS issues | Media | Configurar origins en backend |
| JWT expiracion | Media | Implementar refresh token |
6. RECURSOS REQUERIDOS
6.1 Desarrollo
- 1 Backend Developer (A1-A6, C1-C7, D1-D3)
- 1 Frontend Developer (B1-B10)
- QA para E1-E8
6.2 Infraestructura
- PostgreSQL corriendo (ya disponible)
- Redis (opcional para cache)
- Cuenta WhatsApp Business (para C1-C7)
6.3 Herramientas
- Postman/Insomnia para testing API
- pgAdmin para verificar datos
7. ESTIMACION TOTAL
| Bloque | Horas | Dias (8h) |
|---|---|---|
| A | 12.5h | 1.5 |
| B | 17h | 2 |
| C | 11h | 1.5 |
| D | 6.5h | 1 |
| E | 12h | 1.5 |
| Total | 59h | 7.5 dias |
Buffer 20%: 9 dias habiles
8. ENTREGABLES FINALES FASE 2
- Backend conectado a PostgreSQL con RLS
- Frontend funcional con API real
- WhatsApp Service integrado
- MCP Server operativo
- Suite de pruebas manuales documentada
- .env.example actualizado
- README actualizado con instrucciones de setup
Aprobacion requerida para continuar a Fase 3 (Mobile App)
Fin del Plan FASE 2