@wowyuarm/dsh-context-continuity

dsh-context-continuity — one continuous context across many Sessions

English | 简体中文

Let a DeepSeek Harness agent manage its own context, and turn its past Sessions into context it can draw on.

The problem

Every Session eventually fills up. It gets compacted, or it rolls over into a new one — and the agent loses the thread. Whatever it was working on, whatever it had figured out, is now on the other side of a wall.

This plugin gives an agent the tools to carry itself across that wall on its own: when a Session is getting full, it writes a quick handoff and keeps going in a fresh one as the same agent; it can mark a spot to come back to; and — with the optional search tools mounted — it can search back through its earlier Sessions and pull out what it said or did. Any agent that runs long enough to fill a Session can use it — a Loom individual, an Agent Team member, a coding agent on a long task.

What the agent gets

Three tools it can call, plus one automatic safeguard — these ship ready to use, so every plugin that adopts this gives its agents the same set:

• context_rollover — start a fresh Session but stay the same agent, carrying a handoff you write into the new one.
• context_checkpoint — mark the current spot so you can come back to it.
• context_timeline — look back over your own history and pick a spot that's safe to return to.
• pressure handling — a heads-up when a Session is filling up, and a safe fallback at the limit, so the agent is never forced to switch at a bad moment.

Two more are opt-in — the agent only gets them if you mount createSearchTools yourself:

• context_search — search your earlier Sessions for something you said or did.
• context_read — open one search result and read around it.

They are kept separate because they ask more of your setup than the core does. You supply a session-query port — the published @deepseek-ai/dsh-session-query contract they are typed against, and the peer this package declares for it — plus which past Sessions each subject is allowed to search. The deployment has to hold up its end too: the ladder reads the Harness Session index, so a deployment that leaves that index closed fails closed instead of returning results. The wiring is seam 7 of docs/integration.md.

How it works

The Harness already knows how to fork a Session, start a new one from an old one, and treat the Session log as the source of truth. This plugin doesn't rebuild any of that — it adds the one thing on top the Harness leaves out: tying a string of Sessions together as the same agent over time. It handles the hard parts (the switch itself, the safety checks, working out which past spots are safe to return to) and asks your plugin only for what it can't figure out on its own. The reasoning is in docs/principles.md.

Using it in your plugin

You tell it who your agent is and how to run a Session switch in your own setup — plus, if you mount the search tools, which past Sessions each subject is allowed to search. It does the rest. The step-by-step guide, with code, is docs/integration.md.

Development

npm install
npm test          # package boundary check + unit tests
npm run typecheck # strict TypeScript, no emit
npm run build     # emit lib/

Tests run against the published @deepseek-ai/dsh-* packages — no sibling Harness checkout, so the whole suite finishes in well under a second.