Review: feat(hub): gaia agent pack + dual-publish to R2 and PyPI

Summary

Solid, well-tested addition that closes the authoring→distribution loop for hub agents. The packager and publisher are cleanly separated, every failure path raises an actionable PackagerError/PublisherError with the what/what-to-do/where triad the project's fail-loudly rule asks for, and the 66 mocked unit tests cover the paths that matter (checksum, wheel location, auth rejections, version immutability, network errors). CLI wiring follows the existing cli_agent.py dispatch pattern exactly.

The one thing to fix before merge: the new agents / agent-summarize extras in setup.py depend on gaia-agent-summarize, which isn't on PyPI yet — so pip install "amd-gaia[agents]" fails today. Everything else is minor.

Issues Found

🟡 agents extra depends on an unpublished package (setup.py:81-86)
gaia-agent-summarize is referenced by both the agents and agent-summarize extras, but it isn't published — hub/agents/python/summarize/README.md:9 says "from PyPI (once published)" and no workflow uploads it. pip install "amd-gaia[agents]" will hard-fail at resolution. This also contradicts the extra's own inline comment ("Add an entry here when each agent's wheel is first published"). Recommend gating the entry behind the actual first publish — either drop these two extras until summarize is live, or land them in the same change that publishes the wheel.

🟡 gaia agent login requires [dev], but the publish workflow installs [publish]
keyring lives in the ui/dev extras, not publish (setup.py:252-258). A user who runs pip install "amd-gaia[publish]" to ship an agent then hits gaia agent login gets told to install [dev] (publisher.py:636-640). The env-var path keeps it from being fully broken, but login is the natural first step of the publish flow. Consider adding keyring>=24.0.0,<26.0.0 to the publish extra so the documented workflow works end-to-end:

        "publish": [
            "build>=1.0.0",
            "twine>=5.0.0",
            "keyring>=24.0.0,<26.0.0",
        ],

🟢 Dual-publish isn't atomic — partial-publish leaves an asymmetric state (publisher.py:762-771)
R2 is published before PyPI; if R2 succeeds and twine then fails, the R2 version is already immutable, so a retry hits 409 and forces a version bump even though PyPI never received the wheel. Errors are loud (good), but worth a one-line note in the publish docstring or CLI help telling authors that on a mid-publish failure they should re-run with --skip-r2 (or bump). Not a blocker for a first cut.

🟢 PyPI 403 detection is a bare substring match (publisher.py:895)
if "403" in lowered can match an unrelated 403 anywhere in twine's combined stdout/stderr. Low risk given the surrounding invalid or non-existent authentication alternative, but tightening to the auth phrase alone would be more robust.

Strengths

• Fail-loudly done right — every raise names what failed, the fix, and where to look; _locate_wheel even distinguishes "no wheel" from "wrong-named wheel" so a pyproject/manifest version mismatch is diagnosable.
• Testable seams — injecting runner / twine_runner and a fake keyring means the suite never shells out or touches the OS credential store, yet still exercises the real control flow. The stale-wheel snapshot test (test_pack_ignores_preexisting_stale_wheel) is a nice touch.
• Convention reuse — manifest is the source of truth for id/version and gates non-Python agents; _hub_base_url defers to catalog.get_hub_base_url() so publish and install agree on the origin; the spec URL correctly keeps the /docs/ prefix.

Verdict

Request changes — only for the broken agents extra (🟡), which ships an install target that fails today. The keyring-in-publish gap is a strong nice-to-have; the two 🟢 items are optional. Once the unpublished-dependency issue is resolved, this is ready to merge.