Sync: Complete project state with all MEGA SPRINT V1-V3 features and Codex stubs
This commit is contained in:
renato97
142
docs/SPRINT_v0.1.5_NEXT.md
Normal file
142
docs/SPRINT_v0.1.5_NEXT.md
Normal file
@@ -0,0 +1,142 @@
|
||||
# Sprint v0.1.5 - Cerrar Async Real y Probar Section-Aware de Punta a Punta
|
||||
|
||||
Fecha: 2026-03-30
|
||||
|
||||
Este sprint reemplaza a `docs/SPRINT_v0.1.4_NEXT.md` como sprint activo.
|
||||
|
||||
## Estado de partida real
|
||||
|
||||
- `temp\smoke_test_async.py` ya no falla por parsing ni por shape incorrecto de `get_tracks`
|
||||
- evidencia actual en `temp\smoke_test_async_report.json`:
|
||||
- `connection_check`: PASS
|
||||
- `launch_async_job`: PASS
|
||||
- `verify_tracks_created`: PASS
|
||||
- `poll_job_status`: FAIL por timeout a 300s
|
||||
- durante ese timeout la cantidad de tracks subio de `122` a `165`, asi que el job estaba haciendo trabajo real
|
||||
- `reference_listener.py` sigue usando logica hardcoded en `_select_candidate()` y no hay evidencia runtime de `JOINT_SCORE`
|
||||
|
||||
## Objetivo
|
||||
|
||||
Pasar de "hay trabajo real ocurriendo pero sin cierre observable" a "el sistema async y el section-aware tienen evidencia end-to-end o un bug localizado con precision".
|
||||
|
||||
## Tarea 1 - Instrumentar el job async de verdad
|
||||
|
||||
Problema:
|
||||
|
||||
- el smoke test ya no esta roto en lo basico
|
||||
- ahora el problema real es que el job no completa dentro del timeout de 300s
|
||||
- hoy no hay suficiente visibilidad de en que etapa exacta se queda
|
||||
|
||||
Haz esto:
|
||||
|
||||
1. agregar mas `stage` updates en el flujo async real
|
||||
2. guardar `last_progress_at` o `last_command` en `_generation_jobs`
|
||||
3. si el job sigue vivo, el polling debe mostrar progreso util
|
||||
4. si el job queda colgado, debe quedar claro en que etapa exacta
|
||||
|
||||
Archivos:
|
||||
|
||||
- `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/server.py`
|
||||
- `temp\smoke_test_async.py`
|
||||
|
||||
Criterio de salida:
|
||||
|
||||
- `get_generation_job_status` devuelve informacion util mientras corre
|
||||
- el reporte final incluye `last_status`, `last_stage` y evidencia de progreso real
|
||||
|
||||
## Tarea 2 - Determinar si el timeout es lentitud o cuelgue
|
||||
|
||||
Problema:
|
||||
|
||||
- hoy sabemos que el job crea tracks, pero no si termina tarde o si se queda en loop
|
||||
- el proceso del smoke test puede seguir vivo despues del timeout porque el worker sigue corriendo
|
||||
|
||||
Haz esto:
|
||||
|
||||
1. correr `python temp\smoke_test_async.py --use-track --genre reggaeton --bpm 95`
|
||||
2. medir cuanto tarda hasta completarse de verdad
|
||||
3. si tarda mas de 300s pero completa, documentarlo y ajustar timeout/reporting
|
||||
4. si no completa, localizar el bucle o cuello de botella
|
||||
|
||||
Pistas actuales:
|
||||
|
||||
- logs muestran muchos `get_track_routing`
|
||||
- logs muestran `ZAIJudges` con `429` y backoff
|
||||
- logs muestran creacion sostenida de tracks y devices
|
||||
|
||||
Criterio de salida:
|
||||
|
||||
- queda claro si el problema es performance, bloqueo o falta de cierre de estado
|
||||
|
||||
## Tarea 3 - Probar o cablear section-aware de verdad
|
||||
|
||||
Problema:
|
||||
|
||||
- `reference_listener.py` setea contexto por seccion
|
||||
- pero `_select_candidate()` sigue usando logica hardcoded
|
||||
- no hay evidencia runtime de `SECTION_CONTEXT` ni `JOINT_SCORE` en generacion real
|
||||
|
||||
Haz esto:
|
||||
|
||||
1. capturar logs reales de una generacion con `SECTION_CONTEXT`
|
||||
2. demostrar si `JOINT_SCORE` entra o no entra
|
||||
3. si no entra, cablear la seleccion real al `SampleSelector` o documentar explicitamente que sigue desacoplada
|
||||
|
||||
Archivos:
|
||||
|
||||
- `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/reference_listener.py`
|
||||
- `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/sample_selector.py`
|
||||
|
||||
Criterio de salida:
|
||||
|
||||
- hay evidencia runtime o fix real, no solo narrativa
|
||||
|
||||
## Tarea 4 - Reducir latencia inutil en la ruta de generacion
|
||||
|
||||
Problema:
|
||||
|
||||
- los `429` de `ZAIJudges` y ciertos loops de consultas a Live pueden inflar la duracion del job
|
||||
|
||||
Haz esto:
|
||||
|
||||
1. medir cuanto aportan los retries de Z.ai al tiempo total
|
||||
2. revisar si `get_track_routing` o consultas similares estan ocurriendo demasiado
|
||||
3. si hace falta, agregar modo smoke-test con judges desactivados o mas agresivamente cacheados
|
||||
|
||||
Archivos:
|
||||
|
||||
- `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/zai_judges.py`
|
||||
- `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/server.py`
|
||||
|
||||
Criterio de salida:
|
||||
|
||||
- una corrida de smoke test tiene tiempo explicable y acotado
|
||||
|
||||
## Tarea 5 - Solo despues seguir con mejoras musicales
|
||||
|
||||
No entres primero aca.
|
||||
|
||||
Primero cierra Tareas 1-4.
|
||||
|
||||
Recien despues:
|
||||
|
||||
1. mejorar coherencia musical por seccion
|
||||
2. hacer que groove extraction afecte el ritmo real
|
||||
3. seguir afinando reggaeton selection
|
||||
|
||||
## Reglas duras
|
||||
|
||||
- usa PowerShell, no bash
|
||||
- usa rutas absolutas de Windows en docs
|
||||
- no declares exito por compilacion sola
|
||||
- no inventes root causes si no estan respaldados por codigo o runtime
|
||||
- si el smoke test cambia de fallo, actualiza el handoff activo
|
||||
|
||||
## Comandos utiles
|
||||
|
||||
```powershell
|
||||
python temp\smoke_test_async.py --use-track --genre reggaeton --bpm 95
|
||||
Get-Content temp\smoke_test_async_report.json
|
||||
Get-Content "$env:APPDATA\Ableton\Live 12.0.15\Preferences\Log.txt" -Tail 200
|
||||
rg -n "_generation_jobs|last_progress_at|stage|get_track_routing" AbletonMCP_AI\AbletonMCP_AI\MCP_Server\server.py
|
||||
```
|
||||
Reference in New Issue
Block a user