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 ~46 of 1500+ 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