docs: documentar TBD, feature flags y convenciones de commits en reglas

Añade documentación completa del flujo trunk-based development a todos
los archivos de reglas y comandos del proyecto:

- CLAUDE.md: sección completa de TBD con flujo, commits, ramas y feature flags
- git-branch.md: sección de features multi-issue y reglas de commits
- git-push.md: reglas críticas de commits (no WIP, no squash, no rebase -i)
- create_issue.md: guía de desglose en sub-issues con feature flags
- fix_issue.md: cuándo usar/no usar feature flags, flujo multi-issue
- index.md: resumen expandido del flujo TBD con commits y flags

Impacto: todas las reglas ahora documentan consistentemente el flujo
de desarrollo, convenciones de commits y uso de feature flags.

.claude/commands/git-push.md

@@ -41,7 +41,7 @@ git diff --stat
 git diff
 ```
 
-Si hay cambios de distinta naturaleza, crear varios commits separados por bloque logico:
+Crear commits **atomicos por bloque logico**. Cada commit agrupa cambios de la misma naturaleza:
 
 ```bash
 git add <archivos_del_bloque_1>
@@ -51,6 +51,12 @@ git add <archivos_del_bloque_2>
 git commit -m "<tipo>: <resumen breve>" -m "Descripcion larga en espanol."
 ```
 
+**Reglas criticas de commits:**
+- **No WIP**: nunca commitear "wip", "tmp", "fix fix" ni codigo a medias. Cada commit debe ser atomico y completo.
+- **No mezclar tipos**: no combinar `feat:` + `test:` en un mismo commit. Separar por bloque logico.
+- **No squash**: los commits individuales se preservan en master via `--no-ff`. Usar `git log --first-parent master` para ver solo merge commits.
+- **No rebase interactivo**: si los commits ya son limpios, no reescribir historia.
+
 ### 3. Ejecutar tests
 
 **Obligatorio antes de mergear.** Si el proyecto tiene tests, ejecutarlos:
@@ -65,13 +71,15 @@ go test -tags goolm ./...
 
 ### 4. Evaluar feature flags
 
+Feature flags se usan cuando el issue es **parte de una feature multi-issue** o el cambio tiene riesgo y necesita poder desactivarse. **Feature flag ≠ WIP** — un flag protege codigo terminado y testeado, no codigo a medias.
+
 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.
+Si el issue es autocontenido (se completa en esta rama), no necesita flag. Saltar este paso.
 
 ### 5. Actualizar master y hacer merge --no-ff