ableton-mcp-ai/docs/SPRINT_v0.1.5_CHANGES.md

Sprint v0.1.5 - Revision de Codex

Fecha: 2026-03-30

Este documento reemplaza la version anterior de SPRINT_v0.1.5_CHANGES.md, que mezclaba avances reales con conclusiones demasiado fuertes.

Resumen honesto

Kimi si dejo trabajo util en este sprint, pero no quedo cerrado como el documento original sugeria.

Lo que si existe en codigo:

• server.py ahora guarda mas estado en _generation_jobs
• server.py tiene cache de routing y se usa en al menos 3 callsites reales
• zai_judges.py redujo backoff y aumento TTL de cache
• reference_listener.py sigue mostrando que el section-aware esta solo parcialmente integrado

Lo que no quedo demostrado:

• que el timeout async ya este resuelto
• que el timeout sea definitivamente O(n^2) por routing y nada mas
• que JOINT_SCORE participe de la generacion real end-to-end
• que las ultimas generaciones sean musicalmente coherentes

Lo que Codex verifico

Codigo

• server.py compila
• reference_listener.py compila
• zai_judges.py compila
• temp\smoke_test_async.py compila
• test_sample_selector.py sigue pasando 25/25

Evidencia runtime disponible

Archivo revisado:

• temp\smoke_test_async_report.json

Estado real del ultimo reporte disponible:

• connection_check: PASS
• launch_async_job: PASS
• verify_tracks_created: PASS
• poll_job_status: FAIL por timeout a 300s

Dato importante:

• durante ese timeout la cuenta de tracks subio de 122 a 165

Eso demuestra que el job estaba haciendo trabajo real. No demuestra por si solo cual es el root cause exacto del timeout.

Correccion del diagnostico async

La version anterior del documento afirmaba demasiado:

• que el timeout ya estaba diagnosticado con precision completa
• que el problema era definitivamente O(n^2) por routing
• que las optimizaciones aplicadas deberian dejar el job por debajo de 300s

Eso hoy no esta probado.

Lo correcto es:

• el routing repetido es un candidato fuerte a cuello de botella
• los retries de ZAIJudges tambien pueden estar inflando la duracion
• el sistema async sigue necesitando mejor instrumentacion para mostrar progreso real mientras corre

Correccion del diagnostico section-aware

La observacion importante de Kimi fue buena:

• reference_listener.py selecciona roles principales antes del loop de secciones
• en esa seleccion global no se pasa contexto por seccion
• _select_candidate() sigue usando logica local hardcoded

Pero el fix sugerido en el documento original no es correcto tal como estaba escrito.

No sirve simplemente pasar current_kind o current_energy en la linea donde se seleccionan roles principales, porque esa seleccion ocurre antes del loop de secciones y no existe una seccion actual unica en ese punto.

La conclusion correcta es:

• el flujo necesita rediseño, no solo un parametro extra
• si queremos section-aware real, hay que:
  • mover mas seleccion dentro del loop de secciones
  • o derivar las variantes de seccion desde un palette global coherente
  • o ambas

Problema de producto mas importante

El problema principal ya no es solo tecnico.

Segun las ultimas pruebas del usuario:

• el sistema genera pistas
• pero el resultado suena como sonidos tirados al azar
• falta coherencia melodica, armonica y de arreglo

Eso cambia la prioridad del proyecto.

La siguiente etapa no debe enfocarse solo en "que termine" o "que cree tracks". Debe enfocarse en:

• coherencia por pack
• coherencia tonal
• coherencia de hook/motivo
• presupuesto de tracks
• mutacion por seccion a partir de un mismo tema

Estado real al cerrar esta revision

• avances utiles: SI
• sprint 0.1.5 totalmente cerrado: NO
• siguiente prioridad: coherencia musical real

Archivos relevantes

• AbletonMCP_AI/AbletonMCP_AI/MCP_Server/server.py
• AbletonMCP_AI/AbletonMCP_AI/MCP_Server/reference_listener.py
• AbletonMCP_AI/AbletonMCP_AI/MCP_Server/zai_judges.py
• temp\smoke_test_async.py
• temp\smoke_test_async_report.json

Siguiente sprint

El sprint activo a partir de ahora es:

• docs/SPRINT_v0.1.6_NEXT.md