chore: sync local config — caveman plugin, command/skill tweaks
- settings.json: enable caveman marketplace+plugin, effortLevel=high - commands/git-branch + git-push: refactor docs - skills/parallel-fix-issues: SKILL.md + scripts updates
This commit is contained in:
@@ -1,8 +1,10 @@
|
||||
# Command: git push
|
||||
# Command: git push (TBD)
|
||||
|
||||
Integra cambios a master y publica. Soporta ramas `issue/*` y `quick/*`.
|
||||
|
||||
## Flujo obligatorio
|
||||
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
|
||||
|
||||
@@ -11,34 +13,24 @@ git branch --show-current
|
||||
git status --short
|
||||
```
|
||||
|
||||
#### Si estamos en una rama `issue/*` o `quick/*`
|
||||
#### Si estamos en `issue/*` o `quick/*`
|
||||
|
||||
Continuar directamente al paso 2.
|
||||
Continuar al paso 2.
|
||||
|
||||
#### Si estamos en `master` con cambios pendientes
|
||||
#### Si estamos en master con cambios pendientes
|
||||
|
||||
Crear una rama automaticamente antes de continuar:
|
||||
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>`.
|
||||
|
||||
1. Preguntar al usuario: **¿Este cambio esta asociado a un issue existente?**
|
||||
2. **Si es un issue**: pedir el numero y slug, crear rama `issue/<NNNN>-<slug>`.
|
||||
3. **Si NO es un issue**: pedir un slug descriptivo, crear rama `quick/<slug>`.
|
||||
**No inventar números de issue.** Solo usar `issue/` si existe en `dev/issues/`.
|
||||
|
||||
```bash
|
||||
# Para issues:
|
||||
git checkout -b issue/<NNNN>-<slug>
|
||||
# Para cambios rapidos:
|
||||
git checkout -b quick/<slug>
|
||||
```
|
||||
#### Si estamos en master sin cambios
|
||||
|
||||
4. Continuar al paso 2 con los cambios ya en la rama nueva.
|
||||
**STOP**: nada que publicar.
|
||||
|
||||
**IMPORTANTE**: No inventar numeros de issue. Solo usar `issue/` si el issue existe en `dev/issues/`.
|
||||
|
||||
#### Si estamos en `master` sin cambios
|
||||
|
||||
**STOP**: no hay nada que publicar.
|
||||
|
||||
### 2. Revisar cambios y crear commits por bloque
|
||||
### 2. Revisar cambios y crear commits atómicos
|
||||
|
||||
```bash
|
||||
git status --short
|
||||
@@ -46,112 +38,90 @@ git diff --stat
|
||||
git diff
|
||||
```
|
||||
|
||||
Crear commits **atomicos por bloque logico**. Cada commit agrupa cambios de la misma naturaleza:
|
||||
Crear commits atómicos por bloque lógico. Cada commit agrupa cambios de la misma naturaleza:
|
||||
|
||||
```bash
|
||||
git add <archivos_del_bloque_1>
|
||||
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 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 "Descripcion larga en espanol."
|
||||
git commit -m "<tipo>: <resumen breve>" -m "Descripción larga en español."
|
||||
```
|
||||
|
||||
**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.
|
||||
**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.** Si el proyecto tiene tests, ejecutarlos:
|
||||
Obligatorio antes de mergear. Comando depende del stack:
|
||||
|
||||
```bash
|
||||
go test -tags goolm ./...
|
||||
```
|
||||
| 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 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.
|
||||
Si fallan → **STOP** y corregir. Si pasan → paso 4.
|
||||
|
||||
### 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.
|
||||
Feature flag = código terminado y testeado, **no** código a medias.
|
||||
|
||||
Si se modifico `dev/feature_flags.json` o si los cambios son parte de una feature que se despliega en fases:
|
||||
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).
|
||||
|
||||
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 autocontenido, saltar.
|
||||
|
||||
Si el issue es autocontenido (se completa en esta rama), no necesita flag. Saltar este paso.
|
||||
|
||||
### 5. Actualizar master y hacer merge --no-ff
|
||||
### 5. Cerrar la rama (registry)
|
||||
|
||||
```bash
|
||||
git checkout master
|
||||
git pull --rebase
|
||||
git merge --no-ff <rama> -m "merge: <rama> — <titulo breve>"
|
||||
source /home/lucas/fn_registry/bash/functions/infra/tbd_branch_finish.sh
|
||||
tbd_branch_finish "<descripción corta del merge>"
|
||||
```
|
||||
|
||||
El merge commit debe tener formato:
|
||||
- Titulo: `merge: <rama> — <descripcion corta>`
|
||||
- Cuerpo (opcional): resumen de lo que entra
|
||||
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>`.
|
||||
|
||||
Ejemplos:
|
||||
- `merge: issue/0021-threads-default-config — habilitar threads en agentes`
|
||||
- `merge: quick/fix-typo-readme — corregir typo en README`
|
||||
### 6. Confirmar al usuario
|
||||
|
||||
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)
|
||||
La función ya imprime `Rama '<rama>' integrada a <base> y publicada. Rama local eliminada.` Repetirlo al usuario.
|
||||
|
||||
### 6. Push a remoto
|
||||
|
||||
```bash
|
||||
git push
|
||||
```
|
||||
|
||||
### 7. Limpiar rama local
|
||||
|
||||
```bash
|
||||
git branch -d <rama>
|
||||
```
|
||||
|
||||
### 8. Confirmar al usuario
|
||||
|
||||
```
|
||||
Rama `<rama>` integrada a master y publicada.
|
||||
Rama local eliminada.
|
||||
```
|
||||
|
||||
## Convencion de commits
|
||||
## Convención de commits
|
||||
|
||||
- `feat:` nueva funcionalidad
|
||||
- `fix:` correccion de error
|
||||
- `fix:` corrección de error
|
||||
- `refactor:` cambio estructural sin cambio funcional
|
||||
- `docs:` documentacion
|
||||
- `docs:` documentación
|
||||
- `chore:` mantenimiento
|
||||
- `test:` tests nuevos o modificados
|
||||
- `merge:` commit de merge (generado por --no-ff)
|
||||
- `merge:` commit de merge (lo genera `tbd_branch_finish` con `--no-ff`)
|
||||
|
||||
## Regla de mensajes
|
||||
|
||||
- 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.
|
||||
- Título corto resume el bloque.
|
||||
- Cuerpo en español: qué se cambió, por qué, qué impacto, qué no se tocó.
|
||||
|
||||
## Checklist rapido
|
||||
## Checklist
|
||||
|
||||
- [ ] Todos los cambios estan commiteados en una rama `issue/*` o `quick/*`.
|
||||
- [ ] Se separaron cambios distintos en commits diferentes.
|
||||
- [ ] Cada commit tiene descripcion larga en espanol.
|
||||
- [ ] Tests ejecutados y pasando (o no aplican).
|
||||
- [ ] 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).
|
||||
- [ ] `git merge --no-ff` ejecutado desde master.
|
||||
- [ ] `git push` ejecutado correctamente.
|
||||
- [ ] Rama local eliminada.
|
||||
- [ ] `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.
|
||||
|
||||
Reference in New Issue
Block a user