feat: añadir flujo de desarrollo con ramas y feature flags

Se añaden las reglas y commands para el flujo trunk-based completo:
- fix_issue.md: guía para implementar issues (rama → tests → merge)
- git-branch.md: command para crear ramas issue/<NNNN>-<slug>
- git-push.md: actualizado con flujo de ramas, tests obligatorios y feature flags
- create_issue.md: ajustado formato de numeración a 4 dígitos
- index.md: añadida sección de flujo de desarrollo y regla fix_issue
- CLAUDE.md: referencia a la nueva regla fix_issue
- feature_flags.json: archivo base para flags de despliegue por fases

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

.claude/rules/fix_issue.md

@@ -0,0 +1,122 @@
+# 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.