feat(ui): first-class Plugin support in the registry UI

[ilackarms]

Description

Motivation: The Plugin kind (ar.dev/v1alpha1, #554) is fully usable from arctl apply, but had zero surface in the Next.js UI — plugins could not be registered, browsed, or inspected without the CLI.

What changed: Adds first-class Plugin support to the catalog UI, following the existing skill/agent/prompt/server component patterns:

• Add-plugin dialog (add-plugin-dialog.tsx): name, title, description, harnesses, and a git source (repository URL + optional branch/commit/subfolder), applied through the shared declarative /v0/apply endpoint via the generated client. The dialog explains that the controller resolves the pointer to a pinned commit and scans the bundle out of band.
• Catalog card (plugin-card.tsx): Plugins tab alongside the other kinds, grouped by name with tag counts. The card surfaces resolution state from status — a Ready badge (green), a Resolving spinner while Ready=False/Progressing, or the failure reason (e.g. SourceUnresolvable) with the condition message in a tooltip — plus the short pinned commit and harness badges.
• Detail page (plugin-detail.tsx): renders the server-derived content — status.resolvedSource (full pinned commit/digest), the parsed status.manifest (displayName, version, description, author, license, homepage, keywords), and the status.inventory. Hooks and executables are the governance risk surface, so they lead the Contents tab in a prominent "Runs code on install" callout ahead of skills, commands, agents, and MCP servers. Resolution failures show the controller's error message inline.
• Status helpers (lib/plugin-utils.ts): implement the readiness contract documented on PluginStatus (absence of Ready=True ⇒ not yet resolved).
• Shims (lib/ui-shims.ts): listPluginsV0/createPluginV0. Plugins postdate the legacy flat response shape, so plugin components consume the v1alpha1 envelope (spec + status) directly; only the list-call ergonomics are shimmed.
• Tests + stories: vitest coverage for the card (all resolution states), detail (manifest, inventory, risk callout, failure banner), dialog (payload shape, DNS-1123 validation, API error surfacing), and status helpers; Storybook stories for the card.

Verified live against a local server built from this branch with the real fixture github.com/ilackarms/repo-analyst registered both via curl to /v0/apply and through the new dialog: the controller pinned the commit and the UI rendered the full manifest and inventory (3 skills, 3 commands, 1 agent); a second commit-pinned tag registered through the dialog grouped correctly (+1 tag count, tag selector); a plugin with a nonexistent repo rendered the SourceUnresolvable failure state. cd ui && npm test (75 passed), make lint-ui (0 errors), tsc --noEmit clean.

Change Type

/kind feature

Changelog

The registry UI now supports Plugins: register a plugin from a git source, browse plugins in the catalog with their resolution status and pinned commit, and inspect the controller-derived manifest and inventory (skills, commands, agents, and the hook/executable risk surface).

Additional Notes

• No backend changes; the UI consumes the existing generated TS client (listPlugins + /v0/apply).
• Deleting plugins from the UI is intentionally out of scope, matching the other kinds (the card supports showDelete for future use, like SkillCard).

[github-actions]

This pull request has been marked as stale due to no activity in the last 14 days. It will be closed in 3 days unless it is tagged "no stalebot" or other activity occurs.

[github-actions]

This pull request has been closed due to inactivity.