El único orden de workflow que escala
Looky es determinístico cuando construís en este orden. Si invertís los pasos, te quedan fallas ambiguas y delivery lenta.
- La estructura y el contexto del workspace están correctos.
- Los aliases de runtime sources están definidos y son válidos.
- Los models Malloy exponen contratos de query estables e idiomáticos (capa semántica, named views — no SQL ad-hoc esparcido por todo el viz YAML).
- Las visualizations mapean campos de query a renderers.
- Los dashboards componen visualizations validadas.
- Validate, diff, push, y verificar en la UI.
La cadena canónica dentro de un workspace
Cada workspace de Looky son las mismas cuatro capas, en este orden de dependencia — leé los archivos de tu workspace en este orden cada vez que necesites debuggear o extender:
runtime/sources.runtime.ymldeclara aliases de source (ej.: un aliasecommerceapuntando a un dataset de BigQuery, o a un connection string de Postgres / MySQL).content/models/*.malloydefine dimensions, measures y queries con nombre reutilizables sobre esos aliases de source.content/visualizations/*.ymlconecta una query de model con un renderer de chart/table.content/dashboards/*.ymlcompone visualizations en las superficies finales que ve la audiencia.
Cada capa referencia solo la de arriba. Si una capa falla la validación, arreglala antes de tocar nada debajo — las capas debajo no pueden recuperarse solas.
Loop de builder que tenés que correr todos los días
cd <local_root>/<billing_account_id>/<workspace_slug>
looky status
looky validate
looky diff
looky push
looky list visualizations
looky list dashboards
Corré este loop por cada cambio significativo. Atrapa issues estructurales antes de que los usuarios vean dashboards rotos.
Definition of done para un cambio de contenido
looky validateno tiene errores bloqueantes.looky diffsolo muestra archivos intencionados.looky pushtiene éxito en el workspace target.- El dashboard es visible y renderiza correcto en
https://my.looky.studio.