fix(website): correct hub install command and clarify agent availability#2207
Conversation
…nt-factory spec Deep dives on the two systems §11 name-checked (OpenClaw ~382K stars / ~52K ClawHub skills / the ClawHavoc malicious-skill incident; Hermes Agent ~211K stars / self-authored skills / usage-statistical Curator with no execution validation) turned the one-line distinctiveness claim into scoped amendments: - §11 rewritten with the precise contrast (OpenClaw = skill distribution + operator-reviewed self-authoring; Hermes = skill learning) and the real positioning: the factory is the trust layer for the loop they popularized. - New §11.6: eight gaps with dispositions — no skill lane, no community producer path, no field→factory feedback, no adversarial eval bucket, no malicious-package recovery, no cycle-time budget, no interop intake, plus the §11 mislabel (fixed). - Inline, non-optional security amendments: an injection-resistance floor in the §5 gate (content-borne attacks defeated every scanner in both ecosystems; signing proves who, not what the text does to the model), and catalog yank + daemon deny-list promoted from 'scope if needed' to M1 (revocation is signing's other half; roll-forward doesn't stop a compromised publisher's existing installs). - New open decisions §12.7–12.9: the skill lane (+ agentskills.io intake), the Community-tier pipeline subset, and privacy-preserving field telemetry as M4's sensory input.
The landing page and hub advertised more than the product ships and showed an install command that errors. Three fixes: - The featured/hub agent card rendered `gaia agent install <id>`, which is not a real CLI action. It now uses the canonical primary command from installMethods() (npm agents show `npm i <package>`), matching the detail page, so copy-pasting it actually installs the agent. - The "Run agents now" cards implied four installable agents while only email is published; the unshipped ones (documents, code, summarize) are now labelled "Coming soon" and non-interactive (no dead links), and the live email card deep-links to /hub/email instead of the generic index. - The "Three ways to use GAIA" cards now name each entry point and who it's for (Agent UI -> end users, Agent packages/npm -> app developers, Python SDK -> agent builders), so visitors can tell which door is theirs.
|
Verdict: Approve ✅ This PR makes the landing page and hub honest: the featured agent card now shows a real install command ( No blocking issues and no security concerns. The one thing worth a follow-up thought (not blocking): the fix relies on the featured agent being an npm package; if a non-npm agent is ever featured, the card falls back to the same 🔍 Technical details🟢 Minor — featured-card fallback can reintroduce the "not a real command" string ( 🟢 Minor — non-"soon" outcome cards depend on (No change needed now — flagging the implicit invariant so it isn't lost.) Strengths
|
|
Reviewed — clean (GitHub blocks a formal approval since this account authored the PR). The featured card now sources its install command from installMethods(), the same canonical source as the detail page, so it can never show a command the agent doesn't support; unpublished agents become non-interactive 'Coming soon' cards instead of dead links. The red 'build' check is main's AgentHubGrid breakage (#2206), not this PR. |
Why this matters
A visitor arriving today hits three friction points on the landing page and hub: the featured agent card shows
gaia agent install <id>— not a real CLI command, so copy-pasting it errors; the "Run agents now" row advertises four agents when only email is published, and all four cards dead-end at the generic/hub; and the "Three ways to use GAIA" cards don't say which entry point is for whom. This PR makes all three honest and clear — no backend or infra changes, all validated byastro build.FeaturedCardnow uses the canonicalinstallMethods()command (npm agents →npm i <package>), matching the detail page. The email card now showsnpm i @amd-gaia/agent-email. The brokengaia agent install emailno longer renders anywhere./hub/email.The hub showcase grid is already catalog-driven (only real agents), so it stays honest automatically.
Test plan
HUB_CATALOG_URL=https://hub.amd-gaia.ai npm run buildpasses (astro check+astro build, 0 errors).dist/index.html: featured card showsnpm i @amd-gaia/agent-email; 3× "Coming soon", 1× "Available now"; email card links to/hub/email;gaia agent install emailabsent fromdist/index.htmlanddist/hub/index.html.Deferred to a follow-up (needs a write-store the Worker doesn't have yet)
Per-agent download counts, 4-star ratings, thumbs-up demand voting on Coming-soon cards, and free-text "request an agent / use-case" feedback all need a persistence layer. The agent-hub Worker (
workers/agent-hub) currently has only an R2 artifact bucket — no KV/D1/Durable Object for counters. Building these requires provisioning that store in the Cloudflare/Railway account + deploying, so they can't be validated inline to the repo's "bulletproof" bar. Proposed next PR: add a KV (or D1) binding +GET/POST /interest/:idand/rating/:idendpoints (with vitest coverage using a fake KV, mirroringtest/fake-r2.ts), then wire the thumbs-up/stars/feedback UI. Download counts can pull npm's publicapi.npmjs.org/downloadsfor npm agents with no new infra.Not changed (audit correction): the "Download for macOS" CTA is already OS-aware —
DownloadButton.astrodetects the visitor's OS and deep-links the matching installer; it showed macOS only because the reviewer was on macOS.