Escribir primero la especificación y luego programar en pasos pequeños con las pruebas primero

## Anotar los requisitos dudosos como preguntas y esperar respuesta antes de planificar No planifiques ni implementes mientras un requisito importante no esté claro. Identifica los requisitos pendientes, las expectativas no funcionales, el comportamiento, la telemetría, las políticas y los criterios de aceptación antes de proponer cambios. Antes de pedir una decisión, registra cada aclaración de gran impacto y cada incertidumbre de impacto medio en el registro de preguntas abiertas designado por el repositorio. Asigna a cada pregunta un identificador estable y mantén la especificación rectora, el plan y la lista de tareas circunscritos a ese identificador hasta que se resuelva. Al presentar alternativas, guarda primero las mismas opciones y después resúmelas directamente para el usuario. Coloca primero la opción recomendada, ofrece ventajas e inconvenientes concisos, cita el identificador de la pregunta y detente hasta disponer de la respuesta necesaria. Una vez resuelta, incorpora la respuesta a las secciones normativas de la especificación y cierra la entrada del registro. ## Leer la especificación y el mapa de arquitectura antes de planificar Trabaja desde la raíz del repositorio y aplica tanto las instrucciones para todo el repositorio como todas las reglas anidadas pertinentes. Antes de planificar, lee la hoja de ruta vigente, la especificación rectora de la funcionalidad, el mapa de módulos o de conocimiento, las convenciones de código y las decisiones arquitectónicas vinculadas a la funcionalidad afectada. Traza los módulos, contratos y límites de responsabilidad que el cambio puede afectar. Utiliza la instantánea de arquitectura mantenida por el repositorio en vez de inferir relaciones solo a partir de un archivo cercano, y actualiza ese mapa cuando cambien los módulos, las dependencias o los contratos. Utiliza las plantillas aprobadas para especificaciones, planes, tareas y decisiones arquitectónicas, de modo que los metadatos, las notas de verificación y los enlaces cruzados mantengan su coherencia. ## Actualizar primero la especificación y después el plan y la lista de tareas Crea o actualiza la especificación de la funcionalidad antes de implementarla. Define los requisitos, los requisitos no funcionales, los detalles de comportamiento o de interfaz, la telemetría y las políticas, las ramas de aceptación y un boceto de la interfaz cuando cambie el comportamiento visual. Resuelve todas las preguntas de impacto alto y medio antes de generar el plan de implementación. Después de actualizar la especificación, registra los resultados importantes para la arquitectura en un registro de decisiones arquitectónicas y conserva las aclaraciones resueltas en las secciones normativas, no en una lista heredada de aclaraciones independiente. Solo entonces actualiza el plan y la lista de tareas. Ordena las pruebas antes que la implementación, divide el trabajo en incrementos lógicos que previsiblemente quepan en 90 minutos y ejecuta la puerta de análisis del repositorio una vez que la especificación, el plan y las tareas coincidan. No inventes comportamientos alternativos ni de compatibilidad salvo que el usuario los solicite explícitamente. ## Retomar la sesión desde una única instantánea guardada y actualizarla antes del traspaso Al iniciar una sesión sin contexto, sigue el procedimiento del repositorio para restablecer o entregar el trabajo. Resume el estado de la hoja de ruta, el progreso del plan activo y las preguntas sin resolver antes de abordar una nueva implementación. Mantén una única instantánea designada de la sesión actual como estado activo entre sesiones. Antes de la entrega, actualízala con la funcionalidad activa, el trabajo terminado, las preguntas pendientes, el estado de verificación y la siguiente acción segura. No crees registros de progreso que compitan entre sí. Mantén explícita la responsabilidad de cada funcionalidad y módulo para que la documentación, la automatización, la seguridad, la persistencia y el trabajo de interfaz se actualicen en sus ubicaciones rectoras. ## Escribir primero una prueba que falle para cada comportamiento Actualiza la especificación rectora y el plan antes de modificar el código. Para cada comportamiento, escribe o amplía primero una prueba ejecutable unitaria, de comportamiento, de contrato o de escenario, y confirma que falla por el motivo previsto. Durante la planificación, enumera las ramas de éxito, validación y fallo, y añade a cada ruta una prueba mínima que falle. Implementa solo el código necesario para que las pruebas pasen y luego refactoriza sin dejar de mantenerlas en verde. Cuando cierres el ciclo, registra los cambios de cobertura, lo aprendido y el trabajo posterior en el plan o la hoja de ruta para que el razonamiento siga siendo auditable. ## Hacer cambios pequeños y completos, y marcar cada tarea como hecha al momento Mantén cada incremento autocontenido y respeta las convenciones de lenguaje, entorno de trabajo, documentación y pruebas del repositorio. Prefiere una coordinación lineal compuesta por pequeñas funciones auxiliares de validación y normalización frente a ramificaciones en línea profundamente anidadas. Sincroniza la hoja de ruta, la especificación, el plan y la lista de tareas a medida que cambie el comportamiento. Marca cada tarea verificada como terminada de inmediato, en lugar de agrupar las actualizaciones de estado, y actualiza el mapa de arquitectura siempre que cambie la relación o el contrato de un módulo. Utiliza registros de decisiones únicamente para decisiones arquitectónicas confirmadas. Evita las refactorizaciones no relacionadas, el formateo masivo y el trabajo especulativo de compatibilidad, y mantén la implementación alineada con el incremento aprobado. ## Ejecutar los controles de los tipos de archivo cambiados e investigar los fallos sin saltarlos Durante las iteraciones, ejecuta el formateador, el analizador de estilo, el análisis estático, la comprobación de tipos y las pruebas específicas en el ámbito aplicable más reducido. Antes de terminar, ejecuta todas las puertas que exija el repositorio para los tipos de archivo modificados y para cualquier límite de integración directamente afectado. Trata una comprobación local o de integración continua que falle como un defecto que debe investigarse, no como una puerta que se pueda eludir. Si la política del repositorio permite explícitamente una exención temporal de pruebas, desactiva solo la prueba afectada, añade un TODO claro con el motivo y registra el seguimiento en el plan rector. Añade o actualiza pruebas para cada comportamiento modificado. Revisa las diferencias finales, confirma que la documentación y la cobertura de pruebas coinciden con la implementación y no declares terminado el incremento mientras siga fallando alguna comprobación obligatoria. ## Pedir aprobación antes de añadir dependencias o hacer operaciones de Git arriesgadas Añade al área de preparación únicamente los archivos que pertenezcan al incremento. No uses una preparación amplia cuando puedan existir resultados generados, artefactos de base de datos o trabajo en paralelo. Prepara una descripción de commit atómico y convencional que incluya el impacto en la especificación cuando la documentación y el código cambien juntos, pero deja que el operador designado cree el commit salvo que la ejecución se haya delegado explícitamente. Obtén aprobación explícita antes de añadir o actualizar dependencias, eliminar archivos o directorios concretos, reescribir el historial, enviar cambios o crear una revisión externa. Registra en el plan de la funcionalidad la justificación de una dependencia aprobada y deja tiempo suficiente para los hooks administrados y los procesos de calidad. No incluyas nunca secretos en un commit ni utilices una limpieza destructiva como atajo. Presenta para revisión los archivos rastreados o sin rastrear que aparezcan de forma inesperada y deja intacto el trabajo no relacionado. ## No añadir alternativas de compatibilidad sin que se pidan y proponer antes los cambios arriesgados Sigue la postura de compatibilidad declarada por el repositorio. Cuando las interfaces se consideren de nueva creación, no añadas comportamientos alternativos, capas de adaptación ni comprobaciones heredadas, salvo que el usuario los solicite explícitamente para la tarea actual. Registra los resúmenes de los prompts, las secuencias de comandos relevantes y sus motivos en el plan activo o en un apéndice enlazado. Propón antes de editar las refactorizaciones arriesgadas, los cambios de persistencia, las modificaciones de la estrategia de seguridad y las concesiones no funcionales importantes; después, registra las decisiones arquitectónicas aprobadas en el registro de decisiones adecuado. Mantén en los planes el seguimiento de futuras pruebas de contrato, análisis de mutaciones y ejercicios de seguridad hasta que existan puertas automatizadas. Conserva las orientaciones operativas cerca de su flujo de trabajo oficial y evita duplicar instrucciones que puedan cambiar en varios documentos. ## Probar solo en la base de datos de pruebas y confirmar a cuál se conecta antes de restablecerla No ejecutes nunca una orden de restablecimiento, borrado total o migración desde cero de una base de datos mediante una conexión sin verificar. Antes de cualquier migración o restablecimiento, confirma el entorno activo, el destino de la conexión y si la operación está limitada a una base de datos de prueba desechable. Ejecuta las pruebas de la aplicación contra la base de datos de prueba aislada del repositorio y utiliza la configuración documentada de transacciones o migraciones. Restablece solo la base de datos de prueba identificada explícitamente cuando sea necesario; no presupongas que una orden de prueba y una orden interactiva de la aplicación utilizan la misma conexión. Crea las nuevas migraciones como archivos y ejecútalas mediante el flujo de pruebas. Si el ámbito de la base de datos es ambiguo, detente y pide confirmación en vez de poner en riesgo los datos de desarrollo o producción. ## Cerrar cada paso con un traspaso de lo cambiado y lo comprobado Después de que un incremento autocontenido supere las puertas aplicables, confirma que las tareas terminadas, el estado de la hoja de ruta, los cambios de la especificación, los registros de decisiones y la instantánea de la sesión actual estén sincronizados. Ofrece una entrega breve que enumere los archivos modificados, las comprobaciones realizadas y sus resultados, los bloqueos pendientes, el trabajo posterior y cualquier orden lista para copiar destinada al operador. Distingue el trabajo implementado del que solo está planificado o pendiente de autorización. Prepara con rapidez el commit de la funcionalidad tras verificarla, pero ejecútalo solo dentro de la política de delegación del repositorio. Conserva evidencias suficientes para que la siguiente sesión pueda reanudar el trabajo sin repetir la investigación.