Publicar

/publicar — De tu compu a producción, sin el bucle de parches

"El build que pasa no es el objetivo. El objetivo es que un usuario real abra la URL y la app le responda."

Esta skill resuelve el dolor más común de quien construye con la SaaS Factory: tu app funciona perfecto en tu computadora (localhost), la subes a Vercel, y truena — el build falla, o peor: el build pasa pero la app responde con "Error de conexión" cuando alguien la usa. Aplicas un ajuste para que el build pase, y eso rompe la funcionalidad. Aplicas otro, y rompe algo distinto. Es un bucle de parches sin salida.

Esta skill rompe ese bucle. No te da una lista de comandos: toma tu app (sana o rota), encuentra la causa raíz de lo que la detiene, la arregla, vuelve a desplegar, y comprueba en vivo que responde — y si no responde, lo intenta de otra forma, sin detenerse, hasta dejarla viva.

Dónde encaja /publicar (el 5º paso)

/publicar hace UNA cosa y la hace hasta el final: el deploy. No corre auditorías ni revisiones — eso es trabajo de sus skills hermanas, cada una con su momento:

Usa las que tu flujo pida — /publicar no te impone ninguna. Pero el orden sano es: valida primero, publica al final. Esta skill arranca directo en el deploy y asume que tu app ya pasó las revisiones que TÚ decidiste hacerle.

Stack objetivo: Next.js (App Router) + Supabase + un modelo de IA (Vercel AI SDK / OpenRouter / SDK directo), desplegado en Vercel (el Golden Path de la SaaS Factory). Para casos que NO encajan en serverless, la skill lo detecta y te lo explica (ver Familia 7), pero no ejecuta el despliegue en VPS.

Cuándo se activa

• Invocación directa: /publicar
• "Quiero publicar mi app" / "lanza mi app" / "sube mi app a internet"
• "No me sube a Vercel" / "el deploy falla"
• "En local jala pero en producción truena / da Error de conexión"
• "El build pasa pero la app no responde"
• "Mi agente de IA funciona en mi compu pero en Vercel no contesta"
• "Llévame esto a producción" / "deploya mi app"

El principio que lo cambia todo

La mayoría de la gente valida el deploy preguntando "¿cargó el build?". Eso es mentira: un build verde no significa que tu app funcione. El caso real reportado en la comunidad (y que vive media comunidad) es exactamente ese: el build pasa, pero el agente da "Error de conexión" cuando procesa una consulta real.

Por eso esta skill define el éxito de UNA sola forma:

OBJETIVO FIJO: un endpoint REAL de la app (no el home estático — el flujo que importa: el chat, la consulta, la acción del agente) responde correctamente desde la URL de producción, ejecutado como lo ejecutaría un usuario.

Mientras eso no pase, el trabajo NO está hecho. Da igual cuántos builds verdes haya.

EL MOTOR DE LOOP (corazón de la skill)

Es un bucle con objetivo fijo que no se detiene hasta cumplirlo o hasta agotar el presupuesto de intentos. Hereda la mecánica de auto-blindaje del bucle-agentico de Bluntag (mapear → arreglar → documentar → repetir) pero con una diferencia clave: aquí el objetivo no es "completar fases", es "la URL de producción responde bien", y cada vuelta del loop ataca la causa raíz, nunca el síntoma.

                 ┌─────────────────────────────────────────────┐
                 │  OBJETIVO FIJO: el endpoint real responde    │
                 │  correctamente en la URL de produccion       │
                 └─────────────────────────────────────────────┘
                                     │
                 ┌───────────────────▼───────────────────┐
   ┌────────────▶│  1. MAPEAR  (estado real del proyecto) │
   │             └───────────────────┬────────────────────┘
   │                                 ▼
   │             ┌────────────────────────────────────────┐
   │             │  2. DIAGNOSTICAR (¿que familia de falla │
   │             │     del catalogo es? causa raiz, no     │
   │             │     sintoma)                            │
   │             └───────────────────┬────────────────────┘
   │                                 ▼
   │             ┌────────────────────────────────────────┐
   │             │  3. ARREGLAR la causa raiz             │
   │             └───────────────────┬────────────────────┘
   │                                 ▼
   │             ┌────────────────────────────────────────┐
   │             │  4. RE-DESPLEGAR + VALIDAR EN VIVO     │
   │             │     (curl/Playwright al endpoint real  │
   │             │     en la URL de prod)                 │
   │             └───────────────────┬────────────────────┘
   │                                 ▼
   │                        ¿Responde bien?
   │                   ┌─────────┴─────────┐
   │                  NO                   SI
   │                   │                    │
   │         ┌─────────▼────────┐    ┌──────▼───────────────┐
   └─────────│ 5. AUTO-BLINDAJE │    │  CIERRE: reporte +   │
   (otra     │ documentar el    │    │  URL viva            │
   vuelta)   │ aprendizaje;     │    └──────────────────────┘
             │ ¿misma falla 2x? │
             │ cambia hipotesis │
             └──────────────────┘

Reglas del motor

1. Una hipótesis a la vez. Diagnostica UNA causa raíz, arréglala, re-valida. No apliques 5 cambios juntos: si funciona no sabrás cuál fue, y si rompe tampoco.
2. Causa raíz, no síntoma. "Error de conexión" es un síntoma. La causa puede ser runtime Edge, env var ausente, CSP, o RLS. La skill identifica CUÁL antes de tocar nada. Parchear el síntoma es lo que genera el bucle infinito.
3. Valida el flujo real, no el home. Después de cada deploy, ejecuta el endpoint que importa (el chat, la consulta del agente) contra la URL de producción — no te conformes con que cargue la página.
4. Tope de iteraciones: 8 vueltas. Si tras 8 intentos no converge, PARA y entrega un reporte honesto: qué se probó, qué se descartó, cuál es la hipótesis más probable, y si el caso amerita VPS (Familia 7). Nunca finjas éxito.
5. Misma falla 2 veces seguidas → cambia de hipótesis. Si el mismo error reaparece tras un fix, el diagnóstico estaba mal: vuelve al paso 2 con otra familia del catálogo.
6. Auto-blindaje en cada fix. Cada causa raíz nueva que encuentres se documenta en la sección "Aprendizajes" de abajo, para que la próxima vez se diagnostique en segundos.

Por qué un motor propio (y no /goal ni bucle-agentico tal cual)

• bucle-agentico (Bluntag) aporta la columna vertebral: el ciclo mapear→arreglar→documentar→repetir y el auto-blindaje. Pero su objetivo es "completar las fases de un PRP" — abierto. Aquí el objetivo es único y medible ("responde en prod"), lo que permite el tope de intentos y el criterio de parada honesto.
• /goal (skill de Anthropic de persecución de objetivo) aporta la idea de un objetivo terminal verificable con criterio de éxito explícito. Tomamos eso: el éxito es una comprobación externa (curl/Playwright al endpoint), no la opinión del agente.
• Lo nuestro combina ambos en un motor específico para deploy: objetivo medible + ciclo de auto-blindaje + catálogo de causas raíz + criterio de parada. No es ninguna de las dos recicladas — es producto propio. (La comparativa detallada vive en COMPARATIVA-MOTORES.md de esta skill.)

EL FLUJO COMPLETO (lo que la skill ejecuta)

Paso 0 — Revisar las herramientas (para que nada te frene a medio camino)

Antes de empezar, la skill comprueba su propio entorno y, si falta algo, te guía para instalarlo en palabras claras (qué es, para qué sirve, dónde dar clic):

• Que el proyecto sea Next.js y tenga package.json sano.
• Que exista una cuenta de Vercel conectada (vercel whoami); si no, te lleva de la mano por vercel login (es gratis empezar).
• Que el proyecto esté en git (la red de seguridad para deshacer cualquier cosa).

Regla: ningún mensaje de este paso asume conocimiento técnico. "Falta X" siempre viene con "X es… y se arregla así…".

Paso A — MAPEAR el proyecto (antes de tocar nada)

Lee el estado real, no supongas:

• Stack y config: package.json, next.config.{js,ts}, vercel.json (si existe), versiones.
• Runtime de las rutas: grep de export const runtime = 'edge' / 'nodejs' en app/api/** y en server components. (Los SDK de IA y pg/Supabase service suelen NO correr en Edge.)
• Uso de variables de entorno: grep de process.env. — lista TODAS las que la app necesita, separa las NEXT_PUBLIC_* (cliente) de las privadas (servidor).
• Modelo de IA: cómo se llama (OpenRouter / Vercel AI SDK / SDK directo), si la key es de pago o gratis, el endpoint del modelo.
• Supabase: cliente browser vs server vs service_role; dónde se usa cada uno; si hay RLS.
• CSP / headers: si next.config o vercel.json definen Content-Security-Policy, leer connect-src y media-src. OJO: si los headers se aplican solo en producción (patrón común), en local no verás el problema.
• El endpoint que importa: identifica CUÁL ruta es la que el usuario usa (el chat, la consulta del agente) — esa es la que hay que validar en vivo.
• La URL pública real: la URL canónica del proyecto (<proyecto>.vercel.app o el dominio propio), NO la URL del deployment (<deploy>-<scope>.vercel.app) — esa última suele dar 401 por la protección "Vercel Authentication" y te hace creer que la app está rota cuando está viva.

Paso B — DIAGNOSTICAR contra el catálogo

Con el mapa, identifica la familia de falla más probable. Ver CATALOGO-FALLAS.md (7 familias). El diagnóstico se hace leyendo evidencia real, nunca adivinando:

• Build Logs de Vercel si el build falla.
• Runtime Logs de Vercel del momento exacto en que truena, si el build pasa pero el endpoint responde mal.
• Consola del navegador (con Playwright o a mano) si la falla es del lado cliente: las violaciones de CSP, por ejemplo, NO aparecen en los logs de Vercel — solo en la consola del navegador, y la página puede "verse normal" mientras tanto.

Paso C — ARREGLAR la causa raíz

Aplica el fix de la familia diagnosticada. UN cambio. Documenta qué cambiaste y por qué.

Paso D — RE-DESPLEGAR y VALIDAR EN VIVO

• Re-desplegar (commit que dispara Vercel, o vercel --prod si el usuario usa CLI).
• Validar el endpoint real contra la URL pública de producción (la canónica, no la del deployment): un curl/fetch al endpoint del agente con un payload real, o Playwright navegando el flujo. Confirmar respuesta correcta (no 500, no "Error de conexión", la respuesta esperada).
• Si la falla era del lado cliente, revisar también la consola del navegador después del fix: que no queden violaciones de CSP ni errores silenciosos.
• Si responde bien → CIERRE. Si no → Paso E.

Paso E — AUTO-BLINDAJE y otra vuelta

Documenta el aprendizaje, evalúa si la falla cambió (progreso) o es la misma (cambiar hipótesis), y vuelve al Paso B. Respeta el tope de 8 iteraciones.

CIERRE — Reporte en palabras claras

Un solo mensaje, sin jerga:

• Qué estaba roto (causa raíz, en palabras claras).
• Qué se arregló (el cambio concreto, archivo:línea).
• La URL viva + el endpoint validado ← compártela.
• Si aplica: qué se aprendió (quedó blindado para la próxima).
• Si algo NO quedó: se dice con la misma claridad (qué está roto, qué se intentó, cuál es el camino). Esta skill nunca te dice "todo bien" si no es cierto.

El catálogo de fallas

Las 7 familias de causa raíz viven en CATALOGO-FALLAS.md (en esta misma carpeta). Cada una trae: cómo se detecta, cuál es la causa raíz, y cómo se arregla. Es la base de conocimiento que hace el diagnóstico rápido en vez de adivinar.

Reglas duras de esta skill

• Valida el flujo real, no el home. Es la regla #1.
• Una hipótesis a la vez, causa raíz, no síntoma.
• Reporte honesto si no converge. Mejor "no lo resolví, aquí está la hipótesis y probablemente necesitas VPS" que un falso éxito.
• VPS se detecta y explica, NUNCA se ejecuta (Familia 7).
• Sin secretos en logs, commits ni reportes. Si un fix toca una key, se referencia por nombre, nunca se imprime el valor. Para cargar secrets a Vercel, usar stdin (... | vercel env add NOMBRE production) para que el valor no toque la pantalla.
• Sin push a producción sin autorización explícita del usuario.
• Cero jerga sin traducción. Cada término técnico que aparezca en preguntas o reportes va acompañado de su explicación en palabras claras, en el mismo mensaje.
• Cada arreglo se explica en una línea de humano. El usuario siempre sabe qué se le hizo a su app.
• Ortografía impecable en todo lo que ve el usuario.

Aprendizajes (auto-blindaje — crece con cada deploy)

Cada causa raíz nueva que esta skill resuelve se documenta aquí para diagnosticarla en segundos la próxima vez.

2026-06-10 — Primera corrida real (app de muestra, Vercel):

• La URL del deployment NO es la URL pública. Las URLs tipo <deploy>-<scope>.vercel.app que imprime el CLI devuelven 401 por la protección "Vercel Authentication" (activa por default). La URL que ve el usuario real es el alias canónico <proyecto>.vercel.app. Validar SIEMPRE contra el alias público, no contra la URL del deployment — si validas contra la protegida, un 401 parece "app rota" cuando en realidad está viva.
• vercel env add vía stdin no imprime el valor (node -e "...match(...)" | vercel env add NOMBRE production) — forma segura de cargar secrets sin que toquen pantalla ni logs. Tras cargar, redeploy obligatorio (confirmado en vivo: Vercel no relee envs sin deploy nuevo).
• Modelos razonadores (gpt-5/o-series): respuesta VACÍA intermitente si max_completion_tokens es corto — el razonamiento interno consume el presupuesto y el content llega vacío sin error HTTP. Síntoma engañoso: "a veces contesta, a veces no". Fix: reasoning_effort: "low" (o "minimal") + presupuesto holgado. Agregado como causa 4 de la Familia 5.
• Las violaciones de CSP no dejan rastro en los logs de Vercel. La app "se ve normal", el historial simplemente no carga, y el único lugar donde está la verdad es la consola del navegador. Por eso el Paso B incluye la consola como tercera fuente de evidencia.