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:

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:

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