# Planificación de implementación

Convierte una especificación en el conjunto ordenado de cambios que ejecuta quien desarrolla — con cada paso dejando el árbol compilando y el sistema en marcha.

## Entregable

Un documento Markdown, `implementation-plan.md`, con la estructura fijada en **Salida** más abajo. Toma una especificación acordada y alimenta **Revisión de código** en cuanto los pasos empiezan a entrar.

## Entradas obligatorias

- **La especificación** — qué debe ser cierto cuando el trabajo esté hecho, en la forma en que se acordó: un documento de alcance, un ticket, un briefing escrito.
- **Acceso al código donde aterriza el cambio** — el suficiente para abrir los archivos, leer la configuración de compilación y ejecutar las pruebas.
- **La rama o el punto de partida desde el que arranca el trabajo**, para que los pasos se ordenen contra un árbol conocido.

Si falta cualquiera de las tres, detente y reporta cuál. Un plan escrito sin el código nombra archivos que quizá no existan, y un plan escrito sin punto de partida no se puede ordenar.

## Entradas opcionales

- El conjunto de pruebas y cómo se ejecuta, incluyendo qué partes son lentas o inestables
- Convenciones de código, requisitos de revisión y el proceso de integración
- Interfaces de otros equipos a las que este trabajo debe llamar o satisfacer
- Restricciones de despliegue: interruptores de funcionalidad, migraciones, ventanas de publicación
- Intentos anteriores del mismo cambio, y dónde se detuvieron
- Las personas que ejecutarán los pasos, al menos por rol

Cada entrada opcional ausente se registra en **Puntos abiertos**, y los pasos que habría restringido se marcan `sin verificar`. Ninguna se da por supuesta.

## Ejecución

**1 — Leer la especificación contra el código.** Por cada requisito, localiza el módulo, archivo o función donde aterriza y registra la ruta. Un requisito cuyo punto de aterrizaje no se encuentre se lista como `requiere investigación` con la búsqueda que falló — nunca se asigna a un archivo que solo suena parecido.

**2 — Listar primero las interfaces.** Cada firma de función, forma de datos, cambio de esquema o contrato que el trabajo dependiente necesita antes de poder empezar. Estos son los pasos más tempranos, porque el trabajo bloqueado por una interfaz que todavía no existe es trabajo parado.

**3 — Ordenar los cambios para que el árbol compile en todo momento.** Sigue la dirección de las dependencias: quien llama no puede entrar antes de que compile lo llamado. Cuando dos cambios dependen entre sí, divide uno en un paso de interfaz y un paso de implementación, y di cuál.

**4 — Dimensionar cada paso a un commit.** Un paso es una unidad revisable con un único propósito declarado. Todo lo que necesite la palabra `y` en su propósito son dos pasos. Declara en cada uno qué cambia y qué deja deliberadamente intacto.

**5 — Atar las pruebas a los pasos.** Por cada paso: las pruebas que se escriben con él, qué comprueban y el comando que las ejecuta. Un paso sin prueba declara por qué no es posible y qué se comprueba en su lugar.

**6 — Comprobar el estado del sistema tras cada paso.** Por cada paso, qué debe seguir funcionando cuando entre: la compilación, el conjunto de pruebas, el sistema en marcha. Un paso que deja el sistema roto hasta que entra el siguiente se fusiona con él o se reescribe.

**7 — Registrar lo que el plan no cubre.** Trabajo que requiere investigación, decisiones aún no tomadas y los pasos cuyo orden depende de una respuesta que nadie ha dado todavía.

## Salida

`implementation-plan.md`, en este orden:

- **1. Entrada y punto de partida** — qué especificación, qué rama o commit, y cuándo
- **2. Puntos de aterrizaje** — una línea por requisito: el requisito, el archivo o módulo, y cómo se localizó
- **3. Interfaces** — los contratos que deben existir primero, cada uno con los pasos que dependen de él
- **4. Pasos** — ordenados; por paso: propósito, archivos tocados, qué deja intacto y el estado del sistema después
- **5. Pruebas** — por paso: las pruebas añadidas, qué comprueban, el comando que las ejecuta
- **6. Puntos de control** — qué debe pasar tras cada paso, y qué hacer cuando no pasa
- **7. Requiere investigación** — requisitos sin punto de aterrizaje localizado, cada uno con la pregunta y quién puede responderla
- **8. Puntos abiertos** — decisiones, accesos e información que el plan está esperando

## Validación

El plan está listo cuando se cumple todo esto:

- Cada requisito de la especificación aparece en la sección 2 o en la sección 7
- Cada paso nombra los archivos que toca, y cada archivo nombrado existe en el punto de partida declarado
- Ningún paso depende de un paso posterior
- Cada paso declara el estado del sistema que deja detrás, y ninguno es `roto`
- Cada paso lleva una prueba o declara por qué no puede llevarla
- No aparece ninguna ruta de archivo que no se haya encontrado en el código

Falla la ejecución si un paso deja la compilación sin poder completarse, o si un requisito se asignó a un archivo que no se pudo abrir.

## Gestión de fallos

- **Sin especificación** — detente. Informa de que no hay nada contra lo que planificar, y de que un plan derivado del código repetiría lo que existe en lugar de lo que se quiere.
- **Sin acceso al código** — produce solo las secciones 1, 3 y 7, marca cada punto de aterrizaje como `sin verificar` y declara que el orden no es fiable hasta que se lean los archivos.
- **La especificación contradice al código** — registra ambos, nombra el archivo y el requisito, y eleva el conflicto a la sección 8 como bloqueante. No lo resuelvas eligiendo el que sea más fácil de construir.
- **Un requisito sin punto de aterrizaje** — lístalo en la sección 7 con la búsqueda que falló. Nunca le inventes un archivo.
- **Acceso parcial** — planifica las partes que se leyeron, marca el resto como `INCOMPLETO — pendiente de acceso a <área>` y entrega. El alcance del plan se declara, no se insinúa.