| name | registrar-implementacion |
| description | Registra en docs/gestion/registro-de-implementaciones.md una unidad de trabajo terminada y fusionada, con su requisito, su Pull Request y su prueba. Úsala al fusionar un PR a develop o cuando el usuario diga que terminó una funcionalidad. |
Registrar una implementación
Convierte "ya está listo" en evidencia verificable: qué requisito quedó cubierto, con qué PR y con qué
prueba. Es el insumo directo de la matriz de trazabilidad y del Capítulo IV del informe.
Cuándo usar esto
Cuando un Pull Request se fusiona a develop. No antes — el código en una rama de trabajo todavía
puede cambiar o descartarse.
Paso 1 — Verificar la definición de terminado
Antes de escribir la fila, comprueba (docs/gestion/README.md, sección Definición de terminado):
Si algo falta, dilo y no registres la fila. Registrar como terminado lo que no lo está vuelve
inútil la métrica de cobertura del Capítulo IV.
Paso 2 — Localizar el requisito
Busca el id en docs/product-requirements.md.
- Si no existe un requisito que cubra lo implementado, hay un problema real: o se construyó algo
fuera de alcance, o falta escribir el requisito. Señálalo antes de continuar; no inventes un id.
- Si el requisito quedó cubierto solo en parte, dilo en la columna "Qué" en vez de darlo por
completo.
Paso 3 — Escribir la fila
En la tabla del sprint en curso de docs/gestion/registro-de-implementaciones.md:
| RF0NN | M<N> | <qué quedó funcionando, en pasado> | D<N> | #<PR> | <nombre de la prueba> |
Después actualiza la tabla Estado de cobertura de requisitos al final del archivo.
Paso 4 — Efectos colaterales
| Si la implementación… | Entonces |
|---|
| Cambió una decisión de diseño | Nuevo ADR con la skill registrar-decision |
| Reveló un hecho que costó descubrir | Línea en MEMORY.md |
| Reveló que un requisito estaba mal escrito | Corrige docs/product-requirements.md y dilo |
| Tocó el backend | Verifica las capas con la skill verificar-arquitectura |
Reglas de escritura
- En pasado y concreto.
Endpoint POST /api/reportes con rate limiting por dispositivo en Redis,
no avance en el módulo de reportes.
- La prueba se nombra.
RegistrarReporteServiceTest, reporte.spec.ts. "Probado manualmente" no
es una prueba: es un recuerdo.
- Una fila por unidad entregada, no una por commit ni una por sprint.
Efecto en la Sala de control
Esta fila alimenta la Sala de control (docs/gestion/README.md), que se regenera sola en cada push a
develop — el HTML no se edita a mano. Si el PR además cerró un compromiso del sprint, marca su
docs/gestion/sprint-N.md §2, con ✅/🟡 al inicio del Entregable: sin eso
el tablero seguirá diciendo que el trabajo está sin empezar, y el avance del proyecto saldrá más bajo
de lo que es.
