e8f5c0b51b
Minimal Electron shell over the DSH JSON-RPC runtime — a first-look at what a ChatGPT.app-style host on top of the DeepSeek Harness looks like, with the harness's normally-invisible internals (trace timeline, context surface, subagent tree, compaction, plugin registry, rubrics) brought forward as first-class UI surfaces so plugin authors and researchers can see what the agent is actually doing. Runs against three keyless-to-live profiles (stdio-echo works on master out of the box; daemon-echo / daemon-vibe-echo activate once the daemon-demo lands; stdio-deepseek and daemon-vibe hit the real DeepSeek API when you supply a key). HARNESS_DEV auto-resolves to the in-repo runtime when this shell ships under examples/desktop/, so a fresh clone launches without config; env DSH_DEV_ROOT overrides for custom layouts, and a sibling deepseek-harness-dev/ checkout is the original dev workflow. Cold-clone gate (P0 fixes for first-time-clone usability): - HARNESS_DEV: 3-candidate resolver (env → walk-up in-repo marker → sibling), unit-tested via mock fs so ordering is locked without needing either real layout on disk. - config yml leaves rewritten at assemble time so the sibling-clone paths (../../deepseek-harness-dev/examples/echo-agent/…) become the in-repo paths (../../echo-agent/…) in the released tree — source yml stays usable for local dev, released tree ships a working shape. - pnpm-workspace.yaml allowBuilds.electron = true (was placeholder). - missing-key card in stdio-deepseek offers a one-click switch to stdio-echo (the keyless profile that works on master) rather than daemon-echo (blocked on the not-yet-shipped daemon-demo). - assemble-oss-release.sh rewrites the source-side breadcrumb name 'dsh-desktop-demo' → 'dsh-desktop' for the released package.json. FOUC guard on the onboarding gate (41fc5df carried) keeps the first-launch splash from flashing before the runtime probe finishes. Test suite (1634 tests in source, 3990 in the runtime repo) covers resolver ordering, renderer classifiers, trace timeline shape, compaction diff rendering, rubric parity, and the missing-key onboarding paths.
1006 B
1006 B
name, group, template, executor, version, description
| name | group | template | executor | version | description |
|---|---|---|---|---|---|
| multi-turn-feedback | interaction-reasoning | multi-turn | llm-judge | v1 | Score each assistant turn against the 5 fixed multi-turn dimensions; each dim 1-5 relative to the immediately preceding user feedback. |
Checklist
- Feedback understanding — the model correctly parsed the user's ask
- Fix effectiveness — the response actually addressed the previous feedback
- No regression — behavior that was already good stayed good
- Over-correction — the model changed only what the feedback asked for
- Convergence — the turn is moving toward a stable answer
Notes
- One score per dimension per assistant turn, on a 1–5 scale.
- The pinned prior-user feedback is the anchor: every dim scores this turn relative to that specific prior message, not the whole trajectory.
- Stage-2 of the RL plan uses this rubric alongside the stage-1 task rubric — this one grades feedback response quality, the other grades base task quality.