# 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`