SDD: haz que la especificación sea ejecutable
Mantén conectados la intención, las tareas de implementación y la evidencia de aceptación mientras el software cambia.
AL TERMINAR, PODRÁS
- Separar una especificación de comportamiento de un plan de implementación
- Vincular los requisitos con las tareas y las pruebas de aceptación
- Actualizar una especificación viva cuando la evidencia cambia el diseño
Descripción del diagrama: Especificación → Plan; Plan → Tareas; Tareas → Código; Código → Tests de aceptación (comprobado por); Tests de aceptación → Especificación (se remontan a)
Aclara la promesa antes que el mecanismo
Aquí SDD significa spec-driven development (desarrollo guiado por especificación): una descripción revisada del comportamiento guía la planificación, la implementación y la verificación.
Para la cancelación en Relay, «cancelar un trabajo» está incompleto. ¿Se pueden cancelar los trabajos en ejecución? ¿Quién puede pedirlo?
¿Qué pasa si la cancelación compite con un worker que está reservando (claim) el trabajo? Escribe una especificación inicial alrededor de los resultados para el usuario, ejemplos, restricciones y lo que queda fuera (non-goals). Resuelve las ambigüedades con las personas responsables del comportamiento.
Numera los criterios de aceptación: AC-1 podría exigir que una cancelación autorizada de un trabajo pendiente impida que un worker lo reserve después. Define la carrera con precisión antes de elegir un mecanismo.
Conecta el plan con evidencia observable
El plan explica cómo cumplir esa promesa: transiciones de estado, transacción de almacenamiento, respuesta de la API y compatibilidad.
Las tareas dividen el plan en trabajo revisable. Conecta AC-1 con la tarea de transición de estado y con una prueba (test) que intente reservar un trabajo cancelado. Agrega una prueba de concurrencia para la regla de carrera elegida; un ejemplo secuencial no puede demostrarla.
Basa las expectativas de aceptación en la especificación, en lugar de copiar lo que haga la implementación generada. Pídele a un asistente que encuentre contradicciones entre la especificación, el plan, las tareas y las pruebas. Aun así, una persona revisora debe decidir si el contrato es correcto.
Usa documentos vivos, en proporción al riesgo
GitHub Spec Kit ofrece un flujo concreto para especificar, aclarar, planificar, dividir en tareas y comprobar la implementación.
SDD no exige esa herramienta ni un gran conjunto de documentos. Una función pura diminuta puede necesitar unos pocos criterios junto a sus pruebas; una cancelación con concurrencia y permisos necesita una revisión más profunda. Cuando una investigación cambia una suposición, actualiza juntos la especificación, el registro de decisión y las pruebas afectadas.
Conserva la razón de un cambio importante. Los documentos generados y las casillas marcadas no garantizan completitud, seguridad ni buena arquitectura. Cierra el ciclo comparando el comportamiento implementado con la necesidad original del usuario.
ERROR FRECUENTE
Tratar una especificación generada como verdad aprobada, o cambiar en silencio las pruebas de aceptación para que coincidan con código que viola el contrato previsto.
INTÉNTALO TÚ
Escribe una especificación compacta de cancelación en Relay con tres criterios de aceptación, algo que quede fuera y una pregunta de carrera sin resolver. Conecta cada criterio con una tarea y una prueba con un resultado esperado observable.
Decide en el laboratorio.
El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.
Abrir en el laboratorio ↗CONÉCTALO CON RELAY
En el proyecto de entrega con IA, especifica la reutilización de duplicados, el rechazo de contenidos en conflicto, la validación antes de reservar una clave y una copia estable del contenido. Conecta los criterios con tareas y pruebas. Indica el límite de concurrencia del prototipo y la atomicidad que necesitaría un diseño de producción.