Render plugin registry browse entries as cards #201

New issue

Closed

opened 2026-06-01 15:53:40 +00:00 by steve · 0 comments

steve commented

2026-06-01 15:53:40 +00:00

Owner

Problem

The Plugins settings Browse tab currently renders official registry entries as a dense list. The separate lapis-plugin-registry site presents the same catalog as scan-friendly cards, and the app should use a similar shape so plugin names, summaries, provenance, install state, and update recency are easier to compare.

Goal

Render plugin registry browse entries as cards in the app settings UI and show each plugin's latest known update time when registry metadata includes it.

Scope

Update the workspace Plugins settings Browse tab to use a card-grid/list presentation modeled on /Users/stevejuma/code/lapis-plugin-registry.
Surface a "last updated" or equivalent timestamp from verified registry entry/detail metadata, with graceful fallback when metadata is absent.
Preserve existing search, filter, install/update, status, source, compatibility, and diagnostic behaviors.
Update the relevant specs if the UI or metadata contract changes.

Non-goals

Adding third-party registry source management.
Changing the plugin verification, install, update, uninstall, or signing trust model.
Changing the public registry website beyond using it as the visual reference.

Acceptance Criteria

Browse renders registry plugins as cards with title, description, version/provenance/status context, and existing actions.
Each card shows the plugin's last updated time when registry metadata provides it, formatted in a compact user-facing way.
Opening details uses a wide modal instead of inline expansion.
The details modal keeps the filtered Browse result set visible in a resizable left sidebar, and selecting another plugin replaces the modal detail content without losing the filtered list.
Missing update metadata does not render misleading stale dates or break browse rendering.
Existing browse search/filter and install/update actions still work.
Focused package checks pass for affected packages, and app smoke runs if the runtime shell is affected.

Implementation Notes

Compare the app UI against /Users/stevejuma/code/lapis-plugin-registry before editing the workspace component.
Prefer existing settings/UI styling tokens over introducing a separate card system.
If registry metadata lacks a direct updated-at field in the app contract, either map an existing release metadata timestamp or add a narrow optional field through the API contract and fixture path.
Keep modal navigation scoped to the already-filtered Browse entries so the detail view mirrors the list the user was looking at.

Suggested Files or Specs To Inspect

packages/workspace/src/lib/components/configuration/plugin-extension-panel.svelte
packages/workspace/src/lib/components/configuration/
packages/api/src/lib/plugin-distribution/
spec/src/20-packages/workspace/index.md
spec/src/20-packages/api/index.md
spec/src/30-cross-package-contracts/plugin-registry.md
/Users/stevejuma/code/lapis-plugin-registry

Validation Commands

pnpm --filter @lapis-notes/workspace check:all
pnpm --filter @lapis-notes/api check:all if API contracts change
make spec-lint and mdbook build spec if spec changes
pnpm test:smoke if the running app shell behavior is affected

Follow-up to #175 — Add Plugins settings registry UI

Follow-up Tasks

Implementation Summary

Rendered plugin registry Browse results as scan-friendly cards with latest-release update dates from verified detail metadata. Details now open in a full settings-width modal with a resizable filtered-result sidebar and replaceable README/detail content. Updated workspace specs and validated workspace checks, spec lint/build, browser verification, and smoke.

## Problem The Plugins settings Browse tab currently renders official registry entries as a dense list. The separate `lapis-plugin-registry` site presents the same catalog as scan-friendly cards, and the app should use a similar shape so plugin names, summaries, provenance, install state, and update recency are easier to compare. ## Goal Render plugin registry browse entries as cards in the app settings UI and show each plugin's latest known update time when registry metadata includes it. ## Scope - Update the workspace Plugins settings Browse tab to use a card-grid/list presentation modeled on `/Users/stevejuma/code/lapis-plugin-registry`. - Surface a "last updated" or equivalent timestamp from verified registry entry/detail metadata, with graceful fallback when metadata is absent. - Preserve existing search, filter, install/update, status, source, compatibility, and diagnostic behaviors. - Update the relevant specs if the UI or metadata contract changes. ## Non-goals - Adding third-party registry source management. - Changing the plugin verification, install, update, uninstall, or signing trust model. - Changing the public registry website beyond using it as the visual reference. ## Acceptance Criteria - Browse renders registry plugins as cards with title, description, version/provenance/status context, and existing actions. - Each card shows the plugin's last updated time when registry metadata provides it, formatted in a compact user-facing way. - Opening details uses a wide modal instead of inline expansion. - The details modal keeps the filtered Browse result set visible in a resizable left sidebar, and selecting another plugin replaces the modal detail content without losing the filtered list. - Missing update metadata does not render misleading stale dates or break browse rendering. - Existing browse search/filter and install/update actions still work. - Focused package checks pass for affected packages, and app smoke runs if the runtime shell is affected. ## Implementation Notes - Compare the app UI against `/Users/stevejuma/code/lapis-plugin-registry` before editing the workspace component. - Prefer existing settings/UI styling tokens over introducing a separate card system. - If registry metadata lacks a direct updated-at field in the app contract, either map an existing release metadata timestamp or add a narrow optional field through the API contract and fixture path. - Keep modal navigation scoped to the already-filtered Browse entries so the detail view mirrors the list the user was looking at. ## Suggested Files or Specs To Inspect - `packages/workspace/src/lib/components/configuration/plugin-extension-panel.svelte` - `packages/workspace/src/lib/components/configuration/` - `packages/api/src/lib/plugin-distribution/` - `spec/src/20-packages/workspace/index.md` - `spec/src/20-packages/api/index.md` - `spec/src/30-cross-package-contracts/plugin-registry.md` - `/Users/stevejuma/code/lapis-plugin-registry` ## Validation Commands - `pnpm --filter @lapis-notes/workspace check:all` - `pnpm --filter @lapis-notes/api check:all` if API contracts change - `make spec-lint` and `mdbook build spec` if spec changes - `pnpm test:smoke` if the running app shell behavior is affected ## Related Issues - Follow-up to #175 — [Add Plugins settings registry UI](../closed/175-add-plugins-settings-registry-ui.md) ## Follow-up Tasks ## Implementation Summary Rendered plugin registry Browse results as scan-friendly cards with latest-release update dates from verified detail metadata. Details now open in a full settings-width modal with a resizable filtered-result sidebar and replaceable README/detail content. Updated workspace specs and validated workspace checks, spec lint/build, browser verification, and smoke.

steve added this to the Full Registry V1 milestone

2026-06-01 15:53:40 +00:00

steve

2026-06-01 15:53:40 +00:00