- FASE-0: Diagnostic audit of 500+ files, 33 findings cataloged (7P0/8P1/12P2/6P3) - FASE-1: Resolved 7 P0 critical conflicts (ports, paths, dedup OQI-010/ADR-002, orphan schemas) - FASE-2: Resolved 8 P1 issues (traces, README/CLAUDE.md, DEPENDENCY-GRAPH v2.0, DDL drift, stack versions, DoR/DoD) - FASE-3: Resolved 12 P2 issues (archived tasks indexed, RNFs created, OQI-010 US/RF/ET, AGENTS v2.0) - FASE-4: Purged 3 obsolete docs to _archive/, fixed MODELO-NEGOCIO.md broken ref - FASE-5: Cross-layer validation (DDL→OQI 66%, OQI→BE 72%, BE→FE 78%, Inventories 95%) - FASE-6: INFORME-FINAL, SA-INDEX (18 subagents), METADATA COMPLETED 27/33 findings resolved (82%), 6 P3 deferred to backlog. 18 new files created, 40+ modified, 4 archived. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
3.7 KiB
3.7 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-02-06 |
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
LLM Strategy Agent (OQI-007)
- LLM API documentada (Claude/GPT endpoints, auth, rate limits)
- Schema de conversaciones definido (messages, tool_calls, tokens)
- Definiciones de tools completas (get_signal, analyze_chart, execute_trade)
- Prompt templates listos y revisados
Portfolio Manager (OQI-008)
- Schema de portfolio definido (allocations, goals, snapshots)
- Algoritmos de allocation documentados (risk-based, target-based)
- Modelo de riesgo especificado (risk profiles, drift thresholds)
Marketplace (OQI-009)
- Schema de catalogo de productos definido (products, pricing, subscriptions)
- Integracion Stripe documentada (checkout, webhooks, refunds)
- Modelo de precios aprobado (planes, comisiones, advisory fees)
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)