El CI no dispara en pull_request: `gh pr checks` sale 0 sin checks, y el gate de merge lo lee como verde

[A-PachecoT]

Contexto

.github/workflows/ci.yml declara on: pull_request, pero ningún PR dispara un run. Verificado sobre el PR #6 (mergeado 2026-08-06):

$ gh pr checks 6
no checks reported on the 'feat/cli-first-and-agent-path' branch
$ echo $?
0

$ gh run list --branch feat/cli-first-and-agent-path
(vacío)

$ gh run list --limit 4
completed  success  Merge feat/hooks… (#2)      ci  main  push  2026-07-24
completed  success  docs(readme)…               ci  main  push  2026-07-23
completed  success  feat(brand)…                ci  main  push  2026-07-23
completed  success  chore(oss)…                 ci  main  push  2026-07-23

Los cuatro runs más recientes son todos push sobre main. Ninguno es pull_request, y el más nuevo tiene dos semanas. El trigger de push funciona; el de PR no ha disparado nunca de forma observable.

Por qué importa más que un check faltante: gh pr checks sale con exit 0 cuando no hay checks. Un flujo de merge que usa ese exit code como gate —que es exactamente lo que recomienda handbook/governance/git-strategy.md para Tier B— lee "sin señal" como "todo verde" y mergea. El repo hoy no tiene gate real en PRs: cualquier PR se puede mergear sin verificación automática, y el comando que debería frenarlo devuelve éxito.

El PR #6 se mergeó así. La verificación existió, pero porque se corrió a mano (bash scripts/validate-skills.sh → exit 0, bash plugins/basalt/hooks/tests/run.sh → 26/26), no porque el CI la produjera.

Fix propuesto

Diagnosticar por qué el evento pull_request no encola un run. Candidatos en orden de probabilidad, todos verificables desde Settings o la API:

1. Actions restringido a ciertos eventos o deshabilitado para PRs en la config del repo/organización.
2. Approval requerido para PRs (Settings → Actions → Fork pull request workflows), que deja el run en action_required en vez de encolarlo.
3. El workflow requiere un permiso o secret que el contexto de PR no otorga y falla antes de registrar el check.

Una vez identificado, corregir la config y añadir el check al ruleset de main como requerido, para que la ausencia de señal deje de leerse como aprobación.

Criterios de aceptación

1. Abrir un PR de prueba contra main produce un run visible: gh run list --branch <rama> devuelve al menos una fila con pull_request como evento.
2. gh pr checks <n> sobre ese PR lista el check ci (no "no checks reported").
3. Un PR que rompe los tests falla el check: introducir un fallo deliberado en plugins/basalt/hooks/tests/run.sh hace que gh pr checks salga distinto de cero.
4. El check ci figura como requerido en el ruleset de main, de modo que un PR sin él no sea mergeable.

El criterio 3 es el que importa: sin él, sólo se prueba que algo corre, no que pueda decir que no.

Método de verificación — OBSERVED

Todos los comandos de arriba se corrieron literalmente el 2026-08-06 contra cofoundy/basalt-plugin desde esta máquina; los outputs están pegados sin editar.

Para verificar el fix, con un PR de prueba abierto:

gh run list --repo cofoundy/basalt-plugin --branch <rama-de-prueba> --limit 3
gh pr checks <n> --repo cofoundy/basalt-plugin   # debe LISTAR ci, no decir "no checks"

Control conocido-bueno para no confiar en un negativo: gh run list --limit 4 sí devuelve filas (las de push), así que el comando y las credenciales funcionan — un resultado vacío filtrado por rama significa "no hubo run", no "no pude consultar".

Guardrails

• No relajar el workflow para que "pase". El objetivo es que el check EXISTA y pueda fallar; un CI que siempre da verde es peor que ninguno.
• No cambiar scripts/validate-skills.sh ni los tests de hooks — están verdes y no son la causa.
• No añadir un segundo workflow como rodeo. Arreglar por qué el existente no dispara.

Alcance + referencias

• Superficie: .github/workflows/ci.yml + la config de Actions del repo/organización + el ruleset de main.
• Caso vivo: PR CLI-first routing, progressive disclosure, and a sensor for the silent vault failure #6, mergeado sin ningún check reportado.
• Relacionado: handbook/governance/git-strategy.md usa el exit code de gh pr checks como gate de merge — precisamente el que este hueco vuelve inútil.