docs(plans): scope agent-ui Agent Hub publishing + in-app marketplace#1714
Conversation
…ipts Harden the email release per the security audit: - Bind the publish job to an `agent-publish` environment so it pauses for a required-reviewer approval before any hub/npm publish (human backstop for an accidental/tampered release tag). GAIA_HUB_TOKEN moves to an environment secret so the publish credential is unreadable until approval. - Drop the redundant macos-26-intel leg: both Intel legs built the same x86_64 binary (not a different test) and the collect step deduped nondeterministically. Keep a single best-effort macos-15-intel — older OS = broader min-OS compat. - Add --ignore-scripts to `npm publish` so no lifecycle/dependency script runs in the OIDC-privileged job (dist/ is already built). Matches publish.yml.
…acOS 15 Switch the Intel build to the latest Intel image (macos-26-intel). Because building on a newer macOS can raise the binary's minimum-OS, add a verify-darwin-x64-compat job on macos-15-intel that smoke-tests the frozen binary on the older OS. If it fails there, publish DROPS darwin-x64 (ships the 3 required platforms) instead of shipping a binary broken on older Intel Macs — best-effort + continue-on-error so an Intel-runner issue never blocks the release. publish ships darwin-x64 only when the check reports ok=true.
- Wrap the Linux CLI-integration model pull in an exponential-backoff retry (60s→120s→240s, 3 retries) so a transient HuggingFace 429 doesn't fail CI; still fails loudly once exhausted. - Review feedback: correct the agent-publish environment setup comments to say deployment branches/tags = main + agent-pkg-* (the release is a tag push, so a main-only rule would block the gate), and fix the token-presence error to say "environment secret" not "repo secret".
Plan for distributing the Agent UI through the Agent Hub the way the email agent already is. Three threads a reviewer can evaluate independently: - Part 1: publish the Agent UI installers to R2 via the Agent Hub Worker and turn @amd-gaia/agent-ui into a thin R2-fetching wrapper (mirror email), with R2 as the primary download + auto-update feed. - Part 2: implement the stubbed in-app install runtime so the UI can browse the Hub catalog and one-click install published agents (the agent:install IPC handlers throw "not yet implemented" today). - Part 3: the UX/speed gaps underneath both — chiefly that first use is a 7-20 min cold Python-backend bootstrap; a frozen backend (reusing the agent freeze tooling) is the highest-leverage fix. Scope only; no implementation. Registered in docs.json under Ecosystem.
github-actions
Bot
added
documentation
Consolidate every gap surfaced in the investigation into one severity-ranked checklist (publishing, in-app install, first-use speed, cross-cutting trust/ resilience), including ones not previously written down: Worker CORS, the unbuilt gaia agent install CLI, a lighter first-run model, install telemetry. Add the independent-versioning rationale: the Hub package model decouples the UI, each agent, and the catalog from the core amd-gaia release train.
SummarySolid, mergeable work — the scoping doc is exceptionally well-grounded (every file reference and code claim I spot-checked is accurate), and the three CI commits are each sound and fail loudly. The one thing worth addressing before merge isn't in the code: the PR is titled Everything I verified:
Issues🟡 ImportantPR title + description omit the bundled CI changes (PR metadata).
This is low practical risk here (you authored the CI changes and you're the reviewer), so it's not a correctness blocker — but the title/description should match what the diff actually does. 🟢 MinorIntel build redundancy traded for compat verification ( Strengths
VerdictApprove with suggestions. No code-correctness blockers — the docs and CI logic are both clean. Before merge, reconcile the title/description with the actual diff (split the CI commits out, or disclose them as threads) so the email-release-gating change isn't shipping under a docs-only headline. |
|
🟡 The new exponential backoff for the model pull sleeps up to 420 s (60+120+240) across 3 retries. The Lemonade server-start loop already burns up to 300 s. Both together can consume 12 min of the job's 15-min timeout before a single CLI test runs — any retry in CI will cause the job to time out instead of fail loudly. Or, if the intent is to keep the test fast: shrink the delays to 30 s → 60 s → 120 s (total 210 s), which fits comfortably within 15 min even with the server-start wait. |
setup.py:143 declares faiss + sentence-transformers + torch directly in the [ui] extra and gaia.ui.server boots them eagerly (#845), so the email freeze recipe (which excludes torch/faiss) doesn't transfer. Note the real options (remote embeddings / wheelhouse / large freeze) and flag the 7-20 min figure as an unmeasured estimate.
The Hub hosts more than agents: apps (the Agent UI), components (RAG, memory), and agents. Add the component-type model — a manifest/catalog `type` discriminator, per-type validation and install semantics, inter-component dependency edges, and a separate lane for apps so the UI doesn't self-list in the agent list it renders. Resolves the "is the UI an agent?" tension (it's an app) and adds gap inventory section E.
Turn the multi-component concept into a grounded extension spec: a type discriminator (app/component/agent) across both validators (canonical src/gaia/hub/manifest.py + the Worker manifest.ts gate), a schema_version bump with back-compat (default missing type -> agent), the agents/ R2 namespace decision, branching the src/gaia/hub Python SDK by type, and the component provides/requires dependency contract as the new hard problem. Inventory §E extended (E8-E13).
Self-review pass over the plan after the multi-component additions: - type: desktop-app -> app (align Part 1 workstream + Worker note with §E) - fix CORS self-contradiction: Feature 2 claimed "no CORS blocker" while B8 says the Worker sets none and the fetch may be blocked — keep B8's position - de-presuppose the npm install path in Part 2 (multi-component branches by type; wheel-vs-sidecar is open per B2/B4) - frozen backend no longer claims it "reuses Part 1 tooling" (C1 caveat) - "both parts" -> "Parts 1-2"; soften the unmeasured 7-20 min header
Resolve conflict in release_agent_email.yml — keep main's website redeploy step (PR is docs-only and never touched this workflow).
3 participants
Why this matters
The Agent UI ships installers to GitHub Releases + npm today, but nothing reaches R2 / the Agent Hub, and the in-app "install an agent" path is a stub that throws
"not yet implemented"— so the desktop app can't be distributed or discovered through the Hub the way the email agent already is, and it can't install other published agents. This plan scopes closing that gap end-to-end. It also surfaces the gap that matters most for adoption: even with an instant installer, first use is a 7–20 min cold Python-backend bootstrap.Scope only — no implementation code. The doc is the deliverable.
What's in the plan
@amd-gaia/agent-uibecomes a thin R2-fetching wrapper withbinaries.lock.jsonintegrity (mirror email), R2 as the primary download + auto-update feed. Flags the real wrinkles: multi-file-per-platform lock, a mutable "latest" channel vs. the Worker's immutability guarantee, and the@amd-gaia/agent-uinpm name collision.agent:install/agent:uninstallruntime, an in-app Hub mirror page, and click/deep-link (gaia://hub/install/<id>) install. Notes the front-half scaffolding that already exists vs. the missing back-half service.Test plan
docs.jsonregistersplans/agent-ui-hub-publish).node -e "JSON.parse(require('fs').readFileSync('docs/docs.json','utf8'))"passes (valid JSON).