trading-platform/docs/04-fase-backlog/DEFINITION-OF-READY.md
Adrian Flores Cortes 8f0235c096 [TASK-2026-02-06-ANALISIS-INTEGRAL-DOCUMENTACION] docs: Complete 6-phase documentation analysis
- 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>
2026-02-06 10:57:03 -06:00

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)