Branch protection, code review automatizado con BecarIA, automerge y override de emergencia. Todo el ciclo de vida de una PR documentado.
Todo cambio entra al repositorio mediante Pull Request. Sin excepciones. La rama main esta protegida en todos los repositorios de la organizacion.
No se permite git push origin main ni git push --force a main. Branch protection rechazara el push. Cualquier cambio, por pequeno que sea, debe pasar por una PR revisada y aprobada.
Desde la creacion de la rama hasta la apertura de la Pull Request. Commits pequenos, convenciones claras.
Usa el formato estandar con el ID de la card del Planning Game y una descripcion corta.
Para bugs: fix/PRJ-BUG-XXXX-descripcion-corta
Cada commit debe seguir el formato estandar. El hook de commit valida el formato automaticamente.
Prefijos validos: feat: fix: refactor: chore: test: docs:
Maximo ~300 lineas cambiadas por PR, idealmente menos de 200. PRs atomicas: un solo proposito por PR. Separar infraestructura y refactors de cambios funcionales.
Sube la rama y crea la Pull Request con el CLI de GitHub.
BecarIA es la GitHub App de Geniova que publica reviews automaticas en Pull Requests. Analiza el diff contra las review-rules definidas.
El flujo recomendado. El desarrollador ejecuta la review en local y BecarIA la publica en GitHub.
kj review en local (con su propia API key)becaria.enabled: true en kj.config.yml, envia repository_dispatch a GitHubbecaria-reviewer[bot]Alternativa cuando Karajan no esta disponible o configurado.
Ambos flujos son validos. Karajan automatiza el proceso pero no es obligatorio para todas las PRs.
Las reglas que BecarIA evalua en cada Pull Request. Si alguna falla, la review sera REQUEST_CHANGES.
Todos los commits siguen el formato feat:, fix:, refactor:, etc.
No API keys, credenciales, tokens ni secretos en el codigo.
No referencias a Claude, Copilot u otras IA en commits o codigo.
Funcionalidad nueva debe incluir tests. Coverage minimo segun tipo.
Sin XSS, SQL injection, command injection ni path traversal.
No console.log en codigo de produccion. Usar logger apropiado.
Usar const siempre. let solo cuando la reasignacion sea necesaria.
Variables y funciones en ingles con nombres claros y descriptivos.
No alert/confirm/prompt nativos. Loading states. Mobile-first.
Dos labels que activan flujos automaticos en las Pull Requests. Usar con conocimiento de causa.
Se anade a PRs que quieres mergear automaticamente tras la aprobacion. Ideal para PRs de bajo riesgo que ya han sido revisadas.
Requisitos: aprobacion de BecarIA + todos los checks CI en verde. El workflow verifica ambas condiciones antes de ejecutar el merge por squash.
Para situaciones criticas que requieren merge inmediato. Solo puede usarlo el usuario autorizado configurado en HOUSTON_AUTHORIZED_USER.
Uso: comentar /houston <razon> en la PR. Auto-aprueba y mergea inmediatamente. Deja registro completo: quien, cuando, por que.
Reservado para GeniovaIT. Usar con extrema precaucion.
Configuracion aplicada a todos los repositorios de la organizacion Geniova-Technologies.
El recorrido completo de una Pull Request desde el push hasta el merge, incluyendo los flujos alternativos.
Los cuatro workflows de GitHub Actions que automatizan el flujo de PRs en los repositorios de Geniova.
Recibe el evento repository_dispatch de Karajan, genera un token de instalacion de la GitHub App y publica la review como becaria-reviewer[bot].
Monitoriza PRs con el label automerge. Cuando detecta aprobacion de BecarIA y todos los checks CI en verde, ejecuta merge por squash automaticamente.
Override de emergencia. Escucha el comentario /houston en PRs con el label houston. Verifica el usuario autorizado, auto-aprueba y mergea con registro de auditoria.
Bloquea atribucion a IA en PRs, issues y comentarios. Detecta Co-Authored-By de Claude, Copilot, y otras referencias a herramientas de IA.