trading-platform/orchestration/tareas/TASK-2026-02-04-ANALISIS-PLANIFICACION-INTEGRAL/03-PLANIFICACION.md

# 03-PLANIFICACION - Análisis y Planeación Integral

**Tarea:** TASK-2026-02-04-ANALISIS-PLANIFICACION-INTEGRAL
**Fase:** P (Planificación)
**Estado:** EN PROGRESO
**Fecha:** 2026-02-04
**Agente:** Claude Code (Opus 4.5)

---

## 1. ESTRUCTURA DEL PLAN MAESTRO

### 1.1 Organización Jerárquica

```
PLAN-MAESTRO-TRADING-PLATFORM-2026-Q1
│
├── FASE-0: PREPARACIÓN (8h)
│   ├── SUBTAREA-0.1: Purga documentación obsoleta
│   ├── SUBTAREA-0.2: Sincronización inventarios
│   └── SUBTAREA-0.3: Actualización PROJECT-STATUS
│
├── FASE-1: DDL GAPS (16h)
│   ├── SUBTAREA-1.1: education.instructors table
│   ├── SUBTAREA-1.2: education.course_tags field
│   ├── SUBTAREA-1.3: trading.price_alerts table
│   └── SUBTAREA-1.4: Validación DDL post-cambios
│
├── FASE-2: BACKEND SERVICES (48h)
│   ├── SUBTAREA-2.1: Market Data OHLCV Service (P0)
│   ├── SUBTAREA-2.2: Notifications Complete Service (P1)
│   ├── SUBTAREA-2.3: User Profile Service (P0)
│   ├── SUBTAREA-2.4: Audit Service (P2)
│   └── SUBTAREA-2.5: 2FA Complete Flow (P1)
│
├── FASE-3: BACKEND API (24h)
│   ├── SUBTAREA-3.1: Market Data Endpoints
│   ├── SUBTAREA-3.2: Notifications Endpoints
│   ├── SUBTAREA-3.3: User Profile Endpoints
│   ├── SUBTAREA-3.4: Trading Agents Endpoints
│   └── SUBTAREA-3.5: 2FA Setup Endpoints
│
├── FASE-4: FRONTEND INTEGRATION (180h)
│   ├── SPRINT-FE-1: Fundamentos (17 SP)
│   ├── SPRINT-FE-2: Trading Core (60 SP)
│   ├── SPRINT-FE-3: Investment (81 SP)
│   ├── SPRINT-FE-4: Advanced Features (128 SP)
│   └── SPRINT-FE-5: Growth (55 SP)
│
├── FASE-5: ARCHITECTURE REFACTOR (24h)
│   ├── SUBTAREA-5.1: Proxy Python Services (ARCH-001)
│   └── SUBTAREA-5.2: Standardize apiClient (ARCH-002)
│
├── FASE-6: TESTING (40h)
│   ├── SUBTAREA-6.1: Unit Tests Backend
│   ├── SUBTAREA-6.2: Unit Tests Frontend
│   ├── SUBTAREA-6.3: Integration Tests
│   └── SUBTAREA-6.4: E2E Tests
│
└── FASE-7: DOCUMENTACIÓN (16h)
    ├── SUBTAREA-7.1: Guías desarrollo
    ├── SUBTAREA-7.2: API Documentation
    └── SUBTAREA-7.3: Actualización inventarios final
```

---

## 2. DETALLE DE SUBTAREAS - FASE 0: PREPARACIÓN

### SUBTAREA-0.1: Purga Documentación Obsoleta

**ID:** ST-0.1
**Prioridad:** P0
**Esfuerzo:** 2h
**Perfil:** PERFIL-ORQUESTADOR
**Parallelizable:** Sí

**CAPVED:**
- **C:** Identificar documentos obsoletos listados en 01-CAPTURA.md
- **A:** Verificar que no hay referencias activas
- **P:** Plan de archivado/eliminación
- **V:** No aplica (no código)
- **E:** Mover/eliminar archivos
- **D:** Actualizar _INDEX.yml

**Acciones:**
1. Mover `TASK-2026-02-03-DDL-VALIDATION/` a `_archive/2026-02/`
2. Eliminar `docs/90-transversal/gaps/ANALISIS-GAPS-DOCUMENTACION.md`
3. Decidir sobre `95-guias-desarrollo/` vacíos

**Criterios Aceptación:**
- [ ] No existen archivos obsoletos identificados
- [ ] _INDEX.yml actualizado
- [ ] Sin referencias rotas

---

### SUBTAREA-0.2: Sincronización Inventarios

**ID:** ST-0.2
**Prioridad:** P0
**Esfuerzo:** 4h
**Perfil:** PERFIL-ORQUESTADOR
**Parallelizable:** Parcial

**CAPVED:**
- **C:** Leer inventarios actuales y código real
- **A:** Identificar discrepancias específicas
- **P:** Lista de correcciones por inventario
- **V:** Verificar conteos con grep/find
- **E:** Actualizar YAML files
- **D:** Commit con changelog

**Acciones:**
1. BACKEND_INVENTORY.yml: Actualizar conteo 57→79 endpoints
2. FRONTEND_INVENTORY.yml: Actualizar conteo 90→146 componentes
3. DATABASE_INVENTORY.yml: Resolver duplicación notifications

**Criterios Aceptación:**
- [ ] Todos los inventarios >95% sincronizados
- [ ] Sin duplicaciones en DDL registry
- [ ] Conteos verificados automáticamente

---

### SUBTAREA-0.3: Actualización PROJECT-STATUS

**ID:** ST-0.3
**Prioridad:** P0
**Esfuerzo:** 2h
**Perfil:** PERFIL-ORQUESTADOR
**Parallelizable:** Sí

**CAPVED:**
- **C:** Leer PROJECT-STATUS.md actual (2026-01-30)
- **A:** Comparar con estado real del proyecto
- **P:** Lista de secciones a actualizar
- **V:** No aplica
- **E:** Editar PROJECT-STATUS.md y PROXIMA-ACCION.md
- **D:** Commit

**Criterios Aceptación:**
- [ ] PROJECT-STATUS.md con fecha actual
- [ ] PROXIMA-ACCION.md refleja tarea actual
- [ ] Métricas actualizadas

---

## 3. DETALLE DE SUBTAREAS - FASE 1: DDL GAPS

### SUBTAREA-1.1: education.instructors Table

**ID:** ST-1.1
**Prioridad:** P1
**Esfuerzo:** 4h
**Perfil:** PERFIL-DATABASE-POSTGRESQL
**Parallelizable:** Sí (con ST-1.2, ST-1.3)
**Depende de:** ST-0.2

**CAPVED:**
- **C:** Revisar requerimientos OQI-002 para instructores
- **A:** Diseñar schema de tabla con campos necesarios
- **P:** DDL script con constraints y índices
- **V:** Validar FK hacia auth.user_profiles
- **E:** Crear DDL y ejecutar en WSL
- **D:** Actualizar DATABASE_INVENTORY.yml

**DDL Propuesto:**
```sql
CREATE TABLE education.instructors (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL REFERENCES auth.user_profiles(id),
    bio TEXT,
    specializations TEXT[],
    rating DECIMAL(3,2) DEFAULT 0,
    total_courses INTEGER DEFAULT 0,
    total_students INTEGER DEFAULT 0,
    is_verified BOOLEAN DEFAULT false,
    created_at TIMESTAMPTZ DEFAULT NOW(),
    updated_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE INDEX idx_instructors_user_id ON education.instructors(user_id);
CREATE INDEX idx_instructors_rating ON education.instructors(rating DESC);
```

**Criterios Aceptación:**
- [ ] Tabla creada en schema education
- [ ] FK válida hacia auth.user_profiles
- [ ] Índices creados
- [ ] DDL documentado en apps/database/

---

### SUBTAREA-1.2: education.course_tags Field

**ID:** ST-1.2
**Prioridad:** P1
**Esfuerzo:** 2h
**Perfil:** PERFIL-DATABASE-POSTGRESQL
**Parallelizable:** Sí (con ST-1.1, ST-1.3)
**Depende de:** ST-0.2

**CAPVED:**
- **C:** Revisar OQI-002 para filtrado por tags
- **A:** Decidir: campo TEXT[] o tabla de relación
- **P:** DDL para campo o tabla
- **V:** Compatibilidad con queries existentes
- **E:** Ejecutar DDL en WSL
- **D:** Actualizar inventario

**Decisión Arquitectural:**
Usar tabla de relación `education.course_tag_assignments` (ya existe tag.service.ts)

**Criterios Aceptación:**
- [ ] Tags pueden asignarse a cursos
- [ ] Queries de filtrado funcionan
- [ ] Coherencia con tag.service.ts existente

---

### SUBTAREA-1.3: trading.price_alerts Table

**ID:** ST-1.3
**Prioridad:** P0
**Esfuerzo:** 4h
**Perfil:** PERFIL-DATABASE-POSTGRESQL
**Parallelizable:** Sí (con ST-1.1, ST-1.2)
**Depende de:** ST-0.2

**CAPVED:**
- **C:** Revisar OQI-003 para alertas de precio
- **A:** Diseñar schema con tipos de alerta
- **P:** DDL con enum y tabla
- **V:** FK hacia trading.symbols
- **E:** Ejecutar DDL
- **D:** Documentar

**DDL Propuesto:**
```sql
CREATE TYPE trading.alert_type AS ENUM ('price_above', 'price_below', 'percent_change', 'volume_spike');
CREATE TYPE trading.alert_status AS ENUM ('active', 'triggered', 'expired', 'cancelled');

CREATE TABLE trading.price_alerts (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL REFERENCES auth.user_profiles(id),
    symbol_id UUID NOT NULL REFERENCES trading.symbols(id),
    alert_type trading.alert_type NOT NULL,
    target_price DECIMAL(18,8),
    percent_threshold DECIMAL(5,2),
    status trading.alert_status DEFAULT 'active',
    triggered_at TIMESTAMPTZ,
    expires_at TIMESTAMPTZ,
    notification_channels TEXT[] DEFAULT ARRAY['push', 'email'],
    created_at TIMESTAMPTZ DEFAULT NOW(),
    updated_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE INDEX idx_price_alerts_user ON trading.price_alerts(user_id);
CREATE INDEX idx_price_alerts_symbol ON trading.price_alerts(symbol_id);
CREATE INDEX idx_price_alerts_active ON trading.price_alerts(status) WHERE status = 'active';
```

**Criterios Aceptación:**
- [ ] Tabla creada con enums
- [ ] FKs válidas
- [ ] Índice parcial para alertas activas
- [ ] Compatible con notification service

---

### SUBTAREA-1.4: Validación DDL Post-Cambios

**ID:** ST-1.4
**Prioridad:** P0
**Esfuerzo:** 2h
**Perfil:** PERFIL-DATABASE-POSTGRESQL
**Parallelizable:** No
**Depende de:** ST-1.1, ST-1.2, ST-1.3

**CAPVED:**
- **C:** Lista de cambios DDL realizados
- **A:** Verificar integridad referencial
- **P:** Script de validación
- **V:** Ejecutar validaciones
- **E:** Corregir si hay errores
- **D:** Actualizar DDL-VALIDATION-MATRIX.yml

**Criterios Aceptación:**
- [ ] Todas las FK válidas
- [ ] Índices optimizados
- [ ] Sin conflictos de nombres
- [ ] Script recreate-db funciona

---

## 4. DETALLE DE SUBTAREAS - FASE 2: BACKEND SERVICES

### SUBTAREA-2.1: Market Data OHLCV Service (CRÍTICO)

**ID:** ST-2.1
**Prioridad:** P0
**Esfuerzo:** 16h
**Perfil:** PERFIL-BACKEND-NESTJS
**Parallelizable:** No (bloquea CHAIN-001)
**Depende de:** ST-1.4

**CAPVED:**
- **C:** Leer especificaciones OQI-003 para datos de mercado
- **A:** Diseñar service con cache Redis
- **P:** Estructura de archivos y endpoints
- **V:** Validar contra DDL market_data
- **E:** Implementar service + controller
- **D:** Swagger docs

**Estructura:**
```
apps/backend/src/modules/market-data/
├── market-data.module.ts
├── market-data.controller.ts
├── market-data.service.ts
├── interfaces/
│   ├── ohlcv.interface.ts
│   └── ticker.interface.ts
├── dto/
│   ├── get-ohlcv.dto.ts
│   └── get-ticker.dto.ts
└── index.ts
```

**Endpoints:**
- GET /api/market-data/ohlcv/:symbol
- GET /api/market-data/tickers
- GET /api/market-data/ticker/:symbol
- WS /ws/market-data/stream

**Criterios Aceptación:**
- [ ] Service implementado con caching
- [ ] Endpoints funcionando
- [ ] WebSocket stream activo
- [ ] Swagger documentado
- [ ] Tests unitarios

---

### SUBTAREA-2.2: Notifications Complete Service

**ID:** ST-2.2
**Prioridad:** P1
**Esfuerzo:** 12h
**Perfil:** PERFIL-BACKEND-NESTJS
**Parallelizable:** Sí (con ST-2.3)
**Depende de:** ST-1.4

**CAPVED:**
- **C:** Revisar notification.service.ts existente (parcial)
- **A:** Identificar funcionalidad faltante
- **P:** Completar service + controller + push
- **V:** Validar contra DDL auth.notifications
- **E:** Implementar
- **D:** Documentar

**Funcionalidad Faltante:**
- Push notifications (web push)
- Email notifications
- In-app notifications API
- User preferences

**Criterios Aceptación:**
- [ ] Push notifications funcionando
- [ ] Preferences guardadas
- [ ] API completa
- [ ] Tests

---

### SUBTAREA-2.3: User Profile Service

**ID:** ST-2.3
**Prioridad:** P0
**Esfuerzo:** 6h
**Perfil:** PERFIL-BACKEND-NESTJS
**Parallelizable:** Sí (con ST-2.2)
**Depende de:** NINGUNA

**CAPVED:**
- **C:** Revisar auth.user_profiles DDL
- **A:** Diseñar CRUD operations
- **P:** Service + Controller
- **V:** Validar auth guards
- **E:** Implementar
- **D:** Swagger

**Estructura:**
```
apps/backend/src/modules/users/
├── users.module.ts
├── users.controller.ts
├── users.service.ts
├── dto/
│   ├── update-profile.dto.ts
│   └── change-password.dto.ts
└── index.ts
```

**Criterios Aceptación:**
- [ ] CRUD de perfil
- [ ] Cambio de password
- [ ] Avatar upload
- [ ] Guards aplicados

---

### SUBTAREA-2.4: Audit Service

**ID:** ST-2.4
**Prioridad:** P2
**Esfuerzo:** 8h
**Perfil:** PERFIL-BACKEND-NESTJS
**Parallelizable:** Sí
**Depende de:** ST-1.4

**CAPVED:**
- **C:** Revisar audit.service.ts existente (parcial)
- **A:** Evaluar reutilización de template-saas
- **P:** Completar queries y endpoints
- **V:** Validar DDL audit schema
- **E:** Implementar
- **D:** Documentar

**Criterios Aceptación:**
- [ ] Log de eventos
- [ ] Queries por usuario/fecha
- [ ] Export capability
- [ ] Admin endpoints

---

### SUBTAREA-2.5: 2FA Complete Flow

**ID:** ST-2.5
**Prioridad:** P1
**Esfuerzo:** 8h
**Perfil:** PERFIL-BACKEND-NESTJS
**Parallelizable:** Sí
**Depende de:** NINGUNA

**CAPVED:**
- **C:** Revisar twofa.service.ts existente
- **A:** Identificar endpoints faltantes
- **P:** Setup + Verify + Backup codes
- **V:** Tests de seguridad
- **E:** Implementar endpoints
- **D:** Documentar flujo

**Endpoints Faltantes:**
- POST /api/auth/2fa/setup
- POST /api/auth/2fa/verify
- POST /api/auth/2fa/disable
- GET /api/auth/2fa/backup-codes

**Criterios Aceptación:**
- [ ] Setup con QR code
- [ ] Verify con TOTP
- [ ] Backup codes generados
- [ ] Disable con password confirm

---

## 5. DETALLE DE SUBTAREAS - FASE 3: BACKEND API

(Resumen - detalles similares a FASE 2)

| ID | Subtarea | Esfuerzo | Depende de |
|----|----------|----------|------------|
| ST-3.1 | Market Data Endpoints | 4h | ST-2.1 |
| ST-3.2 | Notifications Endpoints | 4h | ST-2.2 |
| ST-3.3 | User Profile Endpoints | 4h | ST-2.3 |
| ST-3.4 | Trading Agents Endpoints | 8h | DDL trading |
| ST-3.5 | 2FA Setup Endpoints | 4h | ST-2.5 |

---

## 6. DETALLE DE SUBTAREAS - FASE 4: FRONTEND

### SPRINT-FE-1: Fundamentos (17 SP)

| ID | Subtarea | SP | Depende de |
|----|----------|-----|------------|
| SUBTASK-001 | Routing y Huérfanos | 4 | NINGUNA |
| SUBTASK-002 | OQI-001 Auth Completar | 13 | ST-2.5, ST-3.3 |

### SPRINT-FE-2: Trading Core (60 SP)

| ID | Subtarea | SP | Depende de |
|----|----------|-----|------------|
| SUBTASK-003 | OQI-003 Trading | 44 | ST-3.1, ST-3.4 |
| SUBTASK-004 | OQI-006 ML | 16 | ST-3.1 |

### SPRINT-FE-3: Investment (81 SP)

| ID | Subtarea | SP | Depende de |
|----|----------|-----|------------|
| SUBTASK-005 | OQI-004 Investment | 68 | Backend investment |
| SUBTASK-006 | OQI-005 Payments | 13 | Backend payments |

### SPRINT-FE-4: Advanced Features (128 SP)

| ID | Subtarea | SP | Depende de |
|----|----------|-----|------------|
| SUBTASK-007 | OQI-002 Education | 21 | ST-1.1, ST-1.2 |
| SUBTASK-008 | OQI-007 LLM | 44 | Backend LLM |
| SUBTASK-009 | OQI-008 Portfolio | 63 | Backend portfolio |

### SPRINT-FE-5: Growth (55 SP)

| ID | Subtarea | SP | Depende de |
|----|----------|-----|------------|
| SUBTASK-010 | OQI-009 Marketplace | 42 | Docs OQI-009 |
| SUBTASK-011 | Migración Docs | 8 | NINGUNA |
| SUBTASK-012 | Inventarios Sync | 5 | NINGUNA |

---

## 7. PLAN DE EJECUCIÓN ORDENADO

### Semana 1: Preparación + DDL

| Día | Subtareas | Paralelismo | Horas |
|-----|-----------|-------------|-------|
| D1 | ST-0.1, ST-0.2, ST-0.3 | 3 parallel | 8h |
| D2 | ST-1.1, ST-1.2, ST-1.3 | 3 parallel | 8h |
| D3 | ST-1.4 | Secuencial | 2h |

**Entregables Semana 1:**
- Documentación purgada
- Inventarios sincronizados
- DDL gaps resueltos

### Semana 2-3: Backend Services

| Día | Subtareas | Paralelismo | Horas |
|-----|-----------|-------------|-------|
| D4-D5 | ST-2.1 (Market Data) | Critical path | 16h |
| D6 | ST-2.2, ST-2.3 | 2 parallel | 12h |
| D7 | ST-2.4, ST-2.5 | 2 parallel | 16h |
| D8 | ST-3.1, ST-3.2 | 2 parallel | 8h |
| D9 | ST-3.3, ST-3.4, ST-3.5 | 3 parallel | 16h |

**Entregables Semana 2-3:**
- Market Data Service completo (CHAIN-001 desbloqueado)
- Notifications completo
- User Profile completo
- 2FA completo

### Semana 4-8: Frontend Sprints

| Sprint | Duración | Subtareas | Paralelismo |
|--------|----------|-----------|-------------|
| FE-1 | 3 días | SUBTASK-001, 002 | 2 parallel |
| FE-2 | 5 días | SUBTASK-003, 004 | 2 parallel |
| FE-3 | 6 días | SUBTASK-005, 006 | 2 parallel |
| FE-4 | 10 días | SUBTASK-007-009 | 3 parallel |
| FE-5 | 4 días | SUBTASK-010-012 | 3 parallel |

### Semana 9-10: Refactor + Testing

| Día | Subtareas | Horas |
|-----|-----------|-------|
| D1-D2 | ST-5.1 (ARCH-001) | 16h |
| D3 | ST-5.2 (ARCH-002) | 8h |
| D4-D7 | ST-6.1-6.4 Tests | 40h |
| D8-D9 | ST-7.1-7.3 Docs | 16h |

---

## 8. ASIGNACIÓN DE PERFILES POR SUBTAREA

| Subtarea | Perfil Principal | Perfil Backup |
|----------|------------------|---------------|
| ST-0.* | PERFIL-ORQUESTADOR | - |
| ST-1.* | PERFIL-DATABASE-POSTGRESQL | PERFIL-DATABASE-COMPACT |
| ST-2.* | PERFIL-BACKEND-NESTJS | PERFIL-BACKEND-COMPACT |
| ST-3.* | PERFIL-BACKEND-NESTJS | - |
| SUBTASK-* | PERFIL-FRONTEND-REACT | PERFIL-GENERIC-SUBAGENT |
| ST-5.* | PERFIL-BACKEND-NESTJS | - |
| ST-6.* | PERFIL-QA-TESTER | PERFIL-BACKEND-NESTJS |
| ST-7.* | PERFIL-DOCUMENTACION | PERFIL-ORQUESTADOR |

---

## 9. CRITERIOS DE ÉXITO DEL PLAN

### Métricas Objetivo

| Métrica | Actual | Objetivo | Incremento |
|---------|--------|----------|------------|
| Coherencia Global | 81.25% | 95% | +13.75% |
| DDL-Backend | 85% | 98% | +13% |
| Backend-Frontend | 77.5% | 92% | +14.5% |
| Test Coverage | 15% | 40% | +25% |
| Gaps P0 | 3 | 0 | -3 |
| Gaps P1 | 6 | 2 | -4 |

### Hitos de Validación

| Hito | Semana | Criterio |
|------|--------|----------|
| M1 | 1 | DDL 100% sincronizado |
| M2 | 3 | CHAIN-001 desbloqueado |
| M3 | 5 | Frontend Sprint 2 completado |
| M4 | 8 | Frontend MVP completado |
| M5 | 10 | Tests 40%+ coverage |

---

## 10. PLAN DE CONTINGENCIA

### Riesgos y Mitigaciones

| Riesgo | Trigger | Mitigación |
|--------|---------|------------|
| Bloqueo en Market Data | >3 días delay | Usar mock service temporal |
| Tests lentos | >8h por suite | Paralelizar CI |
| Dependencia externa | API down | Cache agresivo |
| Scope creep | +20% SP | Congelar scope Sprint |

### Escalation Path

1. Blocker técnico → Consultar ARCH-001/002 solutions
2. Blocker de dependencia → Reordenar subtareas
3. Blocker de recurso → Solicitar subagente adicional

---

**Siguiente Fase:** E (Ejecución) - Delegación a subagentes