@trapstreet/dsh-trapstreet

Readme

# @trapstreet/dsh-trapstreet

You installed some DeepSeek Harness plugins. Are any of them actually running?

```
dsh plugin --profile <name> add @trapstreet/dsh-trapstreet
```

<sub>Or `dsh plugin --profile <name> add github:trapstreet/dsh-trapstreet` to skip npm.</sub>

---

## `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](https://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

```js
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