[binlecode]

PyPI publishing is no longer part of the tag flow

publish-pypi.yml no longer triggers on push: tags. It is workflow_dispatch only, taking the tag as an input:

gh workflow run publish-pypi.yml --ref vX.Y.Z -f tag_name=vX.Y.Z

Why. The automatic form was self-defeating. The tag push started the publish at the same moment the tag appeared, so the run raced the release it was meant to ship rather than publishing a settled one — publishing could never be ordered after the tag and its CI, which is the only point at which you actually know what you're shipping. Making it a dispatch that names an already-existing tag removes the ordering problem instead of retrying around it.

--ref must be the tag, not a branch. The pypi environment's deployment policy admits only v* refs (verified: custom_branch_policies: true, one policy, v*), so a dispatch from main is rejected before the job starts. Pointing it at the tag satisfies the policy — so the "only a tagged commit ever reaches PyPI" guarantee the automatic trigger provided is preserved, not weakened.

OIDC trusted publishing is unchanged and no long-lived token is introduced. The workflow already validated that the tag matches pyproject.toml, and that check still runs on the dispatch path.

Release flow is now three steps: merge the bump PR → scripts/tag_release.sh → dispatch the publish.

Hero GIF re-recorded — and the tape had been recording the wrong binary

The tape typed a bare actop, which resolved to whatever was installed on PATH. On this machine that was a Homebrew v1.8.0 build, so the capture showed a dashboard with no Network/Disk sections at all — the demo had silently drifted from the code. The tape now Requires .venv/bin/actop and launches through it, so it always records the repo build.

The capture also moved from stack to the default grid layout at 1800x930:

• Seven sections since v1.9.0 make the stacked column ~58 rows; at the old height the two new I/O boxes fell below the fold.
• Width is load-bearing: p splits the dashboard against the fixed 74-col process table, and below ~96 cols grid auto-degrades to stack. At 1400px the dashboard dropped to ~80 cols and degraded mid-take; 1800px leaves it ~122 and grid survives the whole recording.

Now covers the mirrored Network/Disk pair side by side, per-core panels (c), both glyph modes (g), the process table with watt attribution (p), and the theme cycle (t). 4.3 MB / 39.8 s.

Recording needed real external I/O: the GPU workload runs against a router on localhost, and loopback is excluded from the if_data counters by design, so the new sections would otherwise have recorded flat.

Known issue, not introduced here

The final frame shows truncated metric rows (max 41 without %, idle60 low1 mid2 without high). That is the pre-existing narrow-grid-column clipping, now visible in the hero because the process table halves the dashboard width. Not addressed in this PR.

Tested

macOS 15 (Darwin 25.5.0), Apple M4 Max.

.venv/bin/ruff check .        # clean
.venv/bin/ruff format --check .  # 60 files already formatted

Workflow trigger verified: no push: block remains, workflow_dispatch present. Environment policy confirmed via gh api /repos/binlecode/actop/environments/pypi.

🤖 Generated with Claude Code