[rdimitrov]

Why

Every release dispatch spent about 3.5 minutes in create-release-pr.yml's preflight before it could open the release PR. The preflight built both execution images (provider and workload) for amd64 and arm64 without publishing them: four cold Go builds. Opening the PR itself takes about 20 seconds. ToolHive and the registry server have no such step; they build their images on every push to main.

The build does guard against something real. release.yml publishes these images only after the tag exists, and a published tag can't be moved. It's also the only pre-release build of the provider Dockerfile, because the Kind suites build the provider with ko, and the only arm64 build of either image.

What

• create-release-pr.yml: the preflight drops the image build. It keeps the base-image pin check (about 2 seconds), which also runs again at tag time and in release.yml. Opening a release PR goes from about 5 minutes to under a minute.
• New execution-images.yml: the same no-publish amd64 + arm64 build of both images, on every push to main (docs-only pushes excluded) and on manual dispatch. A broken provider Dockerfile or arm64 build shows up within minutes of the merge that causes it, before a release is cut from it.
• release-workflow-graph_test.py: now asserts that the build is gone from the release-PR workflow and present, after the pin check, in execution-images.yml.
• The cut-release skill says where the build runs now.

Trade-off: the break surfaces on main after merge, not on the PR. That matches ToolHive and the registry server. It costs about 4 runner-minutes per merge, off the critical path.

Testing

• release-workflow-graph_test.py passes. Restoring main's release-PR workflow, which still has the build, makes it fail.
• actionlint, the expression-placeholder check, release-tag-guard_test.sh and task docs pass.
• The new workflow runs on main only, so its first run is the first push to main after this merges. It can also be dispatched by hand.

🤖 Generated with Claude Code