Síntoma
Al recibir el update v1.4.3 → v1.5.0, el diálogo del auto-updater muestra "No release notes provided." en el cuerpo (observado en macOS; captura del 2026-08-17). El update funciona, pero el usuario no ve qué trae la versión.
Causa probable
release.yml pasa releaseBody: '' a tauri-action, y el campo notes de latest.json se llena desde ahí → queda vacío. Las notas reales del release sí existen (el job create-release usa gh release create --generate-notes), pero nunca llegan al manifest del updater.
Fix propuesto
En el job aggregate-updater-json (script scripts/aggregate-updater-json.js), al reconstruir/validar latest.json, poblar notes desde el body del release de GitHub (gh api /repos/.../releases/tags/<tag> → .body), con truncado razonable (el diálogo es pequeño; p. ej. primeras N líneas o un resumen "Highlights"). Alternativa: mantener un bloque de highlights curado en el release body y copiar solo esa sección.
Criterios de aceptación
Síntoma
Al recibir el update v1.4.3 → v1.5.0, el diálogo del auto-updater muestra "No release notes provided." en el cuerpo (observado en macOS; captura del 2026-08-17). El update funciona, pero el usuario no ve qué trae la versión.
Causa probable
release.ymlpasareleaseBody: ''atauri-action, y el camponotesdelatest.jsonse llena desde ahí → queda vacío. Las notas reales del release sí existen (el jobcreate-releaseusagh release create --generate-notes), pero nunca llegan al manifest del updater.Fix propuesto
En el job
aggregate-updater-json(scriptscripts/aggregate-updater-json.js), al reconstruir/validarlatest.json, poblarnotesdesde el body del release de GitHub (gh api /repos/.../releases/tags/<tag> → .body), con truncado razonable (el diálogo es pequeño; p. ej. primeras N líneas o un resumen "Highlights"). Alternativa: mantener un bloque de highlights curado en el release body y copiar solo esa sección.Criterios de aceptación
latest.json.notesno vacío).