[AAASM-2345] 🐛 (release): Fix three aasm-staging bugs that broke v0.0.1-alpha.4 publish

[Chisanan232]

What changed

Fixes three independent bugs in .github/workflows/release-python.yml's
Stage aasm sidecar binary step that together broke the
v0.0.1-alpha.4 release run
(all four wheel-build jobs failed at step 4 within 5–8s).

Bug 1 — gh release download --tag X is invalid syntax

gh release download takes the tag as a positional argument, not a
--tag flag. The previous invocation expanded
TAG_ARG=(--tag "$AASM_TAG") to --tag v0.0.1-alpha.4, which the CLI
rejects with unknown flag: --tag (confirmed in the job logs).

Fix: drop the --tag literal so TAG_ARG holds only the tag value,
expanding as a positional. When AASM_TAG is empty (workflow_dispatch
dry-run) the array stays empty and gh release download defaults to
the latest release.

This was introduced in PR #73 (AAASM-2342) — the previous code used
silent 2>/dev/null fallbacks, which masked the next two bugs as well.

Bug 2 — patterns didn't match upstream asset names

agent-assembly's release.yml publishes the sidecar under Rust
target-triple names:

Platform job	Old (never matched)	New (correct)
manylinux_x86_64	aasm-linux-x86_64	aasm-x86_64-unknown-linux-gnu.tar.gz
manylinux_aarch64	aasm-linux-aarch64	aasm-aarch64-unknown-linux-gnu.tar.gz
macosx_x86_64	aasm-macos-x86_64	aasm-x86_64-apple-darwin.tar.gz
macosx_arm64	aasm-macos-arm64	aasm-aarch64-apple-darwin.tar.gz

The mismatch is pre-existing but was hidden by the silent
2>/dev/null swallow that PR #73 removed. The published
agent-assembly==0.0.2 wheel on PyPI contains no aasm binary
(confirmed via unzip -l … | grep aasm returning empty), so previous
releases shipped binary-less wheels.

Bug 3 — assets are .tar.gz, can't be mv'd to the target path

Each upstream asset is a gzipped tarball containing a single aasm
binary at the root (confirmed via
tar tzf aasm-x86_64-unknown-linux-gnu.tar.gz → aasm). The previous
mv aasm-<triple>.tar.gz agent_assembly/bin/aasm would have produced
a gzipped archive named aasm in the wheel, not an executable.

Fix: replace each mv with tar -xzf … -C agent_assembly/bin/
followed by removing the tarball. The subsequent
chmod +x agent_assembly/bin/aasm is now correct because the
extracted file actually is the executable.

Verified locally: extracting the v0.0.1-alpha.4 Linux x86_64 tarball
yields a 17 MB ELF executable at agent_assembly/bin/aasm.

Why

Without all three fixes, the release-python workflow either fails
hard (with the --tag flag bug present) or silently ships wheels that
fall back to subprocess-launching whatever aasm happens to be on
the user's $PATH (with the --tag bug absent but the other two
present).

How to verify

After merge, re-trigger release-python.yml via workflow_dispatch
with release_tag: v0.0.1-alpha.4 to re-publish — no new tag
needed, because PyPI 0.0.1a4 was never created (the prior run
failed before the publish job ever ran).

Smoke-tested locally:

gh release download v0.0.1-alpha.4 --repo AI-agent-assembly/agent-assembly \
  --pattern 'aasm-x86_64-unknown-linux-gnu.tar.gz' -O /tmp/aasm.tar.gz
tar tzf /tmp/aasm.tar.gz                                                    # → aasm
mkdir -p /tmp/staging/agent_assembly/bin && cp /tmp/aasm.tar.gz /tmp/staging/agent_assembly/bin/
cd /tmp/staging
tar -xzf agent_assembly/bin/aasm-*.tar.gz -C agent_assembly/bin/
rm -f agent_assembly/bin/aasm-*.tar.gz
chmod +x agent_assembly/bin/aasm
file agent_assembly/bin/aasm                                                # → ELF 64-bit, x86-64

Related

• Failed CI run: https://github.com/ai-agent-assembly/python-sdk/actions/runs/26855112577
• Companion fixes (forthcoming):
  • agent-assembly PR — --allow-dirty for cargo workspaces publish
  • node-sdk PR — lowercase repository.url
• Closes AAASM-2345

[Chisanan232]

Claude Code review — AAASM-2345

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

mergeable: MERGEABLE, mergeStateStatus: CLEAN. The 6 SKIPPED 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 only, so those workflows correctly skip themselves rather than running irrelevant validation. Standard pattern (memory: project_verification_report_prs_no_ci.md-style — path filters match only the changed file).

Scope vs. acceptance criteria

AC (from AAASM-2345 ticket)	Status	Evidence
Bug 1 — gh release download --tag X is invalid; tag must be positional	✅	Commit c1404611 — --tag "$AASM_TAG" removed, replaced with positional gh release download "$AASM_TAG"
Bug 2 — asset patterns don't match real names (was aasm-linux-x86_64, should be aasm-x86_64-unknown-linux-gnu.tar.gz)	✅	Commit bf6d6b95 — all 4 platform patterns rewritten to Rust target triples + .tar.gz suffix
Bug 3 — assets are .tar.gz tarballs requiring extraction, not bare-binary mv	✅	Commit 1817cd57 — tar -xzf + extract + clean up replaces the bare mv
Apply to all 4 platform Stage steps (manylinux x86_64/aarch64, macosx arm64/x86_64)	✅	Diff stat shows 24+/12- on the single release-python.yml file, consistent with 4 platform patches
Re-trigger release-python.yml via workflow_dispatch against v0.0.1-alpha.4 after merge	⏳ post-merge	I will trigger this once Group 1 PRs are all merged

Commit granularity

3 commits, one per bug — matches the repo's per-logical-unit convention:

1. 🐛 (release): Fix gh release download --tag flag — tag is positional
2. 🐛 (release): Correct aasm asset patterns to Rust target triples
3. 🐛 (release): Extract aasm-*.tar.gz instead of mv

Splitting was correct here — each bug is independently understandable and the commits stay bisectable.

What this PR does NOT cover (and the user should know)

The python-sdk PyPI publish flow has a second, more insidious bug that this PR does not address: the centralized reusable workflow at Chisanan232/GitHub-Action_Reusable_Workflows-Python/.../rw_release_complete.yaml@master (called from python-sdk's separate release.yml, NOT this release-python.yml) auto-bumps pyproject.toml from 0.0.1aN → 0.0.2 by stripping the PEP-440 alpha suffix. This is how PyPI ended up with the bogus agent-assembly==0.0.2. Investigation findings posted on AAASM-2454.

Implication for alpha-4 republish: even after this PR merges, the next release-python.yml run may still publish a malformed version unless the upstream bumper is pinned/replaced. This is a separate ticket awaiting user decision (proposed as AAASM-2458).

Verdict

Ready for human approval and merge. All three documented bugs fixed, atomic commits, well-justified deviations (per the agent's report — release-staging.yml / release-validate.yml reviewed and don't have the same swallow pattern). Workflow-injection-safe consumption of dispatch payload via env-var indirection.

After merge: requires the upstream-bumper bug (AAASM-2454/2458) to be resolved before alpha-4 republish actually lands on PyPI.

— Claude Code (Opus 4.7, 1M context)