2026-09-13 — Turismo: Places (New) + Places Aggregate + BigQuery

Qué se decidió y veredicto final

1. Lo que importa ya funciona. La key estándar de la org responde a places.googleapis.com/v1/places:searchText con rating, userRatingCount y reviews reales en español. El conector googleplaces.ts tiene la señal de sobreprecio que CF.md necesita. La llave anterior era “account-bound” y Places la rechazaba (“Expected OAuth2”); se sustituyó por key estándar.

2. BigQuery es sumidero opcional, no columna. CF.md (Cloudflare MCP) corre sobre Workers + KV + DuckDB + Airflow; no usa BigQuery. La app ya lo soporta como sink opcional por env vars. Se creó el dataset estado_turismo y la tabla observaciones en yt-extract-505518 por completitud, pero no es requisito del retrieval.

3. ADC local owner, sin llave SA. La org bloquea creación de llaves de cuenta de servicio (iam.disableServiceAccountKeyCreation, enforced). Para desarrollo local/usar BQ hoy: GOOGLE_APPLICATION_CREDENTIALS vacío → usa ADC (owner del proyecto). Para el servidor (Vercel/Workers) se resolverá con Workload Identity Federation cuando se decida; la política de la org lo impide por ahora.

4. Places Aggregate API — endpoint correcto es areainsights.googleapis.com (endpoint https://areainsights.googleapis.com/v1:computeInsights), NO placesaggregate.googleapis.com. Habilita “Places Aggregate API”; conteos por estrato (precio nivel / rating / tipo / operating status) sin abrir lugar por lugar. Complementa el conteo manual de competencia por estrato.

Acciones realizadas

• yt-extract-505518: dataset estado_turismo, tabla observaciones (destino, periodo, metrica, valor, fuente, modo, n, capturado) creados vía bq mk.
• Verificación con curl: key estándar devuelve rating+reseñas. ✅
• .env ajustado: BQ_DATASET=estado_turismo, ADC local.
• Política de la org dejada como estaba (no se relajó; solo hereda).

Reconciliación con OSS.md (2026-09-13)

OSS.md (512 líneas) refuerza CF.md: stack target es open-source-first, soberanía de datos: DuckDB + Parquet + PostgreSQL + Apache Airflow + Iceberg, todo embebido/on-prem. Lista explícitamente en “Qué NO usar”:

❌ BigQuery (cloud-only, soberanía de datos)

Conclusión: BigQuery NO es la arquitectura target. El dataset/tabla estado_turismo crean un sumidero opcional (env-gated) para la entrega académica/prototipo y para correr el prototipo con Places (New) reviews reales. En producción el almacén principal es DuckDB, igual que en CF.md. No hay conflicto entre lo aprendido y el plan OSS.md; solo aclarar el rol del sink para no parecer lock-in cloud en la evaluación.

Pendiente (futuro)

• Deploy server: WIF en lugar de llave SA (org lo exige).
• CF.md menciona “lugares bajo el capó” que ya no scrapea: actualizar a Places (New) + includedType si se retoma ese doc.