DSH Plugin Hub 2.2.5: market, notifications, custom install

2.2.5 is not a reskin: it pulls four daily jobs — browsing the market, watching progress, installing something outside the catalog and tuning market behavior — into one interface. The test of any release is whether it changes the path your hands take every day, and this one changes exactly that: the market toolbar, the notification center, the three custom-install cards and the five settings groups can all be checked against the official screenshot index (2.2.5 index). The entry to DSH Plugin Hub has not moved; what changed is how you work once you are inside.

DSH Plugin Hub 2.2.5 market: search, sort and categories on one toolbar

The real change is not extra buttons but compression: search, result count, sort and category now share one toolbar, so the filter state and the card state are visible at the same moment. Previously you had to keep asking "am I still filtered to Installed?"; now the toolbar sits beside the list and a wrong filter is obvious.

1. Open Settings → Plugin Market, stay on the market tab and confirm all four toolbar controls are present.
2. Type a function word and watch the result count change; if it does not move, the category filter is probably hiding results.
3. Switch the category to Not Installed, sort by Recent descending and scan the first ten cards to build a candidate pool.
4. Open one card and confirm that version, category and topics match the job you have in mind.

This section only produces candidates; it does not decide whether to install. Stop at five to ten cards and let the card signals do the rest. For the whole loop, see your first five minutes in dsh plugin market.

Notifications and system logs: DSH Plugin Hub separates progress from history

2.2.5 splits "happening now" from "already happened": the notification center owns live progress and restart reminders, while system logs own an exportable trail of operations. The division is practical — watch notifications during an install, open logs after it fails, and the two never drown each other.

1. After clicking Install, open the notification center and confirm the task moves from in progress to complete, noting any pending-restart reminder.
2. If the task fails, copy the full log from the notification center first so the failure context survives.
3. Switch to system logs, filter by install-related category and error level, and find the entry at the same timestamp.
4. Use Export Logs or Copy Full Text to take the evidence away before deciding whether to retry or change the source.

History entries can be deleted one by one or cleared at once; copy what you need before clearing, or the next investigation has no baseline. System logs also let you relocate the log directory and open the file, which matters when you need long-term records. The full triage sequence is in how to read notifications when a plugin install fails.

Custom install: DSH plugin input formats and validation

The three custom-install cards are not three interchangeable attempts; they exist so that a format error is caught before a request leaves your machine. Each card shows a channel name, an example, an input field and a format hint, so pasting into the wrong card fails in place (2.2.5 index).

1. Decide what you actually hold: a package name, a repository address or an official command.
2. Pick the matching card, paste, and wait for format validation; if it fails, read the recommended format instead of forcing an edit.
3. After validation, check the plugin name and source in the confirmation dialog before approving.
4. Once installed, open Installed, filter by manual source and confirm the plugin carries the manual-install label.

The cards isolate input formats rather than complement one another. For each channel's boundaries and error output, see the three custom install channels.

Settings in dsh plugin market: updates, mirror, proxy and trust

The settings page has five fixed groups in 2.2.5 — Update Settings, Security Trust, System Diagnostics, System Logs and Restore Defaults — and daily work touches the first two most often. Update Settings holds the check-at-startup toggle, an npm mirror dropdown and a proxy address field, each with a title and explanation, so nothing has to be guessed (2.2.5 index).

1. Open Settings → Plugin Market → Settings and check whether the three Update Settings values match your network.
2. On a restricted network, pick a working npm mirror; if mirror lag produces a 404, switch back to the official registry briefly to confirm.
3. If outbound traffic needs a proxy, enter the proxy address on the settings page instead of scattering it across terminal windows.
4. If you never use a custom-install channel, turn off its switch under Security Trust to shrink the surface for executable code.
5. Save, restart DeepSeek Harness, then load the market list once to confirm the configuration took effect.

Restore Defaults is not a magic button: it resets all five groups together, so record the current values first. Per-field guidance and validation live in how to configure DSH Plugin Hub settings.

Upgrading to 2.2.5: a three-part DeepSeek Harness verification

The correct order is record the current state, update, then verify in three places; skip the record and you have no baseline when something breaks. The 2.2.5 changes cluster in the market, notifications, custom install and settings, so confirm all four open after the upgrade.

1. Record the current Hub version, the Harness core version, and every installed plugin with its version.
2. Update to 2.2.5 through the update prompt under Settings → Plugin Market → Installed or through the official channel, then wait for completion.
3. Restart DeepSeek Harness, reopen the market and confirm that cards load and search returns results.
4. Open the notification center and system logs and confirm both show records from before and after the upgrade.
5. Pick any installed plugin and walk the cancel path of an update or uninstall confirmation to confirm the dialog still behaves.

A read-only check after the upgrade

Reading without changing anything separates "the UI moved" from "the feature works".

# 1. Confirm Hub is still present in the current profile
dsh plugin --profile web list | grep -i hub
# 2. Confirm the Hub load layer exists in the composed config
dsh --profile web --dump-config | grep -in hub
# 3. Record the post-upgrade CLI version for comparison
dsh --version

Expected: all three commands print something. If one is empty, confirm the --profile value first and check whether Hub lives in another profile; do not reinstall immediately.

The three checks map to three kinds of evidence: the interface opens, the data loads and operations leave records. If any one fails, read how to read the Hub changelog before deciding to roll back or wait for a patch. Never reinstall repeatedly without a recorded baseline.

For the broader picture of what the market contains, DSH Plugin Hub is the entry point, and the practical browsing route is in dsh plugin market first week.