Files

T

egutierrez 9a77ef59e8 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>

2026-03-07 18:39:43 +00:00

3.7 KiB

Raw Blame History

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:

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:

{
  "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

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:

Commitear los cambios restantes (cierre de issue, README)
Hacer merge --no-ff de la rama a master
Push a remoto
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.

3.7 KiB Raw Blame History