ci(release): publish-pypi no se dispara con el Release de release-please (GITHUB_TOKEN no encadena workflows)

[complexluise]

Síntoma

La 0.8.0 se cortó bien (tag v0.8.0 + GitHub Release, PRs #129/#130 mergeados), pero publish-pypi.yml NO corrió → la 0.8.0 no llegó a PyPI. La única corrida de publish-pypi es el workflow_dispatch manual de la 0.7.0.

Causa raíz

publish-pypi.yml usa on: release: published. El Release lo crea release-please con el GITHUB_TOKEN por defecto, y GitHub NO dispara nuevos workflows desde eventos generados por el GITHUB_TOKEN (regla anti-recursión). El evento ocurre pero no enciende el workflow. Gotcha conocido de release-please + Trusted Publishing.

Workaround (cada release, hasta el fix)

workflow_dispatch manual de publish-pypi.yml desde main (donde pyproject ya tiene la versión nueva). Disparar desde dev publicaría la versión vieja.

Fix permanente (elegir uno)

• (a, recomendado) Mover el job de publish dentro del workflow de release-please, gateado por su output release_created (corre en el MISMO run; no depende del evento release). Es el patrón estándar.
• (b) Darle a release-please un PAT / GitHub App token (no el GITHUB_TOKEN) para que el Release que crea sí dispare on: release workflows.

Prioridad

Media — cada release necesita el dispatch manual hasta arreglarlo. No bloquea (el workaround publica).

[complexluise]

Resuelto en #137 (mergeado a dev) — Opción A + back-merge automático

release-please.yml ahora hace dos cosas post-release, gateadas por release_created:

• publish → reusa publish-pypi.yml (workflow_call) y publica a PyPI en el mismo run (sin depender del evento release).
• back-merge → merge directo main → dev + push (sin PR ni gate; si hay conflicto, falla y se resuelve a mano).

Toma efecto al próximo release (cuando #137 llegue a main).

⚠️ Setup requerido (una vez) para el back-merge

El job pushea a dev protegido. Hay que permitir que el bot lo haga — una opción:

• (a) Settings → Branches → regla de dev → "Allow specified actors to bypass required pull requests" → agregar github-actions[bot].
• (b) Setear el secret RELEASE_PLEASE_TOKEN (un PAT con contents:write) — el workflow ya lo usa con fallback (RELEASE_PLEASE_TOKEN || GITHUB_TOKEN); de paso robustece el publish.

Sin esto, el back-merge corre pero el push lo rechaza la protección (falla visible).

[complexluise]

Fix mergeado en #137 (auto-publish vía workflow_call + auto-back-merge, gateados por release_created). Se auto-valida en el próximo release; si el workflow falla ahí, se reabre. Pendiente de tu lado (una vez): el setting de bypass para el bot en la protección de dev (pasos en los comentarios de arriba). Cierro para no generar ruido.