* 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>
The cover-letter and MCP OAuth flow suites were gated on environment variables
CI never set, so they never ran. Point them at the job's PostgreSQL. The
cover-letter suite works in its own schema; the OAuth suite gets a database of
its own because it writes signing keys under its own secret, which the e2e
server can't decrypt.
Nothing reads the unit step's coverage report, so test:ci no longer collects it.
Prune the unit and e2e suites to what protects security, user data, public
contracts and past regressions. Drop what slowed development without catching
bugs: markup and label assertions, wrappers that only proved Base UI works,
copied inventories and snapshots, mock call-shape checks, permutation matrices
across templates, fonts and locales, and env-gated suites that never ran in CI.
- Unit: 4749 tests in 421 files become 1212 in 227. PDF tests that rendered or
rasterized every template, font and locale combination go; one render per
template stays and now checks that every visible section reaches a page,
which a blank page used to pass.
- E2E: 55 tests in 35 specs become 11 in 9, one journey per severe area: sign-up
and sign-in, autosave, a failed save during navigation, JSON export and import,
public and password-protected sharing, slug redirects, OAuth consent for MCP
clients, and the assistant.
- Tests a coverage review found to be the only guard of a contract were kept or
restored, each checked by breaking the code it guards.
- Remove exports, tooling and dev dependencies that only the pruned tests used.
- The Semantic CSS guide check now reads indented code fences, so the guide
example it skipped is compiled too.
Bump workspace dependencies to their latest versions and dedupe the lockfile.
The upgrade left stale duplicates in pnpm-lock.yaml that broke the build and tests:
- @deepseek-ai/schemastery resolved to both 3.18.2 and 3.18.4. Both copies declare
the global Schemastery namespace, so dsh-plugin's declaration emit failed with
TS2883 on `Config`. `pnpm dedupe` collapses it to 3.18.4.
- vite's optional tsx peer resolved to 4.23.13 for importers without a direct tsx
dependency and 4.23.15 elsewhere, producing two vitest 5.0.2 instances. Loading
both in one run broke `expect(...).rejects`. Re-resolving tsx unifies the graph.
Upgrades to Better Auth 1.7, expands Custom Styles coverage of item headers, and adds a human-approval step to the AI agent's resume edits.
Breaking for self-hosters using a custom OAuth provider: the callback path changes from /api/auth/oauth2/callback/custom to /api/auth/callback/custom, and installs using OAUTH_DISCOVERY_URL need one additional UPDATE after upgrading. Both are documented in docs/self-hosting/sso.mdx.
- Better Auth 1.7, with the account issuer migration and the jwks alg/crv columns the 1.7 jwt plugin requires
- Agent edits gated behind an approval step, with crash-safe runs and context pruning
- item-header now covers every section header row on every template; adds the item-header-row part
- Fixes provider unlinking, auth error messages, and version conflicts on freshly created resumes
- New /auth/error page, translated across all 53 target locales
- DeepSeek Harness plugin moved into packages/dsh-plugin
- Dependency bumps across the workspace
* 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.
Amruth Pillai
