[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