Una sola forma, corra el comando que corra
Todo comando que cambia archivos en tu proyecto sigue el mismo recorrido. El comando de implementación es el ejemplo más claro, así que ese es el que se cuenta aquí, pero las compuertas de abajo son compartidas: una revisión, una limpieza y una reparación pasan por todas ellas.
Conocer la forma vale los cinco minutos. Te dice dónde te van a preguntar algo, dónde puede detenerse la corrida y qué estás viendo en el reporte final.
1. No se escribe nada antes de acordar el alcance
Tu asistente repite lo que entendió, nombra los archivos y flujos que espera tocar, pregunta lo que de verdad falta y espera. Las peticiones vagas regresan como preguntas, no como suposiciones.
El único caso en que no se te pregunta de nuevo es una petición que la compuerta del propio comando ya probó completa: leyó tu petición contra el código y no encontró nada faltante. Preguntar después de eso no confirma nada y solo retrasa un trabajo que ya describiste entero.
Si llegas con un prompt que escribió antes el comando de planeación, se reconoce por la línea que lleva arriba nombrando al comando que lo escribió, y la corrida parte de lo que ese prompt ya dejó resuelto en vez de volver a preguntarte.
2. Los entregables quedan escritos como una lista
Antes de tocar código, el trabajo se vuelve una lista numerada: qué debe existir cuando esto esté terminado y en qué estados. Contra esa lista se mide la corrida después, así que vale la pena leerla mientras corregirla todavía sale barato.
En ese mismo punto tu asistente dice qué va a probar el cambio — la pantalla que va a abrir, el comando que va a correr, la migración que va a ejecutar — y qué más necesita de ti para poder llegar ahí.
3. Tu trabajo sin commitear queda aparte
El estado de tu árbol de trabajo se registra antes del primer cambio, así que los archivos que la tarea posee se mantienen separados de lo que ya tenías en curso. Nada fuera de ese conjunto se agrega, revierte, guarda en stash ni reinicia. Lo que traías en curso se queda exactamente como lo dejaste.
4. El cambio se implementa
Las ediciones se quedan dentro del alcance acordado. El código que no se toca no se reordena, ni se reestiliza, ni se ordena de pasada: si algo fuera del alcance se ve mal, se te reporta en lugar de cambiarse.
Antes de cambiar código que ya existe, /develop revisa quién lo puso ahí. Lee la historia de exactamente las líneas que va a cambiar, y cuando un commit cambió esas líneas a lo que son hoy a propósito, y la edición desharía esa decisión, se detiene y te pregunta en lugar de revertirla en silencio — nombrando el commit y lo que decidió. Agregar un caso junto al código que existe, o extenderlo, no deshace nada y sigue adelante. Dentro de /next, donde nada se pregunta a mitad de la corrida, la misma pregunta se escribe en el plan como pregunta abierta con el commit, el trabajo que depende de la respuesta la espera, y el resto se construye.
Si el trabajo necesita datos — un usuario, un rol, un registro que deje una pantalla en el estado que se está construyendo —, tu asistente confirma primero el entorno, y en un entorno local confirmado crea lo que necesita y entra a la sesión él mismo en vez de pedírtelo a ti. Lo que creó es suyo y puede cambiarlo. Lo que ya estaba ahí no lo es: un registro existente nunca se borra, y uno que la tarea tuvo que cambiar se deja como estaba antes de terminar.
5. Se valida, no se supone
La validación es donde se va la mayor parte del tiempo, y tiene tres partes.
Cada archivo pasa por el analizador. Cada archivo que la tarea escribió se envía con su ruta y su contenido completo, se corrige cada error que regresa y se vuelve a enviar hasta que regresa limpio. Si la conexión con el servidor está caída, se te dice con todas sus letras y un revisor interno toma su lugar — reportado como otra cosa, nunca como una pasada del analizador, porque no son lo mismo. Mira Analizar un archivo y Leer un hallazgo.
Lo que prueba el cambio se corre de verdad. Una migración que existe pero que nunca se corrió deja el cambio sin probar. Lo mismo una dependencia faltante, un asset sin compilar y un servidor de desarrollo que nadie levantó. Recuperar ese entorno es parte del trabajo, no una razón para detenerse: la corrida instala, migra, compila y levanta lo que haga falta, y solo un bloqueo real la termina antes.
Todo lo que una persona puede ver se abre y se mira. No una captura, no la página respondiendo sin error: tu navegador real, en las pantallas que toca el cambio. Se revisa que los elementos se vean completos y sin nada encima; de un modal se revisa que abra sobre la página, que haga scroll dentro de sí mismo y que no deje nada atrás al cerrarse. Cada uno regresa como pasa o falla, nombrando la pantalla y el elemento.
Esa pasada por el navegador corre contra cada estado que distingue el código cambiado, no solo el que tu base de datos tenga en ese momento: una lista vacía además de una llena, una cuenta con suscripción además de una sin ella. Un estado que no se puede crear se reporta como no cubierto en lugar de contarse callando como aprobado. Y como la validación misma escribe registros, la pasada por el navegador corre una vez más después de la última escritura, antes del commit.
6. La lista se recorre punto por punto
Cada entregable del paso 2 se marca hecho o no hecho contra evidencia concreta: el archivo, la corrida, la pantalla abierta, la migración ejecutada. Un punto sin evidencia no está hecho. Nada a medias se reporta como terminado.
Un punto bloqueado no deshace a los demás. Los puntos que se sostienen en evidencia siguen hechos, el bloqueado se nombra con su razón, y el código ya escrito para él viaja con el resto en lugar de tirarse.
7. Un commit, y nada de push
Lo probado se vuelve un solo commit enfocado, agregando únicamente los archivos que la tarea posee, con un mensaje en inglés aunque tú hayas trabajado en otro idioma. No se hace push, no se crea rama, no se reescribe ningún commit anterior. El hash del commit va en el reporte.
El commit se omite cuando no se pudo correr ninguna validación, cuando Git no está disponible o cuando tus otros cambios hacen ambiguo agregar archivos con seguridad. En ese caso recibes el bloqueo y la lista de archivos en su lugar.
8. El reporte te dice qué queda pendiente
El reporte final nombra qué se construyó, qué se corrió para probarlo, cómo salió la pasada por el navegador, el commit que se creó y lo que quedó abierto.
La documentación ya está escrita para entonces: la misma corrida que construye un cambio escribe lo que ese cambio debe — la documentación de desarrollo, y el ítem de la función y su guía cuando es algo que un usuario nota — de modo que describe lo que de verdad se construyó y no lo que alguien recordó una semana después. Lo que la última línea sigue nombrando como pendiente es la entrada del changelog, que escribe /finish parado en la rama principal: la fecha es la del momento en que el trabajo llega a los usuarios, no la del día en que se escribió.
Sigue por aquí
- Qué hace cada comando — elegir con cuál empezar.
- Los agentes detrás de un comando — quién hace cada parte de este recorrido.