Plantillas reproducibles

La configuración de un caso (Ontología + Actions + DataSources) se puede expresar como un template JSON versionado y cargarla llamando las callables reales. Así la config de un cliente deja de ser “clicks irrepetibles en la UI” y pasa a ser un artefacto en git, reproducible y revisable.

El formato del template

{
  "meta": { "name": "Operaciones de Soporte", "version": 1 },
  "ontologyTypes": [ /* en orden de dependencia */ ],
  "actionTypes":   [ /* … */ ],
  "dataSources":   [ /* … */ ]
}

El de referencia vive en scripts/pilot/reference-pilot.json y es la mejor plantilla para empezar: copialo, cambiá tipos/acciones/fuentes por los del cliente.

El loader

scripts/pilot/load-config.mjs lee el template, firma como el admin de la org e invoca createOntologyType / createActionType / createDataSource en orden. Es idempotente: lo que ya existe se saltea, así re-correrlo tras editar el template solo agrega lo nuevo.

# Emulador (default)
node scripts/pilot/load-config.mjs
 
# Producción (apuntás los hosts a lo real, firmás como el admin del cliente)
AUTH_BASE="https://identitytoolkit.googleapis.com/v1" \
FUNCTIONS_BASE="https://us-central1-dawoork-mentat.cloudfunctions.net" \
SEED_API_KEY="<web-api-key>" \
SEED_EMAIL="admin@cliente.com" SEED_PASSWORD="..." \
SEED_ORG_ID="cliente" \
TEMPLATE="scripts/pilot/<caso>.json" \
  node scripts/pilot/load-config.mjs --confirm-prod

Por qué pasar por las callables (y no escribir Firestore directo)

Cargar por las callables ejerce el mismo backend que la UI: validación de schema, integridad cross-type, optimistic locking y audit trail. Un seed directo a Firestore saltearía todo eso y podría dejar datos inconsistentes. La regla del proyecto: cero writes directos del cliente.

Smoke test

Tras cargar, podés validar el caso con un smoke (crear objetos + ejecutar una Action

• verificar):

node scripts/pilot/prod-smoke.mjs    # con las env vars de la org apuntando a prod