Commit Graph
7 Commits
Author SHA1 Message Date
Amruth Pillai fcfb18fe5a chore: migrate linting and formatting to Oxc 2026-09-30 22:53:16 +02:00
179861e39e fix(dsh-plugin): support DSH 0.2 host versions (#3552)
* fix(dsh-plugin): accept the DSH 0.2 host line in peer ranges

The Harness peer ranges pinned `^0.1.0-rc.6`, which the 0.2.0-rc.2 host
rejects, so a profile on the new core refused to load the plugin:

  Plugin dsh-plugin-reactive-resume@0.1.0 is incompatible with dsh 0.2.0-rc.2

The host decides that with
`semver.satisfies(runtime, range, { includePrerelease: true })`. Under that
mode the upper bound is what fails: `^0.1.0-rc.6` expands to
`>=0.1.0-rc.6 <0.2.0-0`, and `0.2.0-rc.2` sorts above `0.2.0-0` because the
numeric identifier `0` precedes `rc`.

npm's default mode, which the plugin market's checker uses, is stricter: a
prerelease only satisfies a comparator set that pins the same
major.minor.patch tuple with a prerelease of its own. There the bare
`^0.1.0-rc.6` admits only `0.1.0-rc.6` through `0.1.0-rc.8`;
`>=0.1.0-rc.6 <0.3.0-0` still admits only those three, and `*` admits none of
the 29 published releases. An explicit union is the only form both modes
accept, so the MCP bridge peer and the prompt peer both become
`^0.1.0-rc.6 || ^0.2.0-rc.1`.

The union is additive: everything the old range admitted is still admitted.
`devDependencies` move to `^0.2.0-rc.2` so the package develops against the
core it now claims.

No source change was needed. `dsh-mcp-client@0.2.0-rc.2` keeps its `Config`
union, its `apply(ctx, config)` signature, and the
`mcp__<serverName>__<rawName>` public tool name, while
`dsh-system-prompt@0.2.0-rc.2` keeps `section({ name, order, text })`. The
0.2 additions to the bridge — MCP resource publishing and a
server-instructions prompt section — are additive and scoped to
`ctx.inject(["mcpResources"])` and `ctx.inject(["systemPrompt"])`, neither of
which this package depends on.

The README records the two comparison modes, since the prerelease rule makes
the obvious alternatives silently wrong.

* fix(dsh-plugin): refresh DSH 0.2 lockfile

---------

Co-authored-by: ddddd-ren <ddddd-ren@users.noreply.github.com>
Co-authored-by: Amruth Pillai <im.amruth@gmail.com>
2026-09-30 06:46:49 +02:00
Amruth Pillai f89acb4368 chore: migrate repository links to reactive-resume/reactive-resume 2026-09-12 11:18:32 +02:00
Amruth Pillai d77cb93494 fix: complete repository links and container publishing migration 2026-09-11 11:09:55 +02:00
Amruth Pillai 9550910f17 revert: remove repository migration changes from main 2026-09-11 03:23:27 +02:00
Amruth Pillai 31d6ee6251 chore: prepare repository migration and Docker Build Cloud publishing 2026-09-11 02:55:52 +02:00
Amruth Pillai 65618a82a0 feat/dsh plugin (#3356)
* docs: remove .superpowers

* feat(dsh-plugin): bring the DeepSeek Harness plugin into the monorepo

Moves dsh-plugin-reactive-resume out of its own repository and into
packages/dsh-plugin. It stays a published, public npm package — the only
one here — but now builds, typechecks, tests, and lints under the same
turbo tasks as everything else.

The move pays for itself in the drift guard. Standalone, the plugin kept a
generated snapshot of the tool names scraped from the live server card at
https://rxresu.me, plus a weekly CI job to notice when that snapshot went
stale. Sitting next to packages/mcp, it reads MCP_TOOL_NAME directly, so a
tool rename breaks the prompt guide on the same pull request instead of
days later. The snapshot, the fetch script, and the scheduled job are gone.

packages/mcp gains a ./tool-names export so that import goes through the
public export map rather than another workspace's src.

Also flips autoInstallPeers off. The DeepSeek Harness rc packages declare
peers that are host-supplied and, in one case
(@deepseek-ai/dsh-type-meta), not published at all, so auto-install 404s
the whole workspace. Turning it off drops only optional peers elsewhere;
@neodrag/core was the single hard peer that had been arriving implicitly,
and it is now declared where it is used. Full typecheck and test suites
pass, and pnpm peers check reports nothing new beyond the pre-existing
drizzle-orm range mismatch.

Tests move from test/ to colocated src/*.test.ts and the build output from
lib/ to dist/ to match repository conventions.

* fix(dsh-plugin): ship a bundle manifest and target the current Harness

`dsh plugin add` warned that the package "declares no dsh.bundle — installed
as a plain dependency, not a profile layer", and it was right. Every other
Harness plugin, in-box and third-party, ships a cordis.patch.yml and points
dsh.bundle.patch at it; that declaration is what joins a package to a
profile's bundle stack. Without it the package installed and then sat inert,
and the README's hand-written insert row was a workaround for the gap rather
than the intended way in.

The peer ranges were also a generation behind. They asked for
@deepseek-ai/dsh-mcp-client and dsh-system-prompt at ^0.0.1-rc.1, which
cannot match the 0.1.0-rc.6 a current harness ships, so the plugin could
never have resolved against the thing it targets. Both APIs are unchanged
across the bump — StreamableHttpConfig still takes the same six fields and
PromptSection still takes name/order/text — so this is a range correction,
not a migration.

That bump pays for itself elsewhere. The old generation peer-depended on
@deepseek-ai/dsh-type-meta, which was never published, and working around
that 404 is why merging this package turned autoInstallPeers off for the
whole repository and pulled @neodrag/core in by hand. The new generation
dropped that peer and publishes every other one, so both changes are
reverted and pnpm-workspace.yaml is back to what it was.

Because a bundle patch mounts the plugin the moment it is installed, a
required apiKey would fail config validation and take the profile down
before the user ever had a chance to mint a key. It now defaults to empty
and apply() warns and mounts nothing, matching how dsh-honcho-memory
handles the same problem.

Verified by packing the tarball and installing it into a clean project with
default pnpm settings: it resolves, imports, and reports its exports.
2026-08-18 20:42:42 +02:00