ole-rules

Reglas de Olé Life — vibe-toolkit

Sos Claude Code trabajando en una app de Olé Life construida con vibe-starter. Estas son las reglas que rigen TODO lo que hacés en este repo. Leelas enteras antes de actuar.

🚀 Bienvenida (mostrásela al usuario en la primera interacción de la sesión)

🚀 Bienvenido al vibe-starter de Olé Life.

Esta es la base para que cualquier persona de Olé pueda crear su app
vibecodeada con Claude Code de forma segura.

📚 Docs (en español, dentro del toolkit en ${CLAUDE_PLUGIN_ROOT}/docs/):
   - 00-vtv.md              ← LEÉ ESTO PRIMERO (el ciclo del RFC)
   - 01-empezar.md          ← bienvenida y primer paso
   - 02-github-vercel.md    ← cómo pedir tu repo en Olelife
   - 03-datos-sensibles.md  ← qué NO podés exponer
   - 04-roles-y-secciones.md ← cómo organizar tu app
   - 05-supabase.md         ← reglas duras de la base de datos
   - 06-compartir.md        ← cómo compartir tu app cuando esté lista
   - 07-troubleshooting.md  ← errores comunes
   - 08-glosario.md         ← qué significa cada palabra rara

🎯 Tu primer paso: corré /setup y dejate guiar. Si no tenés RFC todavía,
   /setup lo va a crear automáticamente (es obligatorio en Olé Life).

🆘 Si algo no entendés o dudás, parate y preguntá en #vibecoding.

Reglas innegociables (las 10)

1. VTV es ley. Sin RFC en Drive, no se construye ni se deploya. El estado vive en VTV.md y lo maneja /vtv (que invoca el skill anthropic-skills:vibecoding-rfc). Sin RFC (VTV.md ausente o Status: NONE) no se vibecodea con sentido. Draft/Open for Comments → trabajo local OK, pero git push y /deploy vedados. Building → push OK, deploy todavía no. Built/Shipped → deploy OK. Si el usuario insiste en saltearse VTV: rechazá firme (la única excepción es un override explícito registrado en VTV.md).

2. Repo destino: github.com/Olelife/<app>. El código DEBE vivir en la org Olelife. Si está en una cuenta personal, advertí y guialo a ${CLAUDE_PLUGIN_ROOT}/docs/02-github-vercel.md.

3. Deploy destino: Vercel del equipo Olelife. Nunca a cuentas personales.

4. Supabase: schema dedicado, NUNCA public. Todas las tablas viven en vibe_<APP_NAME>. Migraciones contra public están prohibidas. Las aplica un ingeniero senior — el vibecoder solo las escribe (ver ${CLAUDE_PLUGIN_ROOT}/docs/05-supabase.md).

5. Nunca toques lógica crítica sin advertir. Antes de editar VTV.md, src/lib/auth/*, src/lib/supabase/*, src/proxy.ts, src/config/access.ts, src/config/app.ts o supabase/migrations/*, avisá qué vas a cambiar y confirmá.

6. Datos sensibles fuera de (public)/. No referencies tablas/campos con datos personales (emails, teléfonos, documentos, leads, clientes) desde src/app/(public)/. Ante la duda, usá el skill sensitive-data-check y leé ${CLAUDE_PLUGIN_ROOT}/docs/03-datos-sensibles.md.

7. Dependencias solo de la allowlist. Antes de npm install <paquete>, verificá que esté en .claude/allowed-deps.json. Si no está, advertí y proponé pasar por /vtv.

8. Nunca commitear secrets. .env.local está en .gitignore. Nunca git add .env*. Si ves un secret en código, advertí inmediatamente.

9. Stack inalterable sin VTV. No reemplaces Next.js, Tailwind, shadcn/ui ni Supabase Auth sin pasar por /vtv con el líder técnico.

10. Cuando dudes, mostrá el doc. Si la respuesta está en ${CLAUDE_PLUGIN_ROOT}/docs/, leé el doc relevante y respondé citándolo. No improvises.

Estilo de comunicación

• Hablale al usuario en español, simple y directo, asumiendo que NO es ingeniero.
• Cuando uses una palabra técnica, definila o mandalo a ${CLAUDE_PLUGIN_ROOT}/docs/08-glosario.md.
• Si vas a hacer un cambio grande, decí primero qué vas a hacer y por qué, en una oración.
• Si el usuario pide algo riesgoso, advertí y ofrecé alternativas, pero no bloquees si insiste (salvo VTV, que es innegociable).

Herramientas disponibles (vienen del plugin vibe-toolkit)

• Comandos: /setup, /vtv, /deploy, /add-page, /add-component, /enable-supabase.
• Skills auto-invocados: ole-rules (este), sensitive-data-check, access-audit.
• Agente: vibe-reviewer (usalo antes de /deploy o tras cambios grandes).