[kazemek21]

TL;DR

A buzz://plugin-install Git link pinned to both a commit and a path, for a plugin already installed from that same repository and folder, now opens the Update review that a plugin's Git requestInstall already gets. If the link names another branch or tag than the plugin tracks, the review says so. Before, it hit the Add path's Already installed refusal, so there was no reviewed way to update from such a link. Links without both pins, and links to a plugin installed from another source, are still refused as duplicates.

What changed

• When the installed plugin was imported (not bundled), PluginImport treats a link with both commit and path like a bound requestInstall request when deciding between update and duplicate (src/app/PluginImport.tsx). It reuses the existing same-source check: the installed updateSource must be a Git source whose repository matches the fetched preview's source and whose folder matches the candidate's folder, and the candidate must have the installed manifest ID. Native import saves the requested ref, and later update checks follow it. So when a link's or plugin request's ref differs from the installed Git source's ref, the review adds "Future updates will follow instead of ." An empty ref reads as "the repository default".
• Confirming a requested update (link or plugin request) re-reads the live catalog and refuses with "The installed plugin changed. Close this review and check again." if the installed revision, enabled state or saved source changed after the review opened, so the review's "stays disabled" line can't go stale.
• A requested update of a disabled plugin now says "This plugin will stay disabled.", as the Details Update review already does. Native install already keeps the enabled state, and the review offers no enable switch for updates.
• Docs: docs/plugin-architecture.md, docs/deep-links.md and docs/buzz-help.md describe the pinned-link update.

Protections that still apply: the commit pin (native refuses a ref whose tip differs, and the review re-checks the fetched commit), the folder filter, the access review against the installed manifest, the publisher line and native publisher-continuity refusal, the unsigned-to-signed rollback warning, explicit Update confirmation, and preview discard on cancel. Links with only commit, only path, or neither, and pinned links to a bundled plugin, keep showing Already installed / Open in Buzz.

Not in scope: update discovery, Update-all, managed policy feeds or checkers (#2504, #2621, #637), signature or publisher-trust policy (#2212, #2746), and the compact request dialog (#2625). This PR doesn't touch their hunks. #2983 and #2762 also edit tests/browser/plugin-import.spec.mjs; this PR leaves that file unchanged.

Supported operation

On a Buzz desktop build that includes this change, open buzz://plugin-install?repository=<repo>&ref=<ref>&path=<folder>&commit=<40-or-64-hex> for a plugin whose installed copy came from a Git import of that same repository and folder. The review shows Update , with access changes listed against the installed version, and states any change to the branch or tag later updates follow. Nothing changes until you choose Update. Native import still refuses the update if the ref's tip isn't the pinned commit, or if the publisher changed or a signed plugin became unsigned.

Tests

New src/app/PluginImport.test.tsx cases, all with fictional example.com fixtures:

• A pinned link to the installed source reviews as Update, installs the pinned folder, and doesn't call enable. This is the regression test for the original failure.
• A disabled plugin stays disabled and the review says so.
• A pinned link with another ref than the installed plugin tracks (a named ref, or the repository default) reviews as Update, says which ref future updates will follow, and installs on Update. A same-ref link shows no such line.
• A link without both pins (none, path only, commit only), or a pinned link to a bundled plugin, still shows Already installed with Open in Buzz.
• An installed source in another repository or folder, a local folder, or an unknown source is refused with the source-mismatch message and Open in Buzz.
• When only another plugin ID is installed from that source, the link offers a new install.
• A fetched commit that differs from the pin offers no Update.
• Cancel discards the preview without installing.
• If the installed revision, enabled state or source changes after the review opens, Update is refused, for both a link and a plugin's requestInstall.

The request and link harnesses now return a ready catalog from plugins.snapshot(), which the new confirm-time check reads.

Checked on a Linux box at 37cf73e1: biome check on both files, pnpm typecheck, and vitest run src/app/PluginImport.test.tsx (100 passed). After the first review fixes, the same three checks passed locally (102 tests), and the bundled-plugin test fails on the earlier predicate. The later enabled-state drift case (two lines plus one test input) passed biome locally; host load refused a local test run, so PR CI covers it. With only the requested line reverted, 6 of the 8 pinned link tests fail. Against main's PluginImport.tsx, the same 6 fail and the other 94 pass. The two that pass either way are the existing pin-retry test and the other-plugin-ID new-install case, which should behave the same before and after.

After review feedback, the tracked-ref disclosure was verified on a Blox box at e913727f: biome check, pnpm typecheck and vitest run src/app/PluginImport.test.tsx (103 passed). With the review line disabled, the new tracked-ref test fails. The before/after screenshots predate this line and show a same-ref update.

Before / after

These screenshots come from a temporary Chromium journey using the existing nativeImports IPC fixture and fictional example data; the journey is not committed. It installs example.linked from https://github.com/example/plugins at plugins/linked, then delivers the same pinned link again with a newer candidate.

	Light	Dark
Before (main)
After

Remaining gaps

• No native (Tauri) run: the Playwright screenshots use the existing IPC fixture. Native import, publisher continuity and the deep-link handoff were not changed here.
• No human has tried it in the app yet, so buzz-review-completed is not set.

Initiative context

Status: https://g2.sqprod.co/apps/kylez-buzz-improvements-status (buzz-improvements T027).

Fixes NEXUS-4327

🤖 Generated with Claude Code

[tellaho]

🤖 Design review at c5161825879777dc70b2570442d9c7a37104f0d3: no design blockers found. Pinned links now reach an explicit Update review, compare access with the installed version, and preserve whether the plugin is enabled. The supplied wide light/dark screenshots are consistent.

Reviewed the diff, surrounding source and regression cases; did not run tests. Not checked live: native deep-link/update, narrow or enlarged-text layouts, keyboard/focus, agent activity, or rendered disabled/access-change/error states.

[kazemek21]

Thanks for the design pass. Nothing here changes layout: the pinned link reuses the existing Update review, and the only new copy is the "This plugin will stay disabled." line that the Details Update review already shows. I agree the items you listed weren't checked live: native deep-link/update, narrow and enlarged-text layouts, keyboard/focus, and the rendered disabled, access-change and error states. They stay listed under Remaining gaps in the description. The disabled, access-change and changed-plugin refusal states are covered by src/app/PluginImport.test.tsx at c5161825.

— Posted by Claude Code (claude-opus-5-5) on behalf of kylez

[kalvinnchau]

🤖 One update-source correctness issue.

[gilgtm]

🤖 No P0/P1 findings in the deep-dual review of e913727fd5608ca61e3e239e078456ce8d5cec41 against main@80cb3a25569f763a2b36ce473320fe628a17c85f. Reviewed pinned-link update eligibility, confirmation and stale-state guards, native pin/publisher enforcement, source persistence, enabled-state preservation, and regression coverage.

Posted by duel-review skill [driver: codex(high), mode: deep-dual, review synthesized by codex(high)]