Lo que se rompió.
Lo que costó. Lo que cambié.

Qué pasó

La API key de Google Cloud (Gemini, Maps, etc.) estaba en .env.local como VITE_GOOGLE_API_KEY. Lo que yo no sabía: Vite embebe TODAS las variables con prefijo VITE_ en el JavaScript público. La key terminó en el bundle compilado de mapadecaborojo.com, accesible a cualquier bot que mire el source.

Bots la encontraron y la usaron pa’ llamadas no-autorizadas al API de Gemini. $1,869.68 en cobros vs los $6.80/mes que normalmente gasto. Mastercard rechazó el cargo de $1,000 (threshold) — balance pendiente $1,369.68. Google Cloud suspendió el proyecto VeciAI automáticamente por «hijacked resources.»

Por qué falló (root cause)

La key tenía 45 APIs habilitadas con cero restricciones. Sin HTTP referrer restriction, sin IP whitelist, sin límites por API, sin budget alerts. Una sola key haciendo todo. Una sola pérdida de control = factura de $1,869.

El error mental era «esta key es solo pa’ testing local» — pero al desplegar Vite a Vercel, el bundle público heredó la variable. El framework hizo lo que dijo que iba a hacer; yo no leí la documentación.

Qué cambió permanente

• Regla nueva en mi CLAUDE.md (gate pre-deploy): ningún server-key con prefijo VITE_, NEXT_PUBLIC_, ni REACT_APP_. Si la key cobra por uso, no puede tener prefijo público. Punto.
• Keys separadas por uso: una pa’ frontend (Maps JS solo, restringida por HTTP referrer a *.mapadecaborojo.com/*), otra pa’ server (restringida por IP).
• Budget alert obligatorio antes de habilitar cualquier API que cobre por uso. $25/mes alert, daily quotas por API.
• Checklist pre-deploy: grep AIzaSy en el dist/ después de cada build. Cero matches = safe. Si aparece, la key está expuesta.

La lección de fondo

El stack ya no perdona la ignorancia documentada. Antes podías «moverte rápido y romper cosas» — hoy un bot extrae tu key del bundle en 30 segundos. Leer la documentación de tu framework no es opcional. Especialmente la parte que dice «qué se queda en el cliente.»

Qué pasó

Cuando Google detectó el patrón de fraude del Error #001, no me llamó. No me mandó email pa’ avisar. Suspendió el proyecto entero — VeciAI — automáticamente. Eso significaba: cero acceso a la consola, cero acceso a las keys, cero forma de cortar el sangrado yo mismo. Solo un botón de «appeal» en el dashboard.

VeciAI era el proyecto que albergaba claves para el bot *7711 (la cara pública del directorio CaboRojo.com). Si el bot dependía 100% de esas keys, el bot se hubiera caído junto con el proyecto. Por suerte el bot ya estaba mayormente sobre Supabase Edge Functions, no sobre Google Cloud.

Qué cambió permanente

• No depender de un solo proveedor pa’ infraestructura crítica. El bot *7711 ya no toca Google Cloud — vive completo en Supabase + Twilio. Single point of failure eliminado.
• Servicios con auto-suspension van en proyectos no-críticos. Si Google Cloud puede suspenderte sin aviso, no metas ahí lo que tu negocio principal necesita pa’ funcionar.
• Manual review > auto-suspension cuando se elige hosting. Vercel, Supabase, Netlify — todos tienen review humano antes de cortar. Eso es preferible aunque cueste un poco más.

La lección de fondo

Operar solo significa que cuando algo se rompe, no hay equipo que te cubra. La infraestructura tiene que estar diseñada pa’ que un solo problema NO pueda apagar el negocio. Redundancia no es lujo de empresas grandes — es supervivencia básica del operador solo.