docs: añadir comando /fix-issue para flujo de implementacion de issues

Nuevo comando slash que ejecuta de punta a punta el flujo de
implementacion y cierre de un issue, siguiendo estrictamente la
regla fix_issue.md. Incluye:

- Resolucion del issue por numero o slug
- Lectura del issue y extraccion de tareas
- Creacion de rama con /git-branch
- Planificacion con TodoWrite
- Implementacion con compilacion frecuente
- Tests obligatorios antes de cerrar
- Evaluacion de feature flags si aplica
- Cierre del issue (mover a completed/, actualizar README)
- Integracion a master con /git-push

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

.claude/commands/fix-issue.md

@@ -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.