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.
This commit is contained in:
+34
-9
@@ -20,19 +20,44 @@ Guias operativas para LLMs que trabajan en este codebase. Cada regla describe co
|
||||
- **Crear issue**: cuando el usuario pida crear un nuevo issue, feature request o task. Usa el template en `.claude/templates/issue.md`.
|
||||
- **Arreglar issue**: cuando el usuario pida implementar, arreglar o trabajar en un issue existente. Incluye crear rama (`/git-branch`), implementar las tareas con tests, cerrar el issue, e integrar a master (`/git-push`).
|
||||
|
||||
## Flujo de desarrollo (TBD)
|
||||
## Flujo de desarrollo — Trunk-based development (TBD)
|
||||
|
||||
El proyecto usa trunk-based development. **Nunca trabajar directamente en master.**
|
||||
El proyecto usa TBD estricto. **master** es el unico branch estable y siempre deployable. **Nunca trabajar directamente en master.**
|
||||
|
||||
1. `/git-branch` — crea rama `issue/<NNNN>-<slug>` desde master
|
||||
2. Implementar cambios + tests en la rama
|
||||
3. `/git-push` — merge --no-ff a master, push, cleanup rama
|
||||
```
|
||||
master (trunk) ← siempre deployable
|
||||
↑
|
||||
└── issue/<NNNN>-<slug> ← rama efimera (horas, no dias)
|
||||
├── commit: feat: ...
|
||||
├── commit: test: ...
|
||||
└── commit: docs: ...
|
||||
merge --no-ff → master → push → delete branch
|
||||
```
|
||||
|
||||
Comandos disponibles en `.claude/commands/`:
|
||||
- `git-branch.md` — crear rama de trabajo
|
||||
- `git-push.md` — integrar rama a master y publicar
|
||||
1. `/git-branch` — crea rama `issue/<NNNN>-<slug>` desde master actualizado
|
||||
2. Implementar con commits atomicos por bloque logico (no WIP, no mezclar tipos)
|
||||
3. `/git-push` — tests → merge `--no-ff` a master → push → eliminar rama
|
||||
|
||||
Feature flags opcionales en `dev/feature_flags.json` (solo para features que se despliegan en fases).
|
||||
### Commits
|
||||
|
||||
- Cada commit es **atomico por bloque logico** con prefijo: `feat:`, `fix:`, `test:`, `docs:`, `refactor:`, `chore:`
|
||||
- Titulo corto + cuerpo largo en español
|
||||
- **No WIP**: nunca commitear "wip", "tmp", codigo a medias
|
||||
- **No squash**: `--no-ff` preserva commits; `git log --first-parent` da vista limpia
|
||||
- **No rebase -i**: commits limpios desde el inicio
|
||||
|
||||
### Feature flags (para features multi-issue)
|
||||
|
||||
Cuando una feature no cabe en una sola rama corta, desglosar en sub-issues. Cada sub-issue mergea codigo **completo y testeado** protegido por un feature flag (desactivado). **Feature flag ≠ WIP** — un flag protege codigo terminado, no codigo a medias.
|
||||
|
||||
Archivo: `dev/feature_flags.json`
|
||||
|
||||
### Comandos
|
||||
|
||||
- `/git-branch` — crear rama de trabajo (`.claude/commands/git-branch.md`)
|
||||
- `/git-push` — integrar rama a master y publicar (`.claude/commands/git-push.md`)
|
||||
|
||||
Filosofia completa documentada en `CLAUDE.md` seccion "Trunk-based development".
|
||||
|
||||
## Principio general
|
||||
|
||||
|
||||
Reference in New Issue
Block a user