El contrato de sprint

Construir lo que luego te rechazan

Encargas una reforma. El albañil trabaja una semana y, al verla, dices: «Yo pensaba que el armario iba hasta el techo». Nadie mintió: simplemente nadie escribió qué significaba «terminado». Con agentes pasa igual: el generador construye algo razonable, el evaluador lo rechaza según criterios que nunca dijo en voz alta, y empieza el ciclo de reintentos.

Qué es un contrato de sprint

Un contrato de sprint es un acuerdo corto, escrito antes de tocar código, entre quien genera y quien evalúa (pueden ser dos llamadas distintas al mismo agente). Fija tres cosas:

• Alcance: qué se va a cambiar.
• Criterios de verificación: cómo se comprobará que está hecho.
• Exclusiones: qué NO se va a tocar.

Ejemplo mínimo

Este formato lo puedes copiar tal cual:

# Contrato de sprint: modo oscuro

## Alcance
- Cambiar el componente del interruptor de tema
- Actualizar las variables CSS globales
- Añadir tests del modo oscuro

## Criterios de verificación
- Los tests de regresión visual pasan en cada componente
- Los tests de punta a punta del flujo principal pasan
- No hay destello de estilos sin aplicar al cargar

## Exclusiones
- No se tocan los estilos de impresión
- No se trata el modo oscuro de componentes de terceros

Otro ejemplo del material del curso, para una aplicación de preguntas y respuestas sobre documentos: el objetivo es «añadir citas visibles a las respuestas», y «hecho» significa que el usuario pregunta, la app responde, se muestra al menos una cita, y al hacer clic en la cita se abre el lugar exacto del documento fuente. Cuatro frases y nada que interpretar.

Qué hace bien un buen contrato

Conecta con lecciones anteriores: las exclusiones son el mismo control de alcance de una lista de funciones, y los criterios son la versión local de una definición de «hecho».