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/commands/git-push.md

@@ -1,75 +1,140 @@
 # Command: git push
 
-Usa este comando para cerrar una tarea completa con sincronización, commits por bloques de cambio y publicación al remoto.
+Integra cambios a master y publica. Soporta dos flujos segun la rama actual.
 
 ## Flujo obligatorio
 
-1. Verificar rama y estado:
+### 1. Verificar rama actual y estado
 
 ```bash
 git branch --show-current
 git status --short
 ```
 
-2. Sincronizar antes de preparar commits (stash para proteger cambios locales):
+#### Si estamos en una rama `issue/*`
+
+Continuar directamente al paso 2.
+
+#### Si estamos en `master` con cambios pendientes
+
+Crear una rama automaticamente antes de continuar:
+
+1. Preguntar al usuario un nombre descriptivo si no es obvio por los cambios.
+2. Determinar el siguiente numero de issue disponible (buscar en `dev/issues/` y `dev/issues/completed/`).
+3. Crear la rama:
 
 ```bash
-git stash
-git pull --rebase
-git stash pop
+git checkout -b issue/<NNNN>-<slug>
 ```
 
-Si `git stash` reporta "No local changes to save", continuar directo con `git pull --rebase` (sin stash pop).
+4. Continuar al paso 2 con los cambios ya en la rama nueva.
 
-3. Revisar cambios y separarlos por tema:
+#### Si estamos en `master` sin cambios
+
+**STOP**: no hay nada que publicar.
+
+### 2. Revisar cambios y crear commits por bloque
 
 ```bash
+git status --short
 git diff --stat
 git diff
 ```
 
-4. Si hay cambios de distinta naturaleza, crear varios commits:
-
-- Commit 1: refactor/código
-- Commit 2: documentación
-- Commit 3: reglas/configuración
-
-Comandos sugeridos:
+Si hay cambios de distinta naturaleza, crear varios commits separados por bloque logico:
 
 ```bash
 git add <archivos_del_bloque_1>
-git commit -m "<tipo>: <resumen breve>" -m "Descripción larga en español explicando qué cambia, por qué se hizo, impacto esperado y alcance del bloque."
+git commit -m "<tipo>: <resumen breve>" -m "Descripcion larga en espanol explicando que cambia, por que se hizo, impacto esperado y alcance del bloque."
 
 git add <archivos_del_bloque_2>
-git commit -m "<tipo>: <resumen breve>" -m "Descripción larga en español explicando qué cambia, por qué se hizo, impacto esperado y alcance del bloque."
+git commit -m "<tipo>: <resumen breve>" -m "Descripcion larga en espanol."
 ```
 
-5. Publicar commits:
+### 3. Ejecutar tests
+
+**Obligatorio antes de mergear.** Si el proyecto tiene tests, ejecutarlos:
+
+```bash
+go test -tags goolm ./...
+```
+
+- Si los tests **fallan** → **STOP**: corregir antes de continuar. No mergear codigo roto.
+- Si los tests **pasan** → continuar al paso 4.
+- Si no hay tests aplicables (e.g. solo cambios de docs/config) → indicar al usuario y continuar.
+
+### 4. Evaluar feature flags
+
+Si se modifico `dev/feature_flags.json` o si los cambios son parte de una feature que se despliega en fases:
+
+1. Verificar que `dev/feature_flags.json` existe y esta actualizado.
+2. Confirmar que el flag correspondiente tiene el estado correcto (`enabled: true/false`).
+3. Incluir el archivo en el commit correspondiente (no crear commit separado solo para flags).
+
+Si no aplican feature flags, saltar este paso.
+
+### 5. Actualizar master y hacer merge --no-ff
+
+```bash
+git checkout master
+git pull --rebase
+git merge --no-ff issue/<NNNN>-<slug> -m "merge: issue/<NNNN>-<slug> — <titulo breve>"
+```
+
+El merge commit debe tener formato:
+- Titulo: `merge: issue/<NNNN>-<slug> — <descripcion corta>`
+- Cuerpo (opcional): resumen de lo que entra
+
+Si hay conflictos durante el merge:
+1. Resolver los conflictos
+2. `git add` los archivos resueltos
+3. `git commit` (sin -m, para mantener el mensaje de merge)
+
+### 6. Push a remoto
 
 ```bash
 git push
 ```
 
-## Convención de commits
+### 7. Limpiar rama local
+
+```bash
+git branch -d issue/<NNNN>-<slug>
+```
+
+### 8. Confirmar al usuario
+
+```
+Rama `issue/<NNNN>-<slug>` integrada a master y publicada.
+Rama local eliminada.
+```
+
+## Convencion de commits
 
 - `feat:` nueva funcionalidad
-- `fix:` corrección de error
+- `fix:` correccion de error
 - `refactor:` cambio estructural sin cambio funcional
-- `docs:` documentación
+- `docs:` documentacion
 - `chore:` mantenimiento
+- `test:` tests nuevos o modificados
+- `merge:` commit de merge (generado por --no-ff)
 
 ## Regla de mensajes
 
-- El título (`-m` corto) debe resumir el bloque.
-- El cuerpo (`-m` largo) debe estar en español y explicar:
-	- qué se cambió,
-	- por qué se cambió,
-	- qué impacto tiene,
-	- qué no se tocó.
+- El titulo (`-m` corto) debe resumir el bloque.
+- El cuerpo (`-m` largo) debe estar en espanol y explicar:
+  - que se cambio,
+  - por que se cambio,
+  - que impacto tiene,
+  - que no se toco.
 
-## Checklist rápido
+## Checklist rapido
 
-- [ ] `git stash` + `git pull --rebase` + `git stash pop` ejecutado sin conflictos.
+- [ ] Todos los cambios estan commiteados en una rama `issue/*`.
 - [ ] Se separaron cambios distintos en commits diferentes.
-- [ ] Cada commit tiene descripción larga en español.
+- [ ] Cada commit tiene descripcion larga en espanol.
+- [ ] Tests ejecutados y pasando (o no aplican).
+- [ ] Feature flags evaluados (o no aplican).
+- [ ] `git merge --no-ff` ejecutado desde master.
 - [ ] `git push` ejecutado correctamente.
+- [ ] Rama local eliminada.