dsh-adrian-inject-context

Inject Context for DeepSeek Harness (DSH): persist your own context entries and have them injected as a standalone Remember: row — right after your message — on every turn or once per session, per entry.

Features

• Standalone sourced row — never touches the initial system prompt or the shared runtime-context snapshot
• Simple / Advanced datasets — two independent context lists; the active mode's dataset is what gets injected (exclusive)
• Per-entry checkboxes — toggle any entry on/off, applies from the next request
• Per-entry frequency (v0.3.0) — each entry has an Every turn switch: ticked (default) the entry is injected right after every message; unticked it is injected only at the start of a session and never again — restart-safe, detected from the session's persisted sourced-message surface plus in-memory per-session tracking
• Native Settings UI — Settings → Inject Context: add, edit, delete, toggle, save
• Persistent — datasets and active mode survive sessions and restarts
• Standalone manager page — also available at /adrian-inject-context

Screenshots

Settings → Inject Context — manage your datasets

Remember: row in the Trajectory

Install

dsh plugin --profile web add polohot/dsh-adrian-inject-context

Usage

1. Open Settings → Inject Context
2. Add context entries; per row, two switches:
   • Enabled — off = never injected
   • Every turn (ticked by default) — ticked = injected right after every message; unticked = only the first message of a session
3. Pick the active tab (Simple/Advanced) — its dataset feeds the injection
4. Send any message and check the Trajectory: your message sits above the Remember: block (order: SYSTEM → your message → Remember:)

Per-entry frequency (v0.3.0)

Once-per-session entries are restart-safe: a process restart never re-injects a once-entry into a session that already carries it. Prior injection is detected from the session's persisted sourced-message surface (the adrian-inject-context:lessons rows) plus in-memory per-session tracking while the process lives. Unticking an entry mid-session lets it appear on the next message exactly once more, then never again — per dataset, so Simple and Advanced stay fully independent.

Configuration

Store: ~/.dsh/adrian-inject-context.json (schema v2, auto-migrated from v1):

{
  "version": 2,
  "mode": "simple",
  "simple":   { "lessons": [{ "id": 1, "text": "…", "enabled": true, "everyTurn": true }] },
  "advanced": { "lessons": [] }
}

everyTurn was added in v0.3.0 without a schema bump — entries missing the field default to true (the previous every-turn behavior).

Requirements

• DeepSeek Harness dsh ≥ 0.2.0-rc.2 (tested on the web profile)
• Not compatible with dsh 0.1.x — see Session format v4 below

How it works

Host-side: an agent/pre-step waterfall listener composes the block per step — all enabled every-turn entries plus enabled once-entries not yet delivered to that session — and splices the plugin's own independently-sourced user-role message right after the turn's user message (the same pattern as dsh-agent-instructions), freshly read from the store on every step. It never injects into an empty entering batch (the agent loop's turn-close signal). Client-side: a settings-section module renders the manager against two host routes. Zero system-prompt modification.

Session format v4 (v0.4.0)

DSH 0.2.0 ships Session format v4, which retired the catch-all { kind: 'plugin', plugin: '…' } message source. That kind is now refused at admission: emitting it raises SessionFormatError and aborts the whole turn with format v4 message requires a producer-owned source kind.

This plugin emits the v4 producer-owned form of its own identity:

source: { kind: 'plugin:adrian-inject-context:lessons' }

That is the same kind the shipped v3→v4 migration derives for a third-party plugin, so live rows and rows migrated from older sessions share one identity and the once-per-session surface scan recognises both.

The row's position is decided by a positive test — a user-role row counts as the turn's message only when source.kind === 'user'. Every other producer (the runtime-context snapshot, agent instructions, tool and model rows) declares its own kind and is skipped. v0.3.2 blocklisted the kinds it knew about, so the runtime-context snapshot was mistaken for the user message and the row landed after the snapshot instead of after the message it answers.

License

MIT