🔒 Reglas de publicación

¿Eres nuevo aquí? Publicar (también llamado deploy, «poner en línea») significa hacer que una versión de tu trabajo quede visible y accesible para otras personas en internet, en vez de ejecutarse solo en tu computadora. Es la diferencia entre un borrador en tu escritorio y una carta ya enviada por correo.

Imagina a un pasante excelente y rápido que trabaja por su cuenta en el borrador de un informe para el cliente. Investiga, escribe y revisa el formato; hace todo eso por su cuenta, sin necesitar aprobación en cada frase. Pero hay una línea que nunca cruza por su cuenta: presionar "enviar" en el correo que va para el cliente. Esa decisión siempre le corresponde al gerente, aunque el pasante esté seguro de que el informe está listo.

El agente de código es exactamente ese pasante. Puede construir, probar, ajustar el diseño (módulos 5.1 a 5.6) e incluso ejecutar el comando de publicación por su cuenta, si lo permites: tiene la capacidad técnica. La pregunta de este módulo no es "¿puede publicar por su cuenta?" (sí, puede). Es "¿debería?" Y la respuesta, por defecto, es no, hasta que digas explícitamente que sí.

¿Eres nuevo aquí? O CLAUDE.md es un archivo de texto simple que dejas dentro de la carpeta del proyecto (se explica a fondo en el módulo 0.4), con instrucciones fijas para el agente: este lo lee automáticamente cada vez que abre el proyecto. Es el lugar adecuado para registrar una regla que debe cumplirse siempre, en todas las sesiones, incluso con un agente nuevo o después de meses.

La regla de oro de este módulo es breve y debe escribirse, palabra por palabra, cerca del inicio de ese archivo: el agente nunca publica ni hace deploy por su cuenta: solo cuando la persona da una orden explícita para esa publicación específica. No vale eso de «ya publicó antes, así que puede hacerlo de nuevo». Cada publicación es una nueva decisión.

Leyenda: el agente tiene total libertad para construir y probar en local (verde a la izquierda), pero antes de que cualquier cosa cruce el portón amarillo con candado rumbo al `git push`, necesita tu orden explícita. Después del push, la herramienta externa (amarillo discontinuo a la derecha) publica por sí sola: de forma automática y fuera de tu control directo.

¿Eres nuevo aquí? Uno repositorio (o “repo”) es una carpeta de proyecto guardada con un historial completo de versiones, generalmente alojada en un servicio como GitHub. Commit es el comando que registra una «fotografía» de los cambios que hiciste, con un mensaje que explica qué cambió. Push es el comando que envía esos commits guardados en tu computadora al repositorio en la nube.

Este es el punto que confunde a mucha gente que está empezando: en la mayoría de los proyectos de este curso, «publicar» no es un botón especial de publicación. Es simplemente esto: commit + push al repositorio. Una herramienta externa — Vercel, GitHub Pages y otras parecidas — queda "pendiente" de ese repositorio y, apenas detecta un cambio nuevo, lo publica automáticamente, sin que tengas que hacer nada más.

Esto divide el trabajo en dos partes bien separadas: la parte que tú (o el agente, siguiendo tus instrucciones) controlas directamente — construir, probar y enviar el push — y la parte automática, que se ejecuta sola después de eso y queda fuera de tu control directo. No sirve de nada revisar el panel de la herramienta cada minuto: una vez que se hizo el push, lo demás ocurre entre el repositorio y la herramienta de publicación.

No toda regla escrita en CLAUDE.md protege de verdad. Algunas parecen seguras, pero dejan una brecha; otras son lo bastante explícitas como para contener al agente incluso en un día en que «está seguro» de que todo está listo. Compara:

Tres pasos para que esto funcione de verdad en tu proyecto: escribir la regla, probar en localhost antes de publicar y solo entonces autorizar el push con una frase explícita. Vamos directo a lo que tienes que pegar.

## Reglas de publicación

- **Nunca publiques ni hagas deploy sin una orden explícita.** Esto incluye `git push`,
  cualquier comando de deploy manual o reactivar un deploy bloqueado.
- Construir y probar en `<dirección de tu localhost>` es libre; no
  necesitas aprobación en cada paso.
- Publica solo después de que yo diga algo como "puedes publicar" o "súbelo"
  —palabras explícitas referidas a ESTE cambio específico.
- Si la publicación falla después del push, avísame. No intentes resolverlo
  por tu cuenta volviendo a activar el deploy.

git add <arquivos que mudaram, ou . se for tudo>
git commit -m "<mensagem curta explicando o que mudou>"
git push

Desde el módulo 5.1, esta ruta repite una cifra: el agente entrega rápido alrededor del 60% de cualquier interfaz — genérica, funcional, pero sin alma— y el 40% final (la marca, el pulido, las decisiones precisas) depende de que tú aportes referencias, criterio y revisión. Este módulo muestra que el mismo principio se aplica a la publicación: el 40% final no es solo estético, también es de gobernanza — cuándo e si que algo se publique siempre es una decisión tuya; nunca se delega de forma predeterminada.

Esto no es burocracia ni falta de confianza en el agente. Es la misma disciplina que cualquier equipo serio aplica con cualquier persona nueva: libertad total para producir y una aprobación final que nunca es automática. Separar "construí y probé en local" de "autorice la publicación" en dos frases distintas es lo que garantiza que un error en un paso nunca se convierta en un problema publicado sin que nadie lo haya revisado.