feat: el número de la HU sale del nombre de la rama #6

Merged
julio.caicedo merged 3 commits from feat/hu-desde-el-nombre-de-la-rama into main 2026-10-16 20:47:32 +00:00

Pedir una línea Tarea: #48 en la descripción del PR era pedir dos veces lo mismo: el equipo ya nombra sus ramas feature/1234-agregar-login, con el número de la HU adelante. Ahora de ahí sale.

El orden en el que busca:

  1. El nombre de la rama. feature/1234-agregar-login → 1234. Solo cuentan los dígitos pegados al prefijo y el número tiene que terminar ahí, así que bugfix/arreglar-bug-404 no lleva HU y no se le inventa una con el 404 del final.
  2. El comando: /revisar 48. Hace falta porque en issue_comment el payload no trae el nombre de la rama. Es el camino para volver a correr el revisor después de arreglar algo.
  3. La línea Tarea: #48, que sigue valiendo para una rama que no puede llevar el número.

Lo que cambia de fondo: sin número ya no falla. Avisa con un ::notice:: y sale bien. Un PR de documentación, de CI o un hotfix no sale de ninguna HU y no hay criterios de aceptación contra los que juzgarlo; fallar ahí dejaba una X roja en PRs que están bien. Va en la misma línea que el resto del revisor: comenta, no frena.

Probé las tres expresiones contra los nombres de rama reales del equipo, incluidos los que no llevan número (bugfix/fix_timeout_db, hotfix/error-pago, hotfix/ajuste_cache, fix/BOOT-4-config) y el caso que importaba, bugfix/arreglar-bug-404, que correctamente no da HU. Validé que la plantilla parsea con loader estricto y que workflow_call sigue teniendo solo inputs.

HEAD_REF y COMMENT los elige quien abre el PR, así que entran por env: y nunca se interpolan en el shell, igual que BODY.

La convención del lado del equipo queda escrita en balanzio/api#17.

🤖 Generated with Claude Code

https://claude.ai/code/session_012oVizRo2WB4FeZVRnHr9Ye

Pedir una línea `Tarea: #48` en la descripción del PR era pedir dos veces lo mismo: el equipo ya nombra sus ramas `feature/1234-agregar-login`, con el número de la HU adelante. Ahora de ahí sale. El orden en el que busca: 1. **El nombre de la rama.** `feature/1234-agregar-login` → 1234. Solo cuentan los dígitos pegados al prefijo y el número tiene que terminar ahí, así que `bugfix/arreglar-bug-404` no lleva HU y no se le inventa una con el 404 del final. 2. **El comando: `/revisar 48`.** Hace falta porque en `issue_comment` el payload no trae el nombre de la rama. Es el camino para volver a correr el revisor después de arreglar algo. 3. **La línea `Tarea: #48`**, que sigue valiendo para una rama que no puede llevar el número. **Lo que cambia de fondo: sin número ya no falla.** Avisa con un `::notice::` y sale bien. Un PR de documentación, de CI o un `hotfix` no sale de ninguna HU y no hay criterios de aceptación contra los que juzgarlo; fallar ahí dejaba una X roja en PRs que están bien. Va en la misma línea que el resto del revisor: comenta, no frena. Probé las tres expresiones contra los nombres de rama reales del equipo, incluidos los que no llevan número (`bugfix/fix_timeout_db`, `hotfix/error-pago`, `hotfix/ajuste_cache`, `fix/BOOT-4-config`) y el caso que importaba, `bugfix/arreglar-bug-404`, que correctamente no da HU. Validé que la plantilla parsea con loader estricto y que `workflow_call` sigue teniendo solo `inputs`. `HEAD_REF` y `COMMENT` los elige quien abre el PR, así que entran por `env:` y nunca se interpolan en el shell, igual que `BODY`. La convención del lado del equipo queda escrita en balanzio/api#17. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_012oVizRo2WB4FeZVRnHr9Ye
feat: el número de la HU sale del nombre de la rama
Some checks failed
_analytics.yaml / feat: el número de la HU sale del nombre de la rama (push) Failing after 0s
_build-docker.yaml / feat: el número de la HU sale del nombre de la rama (push) Failing after 0s
_deploy-k8s.yaml / feat: el número de la HU sale del nombre de la rama (push) Failing after 0s
_go-analytics.yaml / feat: el número de la HU sale del nombre de la rama (push) Failing after 0s
_go-build.yaml / feat: el número de la HU sale del nombre de la rama (push) Failing after 0s
_go-deploy.yaml / feat: el número de la HU sale del nombre de la rama (push) Failing after 0s
_go-test.yaml / feat: el número de la HU sale del nombre de la rama (push) Failing after 0s
_test.yaml / feat: el número de la HU sale del nombre de la rama (push) Failing after 0s
_analytics.yaml / feat: el número de la HU sale del nombre de la rama (pull_request) Failing after 0s
_build-docker.yaml / feat: el número de la HU sale del nombre de la rama (pull_request) Failing after 0s
_deploy-k8s.yaml / feat: el número de la HU sale del nombre de la rama (pull_request) Failing after 0s
_go-analytics.yaml / feat: el número de la HU sale del nombre de la rama (pull_request) Failing after 0s
_go-build.yaml / feat: el número de la HU sale del nombre de la rama (pull_request) Failing after 0s
_go-deploy.yaml / feat: el número de la HU sale del nombre de la rama (pull_request) Failing after 0s
_go-test.yaml / feat: el número de la HU sale del nombre de la rama (pull_request) Failing after 0s
_test.yaml / feat: el número de la HU sale del nombre de la rama (pull_request) Failing after 0s
Go / Test (pull_request) Successful in 34s
6b1b960e98
Pedir una línea "Tarea: #48" en la descripción era pedir dos veces lo mismo:
el equipo ya nombra sus ramas "feature/1234-agregar-login", con el número de
la HU adelante. Ahora de ahí sale, y no hay nada extra que recordar al abrir
el PR.

Solo cuentan los dígitos pegados al prefijo y el número tiene que terminar
ahí, así que "bugfix/arreglar-bug-404" no lleva HU y no se le inventa una con
el 404 del final.

Quedan dos caminos para una rama que no puede llevar el número. El comando lo
acepta ("/revisar 48"), que es lo que hace falta en issue_comment porque el
payload de ese evento no trae la rama. Y la línea "Tarea: #48" sigue valiendo.

Lo que cambia de fondo: sin número ya no falla, avisa y sale bien. Un PR de
documentación o de CI no sale de ninguna HU y no hay criterios contra los que
juzgarlo; fallar ahí dejaba una X roja en PRs que están bien.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012oVizRo2WB4FeZVRnHr9Ye
feat: plantilla que valida el nombre de la rama
Some checks failed
_analytics.yaml / feat: plantilla que valida el nombre de la rama (push) Failing after 0s
_analytics.yaml / feat: plantilla que valida el nombre de la rama (pull_request) Failing after 0s
_build-docker.yaml / feat: plantilla que valida el nombre de la rama (pull_request) Failing after 0s
_deploy-k8s.yaml / feat: plantilla que valida el nombre de la rama (pull_request) Failing after 0s
_go-analytics.yaml / feat: plantilla que valida el nombre de la rama (pull_request) Failing after 0s
_go-build.yaml / feat: plantilla que valida el nombre de la rama (pull_request) Failing after 0s
_go-deploy.yaml / feat: plantilla que valida el nombre de la rama (pull_request) Failing after 0s
_go-test.yaml / feat: plantilla que valida el nombre de la rama (pull_request) Failing after 0s
_test.yaml / feat: plantilla que valida el nombre de la rama (pull_request) Failing after 0s
_build-docker.yaml / feat: plantilla que valida el nombre de la rama (push) Failing after 0s
_deploy-k8s.yaml / feat: plantilla que valida el nombre de la rama (push) Failing after 0s
_go-analytics.yaml / feat: plantilla que valida el nombre de la rama (push) Failing after 0s
_go-build.yaml / feat: plantilla que valida el nombre de la rama (push) Failing after 0s
_go-deploy.yaml / feat: plantilla que valida el nombre de la rama (push) Failing after 0s
_go-test.yaml / feat: plantilla que valida el nombre de la rama (push) Failing after 0s
_test.yaml / feat: plantilla que valida el nombre de la rama (push) Failing after 0s
Go / Test (pull_request) Successful in 36s
761efb047d
Complemento del cambio anterior: si de la rama sale el número de la HU, tiene
que haber una puerta que compruebe que la rama se llama como debe. Sin ella
una rama mal nombrada no se revisa y no se entera nadie, porque no revisar se
ve igual que un hotfix que legítimamente no tiene HU.

Dos entradas: qué prefijos valen y cuáles de ellos exigen el número. Un repo
que todavía arrastra ramas con otros prefijos los agrega a la lista en vez de
quedarse sin puerta.

Lee el número con la misma expresión que el revisor, para que lo que pasa acá
sea exactamente lo que encuentra allá.

La rama sí se imprime, que ayuda a quien lee el error: git no deja ":" ni
saltos de línea en un ref, que es lo que haría falta para colar un comando
del runner en la salida del paso.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012oVizRo2WB4FeZVRnHr9Ye
Merge branch 'main' into feat/hu-desde-el-nombre-de-la-rama
All checks were successful
Go / Test (pull_request) Successful in 43s
b0c0cbb30a
julio.caicedo deleted branch feat/hu-desde-el-nombre-de-la-rama 2026-10-16 20:47:32 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
startcodex/ci!6
No description provided.