@trapstreet/dsh-trapstreet
You installed some DeepSeek Harness plugins. Are any of them actually running?
dsh plugin --profile <name> add @trapstreet/dsh-trapstreet
Or dsh plugin --profile <name> add github:trapstreet/dsh-trapstreet to skip npm.
trapstreet_checkup
Reads the live loader tree from inside the running harness. No network, no API
key, no subprocess, no config — instant.
> is anything I installed actually doing anything?
84 plugin entries loaded, 80 active.
Not running:
@deepseek-ai/cordis-plugin-hmr disabled
@deepseek-ai/dsh-pwsh-sandbox disabled
@deepseek-ai/dsh-tool-pwsh disabled
@deepseek-ai/dsh-skill-badge disabled
27 tools available: bash, edit, glob, grep, read, run_workflow, skill,
trapstreet_boards, trapstreet_checkup, web_search, write, ...
It also reports dependencies that never became loader entries at all — the
packages that install cleanly, exit 0, and do nothing because they never
declared dsh.bundle.
Pass classify to also look up what kind of plugin each one is, against the
community directory:
What kinds: 3 session, 1 orchestration
1 not found in the directory: @trapstreet/dsh-trapstreet
This is the only part that touches the network — without it the checkup stays
local and instant. A package's own name often matches nothing the directory
records (github:icetomoyo/dsh_workflow installs as @dsh-external/workflow,
and only 57 of 1769 listed entries carry an npm name at all), so anything that does
not match is listed as unmatched rather than quietly counted as uncategorised.
The tool list is there because a plugin can load, activate, and register
nothing (state 7 below). Which plugin registered which tool is not
recoverable — the registry keys registrations internally, not by loader
entry — so the two lists are reported side by side rather than as an invented
mapping. If you installed something for a capability and no tool for it
appears, that is your answer.
trapstreet_boards
Looks up the public evaluation boards on trapstreet.run.
Read-only: no account, no key, and it never starts a run.
17 boards: 1 with a DeepSeek baseline, 11 untested on DeepSeek, 5 empty
* ledger-close -- 2 entries, top 0.6 (provisional)
- python-bugfix-diff -- 9 entries, top 0.8
! core-pdf-ocr -- no entries yet -- gap, nothing to compare against
Pass a board id for detail: what it tests, which commit is pinned, and which
entries came from a DeepSeek model. Boards are fetched live, so new ones show
up without updating this plugin.
What neither tool can tell you
Loading is not working, and working is not useful.
A plugin can be active in the loader tree and still contribute nothing, or
break every turn it takes part in. This plugin shipped both of those bugs
itself — see below.
Whether a plugin actually helps needs something else entirely: a task that
exercises its capability, a run, and a baseline to compare against. That is
why an empty board is reported as a gap rather than a match — a board with
no baseline can only hand back a number with nothing to rank it against.
"DeepSeek baseline" is inferred from an entry's model name. That is a proxy
for the harness, not proof of it.
Seven ways a plugin can be broken
Every row below was hit while building and testing this plugin. Only the first
three are visible without running the harness, and trapstreet_checkup covers
exactly those three.
| State | Visible to checkup |
|---|
| 1 | Install fails | ✅ the install errors |
| 2 | Installs, never enters the loader tree | ✅ no loader entry |
| 3 | In the tree, module fails to load | ✅ Fiber phase failed or absent |
| 4 | Loads, then breaks the conversation | ❌ |
| 5 | Loads, is called, returns the wrong shape | ❌ and it surfaces as a network error |
| 6 | Never activates, and stops the harness booting | ❌ nothing inside a harness that will not boot can report on it |
| 7 | Activates, contributes nothing | ❌ phase is active; only the agent knows it has no new capability |
The three states worth spelling out, because each cost real time to find:
5 — render must return blocks, not a string
render: (args, value) => [{ type: 'text', text: '...' }] // not '...'
A bare string lands where the harness expects an array and throws
TypeError: content.some is not a function inside dsh-llm. The stream loop's
catch-all reports that as:
dsh: TRANSPORT: DeepSeek API stream from https://api.deepseek.com failed
The plugin mounts, imports, and gets called — and every call kills the turn
while the error blames the network.
6 — a plugin is not portable across profiles
dsh: plugin tree failed to load: 1 entry did not activate
<plugin>: pending (waiting for service: workspaceRegistry)
dsh-memory-evolve, the highest-starred memory plugin in the community
directory, installs fine, appears in the composed tree, and stops the
headless profile from booting at all — it needs a service only some profiles
provide. The identical install activates normally under web. Nothing warns
you, and --dump-config reports it as mounted in both.
7 — active and empty
A plugin can load, activate, and register nothing. @furongjun1999/dsh-memory
does this when installed without its configuration and Python backend: the
loader is satisfied, and the agent's own summary of its capabilities is
"I have no cross-session memory system."
Related: that same package installs as an empty shell over a git spec,
because it builds under prepublishOnly (publish-time) rather than prepare
(install-time) while files excludes src. From npm it ships code; from
GitHub it does not. How you installed a plugin can decide whether it works.
Do not verify with dsh --dump-config
It writes to profiles/<name>/cordis.yml despite the name, so it fails:
- inside DSH's own agent sandbox —
EPERM
- in headless environments —
SecItemCopyMatching failed -67674, a macOS
Keychain error from dsh itself
Both look exactly like the plugin is missing when it is not. That is why
trapstreet_checkup reads the loader tree in-process instead.
If you do run it, grep for the package name, not the spec you installed
with — they differ for most plugins. github:icetomoyo/dsh_workflow installs
as @dsh-external/workflow.
Developing against a local checkout
Install a packed tarball, never a directory path:
npm pack
dsh plugin --profile <name> remove @trapstreet/dsh-trapstreet
dsh plugin --profile <name> add ./trapstreet-dsh-trapstreet-<version>.tgz
Three traps, all of which produce a plugin that looks installed and is not:
- A directory install creates a symlink whose real path escapes
DSH_HOME,
so peer dependencies stop resolving — state 3 above.
- pnpm caches by version, so reinstalling without a version bump is
silently a no-op and you keep testing the old code.
- The tarball's absolute path is recorded in the profile, so deleting an
old tarball breaks the next install in that profile until you
dsh plugin remove first.
Configuration
| Variable | Effect |
|---|
TRAPSTREET_BASE_URL | API host. Defaults to https://trapstreet.run. |
TRAPSTREET_CALL_LOG | If set, appends one line per tool invocation to that path. |
The call log answers a question stdout cannot: did the agent reach for this
tool on its own? A call that throws leaves only the model's narration behind,
which reads exactly like never having called it.
License
MIT
