Workspaces

La carpeta de workspace es el límite de delivery

El CLI de Looky resuelve contexto a partir de tu directorio actual. Directorio equivocado significa identidad de workspace equivocada, contexto de billing equivocado, y resultados de push poco confiables.

Estructura de directorios requerida

<local_root>/
  <billing_account_id>/
    <workspace_slug>/
      workspace.yml
      content/
        models/
        visualizations/
        dashboards/
        exports/
      runtime/
        sources.runtime.yml
      secrets/

workspace.yml

El manifest en el root del workspace. id debe ser igual al slug de la carpeta; name es el nombre para mostrar. El bloque opcional ui define los defaults de locale y timezone para todos los que ven el workspace:

id: ecommerce-showcase
name: Ecommerce Showcase
description: Showcase for the Ecommerce dataset.
ui:
  default_locale: en
  supported_locales: [en, es]

Con timezone (lo usan los filtros de fecha y los exports programados):

id: operations
name: Operations
description: Sales and operations analytics.
ui:
  timezone: America/New_York
  default_locale: en
  supported_locales: [en, es]

Esas son las únicas keys: id (requerida), name, description, y ui.default_locale / ui.supported_locales / ui.timezone. Cualquier otra cosa falla la validación. workspace.yml viaja con el push de contenido default, junto con content/**.

Cómo verificar el contexto del workspace rápido

Ve al root del workspace:

cd <local_root>/<billing_account_id>/<workspace_slug>

Corre:
```
looky status
looky validate
```
Confirma que el workspace id sea <billing_account_id>/<workspace_slug>.
Abre workspace.yml y confirma que el id matchea el slug de la carpeta.

Borrar un workspace

Corre looky delete <workspace_slug> desde <local_root>/<billing_account_id>. El CLI te pide tipear el slug como confirmación; pasa --yes para saltear el prompt en automatización.

Quién puede borrar:

Los owners del billing account pueden borrar cualquier workspace bajo su billing account.
super_admin solo puede borrar workspaces que él mismo creó.
Los developers del billing account no pueden borrar workspaces — ni siquiera los que ellos crearon. Borrar es decisión del billing owner.

Qué se borra en el servidor, atómicamente:

El directorio del workspace bajo workspaces_root/<billing>/<slug>/ (workspace.yml, content, runtime, secrets, caches de runtime).
Cualquier staging de validate en vuelo o zombie bajo workspaces_root/.validation-staging/<billing>/<slug>/.
Las filas en auth_workspace_owners, auth_workspace_memberships, auth_invitation_workspace_grants, catalog_items, ui_user_folders y ui_user_folder_items.

Qué se queda:

Tu copia local bajo <local_root>/<billing_account_id>/<workspace_slug>/. El CLI la deja como está y te imprime un hint con rm -rf para que tú decidas cuándo eliminarla.
Las invitaciones pendientes que daban acceso al workspace borrado siguen siendo válidas para los otros workspaces que otorguen — solo se borra la fila del grant para este workspace.

No hay soft-delete ni undo. Recrear el workspace requiere looky create seguido de un nuevo looky push.

Qué se rompe cuando la estructura está mal

looky validate puede fallar al resolver el workspace local.
looky push puede apuntar al workspace id equivocado.
looky list dashboards puede mostrar resultados de un workspace inesperado.

Tres niveles de directorio, enforced por el CLI. Los comandos que crean o borran un workspace corren un nivel arriba de la carpeta del workspace, porque la carpeta no existe todavía (create, pull) o está por desaparecer (delete).

Desde <local_root> exacto — looky billing list/use, looky workspaces. Correrlos en un subdirectorio se rechaza.
Desde <local_root>/<billing_account_id> — looky create, looky pull, looky delete.
Desde cualquier subdirectorio bajo <local_root>/<billing_account_id>/<workspace_slug> — todo el resto (status, validate, diff, push, list, sources). El CLI sube por el path para inferir el root del workspace, así que content/models/ también funciona.