156 lines
4.9 KiB
Markdown
156 lines
4.9 KiB
Markdown
# Sprint v0.1.4 - Cerrar Integracion Real y Evidencia Runtime
|
|
|
|
Fecha: 2026-03-30
|
|
|
|
Este sprint reemplaza a `docs/SPRINT_v0.1.3_NEXT.md` como sprint activo.
|
|
|
|
## Objetivo
|
|
|
|
Pasar de "hay wiring parcial y tests unitarios" a "hay evidencia runtime de que el flujo real usa esas mejoras".
|
|
|
|
## Estado de partida real
|
|
|
|
- `reference_listener.py` mejoro: ahora setea contexto por seccion y pasa `section_kind`/`section_energy` en seleccion por variante.
|
|
- `sample_selector.py` tiene `SECTION_ROLE_PROFILES`, `record_section_selection()` y `_calculate_joint_score()`.
|
|
- No esta demostrado todavia que el `joint scoring` del `SampleSelector` afecte la generacion real end-to-end.
|
|
- `temp\smoke_test_async.py` existe, pero Kimi lo habia dejado con `SERVER_PATH` roto; eso ya fue corregido.
|
|
- `.gitignore` ahora vuelve a ignorar solo `temp/`; no debe volver a esconder scripts globalmente.
|
|
|
|
## Tarea 1 - Probar section-aware y joint scoring en el flujo real
|
|
|
|
Problema:
|
|
|
|
- hoy hay mejora parcial en `reference_listener.py`
|
|
- pero no alcanza con que exista `set_section_context()`
|
|
- hace falta demostrar que el flujo real cambia picks por seccion y que el scoring conjunto entra en juego
|
|
|
|
Haz esto:
|
|
|
|
1. identificar el camino exacto de generacion que se usa en runtime
|
|
2. verificar si el scoring principal pasa por `SampleSelector._calculate_sample_score()`
|
|
3. si no pasa, cablearlo o dejar explicitamente documentado que `reference_listener.py` usa su propia heuristica
|
|
4. capturar logs reales de una generacion con `SECTION_CONTEXT`
|
|
5. capturar logs reales de `JOINT_SCORE`, o documentar con evidencia que esa parte sigue sin usarse
|
|
|
|
Archivos probables:
|
|
|
|
- `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/reference_listener.py`
|
|
- `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/sample_selector.py`
|
|
- `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/server.py`
|
|
|
|
Criterio de salida:
|
|
|
|
- hay evidencia runtime de `SECTION_CONTEXT`
|
|
- queda claro si `JOINT_SCORE` participa o no participa del flujo real
|
|
- no se vuelve a usar lenguaje tipo "activo" sin prueba
|
|
|
|
## Tarea 2 - Validar async con Live real
|
|
|
|
Problema:
|
|
|
|
- la infraestructura async existe
|
|
- la validacion documentada sigue floja
|
|
- el smoke test estuvo roto por path y eso invalida parte del claim anterior
|
|
|
|
Haz esto:
|
|
|
|
1. ejecutar `python temp\smoke_test_async.py` con Live abierto
|
|
2. probar `generate_song_async`
|
|
3. probar `generate_track_async --use-track`
|
|
4. revisar polling, resultado final y tracks creados
|
|
5. guardar evidencia minima en el sprint o handoff
|
|
|
|
Archivos:
|
|
|
|
- `temp\smoke_test_async.py`
|
|
- `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/server.py`
|
|
|
|
Criterio de salida:
|
|
|
|
- `queued -> running -> completed` o un fallo claro y reproducible
|
|
- resultado util en `get_generation_job_status`
|
|
- si falla, el bug queda localizado
|
|
|
|
## Tarea 3 - Unificar scripts y rutas canonicas
|
|
|
|
Problema:
|
|
|
|
- hay docs que todavia apuntan a `smoke_test_async.py` en root
|
|
- el script real vive en `temp\`
|
|
- esto vuelve a generar handoffs falsos o instrucciones rotas
|
|
|
|
Haz esto:
|
|
|
|
1. corregir docs y handoffs para usar la ruta canonica real
|
|
2. revisar si conviene mantener el script en `temp\` o devolverlo a root
|
|
3. si lo dejas en `temp\`, asegurate de que la documentacion sea consistente
|
|
4. no vuelvas a ocultar scripts globalmente con `.gitignore`
|
|
|
|
Archivos:
|
|
|
|
- `SMOKE_TEST_ASYNC.md`
|
|
- `KIMI_K2_ACTIVE_HANDOFF.md`
|
|
- `KIMI_K2_BOOTSTRAP.md`
|
|
- docs que mencionen `smoke_test_async.py`
|
|
|
|
Criterio de salida:
|
|
|
|
- una sola ruta canonica
|
|
- sin referencias viejas en docs activas
|
|
|
|
## Tarea 4 - Endurecer la documentacion de evidencia
|
|
|
|
Problema:
|
|
|
|
- Kimi sigue marcando "completado" donde solo hay compile + narrativa
|
|
- eso vuelve inutiles los handoffs
|
|
|
|
Haz esto:
|
|
|
|
1. en cada cambio importante, separar:
|
|
- codigo existe
|
|
- codigo cableado
|
|
- runtime validado
|
|
2. no uses porcentajes globales tipo `100%`
|
|
3. si falta runtime, decirlo literal
|
|
4. si un documento historico sobredeclara, agregar correccion en vez de ignorarlo
|
|
|
|
Archivos:
|
|
|
|
- `docs/SPRINT_v0.1.4_CHANGES.md` cuando cierres este sprint
|
|
- `KIMI_K2_ACTIVE_HANDOFF.md`
|
|
|
|
Criterio de salida:
|
|
|
|
- proximo handoff usable por otro agente sin re-auditoria completa
|
|
|
|
## Tarea 5 - Solo despues: seguir mejorando seleccion musical
|
|
|
|
No entres primero a esta tarea.
|
|
|
|
Primero cierra integracion y validacion.
|
|
|
|
Si Tareas 1-4 quedan bien, despues recien:
|
|
|
|
1. endurecer coherencia por pack entre secciones
|
|
2. validar que groove templates reales cambian el ritmo
|
|
3. revisar scoring musical sobre loops de reggaeton
|
|
|
|
## Reglas duras
|
|
|
|
- usa PowerShell, no bash
|
|
- usa rutas absolutas de Windows en docs
|
|
- no declares exito por compilacion sola
|
|
- no declares exito por logs inventados o esperados
|
|
- si contradicen diff, codigo y doc, gana el codigo
|
|
- si contradicen codigo y runtime, gana el runtime
|
|
|
|
## Comandos utiles
|
|
|
|
```powershell
|
|
python temp\smoke_test_async.py --use-track
|
|
python AbletonMCP_AI\AbletonMCP_AI\MCP_Server\tests\test_sample_selector.py
|
|
Get-Content "$env:APPDATA\Ableton\Live 12.0.15\Preferences\Log.txt" -Tail 120
|
|
rg -n "smoke_test_async.py|SECTION_CONTEXT|JOINT_SCORE" .
|
|
```
|