egutierrez
b6af7a0c7e
Simplifica el flujo de fix-issue para crear la rama directamente con git checkout -b en lugar de invocar /git-branch, que añadía una capa de indirección innecesaria. Añade lógica para detectar si ya estamos en la rama correcta y continuar sin recrearla.
96 lines
2.4 KiB
Markdown
96 lines
2.4 KiB
Markdown
# 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 (inline, sin invocar `/git-branch`):
|
|
|
|
Verificar la rama actual:
|
|
|
|
```bash
|
|
git branch --show-current
|
|
```
|
|
|
|
- Si ya estamos en `issue/<NNNN>-<slug>` que coincide con el issue → continuar directamente a paso 4.
|
|
- Si estamos en `master` o cualquier otra rama → crear la rama:
|
|
|
|
```bash
|
|
git checkout master
|
|
git pull --rebase
|
|
git checkout -b issue/<NNNN>-<slug>
|
|
```
|
|
|
|
Nunca trabajar directamente 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. |