Lista de comprobación para publicar un proyecto de vibe coding

Escribe qué hace esta versión

Elige un recorrido que una persona nueva deba completar sin tu ayuda. Define el punto de partida, la acción y el resultado visible. Enumera las funciones que quedan fuera. Si un botón abre otra tienda o sitio web, identifica ese destino en lugar de dar a entender que la acción ocurre dentro de tu app.

Contrasta el texto público con la versión real. Usa capturas auténticas, identifica las ilustraciones y elimina las afirmaciones sin pruebas. Una herramienta pequeña que funciona y explica sus límites resulta más fácil de evaluar que una larga lista de funciones con controles sin terminar.

Prueba el recorrido y sus fallos

Completa el recorrido con el navegador limpio y después con datos existentes. Prueba entradas vacías, textos largos, peticiones lentas, una petición fallida y un clic repetido. Confirma que reintentar no duplica un registro ni hace perder el borrador.

En LaunchVibe, Guardados es una preferencia local del navegador, mientras que un voto de la comunidad es un registro del servidor. Estas acciones necesitan comprobaciones distintas. El total de votos debe reflejar una respuesta correcta del servidor; un guardado local debe explicar un fallo de almacenamiento. Decide qué sistema es responsable de cada resultado antes de probarlo.

• Anota el navegador, el tamaño de su área visible y la versión comprobados.
• Mantén visibles las comprobaciones fallidas hasta corregirlas o excluirlas expresamente del lanzamiento.
• Usa datos de prueba y proveedores simulados cuando una comprobación afectaría a personas reales o a métricas de producción.

Revisa los datos y los permisos por separado

Dibuja un pequeño mapa de lo que permanece en el dispositivo, llega a tu servidor o se envía a otro proveedor. Nunca incluyas un secreto del servidor en el código del navegador. Comprueba si una persona puede modificar registros de otra y si las sesiones caducadas fallan de forma comprensible.

El acceso como invitado también necesita reglas. Un identificador de navegador no demuestra que haya una persona única detrás. Antes de aceptar comentarios públicos, contempla texto sin formato, borrado, denuncias y moderación. Para las acciones destructivas, prueba la confirmación y la recuperación real, sin asumir que basta con una etiqueta «Deshacer».

Úsalo con teclado y en una pantalla pequeña

Sigue el recorrido principal sin ratón. Comprueba el foco visible, las etiquetas claras y los errores que no dependen solo del color. Abre y cierra un diálogo: el foco debe volver a un lugar útil. Prueba traducciones largas y zoom además de una pantalla estrecha.

Easy Checks de W3C es una referencia inicial útil. Superar algunas comprobaciones manuales no equivale a una evaluación completa de accesibilidad. Registra qué has comprobado y señala las tecnologías de asistencia o combinaciones de navegadores que no has probado.

Referencia: W3C WAI: Easy Checks

Haz que la privacidad refleje la app real

Explica qué información procesas realmente y para qué. Si ofreces analítica opcional, prueba el rechazo, la aceptación y la retirada del consentimiento por separado. Revisa si se envían peticiones al proveedor antes de la elección que prometiste respetar.

No incluyas búsquedas, comentarios ni otros datos personales introducidos por el usuario en eventos de analítica. Revisa los enlaces a tiendas externas y explica que allí se aplican sus políticas. Una página de privacidad copiada no describe una implementación que no has revisado; actualízala cuando cambien los flujos de datos.

Publica una versión conocida con una vía de retorno

Compila con el archivo de bloqueo de dependencias guardado en Git, verifica la cuenta de destino y comprueba las rutas publicadas, enlaces, HTTPS y páginas inexistentes. Conserva identificada la versión anterior que funcionaba. En Cloudflare Workers, las versiones del código y los despliegues son independientes; volver a una versión de código no revierte el contenido de la base de datos.

Si el lanzamiento modifica datos, planifica ese cambio por separado. Tras publicar, repite una pequeña comprobación de solo lectura en el dominio real. No presentes una prueba local como evidencia de producción ni una petición como prueba de que el proveedor la procesó.

Versión / commit:
Recorrido principal comprobado:
Entorno y navegadores:
Comprobaciones superadas y pruebas:
Límites conocidos / comprobaciones no realizadas:
Cambios de datos, si los hay:
Versión anterior que funcionaba:
Quién puede revertir el despliegue y cómo:

Referencia: Cloudflare: Versions and deployments

Decide expresamente si publicar

Resuelve los fallos que bloquean el recorrido prometido. Para los límites restantes, decide si aplazas la función, la identificas claramente o retrasas la publicación. Esta lista se refiere a lanzamientos web; las revisiones de apps nativas y las obligaciones específicas de tu producto requieren sus propias comprobaciones.