Constructor de Sitios con Brief

De un vistazo

• Anota primero todo lo que hoy funciona y revisa que siga funcionando.
• Usa tus textos tal como están. Su regla: nada de afirmaciones, precios, testimonios ni credenciales nuevos.
• Lo marcado [POR CONFIRMAR CON EL DUEÑO] nunca llega a una página en vivo; el elemento se queda oculto.

Qué modelo usar

Un agente de programación muestra cada cambio como una comparación o un pull request que puedes revisar antes de que salga en vivo. Un modelo de razonamiento profundo ayuda con un brief largo en dos idiomas. El permiso para publicar se queda contigo, sea cual sea el modelo.

Ajustes que lo hacen cumplir

• Déjalo trabajar en una rama o en un sitio de vista previa, y quédate tú con el permiso de publicar: tú integras el pull request en borrador o publicas la vista previa.
• Usa un modo que pregunte antes de ejecutar comandos y de borrar archivos.
• Mantén los secretos de producción fuera del repositorio, y agrega una regla que bloquee los archivos de secretos si tu herramienta la permite.
• Dale tus afirmaciones y precios aprobados en un solo archivo vigente, y quita las versiones viejas del repositorio.
• No le des acceso a tu dominio, al DNS, a la facturación del hosting ni a tus cuentas de pago; esos cambios te tocan a ti.
• Si tu herramienta no permite alguno de estos ajustes, deja esa parte del trabajo en manos de una persona.

Una revisión antes de confiar en él

Pon en tu brief un punto [POR CONFIRMAR CON EL DUEÑO: horario]. La vista previa debería mostrarlo como un marcador visible, el registro de cambios debería anotarlo y la versión lista para publicar debería ocultar ese elemento.