Runbookactivecreado Wed May 06#claude-method #git #commits #workflow #runbook #harness

Reglas de Commit

Formato del mensaje

tipo: descripcion breve (max 72 chars)

Cuerpo opcional: contexto, motivacion, decision.

Tipos

Tipo	Uso
`feat`	Nueva funcionalidad
`fix`	Correccion de bug
`docs`	Solo documentacion
`refactor`	Cambio de codigo sin cambio funcional
`test`	Anadir o modificar tests
`perf`	Mejora de rendimiento
`security`	Parche de seguridad

Regla 3: Docs incrementales

En cada commit con cambios funcionales, actualizar:

Archivo	Que actualizar
`CLAUDE.md`	Version, stack si cambia
`README.md`	Version en titulo
`CHANGELOG.md`	Entrada nueva en la version actual
`TASK.md`	Estado de tareas (completar/anadir)
`RELEASE_NOTES.md`	Descripcion orientada al usuario

Pequenas actualizaciones en cada commit son menos laboriosas que regularizar versiones acumuladas.

Commits docs-only

Cuando un commit SOLO cambia documentacion (.md, comentarios): push inmediato, sin [skip ci] (Regla 16 en CreaRackSL).

git commit -m "docs: descripcion"
git pull --rebase origin main && git push

Por que no [skip ci] en CreaRackSL (Regla 16, vigente): saltarlo rompe CF Pages Deploy (los cambios de docs no llegan a workspace.crearack.com) y Bibliotecario-Ingest (el grafo no recibe los .md). Con el CI en runners propios (servidor OPS) los minutos de Actions ya no son el cuello de botella. Excepcion unica: emergencia autorizada por Edu/Dani con motivo en el commit.

Portabilidad: en otros proyectos cuyo CI se paga por minuto y donde docs-only no dispara deploys ni ingest, [skip ci] en commits docs-only puede seguir teniendo sentido. Es criterio por proyecto — en CreaRackSL esta prohibido.

Biblioteca (si disponible)

Antes de commitear:

bib_impact_query(file_path="<archivo>") — muestra que docs necesitan actualizacion.
bib_report_change(file_path="<archivo>", change_type="modified") — antes del git commit, por cada archivo de codigo tocado. El hook bib_report_check.py bloquea el commit si falta. Bypass puntual: BIB_SKIP=1 git commit ... (queda registrado en /biblioteca/pulse).

Push vs PR — flujo hibrido

PR obligatorio cuando cumpla CUALQUIERA:

Mas de 5 archivos tocados.
Toca: migrations, compose, Dockerfile, requirements.txt, config/settings, .github/workflows/.
Mensaje de commit empieza con feat: o refactor:.

Push directo a main cuando:

Docs-only o cambios en public/supercontext/.
Fix puntual <5 archivos sin tocar infra.
Mensaje de commit fix: / chore: / style:.

En equipos de 2-3 devs, la fricción de siempre-PR desalienta commits pequeños. El criterio hibrido mantiene review previa para cambios criticos sin ahogar el flujo diario. Merge al verde, MANUAL (gh pr merge <N> --squash).

Reglas operacionales post-Supercontexto

Aprendidas en proyectos reales 2026-04:

#	Regla	Por que
14	Verificar CI tras push · el EFECTO, no la señal	Comprobar TODOS los workflows del commit (`gh run list --json conclusion,name`, NO `--limit 1` ni el exit de `gh run watch`) tras cada push. Deployers automaticos (Dokploy, Vercel, CF Pages) pueden desplegar aunque el CI este rojo y dejar errores invisibles durante dias
15	HTTP 200 != exito	Scripts que hablan con APIs deben parsear `body.errors` y devolver exit!=0 cuando algo fallo semanticamente. Un MCP handler devolvio 200 con `errors:[...]` y el script lo tomo como OK — grafo roto 3 semanas
17	Infraestructura nunca en un PC personal	Crons/webhooks/servicios criticos van en infraestructura compartida (servidor, cron GitHub Actions, CF Workers). Nunca Task Scheduler local: es un SPOF
18	Pre-commit gemelo del CI · pre-push = gate rapido del area	Cada check que corre en CI (linter, formatter, typecheck) tiene su gemelo en `claude-method/harness/pre_commit_check.py`. El pre-push es un gate rapido que corre solo los tests del area tocada (cambios transversales → suite completa); la suite entera la corre siempre el CI
20	Push vs PR hibrido	Ver seccion arriba. Formaliza el criterio para equipos 2-5 devs donde siempre-PR es fricción pero siempre-push es riesgo
21	Tamano de commit	Bug fix <=80 LOC, 1 fix = 1 commit. Feature <=400 LOC por commit. Excepciones documentadas: cierres de iniciativa multi-sesion (`supercontext(iN):`), refactors mecanicos masivos, backfills programaticos con script idempotente referenciado

(Las numeraciones se mantienen historicas — algunos proyectos tienen 14, otros 19, otros 27 segun cuando se incorporaron las reglas.)

Véase también

[[ia-tech—metodo—git-flow]]
[[ia-tech—metodo—multi-dev]]
[[ia-tech—metodo—claude-method-guide]]
[[ia-tech—metodo—harness-engineering]]
[[crearack-tech—guides—agent-rules]]

Reglas de Commit del método Claude