fix: restore client UI on rc.7 and stop shadowing host packages

[AINightCoder]

Problem

On DSH 0.1.0-rc.7 the plugin's host rows mount and report Mounted, Enabled, but the settings panel never renders and no console error appears. Two independent rc.6 → rc.7 breakages cause this.

1. dsh.client.inject references a package that no longer exists

@deepseek-ai/dsh-client-ui-slots was merged into other client packages and is absent from rc.7:

dsh-client-runtime           ok
dsh-client-locale            ok
dsh-client-ui-conversation   ok
dsh-client-ui-settings       ok
dsh-client-ui-slots          MISSING in rc.7
dsh-client-ui-tool           ok

An unresolvable module name stops the whole client bundle from being served, so GET /plugins/@wnjxyk/dsh-codex-oauth/client.js never fires. The host face is unaffected, which is why the plugin looks healthy in the Plugin list.

The ctx.slots service is alive and unchanged in rc.7 (many first-party packages still inject it), so dropping the stale package name from the inject list is sufficient.

2. Slot settings.models.before was removed

rc.7 ships no .before slot family at all — grepping every first-party client.js for *.before returns zero matches. dsh-client-ui-settings-models now registers under settings.section and settings.onboarding.

Re-registered the panel under settings.section with a label, giving it its own Settings entry. settings.onboarding was tried first and rejected: it renders outside the settings dialog.

tool.call.toolview is unchanged in rc.7, so the image-generation tool view needed no edit.

Verification

Verified end to end on DSH 0.1.0-rc.7 (Windows 11, Node 22.22.2):

• Settings → Codex renders: sign-in state, quota meter, feature toggles, visible-model checkboxes
• Browser sign-in completes; quota reads back Pro / weekly 93% remaining
• Model picker lists all seven GPT models
• Native image input confirmed: pasted a generated PNG and asked GPT-5.6 Sol for the exact text and the three shape colors; it returned DSH-VISION-7391 and teal, yellow, red, none of which appear in the prompt

Notes

The panel now lives in its own Codex section rather than inside the Models page, since rc.7 has no equivalent to settings.models.before. If you would rather keep it on the Models page, that likely needs an upstream slot request in DSH itself.

Version bumped to 0.4.2-rc7fix.3 only to distinguish local builds — retag as you see fit.

[AINightCoder]

Added a third fix to this branch (9632cab), found while running the plugin in a dsh-tui profile.

3. Host packages are declared as dependencies, so a second copy gets installed

The seven @deepseek-ai/* entries are supplied by the DSH installation the plugin mounts into. As regular dependencies the package manager installs a second copy inside the profile, and that copy shadows the flat fallback for every bare specifier resolved from the profile directory.

That is not just wasted disk. It breaks tool dispatch outright, because dsh-tools hands its scheduler to dsh-agent-loop through a module-instance-unique key:

const TOOL_RUNTIME_SCHEDULER = Symbol('@deepseek-ai/dsh-tools.scheduler')  // line 2416
[TOOL_RUNTIME_SCHEDULER] = { prepare, dispatch, finalize, finish }         // line 2564
const scheduler = registry[TOOL_RUNTIME_SCHEDULER]                         // line 1220

Symbol(), not Symbol.for(), so the key is only shared inside one module instance. With a shadowing copy present, the tools row mints the registry from the profile-local dsh-tools while dsh-agent-loop resolves the installation's copy and reads registry[its own symbol] → undefined. Every tool call then dies with:

turn error · Cannot read properties of undefined (reading 'prepare')

How it was isolated

profile	local @deepseek-ai/dsh-tools	tool calls
web (base + web-app + this plugin)	absent, resolves to the installation copy	work
dsh-tui (base + dsh-tui + this plugin)	present, shadows the fallback	fail, every call

The asymmetry is what ruled out version drift: both profiles ran identical dsh-tools bytes (0.1.0-rc.8, scheduler.prepare on the same line number), and the failure tracked the presence of the duplicate, not the version. It also reproduced under both the stock standard preset and a custom one, so it is not preset-specific.

Removing the profile-local copy by hand fixed it immediately. Moving the declarations to peerDependencies prevents it from being installed in the first place, on every profile and every machine. Verified after the change: zero @deepseek-ai/* packages under the profile's node_modules, tree composes identically (95 entries), plugin rows unchanged.

Ranges moved to ^0.1.0-rc.7 to match the rest of the branch. For reference, @deepseek-harness-tui/dsh-tui declares its 24 host packages the same way.

[AINightCoder]

Correction on the third commit (9632cab): #3 already fixes this, and got there first (opened 2026-08-19, still open and mergeable, with a regression test). I found the duplicate-module bug independently while running this plugin in a dsh-tui profile and did not check the existing PRs before pushing. Credit belongs there.

The two fixes are the same in effect, differing only in declaration style: #3 moves the host packages to devDependencies, 9632cab moves them to peerDependencies. I have left a note on #3 arguing mildly for peers, on the grounds that DSH writes autoInstallPeers: false into every profile template itself (dsh-app-boot/lib/index.js:344), so peers cost nothing extra there while additionally declaring the host version the plugin expects. Either resolves the crash.

9632cab should be dropped from this PR in favour of whatever lands in #3. I have deliberately not rewritten the branch, only because two of my own profiles install from it and would regress on the next reinstall. Say the word and I will rebase it out, or just take the first commit.

The part of this PR that #3 does not cover is 0590d00, the rc.7 client-face breakage: dsh.client.inject names @deepseek-ai/dsh-client-ui-slots which no longer exists in rc.7, and the settings.models.before slot was removed. That one is independent and still stands on its own.