ship — llevar el trabajo a producción (git + gh)
Flujo de trabajo de envío independiente de la plataforma. Sin atajos, sin atajos.
Pre-push: pipeline CI local (todo en verde antes de hacer push)
- Formato —
cargo fmt --check/prettier --check/ruff format --check - Linter —
cargo clippy -- -D warnings/eslint/ruff check - Type-check —
cargo check/npx tsc --noEmit - Pruebas —
cargo test/npm test/pytest(salida mostrada) - Compilación —
cargo build/npm run build
Si un paso falla: corregir y volver a ejecutar todas las comprobaciones. Nunca hacer push con fallos conocidos.
Secuencia
- Rama dedicada (nunca trabajar directamente en
main). - Commit por fase, mensajes convencionales y basados en evidencia (SHA/PR/CI).
git pushde la rama.- Abrir PR: Resumen + Plan de pruebas (plantilla de 5 secciones si el repositorio la usa).
- Vigilar CI:
gh pr checks <n>— todo EXITOSO antes de continuar. - Fusionar: solo merge-commit (nunca squash, nunca rebase — conserva el historial para agentes paralelos).
- Post-merge: eliminar la rama, hacer fast-forward de
mainlocal, reportar el SHA del merge commit.
Puertas humanas (PARAR — preguntar primero)
- Fusión a
mainque afecte branch-protection/seguridad/licencia/infraestructura de release (#1) - Force-push a
main(#2) — siempre prohibido sin confirmación explícita - CI no totalmente verde → no fusionar nada pendiente/fallado
Comentarios de revisión
Cada comentario (humano o bot) debe ser analizado, comprendido y resuelto correctamente — nunca
resolver en silencio, nunca hacer un "arreglo" que solo toque la línea citada ignorando el fondo.
Responder en el hilo con lo que se hizo y por qué, luego resolver. Consultar skills/review.