[AAASM-2342] ♻️ (release): Replace tag-push trigger + silent download fallback with repository_dispatch listener

[Chisanan232]

Summary

Switches python-sdk's wheel-release pipeline (release-python.yml) from a push: tags trigger that races against upstream binary upload, to a repository_dispatch-driven listener that fires only after agent-assembly has finished publishing its release artifacts.

Tracking ticket: AAASM-2342 — Subtask of AAASM-1202 (F112 Python SDK platform wheel distribution).

Upstream dispatcher: AI-agent-assembly/agent-assembly#842 — adds a notify-downstream job to agent-assembly's release.yml that emits event-type: agent-assembly-release-published with client_payload.release_tag to both python-sdk and node-sdk after the upstream Release object exists.

Changes (one commit each)

1. Switch trigger from push: tags to repository_dispatch — listens for agent-assembly-release-published; keeps workflow_dispatch for dry-runs. Publish-job guard updated from github.event_name == 'push' && startsWith(github.ref, 'refs/tags/v') to github.event_name == 'repository_dispatch'.
2. Pin aasm binary download to the dispatch payload's release_tag — adds AASM_TAG: ${{ github.event.client_payload.release_tag }} env to each Stage step and forwards it via --tag "$AASM_TAG" to gh release download, so a release that ships mid-flight cannot swap binaries underneath us. The workflow_dispatch (dry-run) path passes no --tag and falls back to "latest" as before.
3. Drop the 2>/dev/null swallow + ::warning:: fallback on all four gh release download calls (linux x86_64, linux aarch64, macos arm64, macos x86_64). Each Stage step now runs under set -euo pipefail; failure to download an expected aasm-* binary becomes a hard error and aborts the wheel build. This is intentional — the dispatch trigger guarantees the binaries exist on the upstream release before this workflow runs, so a missing binary is a real problem, not transient noise.

Why removing the tag-push trigger is safe

The dispatch path is now the authoritative source of truth for "a python wheel release should happen". Keeping push: tags in parallel would re-introduce the same race the dispatch model is designed to eliminate (tag arrives at python-sdk before binaries are uploaded). workflow_dispatch is retained for engineer-initiated dry-runs.

release-staging.yml / release-validate.yml

Inspected both — neither contains the gh release download swallow pattern. They delegate to centralized reusable workflows in Chisanan232/GitHub-Action_Reusable_Workflows-Python and don't bundle the aasm sidecar binary. No changes required for AC4 in this PR.

Verification

• python3 -c "import yaml; yaml.safe_load(open('.github/workflows/release-python.yml'))" — passes
• End-to-end verification will happen on the next agent-assembly release (alpha.4) when the upstream notify-downstream job fires for the first time. Until then, workflow_dispatch dry-runs against the latest existing release continue to work.

Test plan

• On agent-assembly v0.0.1-alpha.4 release: verify python-sdk's Release Python SDK workflow auto-starts via repository_dispatch and consumes release_tag correctly.
• On the same release: verify each platform's Stage step downloads aasm-<platform> from the specific tag (not "latest") by checking the gh release download log line.
• On the same release: verify wheels published to PyPI ship the bundled agent_assembly/bin/aasm (e.g. unzip -l the wheel).
• Negative test (optional): trigger workflow_dispatch from the Actions tab — wheels should build against the latest existing aasm release; publish job should be skipped.

[Chisanan232]

Claude Code review — AAASM-2342

CI state — green for merge (7 SUCCESS + 6 SKIPPED, 0 failures)

mergeable: MERGEABLE, mergeStateStatus: CLEAN. The 6 SKIPPED checks are all Complete Release Validation Process / * sub-jobs that path-filter on Python source / Dockerfiles / package config; this PR's diff is scoped to .github/workflows/release-python.yml, so those workflows correctly skip themselves rather than running irrelevant validation. Not failures.

Scope vs. acceptance criteria

AC (from AAASM-2342 ticket)	Status	Evidence
release-python.yml trigger → on: repository_dispatch: { types: [agent-assembly-release-published] }; keep workflow_dispatch for dry-runs; tag-push removed	✅	Commit 36a1b99 — push: tags: 'v*.*.*' replaced cleanly; the publish-job guard updated in the same commit from event_name == 'push' && startsWith(refs/tags/v) to event_name == 'repository_dispatch' (atomic — splitting would have left an intermediate broken state, correctly bundled per the commit message)
Replace tag-derived version resolution with ${{ github.event.client_payload.release_tag }}	✅	Commit b90b852 — adds AASM_TAG env via the workflow-injection-safe pattern (env: AASM_TAG: ${{ github.event.client_payload.release_tag }}, then --tag "$AASM_TAG" in shell as a conditional TAG_ARG=() array). workflow_dispatch dry-runs fall through to "latest"
Drop the four gh release download … 2>/dev/null swallows + the else: echo "::warning::..." warning branch — failure becomes a hard error	✅	Commit a5919e2 — set -euo pipefail added, 2>/dev/null removed, if/else warning fallback dropped on all 4 platform Stage steps (linux x86_64, linux aarch64, macos arm64, macos x86_64)
Review release-staging.yml / release-validate.yml for the same pattern	✅	The implementing agent inspected both: they delegate to centralized reusable workflows in Chisanan232/GitHub-Action_Reusable_Workflows-Python that don't touch aasm binaries, so no equivalent swallow exists there. Documented in the PR description

Commit granularity

3 commits, one logical concern each (matching the workspace's commit-style convention):

1. ♻️ (release): Switch trigger from push:tags to repository_dispatch
2. ♻️ (release): Pin aasm binary download to dispatch payload's release_tag
3. ♻️ (release): Drop silent gh-release-download fallback for aasm binaries

The publish-job guard flip (event_name == 'push' … → event_name == 'repository_dispatch') is correctly bundled into commit 1 — splitting would have left an intermediate state where the trigger fires on dispatch but the publish job still gates on tag-push, which is broken.

Workflow-injection safety

The dispatch payload's release_tag is consumed via the safe pattern recommended by GitHub's Catch GitHub Actions Workflow Injections Before Attackers Do — assigned to an env: var first, then dereferenced as "$AASM_TAG" in shell. Not interpolated directly into a run: block. ✓

Coordination with the upstream dispatcher

This PR is the listener for the dispatcher introduced in agent-assembly PR #842 (AAASM-2336). The dispatcher fires event-type: agent-assembly-release-published with client_payload: { "release_tag": "${{ github.ref_name }}" } to BOTH node-sdk and python-sdk after the GH Release object is published.

The matching node-sdk listener is in node-sdk#66, which the user reports already merged. python-sdk has been on the silent-2>/dev/null workaround until now; this PR closes the loop.

End-to-end verification (deferred to alpha-4 release)

Live verification requires the next agent-assembly tag (v0.0.1-alpha.4) to fire. That release-prep PR is agent-assembly#844 (AAASM-2343). The expected sequence:

1. agent-assembly tag → publish job creates GH Release with aasm-* binaries.
2. notify-downstream fires repository_dispatch at this repo.
3. release-python.yml (under this PR's changes) wakes via repository_dispatch, reads client_payload.release_tag, downloads aasm-* binaries with the upstream tag pinned, succeeds without retry, ships four wheels each with a bundled aasm binary on PyPI.

If the dispatch ever fails to arrive (PAT scope issue, network), the wheels-build step now hard-errors instead of silently shipping binary-less wheels — that's the explicit AC3 win.

Verdict

Ready for human approval and merge. All four ACs delivered or correctly waived (AC4 found nothing to fix). Commits are atomic and well-justified. Workflow-injection-safe consumption of the dispatch payload. CI clean.

Recommend merging this PR alongside agent-assembly#844 in the same release cycle so the dispatch flow is verified live on alpha.4.

— Claude Code (Opus 4.7, 1M context)