# Regla: Arreglar/implementar un issue existente

Guia para trabajar en un issue de `dev/issues/` y cerrarlo al terminar.
Usa trunk-based development: siempre trabajar en una rama, nunca en master.

## Inputs — preguntar al usuario si no los da

| Input | Requerido | Ejemplo |
|-------|-----------|---------|
| Numero o nombre del issue | si | `0010`, `0010-access-control` |

## Pasos

### 1. Leer el issue

Abrir `dev/issues/<NNNN>-<slug>.md` y entender:
- **Objetivo**: que se quiere lograr
- **Tareas**: lista de tareas a completar
- **Arquitectura**: archivos afectados, que es puro vs impuro

### 2. Crear rama de trabajo

Ejecutar `/git-branch` con el numero y slug del issue:

```
/git-branch
```

Esto crea la rama `issue/<NNNN>-<slug>` desde master actualizado.
**Nunca trabajar directamente en master.**

### 3. Planificar el trabajo

Crear un plan con `TodoWrite` basado en las tareas del issue. Respetar el orden de fases si el issue las define. **Incluir siempre una tarea de tests.**

### 4. Implementar

- Seguir las tareas del issue en orden
- Respetar **pure core / impure shell**: `pkg/` puro, `shell/` impuro
- Marcar cada tarea como completada en el TodoWrite conforme se avanza
- Compilar frecuentemente: `go build -tags goolm ./...`

### 5. Tests — OBLIGATORIO

Toda implementacion debe incluir tests. Antes de cerrar el issue:

- Escribir tests para el codigo nuevo o modificado
- Tests de `pkg/` (puro): tests unitarios directos, sin mocks de I/O
- Tests de `shell/` (impuro): pueden usar mocks/stubs para dependencias externas
- Tests de integracion si el issue lo requiere

Ejecutar:

```bash
go test -tags goolm ./...
```

**No cerrar el issue si los tests no pasan.**

### 6. Feature flags (solo si aplica)

Si el issue es parte de una feature mayor que se despliega en fases, actualizar `dev/feature_flags.json`:

```json
{
  "flags": {
    "nombre-del-flag": {
      "enabled": false,
      "issue": "0020",
      "description": "Descripcion breve de la feature",
      "added": "2026-03-07"
    }
  }
}
```

Incluir el cambio en el commit correspondiente (no crear commit separado solo para flags).

### 7. Verificar

- [ ] `go build -tags goolm ./...` compila sin errores
- [ ] `go test -tags goolm ./...` pasa sin errores
- [ ] Todas las tareas del issue estan implementadas
- [ ] El codigo respeta pure core / impure shell
- [ ] Se escribieron tests para el codigo nuevo/modificado

### 8. Cerrar el issue — OBLIGATORIO al terminar

Al completar todas las tareas del issue, ejecutar estos pasos:

#### 8.1. Mover el archivo a completed

```bash
mv dev/issues/<NNNN>-<slug>.md dev/issues/completed/
```

#### 8.2. Actualizar el README

En `dev/issues/README.md`, cambiar la fila del issue:
- **Link**: de `[<NNNN>-<slug>.md](<NNNN>-<slug>.md)` a `[<NNNN>-<slug>.md](completed/<NNNN>-<slug>.md)`
- **Estado**: de `pendiente` a `completado`

### 9. Integrar y publicar

Ejecutar `/git-push` para:
1. Commitear los cambios restantes (cierre de issue, README)
2. Hacer merge --no-ff de la rama a master
3. Push a remoto
4. Eliminar la rama local

El commit de merge tendra formato: `merge: issue/<NNNN>-<slug> — <titulo>`

## Reglas

- **Leer antes de actuar**: siempre leer el issue completo antes de empezar a implementar.
- **Siempre en rama**: nunca trabajar en master. Usar `/git-branch` al inicio.
- **Siempre tests**: toda implementacion debe tener tests. No cerrar sin tests.
- **No saltear tareas**: implementar todas las tareas del issue, no solo las faciles.
- **Cerrar siempre**: nunca dejar un issue implementado sin moverlo a `completed/`.
- **Pure core / impure shell**: toda implementacion debe respetar el patron.
- **Compilar con goolm**: siempre usar `-tags goolm` en build y test.
- **Feature flags**: solo cuando el issue es parte de algo mayor. No es obligatorio en cada fix.