Tasks

---
name: tasks
description: Divide un plan aprobado en tareas pequeñas, ordenadas y verificables (tasks.md). Úsala con /tasks NNN o cuando el usuario pida desglosar un plan en tareas.
---

# /tasks — De plan a tareas ejecutables

Cuarto paso del flujo:

```
/init → /specify → /plan → [/tasks] → /analyze → /implement → /review → /release
```

> Antes de actuar, lee el contrato común del flujo: `../../shared/contract.md` (relativo a este
> archivo). Si algo aquí lo contradice, prevalece el contrato.

Convierte un plan aprobado en una lista de tareas que `/implement` pueda ejecutar **una por una,
sin tener que tomar decisiones de diseño**. Si una tarea obliga a decidir algo que el plan no dice,
el problema está en el plan.

## Uso

```
/tasks <NNN|slug>
/tasks                  # toma el plan approved más antiguo sin tasks.md
/tasks <NNN> --fix A5,A7        # corrige solo las tareas que piden esos hallazgos (lo habitual)
/tasks <NNN> --fix T047,T065     # o las tareas indicadas, tras un /plan --fix
/tasks <NNN> --redo             # regenera conservando las tareas ya hechas
```

## Reglas

- **No escribas código** ni modifiques la spec o el plan.
- **Cada tarea es pequeña:** toca de 1 a 3 archivos y se completa en una sesión corta. Si no,
  divídela. Excepción: lo que **genera un comando** (plataformas nativas, código de un esquema,
  plantilla del framework) se declara como la ruta seguida de `(generado por <comando>)`, p. ej.
  `android/ (generado por npx cap add android)`, y cuenta como un archivo; se revisa el comando,
  no cada archivo (`review-pack` lo deja fuera del diff).
- **Cada tarea es verificable:** tiene un criterio de hecho observable (un test que pasa, un
  comando que funciona, un archivo que existe con cierto contenido).
- **Nada fuera del plan.** Si falta algo para cumplir la spec, detente y sugiere `/plan --redo`.
- **Nunca apruebes por tu cuenta.** `tasks.md` nace en `draft`.
- Escribe en el idioma del proyecto.

---

## Paso 0 — Precondiciones

1. Si no existe `.ai/project.yaml`, detente y sugiere `/init`.
2. La spec debe estar `approved` y su `plan.md` en `status: approved`.
   - Plan en `draft` → sugiere aprobarlo.
   - Plan en `blocked` → detente: hay una violación de la constitución sin resolver.
3. Si ya existe `tasks.md` y no vino `--redo`, muestra su avance y pregunta si regenerarlo.

## Paso 1 — Contexto

Lee la spec (criterios `CA1`, `CA2`…), el plan completo (Cambios por módulo, Contratos y datos,
Estrategia de pruebas, Trazabilidad, Rollout, Impacto en arquitectura), `docs/constitution.md`
(sobre todo la estrategia de testing) y `.ai/project.yaml`. Usa la plantilla de
`docs/templates/tasks.md`.

## Paso 2 — Desglose

Genera tareas a partir del plan, en este orden de fases:

| Fase | Contenido | Fuente en el plan |
|---|---|---|
| Preparación | Dependencias, configuración, flags, migración *expand* | Decisiones, Rollout |
| Tests | Tests que fallan y describen el comportamiento esperado | Trazabilidad, Estrategia de pruebas |
| Implementación | Cambios en código, módulo por módulo | Cambios por módulo, Contratos y datos |
| Integración y documentación | Cableado final, T090–T092 | Impacto en arquitectura |
| Despliegue | T095–T098 (las ejecuta `/release`) | Rollout |

**Seguridad:** por cada amenaza `TM#` del plan, una tarea de test (en la fase Tests) y una de
control (en Implementación); por cada `CA (abuso)`, al menos un test. Los controles no se agrupan
en una tarea genérica tipo "añadir seguridad": cada uno va junto al módulo que protege.

**Orden de tests e implementación:**
- Si la constitución exige TDD: cada tarea de implementación depende de la tarea de test que
  cubre su criterio, y el test se escribe primero.
- Si no: el test puede ir en la misma tarea que la implementación, pero nunca después de la fase
  de Integración.

**Specs con varias historias de usuario:** si las historias pueden entregarse por separado,
agrupa Tests e Implementación por historia (`### Historia 1: …`), de modo que al terminar cada
grupo haya algo funcionando y probado.

**Formato de cada tarea:**

```
- [ ] T012 [P] <verbo + qué> — <archivos> — hecho cuando: <criterio> — cubre: CA2 — depende: T010
```

- `T###`: T001–T089 para el trabajo; **T090–T099 están reservadas** para las tareas fijas de la
  plantilla. Si necesitas más de 89 tareas, la spec es demasiado grande: sugiere dividirla.
- `[P]`: puede ejecutarse en paralelo con las demás `[P]` de su grupo una vez cumplidas sus
  dependencias, porque no comparte archivos con ninguna otra tarea abierta.
- `cubre`: los criterios de aceptación que la tarea ayuda a cumplir (omitir en tareas de soporte).
- `depende`: solo si hay dependencia real; si no, se asume el orden de la lista.
- `verificación manual:` dentro de `hecho cuando:` cuando la Trazabilidad del plan la pide para un
  criterio que cubre la tarea: `hecho cuando: T010 pasa · verificación manual: pantalla a 390 y
  1440 px contra el diseño`. Va en la tarea que construye la pieza, para detectar el fallo ahí.
- Una tarea que ya no aplica no se borra si está hecha o empezada: se marca
  `- [-] T0xx … — obsoleta: <motivo> (AAAA-MM-DD)` (contrato → "Tareas obsoletas").

## Paso 3 — Cobertura

Construye y comprueba estas dos tablas (van al final de `tasks.md`):

```markdown
## Cobertura
| Criterio | Tarea(s) de test | Tarea(s) de implementación |
|---|---|---|
| CA1 | T010 | T020, T021 |

| Cambio del plan (módulo) | Tarea(s) |
|---|---|
| src/notifications | T020, T022 |
```

- Todo `CA` de la spec necesita al menos una tarea de test y una de implementación.
- Todo módulo de "Cambios por módulo" necesita al menos una tarea.
- Toda amenaza `TM#` necesita una tarea de control y una de test (tabla de amenazas de la plantilla).
- Toda tarea de implementación debe poder rastrearse a un cambio del plan. Si no, sobra o el plan
  está incompleto.
- Toda `verificación manual:` de la Trazabilidad del plan va en la tarea que construye esa pieza;
  solo las que exigen staging, dispositivo físico o tienda van como sub-punto de T095 (qué se
  comprueba, dónde y el resultado esperado). Todo requisito no funcional tiene fila en la tabla de
  RNF (test o verificación manual).
- Todo principio ✅ del Constitution Check del plan con `test:` o `lint:` tiene una tarea que crea
  o ejecuta esa comprobación.
- Si el `design.md` de la spec (o el plan) tiene "Cambios a incorporar al sistema", la **primera** tarea actualiza
  `docs/design/system.md` y `system.html`; las tareas de UI `depende:` de ella y su `verificación
  manual:` compara con la composición elegida (`docs/specs/NNN-<slug>/design/opcion-<x>.html`) o
  `system.html`, en los anchos de `design.widths` (y el intermedio si `design.md` lo pide).

## Paso 4 — Constitution Check

Revisa las tareas contra cada principio (no repitas el análisis del plan; busca lo que el
desglose pudo romper). Ejemplos: una tarea que agrega una dependencia sin su ADR, tests puestos
después de la implementación cuando se exige TDD, una migración destructiva antes del deploy.
Registra el resultado en la sección "Constitution Check" con el mismo formato que el plan
(✅ / ➖ / ❌). Un ❌ se corrige reordenando o dividiendo tareas; si no se puede, detente.

## Paso 5 — Autoverificación

- [ ] Todas las tareas tienen archivos y criterio de hecho.
- [ ] Ninguna tarea toca más de 3 archivos.
- [ ] Las marcas `[P]` no comparten archivos entre sí.
- [ ] No hay dependencias circulares.
- [ ] Tablas de cobertura completas.
- [ ] T090–T098 presentes.
- [ ] Cada `TM#` y cada `CA (abuso)` con sus tareas.
- [ ] Las tareas que actualizan `security.md`, `observability.md` o `deployment.md` cambian el
      estado **por corrección** (`RS1.a → mitigada`), nunca el riesgo completo si alguna corrección
      queda fuera.
- [ ] Tras escribir, `python .ai/bin/aidd.py validate docs/specs/NNN-<slug>` (o `python3`) sin errores (el script revisa
      formato, rangos, dependencias, ciclos y cobertura).

## Paso 6 — Escritura y aprobación

1. Escribe `docs/specs/NNN-<slug>/tasks.md` con `status: draft`.
2. Muestra al usuario: número de tareas por fase, cuántas son paralelizables, la ruta crítica
   (cadena de dependencias más larga) y cualquier tarea de riesgo alto.
3. Pregunta si lo aprueba:
   - **Aprueba** → `status: approved`.
   - **Pide cambios** → aplica, repite el Paso 5 y vuelve a preguntar.

Siguiente paso sugerido: `/analyze NNN` (idealmente antes de aprobar las tareas) y después
`/implement NNN`.

---

## Modo `--redo`

- Conserva tal cual las tareas marcadas `[x]` y su número.
- Las tareas pendientes sin empezar que ya no tengan sentido con el nuevo plan se eliminan; las
  hechas o empezadas se marcan `[-]` con `obsoleta:` y motivo. Las nuevas toman números libres
  (nunca reutilices un número de una tarea eliminada u obsoleta).
- Si una tarea hecha contradice el nuevo plan, añade una tarea para revertirla o adaptarla y
  avísale al usuario.
- **Versión anterior:** antes de regenerar, archívala con
  `python .ai/bin/aidd.py rotate docs/specs/NNN-<slug> tasks` (copia a `history/tasks.v<N>.md`).
  Las versiones archivadas no se borran; ninguna skill las lee.

## Modo `--fix <IDs>`

Corrige solo lo indicado: hallazgos de `analysis.md` (`A…`) o tareas concretas (`T…`, p. ej. las
que lista `/plan --fix`).

1. Edita en su lugar las tareas afectadas (descripción, archivos, criterio de hecho, `cubre`,
   `depende`). No renumeres ni reescribas las demás.
2. Las tareas nuevas toman números libres; las que sobran se eliminan si no se empezaron, o se
   marcan `[-]` con `obsoleta:` y motivo si están hechas o empezadas. Nunca reutilices un número.
3. Actualiza solo las filas afectadas de las tablas de Cobertura y del Constitution Check.
4. Muestra el diff por hallazgo o tarea, repite la autoverificación (Paso 5) y el validador.
   `tasks.md` vuelve a `draft` si estaba `approved`.

Si la corrección obliga a reordenar fases o cambia más de ~30 % de las tareas, propone `--redo`.