rckrdmrd
c1b5081208
ML Engine Updates: - Updated BTCUSD with Polygon API data (2024-2025): 215,699 new records - Re-trained all ML models: Attention (R²: 0.223), Base, Metamodel (87.3% confidence) - Backtest results: +176.71R profit with aggressive_filter strategy Documentation Consolidation: - Created docs/99-analisis/_MAP.md index with 13 new analysis documents - Consolidated inventories: removed duplicates from orchestration/inventarios/ - Updated ML_INVENTORY.yml with BTCUSD metrics and training results - Added execution reports: FASE11-BTCUSD, correction issues, alignment validation Architecture & Integration: - Updated all module documentation with NEXUS v3.4 frontmatter - Fixed _MAP.md indexes across all folders - Updated orchestration plans and traces Files: 229 changed, 5064 insertions(+), 1872 deletions(-) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
3.0 KiB
3.0 KiB
| id | title | type | project | version | updated_date |
|---|---|---|---|---|---|
| DEFINITION-OF-READY | Definition of Ready (DoR) - Trading Platform (Trading Platform) | Documentation | trading-platform | 1.0.0 | 2026-01-04 |
Definition of Ready (DoR) - Trading Platform (Trading Platform)
Proyecto: Trading Platform - Plataforma de Trading con IA Ultima actualizacion: 2026-01-04
Proposito
El Definition of Ready (DoR) define los criterios que un item del backlog debe cumplir antes de que pueda ser trabajado en un Sprint.
Criterios Generales
Un item del backlog esta "Ready" cuando:
1. Claridad
- El titulo es claro y descriptivo
- La descripcion del problema/necesidad esta documentada
- Los criterios de aceptacion estan definidos
- No hay ambiguedades en los requisitos
2. Alcance
- El scope esta claramente delimitado
- Las dependencias estan identificadas
- Los items bloqueantes estan resueltos
- El item es lo suficientemente pequeno para un Sprint
3. Estimacion
- El equipo ha estimado story points
- La complejidad tecnica esta evaluada
- Los riesgos estan identificados
4. Documentacion
- Existe RF (Requerimiento Funcional) asociado
- Existe ET (Especificacion Tecnica) si aplica
- Los mockups/wireframes estan disponibles (si aplica)
Checklist por Tipo de Item
User Story
- Formato "Como [rol], quiero [funcionalidad], para [beneficio]"
- Criterios de aceptacion en formato Given-When-Then o checklist
- RF relacionado identificado
- Story points estimados
- Sin bloqueos activos
Bug Fix
- Pasos para reproducir documentados
- Comportamiento esperado vs actual documentado
- Severidad/Prioridad asignada
- Ambiente donde se reproduce identificado
Technical Task
- Objetivo tecnico claro
- Impacto en el sistema documentado
- Criterios de completitud definidos
- Rollback plan si aplica
Criterios de Prioridad
| Prioridad | Descripcion |
|---|---|
| P0 - Critical | Bloqueante para produccion, seguridad |
| P1 - High | Funcionalidad core, deadline cercano |
| P2 - Medium | Mejoras importantes, puede esperar |
| P3 - Low | Nice-to-have, mejoras menores |
Criterios Especificos por Modulo
Autenticacion (OQI-001)
- Flujos de OAuth documentados con proveedores
- Requisitos de seguridad especificados
- Tokens y sesiones definidos
Trading (OQI-003)
- Fuentes de datos de mercado identificadas
- Indicadores tecnicos especificados
- Latencia aceptable definida
ML Signals (OQI-006)
- Datos de entrenamiento disponibles
- Metricas de accuracy definidas
- Pipeline de inferencia especificado
Notas
- Items que no cumplan DoR no entran al Sprint
- El PO es responsable de asegurar que el backlog este "Ready"
- El equipo puede rechazar items que no cumplan DoR en Planning
Basado en: Estandar SCRUM + SIMCO (Sistema Indexado Modular por Contexto)