merge: issue/0020-fix-issue-command — comando /fix-issue para implementar issues
This commit is contained in:
@@ -0,0 +1,85 @@
|
||||
# Command: fix issue
|
||||
|
||||
Ejecuta de punta a punta el flujo de implementacion/cierre de un issue siguiendo **estrictamente** la regla `fix_issue.md`.
|
||||
|
||||
## Inputs
|
||||
|
||||
Se necesita el issue objetivo. Si no se proporciona, preguntar.
|
||||
|
||||
- `issue`: numero o nombre (ej: `0010` o `0010-access-control`)
|
||||
|
||||
## Flujo obligatorio
|
||||
|
||||
1. Resolver el issue objetivo:
|
||||
|
||||
- Si viene solo numero (`0010`), buscar `dev/issues/0010-*.md`.
|
||||
- Si viene slug completo (`0010-access-control`), usar `dev/issues/0010-access-control.md`.
|
||||
- Si no existe en `dev/issues/`, **STOP** e informar al usuario.
|
||||
- Si ya esta en `dev/issues/completed/`, **STOP** e informar al usuario.
|
||||
|
||||
2. Leer completo el issue y extraer:
|
||||
|
||||
- objetivo
|
||||
- tareas/fases
|
||||
- arquitectura y limites (pure core / impure shell)
|
||||
|
||||
3. Crear rama de trabajo usando `/git-branch`:
|
||||
|
||||
```text
|
||||
/git-branch
|
||||
```
|
||||
|
||||
Usar formato `issue/<NNNN>-<slug>` y nunca trabajar en `master`.
|
||||
|
||||
4. Planificar con `TodoWrite`:
|
||||
|
||||
- Crear plan basado en las tareas del issue.
|
||||
- Respetar el orden de fases.
|
||||
- Incluir siempre una tarea de tests.
|
||||
|
||||
5. Implementar el issue completo:
|
||||
|
||||
- Ejecutar tareas en orden.
|
||||
- Respetar pure core / impure shell (`pkg/` puro, `shell/` impuro).
|
||||
- Compilar frecuentemente: `go build -tags goolm ./...`.
|
||||
- Marcar progreso en `TodoWrite` al completar cada bloque.
|
||||
|
||||
6. Tests obligatorios:
|
||||
|
||||
```bash
|
||||
go test -tags goolm ./...
|
||||
```
|
||||
|
||||
- Si falla, corregir antes de continuar.
|
||||
- No cerrar el issue sin tests pasando.
|
||||
|
||||
7. Feature flags (si aplica):
|
||||
|
||||
- Evaluar si es feature multi-issue o despliegue gradual.
|
||||
- Si aplica, actualizar `dev/feature_flags.json` en el commit correspondiente.
|
||||
- No usar flags para esconder codigo incompleto.
|
||||
|
||||
8. Cerrar el issue al terminar:
|
||||
|
||||
```bash
|
||||
mv dev/issues/<NNNN>-<slug>.md dev/issues/completed/
|
||||
```
|
||||
|
||||
Actualizar `dev/issues/README.md`:
|
||||
|
||||
- Link a `completed/<NNNN>-<slug>.md`
|
||||
- Estado a `completado`
|
||||
|
||||
9. Integrar/publicar con `/git-push`:
|
||||
|
||||
```text
|
||||
/git-push
|
||||
```
|
||||
|
||||
## Reglas criticas
|
||||
|
||||
- Seguir `fix_issue.md` de forma estricta.
|
||||
- No saltear tareas del issue.
|
||||
- No hacer commits WIP.
|
||||
- Commits atomicos por bloque logico (`feat:`, `fix:`, `test:`, `docs:`, `refactor:`, `chore:`).
|
||||
- Siempre usar `-tags goolm` en build/test.
|
||||
Reference in New Issue
Block a user