feat(dsh-plugin): experimental obelisk retrieval plugin for DeepSeek Harness

[KinomotoMio]

What this is

An experimental plugin that mounts Obelisk — the cross-tool session archive and its human-approved memory layer — into DeepSeek Harness (DSH) as a second, optional retrieval channel beside DSH's built-in session search. It also gives obelisk_query calls their own card in the DSH web UI. The story below matters more than the code itself.

The story this PR is trying to tell

Every commit here was authored inside DeepSeek Harness. deepseek-v4-pro, running as a coding agent inside DSH, wrote the ADR, the package, the tests, and the client bundle — and DSH produced the commits. The developer never read the DSH source tree to plan this. The integration was derived entirely from what DSH's design says about itself: plugins register tools and system-prompt sections, client views are keyed by wire tool name, skills are discovered from a standard directory. None of that required reading implementation — it required reading the design contract.

It took five short prompts to get from an open question to a working, tested, locally installed plugin with a custom frontend card:

1. "How would obelisk be cleanly designed as a plugin for DSH's session retrieval? What's the differentiation?" → the two-axis analysis: DSH's built-in search is the vertical axis (one tool, one workspace, realtime); obelisk is the horizontal axis (the machine-level archive across tools, plus a memory layer).
2. "Draft it as a reviewable proposal." → ADR-0009.
3. "The decisions are filled in — confirm them." → the ADR is finalized with the reviewer's verbatim answers.
4. "Carry the ADR to its own branch and build the plugin." → the package, the obelisk_query tool, the system-prompt guidance, and the test suite.
5. "Obelisk calls are bash under the hood — can the UI show them as something distinct? Can't the plugin contribute to the frontend?" → the dsh.client half and the dedicated card.

Why that velocity is the actual claim. This is the idea we have been pointing at for a while: DSH moves harness complexity out of the model's context. Tools, prompt sections, and client views are aspects declared through the plugin contract — not code paths an agent has to discover by reading source. Harness engineering becomes AOP, and the contract is small enough to deduce. If the aspects are the contract, then even a meta-harness — a harness that composes other harnesses — stops being "a codebase you must read" and starts being describable as a skill. This PR is a data point for exactly that: the harness was integrated by reasoning about its aspects, in five prompts.

What's inside

• docs/adr/0009-obelisk-as-dsh-optional-retrieval-plugin.md — the accepted design record, including the frontend-presentation addendum.
• packages/dsh-plugin/ (@obelisk/dsh-plugin), a Cordis plugin:
  • one read-only tool, obelisk_query: bounded JavaScript query → obelisk CLI sandbox → capped JSON result, with readable errors for failures, timeouts, and non-JSON output;
  • a system-prompt section that splits the work: session_search for this tool's own history, obelisk_query for the cross-tool archive and memories;
  • the existing obelisk skill is reused unchanged — the model's understanding of obelisk is not rewritten for DSH;
  • a dsh.client browser half that renders a dedicated obelisk_query card (monolith glyph, bounded query summary, expandable QUERY/RESULT) on DSW theme tokens. Three invariants hold: the model-facing surface is unchanged, the durable session record is untouched (the card is only a projection of the frozen call slice), and only the obelisk_query key is claimed.
• Tests: 6 plugin tests + 6 client-model tests; the full suite, typecheck, and lint are green.

An experiment, not a delivery

This PR does not target merge. It is a probe of how far five prompts and the plugin contract can go, and the code does not chase extreme polish. That said, if the code turns out to be reasonable, merging it would simply be a better outcome — the author is not the judge of that.

It is also not complete delivery of obelisk on DSH. The archive does not index DSH's own sessions yet, so obelisk_query retrieves every other tool's history but not DSH's. Until DSH session indexing exists, the two channels are complementary in one direction only. That gap is tracked in #60.

Known limits from the ADR: obelisk is an archive, not a realtime index (just-finished conversations wait for the next indexing round; DSH's built-in search remains the right channel for "just now"), and the originally imagined card for bash-invoked obelisk CLI calls was deferred — toolviews are keyed all-or-nothing and the client purity gate forbids reusing DSH's bash row, so only first-party obelisk_query calls get the custom card in this PR.

Trying it

# on feat/dsh-plugin
pnpm --filter @obelisk/dsh-plugin build

# in ~/.dsh/profiles/web
pnpm add file:/path/to/obelisk/packages/dsh-plugin
# append to cordis.patch.yml:
#   - insert: { id: obelisk, name: '@obelisk/dsh-plugin' }

# restart `dsh web`

Requires obelisk CLI ≥ 0.2.3 (the query-time index-refresh exemption when the daemon holds the write lease). Defaults: 30s timeout, 24000-char result cap, cliPath: obelisk.

It illustrates the unique calling format of obelisk in frontend rendering.

[KinomotoMio]

I only made a few high-level decisions, so the implementation might include parts that don't match my personal review standards. What I keep is the clean, internal self-contained implementation.