dsh-markdown-input

English | 简体中文

A DeepSeek Harness (dsh) plugin with one core capability — live Markdown rendering in the composer — so that prompts written in dsh are easier to organize and easier to think through.

> Status: alpha, under active development. dsh itself is a developer preview with compatibility-breaking changes between versions — see Compatibility for what has actually been verified on a real machine.

What it does

Live-rendering composer

A low-priority entry on the host's conversation.composer election chain (ADR-0005) takes the composer over with a bundled CodeMirror 6 editor that renders while you type, Obsidian Live Preview style: bold, italic, inline code and strikethrough take their real styles, and syntax markers fold away once the cursor leaves their line. A toggle switches to source mode, where every marker stays visible. Enter sends (IME-safe), Shift+Enter breaks the line, and everything you type mirrors into the host draft, so it survives a page reload.

Markdown-rendered user messages

Sent user messages and queued steering messages render as Markdown in the chat history — reusing the host's own rendering pipeline — instead of a wall of plain text. @-mentions and skill chips are preserved, and the line breaks you typed are rendered as hard breaks.

Paste-to-Markdown

Pasting rich text from a web page or a word processor converts the clipboard's text/html into clean Markdown — in the takeover editor at the caret, and on the native composer through the host's version-guarded insertion API. Ctrl/Cmd+Shift+V still pastes plain text, and plain-text, file and image pastes keep their native behavior.

Graceful degradation, face by face

Every surface probes the host before it activates and degrades on its own: built-in takeover panels (approvals, questions, subagents) outrank this plugin and keep the composer whenever they need it; a missing host surface sheds its own feature, never the text face; and a card-level error boundary silently falls back to the native composer with the draft intact.

Install

Requires dsh with the web UI (the desktop app). The build and automated suite currently target dsh 0.2.1-rc.2; the last on-device verification is 0.2.0-rc.2 — see the compatibility matrix before installing.

dsh plugin --profile web add dsh-markdown-input
dsh plugin --profile web add github:long6177/dsh-markdown-input

Compatibility

This project makes no range claims. What it has instead is a tested matrix — combinations actually run on a real machine, with dates and outcomes — and a standing watch on upstream drift.

• Every npm release so far — 0.2.0-alpha.0 (2026-10-02) through 0.2.0-alpha.20 (2026-10-07), then 0.2.2 and 0.2.3 (2026-10-25) — was re-tested on the official desktop client running the 0.2.0-rc.2 kernel (the current public desktop build still bundles that kernel). Each release ships an acceptance checklist; the per-version index with dates lives in docs/release/README.md. 0.2.1 and the 0.2.2→0.2.3 hotfix cycle were covered by the same-day 0.2.3 retest.
• The dependency pins now target upstream 0.2.1-rc.2: the dev-dependency lockstep and CI stay on it (see package.json), and the full automated suite (typecheck, build, published and fidelity test faces) passes against it as of 2026-10-24. The peer range is widened to ^0.2.0-rc.2 || ^0.2.1-rc.2 — both kernels are verified on device (the current public desktop bundles 0.2.0-rc.2, where 0.2.2/0.2.3 passed on 2026-10-25; the union is required because semver only matches prereleases against comparators sharing their [major, minor, patch] tuple). Drift watch (below) keeps tracking whatever upstream ships next.
• Drift watch. A scheduled repository workflow checks four upstream signals every day: the npm registry (new versions and dist-tags), upstream releases and tags, commits touching the contract paths this plugin depends on, and the official contract documentation. A new upstream version triggers the full test suite plus semver checks against it, and one tracking issue per version (labelled upstream-drift). The workflow only opens issues — it does not change code and does not declare compatibility on its own.

Design notes

Four short lines here, deep dives in docs/design/:

• Why takeover — the composer route's engineering story (paint layer → takeover → revival) and the four precise gaps in the current extension model, each backed by upstream source locations.
• Extension points — a source-backed survey of what the dsh web UI lets plugins touch: slots, the composer election chain, message renderers.
• Native surfaces, rebuilt — surface-by-surface specs for the tool-row popups a takeover has to redraw (command menu, permission presets, model selection).
• Prior art — how mainstream chat composers handle Markdown input, compiled from first-party sources.

Decision records (editor choice, takeover, release ritual, dev-dependency model) live in docs/adr/.

Upstream wishlist. The gaps above translate into five concrete interface wishes — view-layer reuse, native seats surviving a takeover, a formal takeover contract with a conformance suite, plugin scaffolding, and a stability or deprecation policy for the preview period. They are written up in docs/design/why-takeover.md · upstream wishlist and will be published as a Discussions "Ideas" thread for community upvoting.

<!-- post-publish: swap in the live Discussions URL -->

Contributing

CONTRIBUTING.md covers the environment (most work needs no dsh desktop app), what still has to be verified on a real device, and the merge gate: green tests plus a maintainer's on-device re-test. Bugs and feature requests go to Issues (templates provided). The path to becoming a co-maintainer is written down as well — this project is maintained with others, not just by one.

License

MIT. This is a community plugin — not an official DeepSeek product, and not affiliated with or endorsed by DeepSeek.