dsh-composer-prediction

dsh-composer-prediction

ChatGPT-style composer predictions for DeepSeek Harness.

After each assistant turn, the plugin asks a cheap chat model for the message you are most likely to send next and paints it as ghost text in the empty composer. Press Tab to insert it into the draft (nothing is sent), Esc to dismiss it, or just start typing to discard it. Turn the whole thing off in Settings → Predictions, a dedicated Settings section this plugin contributes (settings.section), because the shipped Plugins page is read-only.

Behaviour

Install

From the npm registry:

dsh plugin --profile <your-profile> add dsh-composer-prediction

Or straight from a checkout:

dsh plugin --profile <your-profile> add ./dsh-composer-prediction --config.auto-install-peers=false

dsh links the package into the profile and appends the bundle to dsh.profile.bundles because the package declares dsh.bundle. Restart the app afterwards (a page refresh only reloads the browser half).

Verify the layer composed without booting:

dsh --profile <your-profile> --dump-config

You should see a # == dsh-composer-prediction layer and a composer-predict row.

Remove it with:

dsh plugin --profile <your-profile> remove dsh-composer-prediction

Install from the Discover tab

market/index.json is a ready-to-host plugin-market index listing this package. Turn on Custom plugin markets, then add this URL under Plugins → Discover → Add index source:

https://raw.githubusercontent.com/Amir-Bazylkhanov/dsh-composer-prediction/main/market/index.json

Regenerate it after a release with npm run market.

Configuration

Everything lives in $DSH_HOME/composer-predict.json and in the Settings page. The document is written by the plugin's host half (merge + atomic rename); it is not a settings.yaml namespace because the 0.2.x ctx.settings service is a form layer over loader entries and no longer hands a plugin a live namespace scope.

Model and reasoning

By default the plugin calls the harness's own LLM service (ctx.llm), not a private endpoint. That means:

• it uses the same provider route and credentials as your sessions — with a subscription route (deepseek-account, Kimi, …) you need no API key at all;
• the model is your deployment default (ctx.agentDefaultModel, e.g. deepseek-flash) unless you override provider/model in Settings;
• reasoning is pinned to the model's cheapest advertised effort (model.reasoning.efforts[0]). A next-message guess should not spend a thinking budget; if the model advertises no efforts, the provider default is left alone. Output is capped at maxTokens (64 by default).

The direct OpenAI-compatible HTTP path (baseUrl + apiKey) exists only for compositions with no ctx.llm; it is not used in a normal DSH install.

If a prediction cannot run, the reason is no longer swallowed: the Settings card shows it and the browser console logs [composer-predict] ….

Settings page and status

The plugin contributes its own Settings → Predictions section (settings.section, the same list slot that hosts "Built-in plugins"), with the enable switch, provider/model overrides and timing.

There is no placeholder state: the ghost text simply appears when it is ready. When a prediction comes back empty or fails, the composer shows the reason instead (no prediction: no-model-route, composer-predict: provider HTTP 401, …) and keeps showing it until you type, dismiss it, switch session, or disable the feature. The console logs [composer-predict] … in both cases.

How it works

 host half (lib/index.js, lib/handler.js)
   ├─ config document `composer-predict.json`  → $DSH_HOME
   └─ POST /api/composer-predict/rpc         → config.get / config.set / predict / cancel
                                                └─ chat completion → normalizeSuggestion()

 browser half (lib/client.js)
   ├─ slot conversation.input.overlay  → ghost text over the empty composer
   ├─ slot settings.section            → "Predictions" Settings page
   ├─ useChat(legacy.nodes)            → transcript tail
   ├─ useInput(draft) / useSession(running) → eligibility
   └─ capture keydown                  → Tab accepts, Esc dismisses

The overlay measures the real [data-composer-input] element and clones its font metrics, so padding, wrapping and height follow the composer instead of guessing at CSS. The native placeholder is hidden (and restored) only while the ghost is visible.

Bundles are built without a toolchain: scripts/build-client.mjs concatenates the shared helpers and the component body into the window.__ModuleLoader__ factory the host serves — no bundler, no dependencies, no network.

Development

node scripts/build-client.mjs   # regenerate lib/client.js
node scripts/test.mjs           # 33 tests across shared/host/client
node --check lib/index.js

Tests cover suggestion normalization, transcript extraction, prompt building, config sanitization, every RPC endpoint (with a stubbed provider), cancellation, and a VM smoke test that loads the generated bundle, runs apply() and renders the overlay.

Manual verification

The client exposes window.__composerPredict so the overlay can be exercised without waiting for a turn:

__composerPredict.suggest('Add a regression test for the empty-input case.')
__composerPredict.state()
__composerPredict.clear()
__composerPredict.predictNow()   // re-run the real prediction path

Coexistence

Install only one composer ghost-text plugin. A plugin such as dsh-next-hint paints a suggestion into the same empty composer for the same finished turn, so installing both means two overlapping ghosts and two model calls per turn. Both also accept Tab while a ghost is visible, so one Tab press can act on both offers. Pick one.

If both are installed anyway, this plugin stands down at runtime: it checks the client module manifest for known ghost-text packages (dsh-next-hint), watches the composer overlay slot for ghost-like entries, and recognises dsh-next-hint's data-next-hint* DOM markers. While a conflict is detected no prediction is requested or painted, Tab/Esc stay untouched, and Settings → Predictions says why. Detection also re-runs on DOM and slot changes, so a plugin that mounts late is caught before the next turn.

Ghost-text plugins can opt into the shared data-composer-ghost attribute on their painted ghost node, present only while a suggestion is visible (this plugin sets data-composer-ghost="dsh-composer-prediction" there). The always-mounted anchor is marked with data-composer-predict instead, so a plugin can tell "this plugin is loaded" from "a suggestion is visible". A plugin that wants dynamic deference can gate on the marker; this plugin's own pause is presence-level.

Deference here is one-way by design: while another ghost plugin is present this plugin stays paused, even between that plugin's offers, so with both installed dsh-next-hint is the deterministic winner and the two never race for the same composer.

Limitations

• The prediction triggers on the idle transition; if you are already typing when the turn ends, no offer is made (deliberately: it should never fight the user).
• The ghost is positioned over the first line of an empty composer; a composer pre-filled with attachments does not show an offer.
• predictNow needs a finished turn to have transcript context.
• Verified against DSH 0.2.1-rc.2; the client bundle targets the conversation.input.overlay slot and the data-composer-input contenteditable introduced in 0.1.5.

Credits

The Settings navigation glyph is from SVG Repo and is CC0 1.0 (public domain; no attribution required — the credit is a courtesy). It has been modified: cropped viewBox, filled with currentColor via an alpha mask. See NOTICE for details.

License

MIT