ci: verify the built artifact before publishing it

[pofallon]

Fixes the gap that has been letting broken releases reach PyPI.

The hole

release.yml's test job runs uv sync --all-extras --group dev — it installs the source tree. publish then ran uv build and shipped the result. Nothing in between ever installed the wheel, so the first person to install a release was a user, and every packaging-layer bug sailed through:

• a wrong [tool.hatch.build.targets.wheel] packages =
• a runtime dependency that only the dev group was satisfying
• a broken [project.optional-dependencies] entry
• an sdist exclude that dropped something needed at runtime

The restructure

test → build → install-matrix → release → publish

• build — uv build --no-sources, then twine check + check-wheel-contents, uploads dist/ as an artifact. --no-sources proves the build works with tool.uv.sources disabled, which is how every other build tool (and therefore PyPI) sees the project. No sources are declared today, so it's insurance, not a fix.
• install-matrix — installs that artifact into a clean venv across {3.12, 3.13} × {no extras, each of the six, all} = 14 combinations, and runs scripts/smoke_install.py.
• publish — no checkout, no rebuild. Downloads and ships the exact artifact the matrix exercised.

The bare "no extras" row is the point. It's the only configuration where the vendor SDKs are genuinely absent, so it's the only place the lazy-import invariant from CLAUDE.md can actually fail — and it's a configuration CI has never executed.

One bug found while building this

Install is by wheel path, not by name, and that's load-bearing. My first version used uv pip install --find-links dist/ "airframe-agents[claude]". --find-links only adds to the index — PyPI already has 0.9.2, the local build is 0.9.1, so the resolver picked 0.9.2 and the smoke test silently verified the previously-published package. A gate that tests the wrong artifact is worse than no gate. Appending the extra to the path ("${WHEEL}[claude]") still resolves that extra's dependencies from PyPI, which is what we want.

tests/test_lazy_imports.py

So the invariant is enforced at PR time, not only at release. Probes in a subprocess — the pytest process has already imported the vendor SDKs deliberately, so an in-process sys.modules check would pass vacuously.

Verified it can fail: injecting a top-level import openai into openrouter.py turns 10 of the 11 tests red; reverting returns them to green. The 11th guards the guard — it asserts every adapter's REQUIRES_PACKAGE appears in the watched list, so a new adapter with a new SDK can't silently create an unwatched eager-import path.

On what the smoke script checks

It deliberately does not assert an exact provider roster — tests/test_discovery.py already does that on every PR and doesn't need a release to catch a regression. What only an installed artifact can prove is that every adapter module the wheel claims to serve is importable from the wheel, so it calls runtime_for() per provider and requires either a class or the documented ImportError naming the extra.

Verification

Ran the whole thing locally against a real build before pushing:

(no extras)      exit=0  passed=15
[claude]         exit=0  passed=15
[copilot]        exit=0  passed=15
[openai-compat]  exit=0  passed=15
[bedrock]        exit=0  passed=15
[opencode]       exit=0  passed=15
[all]            exit=0  passed=15
OVERALL: PASS

twine check and check-wheel-contents both clean on the built sdist and wheel. make ci green (1035 passed, +11 new).

Note the workflow itself only executes on a v* tag push, so this PR's CI will not exercise it — the local run above is the evidence.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UBTr6Q6kTGUMQiwwBHcdMj