repo_Claude/.claude/commands/git-push.md

Command: git push (TBD)

Integra cambios a master y publica. Soporta ramas issue/* y quick/*.

La fase final (pull --rebase master + merge --no-ff + git push + git branch -d) la hace tbd_branch_finish_bash_infra del registry. Tests y commits no los hace la función — los corre el asistente porque dependen del stack.

Pasos del asistente

1. Verificar rama actual y estado

git branch --show-current
git status --short

Si estamos en issue/* o quick/*

Continuar al paso 2.

Si estamos en master con cambios pendientes

Crear rama primero:

1. Preguntar si el cambio está asociado a un issue.
2. Si es issue: pedir <NNNN> y <slug>, llamar /git-branch issue <NNNN> <slug>.
3. Si es quick: pedir <slug>, llamar /git-branch quick <slug>.

No inventar números de issue. Solo usar issue/ si existe en dev/issues/.

Si estamos en master sin cambios

STOP: nada que publicar.

2. Revisar cambios y crear commits atómicos

git status --short
git diff --stat
git diff

Crear commits atómicos por bloque lógico. Cada commit agrupa cambios de la misma naturaleza:

git add <archivos_del_bloque_1>
git commit -m "<tipo>: <resumen breve>" -m "Descripción larga en español: qué cambia, por qué, impacto, alcance."

git add <archivos_del_bloque_2>
git commit -m "<tipo>: <resumen breve>" -m "Descripción larga en español."

Reglas críticas:

• No WIP: nunca commitear "wip", "tmp", código a medias.
• No mezclar tipos: no combinar feat: + test: en un mismo commit.
• No squash: los commits individuales se preservan via --no-ff. Usar git log --first-parent master para ver merges.
• No rebase interactivo.

3. Ejecutar tests

Obligatorio antes de mergear. Comando depende del stack:

Stack	Comando
Go	go test ./... (o con tags si aplica: -tags goolm / -tags fts5)
C++	ctest --test-dir cpp/build
Python	pytest
Sin tests aplicables (solo docs/config)	indicar al usuario y continuar

Si fallan → STOP y corregir. Si pasan → paso 4.

4. Evaluar feature flags

Feature flag = código terminado y testeado, no código a medias.

Si se modificó dev/feature_flags.json o el cambio es parte de feature multi-fase:

1. Verificar que dev/feature_flags.json esté actualizado.
2. Confirmar estado correcto del flag (enabled: true/false).
3. Incluir el archivo en el commit correspondiente (no commit separado).

Si autocontenido, saltar.

5. Cerrar la rama (registry)

source /home/lucas/fn_registry/bash/functions/infra/tbd_branch_finish.sh
tbd_branch_finish "<descripción corta del merge>"

La función:

• Verifica working tree limpio.
• Autodetecta master/main.
• git checkout <base> + git pull --rebase.
• git merge --no-ff <rama> -m "merge: <rama> — <título>".
• Si conflicto → exit 2, deja al usuario resolver con git add + git commit + retry.
• git push.
• git branch -d <rama>.

6. Confirmar al usuario

La función ya imprime Rama '<rama>' integrada a <base> y publicada. Rama local eliminada. Repetirlo al usuario.

Convención de commits

• feat: nueva funcionalidad
• fix: corrección de error
• refactor: cambio estructural sin cambio funcional
• docs: documentación
• chore: mantenimiento
• test: tests nuevos o modificados
• merge: commit de merge (lo genera tbd_branch_finish con --no-ff)

Regla de mensajes

• Título corto resume el bloque.
• Cuerpo en español: qué se cambió, por qué, qué impacto, qué no se tocó.

Checklist

• Cambios commiteados en rama issue/* o quick/*.
• Cambios distintos en commits diferentes.
• Cada commit con descripción larga en español.
• Tests pasando (o no aplican).
• Feature flags evaluados (o no aplican).
• tbd_branch_finish ejecutado con éxito.

Para tocar la lógica de cierre

Editar tbd_branch_finish_bash_infra en bash/functions/infra/tbd_branch_finish.sh. La parte de tests y commits se queda en este comando porque depende del stack.