dsh-trapstreet

@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