[Feedback] Five smaller gaps with reproducible steps (DSH Web 0.1.7-rc.2, Windows, profile=web)

[2JumpSinA]

This is the companion to my longer post (Feedback after ~30 days of daily production use). I'm keeping the five smaller items in one place so they're easy to triage; happy to split them into five separate issues if that's easier for you — the titles are listed at the end.

Each item below is self-contained: environment, what I observed, how to reproduce, impact, and what I'd suggest.

Desensitisation note: all group IDs, user IDs, session IDs and machine-specific paths in this post are placeholders or generic. I've also removed all client/company names. The technical details — versions, package names, record counts, byte sizes — are unchanged.

Environment unless stated otherwise: DSH Web 0.1.7-rc.2, profile=web, Windows, multi-plugin profile, long-lived runtime, sessions fed from both the Web GUI and IM (WeCom) groups.

---

1. The model-facing session-query package is not shipped — the model cannot search its own history

Status: re-verified today on 0.1.7-rc.2.

Observed. dsh-session-query (service contract) and dsh-session-query-sqlite (FTS5 backend) are installed. The model-facing consumer package (packages/session-query/tool-session-query upstream) is not part of the published install.

Evidence.

$ ls <install>/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai | grep session
dsh-session-query
dsh-session-query-sqlite
# ... 25 session-related packages in total, including:
#   dsh-session-format-v2-to-v3, dsh-session-persistence-jsonl,
#   dsh-session-projection, dsh-session-log-export, dsh-session-title ...
# (there is no dsh-tool-session-query)

dsh-session-query/README.zh.md states that reads prefer the live session, that ranked full-text search requires a backend such as dsh-session-query-sqlite, and points to ../tool-session-query/README.zh.md — described there as "for the model as consumer, built on top of this service".

Impact. In a long session the model has no built-in way to look up what the user actually asked earlier. It can only use whatever is still in context, or write its own script to decompress the session log (which is exactly what I do — see item 4). Users end up copy-pasting history by hand, which is precisely the work that should be automatable.

Suggestion. Include dsh-tool-session-query in the default composition (the backend already exists), or make it explicitly enable-able via configuration.

---

2. No documented filesystem location for user/agent-authored skills — and skill <name> gives no hint

Status: re-verified today on 0.1.7-rc.2; <DSH_HOME>/skills still does not exist.

Observed.

• A skill placed in an ordinary directory (e.g. <some dir>/skills/ppt-master/) is invisible: skill ppt-master returns
  "ppt-master" is unknown or no longer available.
• Searching <DSH_HOME>, the DSH install directory and the profile directory turns up no skills/ directory to put one in. <DSH_HOME> today contains: attachments, cache, integrations, llm-deepseek, memories, plugin-src, plugin-src-disabled, profiles, sessions, storages, task-board, vault, ... — but no skills.
• The skill directories that do exist (dingtalk-* / wecomcli-*) appear to be provided by plugin packages rather than discovered from the filesystem.

Impact. A skill that a user or an agent has written cannot be invoked through the skill tool; the only workaround is the crude "just read SKILL.md". The skill ecosystem is effectively limited to published plugin packages.

Suggestion.

1. Define and document a skill root — e.g. <DSH_HOME>/skills/<name>/SKILL.md — or support a skills.dirs configuration entry.
2. When skill <name> fails, say where skills are loaded from and where one can be placed, instead of only unknown or no longer available. For someone writing their first skill this message is a dead end.

---

3. Web UI degrades noticeably on very long sessions; no built-in collapse or virtualisation

Observed. After a session accumulated a few thousand records (about 3 hours of continuous development plus IM group traffic), scrolling and typing in the Web UI became visibly laggy.

Measured, same session:

Metric	Value
Session log	4.69 MB compressed / 16.68 MB uncompressed
Records	3,549 (tool/call 710, tool/result 720)
Must be rendered	644 chat bubbles + 1,430 tool cards
Oversized records	43 records > 50 KB, largest 107 KB
Web process	599 MB resident, 710 s cumulative CPU

Supporting evidence that this is general, not my edge case: a community plugin already exists whose whole purpose is to collapse completed turns into a single processed in Xs line (kudos to its author) — meaning "long session rendering" is a shared pain.

Impact. During long development you must either start a new session mid-task (losing continuity) or work with the lag.

Suggestion. Built-in turn collapsing and/or message virtualisation; optionally a threshold hint ("this session has 3,000+ records; consider starting a new one").

---

4. The session log is appended multi-frame zstd; there is no official way to read or grep it

Observed and reproduced.

// One-shot decompression returns only the FIRST frame:
zstdDecompressSync(readFileSync('session.v3.jsonl.zstd')).toString()
// → a 4.69 MB file yields a single line {"type":"session",...}: it looks empty

// Streaming decompression dies on the second frame:
createZstdDecompress()  // → error: Unknown frame descriptor

What worked (my current approach): scan for the magic number 28 B5 2F FD, split into frames, zstdDecompressSync each frame, then concatenate:

4.69 MB (compressed) → 1,946 frames → 16.68 MB of text → 3,549 JSONL records

Impact. Anyone — including the application layer — who wants to look up history by keyword has to reverse-engineer the multi-frame layout first, and is likely to conclude "the session is empty" when it isn't.

Suggestion.

1. Document the format explicitly: one zstd frame is appended per batch.
2. Provide an official read path, e.g. dsh session grep <pattern>, or wrap multi-frame decompression in the official reader.

---

5. The Web GUI session and IM group sessions share one session id — is that intended?

Observed. A single Web session id was mapped to one direct IM conversation and to several group conversations at the same time:

# environment (Web side)
DSH_SESSION_ID=session-0000…

# dsh-im state mapping (IM side)
"direct:woXXXX…"      → session-0000…
"group:wrXXXX… (group 1)" → session-0000…
"group:wrXXXX… (group 2)" → session-0000…

(Group names and IDs replaced with placeholders; the mapping itself is verbatim.)

Impact.

1. Group messages and GUI conversation land in the same history, so the session grows far faster than pure GUI use — 16.68 MB in about three hours in my case.
2. The two contexts contaminate each other: one session is being written from two entry points.
3. When you start or fork a session, the IM binding does not follow, which makes it easy to assume "the new session will take over the group messages" — it won't.

Suggestion. Please clarify whether this is intended or a default. If it's a default, consider binding IM to its own session by default, or at least badge the session in the UI: "this session is currently shared by N groups".

---

Ready-to-split titles (if you prefer separate issues)

1. dsh-tool-session-query is absent from the published composition — the model cannot search its own session history
2. No documented filesystem location for agent-authored skills — skill <name> cannot see them
3. Web UI degrades noticeably on very long sessions; no built-in collapse or virtualisation control
4. Session log is multi-frame appended zstd; no official way to read or grep it
5. The Web GUI session and IM group sessions share one session id — is that intended?

Happy to add a minimal reproduction for any of these, or to test a fix on this setup.

中文摘要（点击展开）

中文摘要（五条缺口）

1. 面向模型的会话检索包没有随组合发布（今天在 0.1.7-rc.2 上复核仍成立）：dsh-session-query 与 dsh-session-query-sqlite 都在，dsh-tool-session-query 不在。后果：超长会话里模型没有任何内置手段回查"用户前面说过什么"，只能靠上下文残留或自己写脚本解压会话文件。建议纳入默认组合。
2. 用户/agent 自写技能没有可放置的位置（<DSH_HOME>/skills 仍不存在）：放在普通目录里的技能，skill <name> 返回 unknown or no longer available；建议明确技能根目录（或 skills.dirs 配置），并让报错提示"技能从哪里加载、可以放到哪里"。
3. 超长会话让 Web 界面明显卡顿：3,549 条记录、展开 16.68 MB、需渲染 644 个气泡 + 1,430 张工具卡片、进程常驻 599 MB；社区已有"折叠已完成轮次"的插件，说明是普遍痛点。建议内置轮次折叠/虚拟滚动 + 阈值提示。
4. 会话文件是多帧追加 zstd，没有官方读取方式：一次性解压只出第一帧（看起来像空文件），流式解压到第二帧报 Unknown frame descriptor；我靠扫魔数 28 B5 2F FD 切出 1,946 帧才能检索。建议把格式写进文档，并提供 dsh session grep 之类的官方入口。
5. Web 会话与 IM 群会话共用同一个 session id：一个 Web session 同时映射到 1 个单聊 + 多个群聊 → 历史混在一起（3 小时到 16.68 MB）、上下文互相污染、且分叉会话时 IM 绑定不会跟着走。请澄清是有意还是默认。

脱敏声明：本贴所有群 ID / userid / session id / 本机路径均为占位符或通用写法，客户与公司名已全部移除；版本号、包名、记录数、字节数等技术细节未改动。