Repository navigation
两条真发现 #2
Description
-
dsh: NOT_FOUND_IN_CURRENT_AUDIT——DSH 明明装在这台机器上，46 个会话就是从它索引出来的，但 doctor 的 provider 审计没找到它，effective 状态被降级成 NOT_FOUND。十有八九是审计的 Windows 路径判定问题（audit 找的位置和真实安装位置不一致）。voyager doctor 原样输出就是现成的 issue 证据。
-
provenance: 469,039 events, 0.0% classified——真实索引里 0% 事件被分类。要么分类需要某个开关/重扫，要么分类器对 DSH 的 zstd 事件类型没覆盖。值得直接问作者一句“这在你的机器上也是 0 吗”。
顺带第三条：by_provider 里只有 dsh——OpenCode 适配器缺口有了实机佐证（我这个会话的历史不进索引），草稿一的 #1 条建议现在是从真机上长出来的了。
使用提示（两条，都来自作者自己的实测教训）
在 DSH 里点名式提问：“继续我在这个 repo 上没做完的那段工作”——裸说“继续”是它 README 里记录过的真实失败场景（agent 一个工具都不调、自己编了 scope）；
第一个 WorkThread 让 DSH agent 用 sessionflow_current_work + sessionflow_merge 建，或者你手动 voyager merge ——建好之后零接触接力（session start 自动注入上下文）才开始生效。
Activity
HarryHeYu commentedon Nov 9, 2026
也回一下这条。两条我都去代码里核了一遍，有一条结论和你猜的不太一样，说清楚免得往错方向查。
1.
NOT_FOUND_IN_CURRENT_AUDIT不是 Windows 路径判定问题。 我在干净隔离环境里只造了一个空的~/.dsh/sessions，再跑doctor --json，dsh 段就是"installed": true、"source_path": "~/.dsh/sessions"—— 路径判定这层是通的。verify dsh --json给的是三层：declared = NOT_FOUND_IN_CURRENT_AUDIT、observed = null、effective同 declared。原因是
capability_matrix.py里 DSH 的五个启动相关维度（startup_hook/dynamic_context_injection/native_session_id_at_start/native_auto_attach/live_zero_touch_continuity）静态声明就是 NOT_FOUND（注释写的是 "no native startup surface; profiles/plugins/ACP only"）；query_status取这些 machine-dependent 维度里最强的一个当declared，所以整体落在 NOT_FOUND。而session_discovery/session_indexing其实是LIVE_VERIFIED—— 46 个会话能索引出来，和这行状态并不矛盾。所以现象是真的，但性质是状态名/汇总口径容易误读（听起来像「没找到这个 provider」，实际是「启动链能力未声明」），不是路径探测失败。前者值得改，后者不用动。我没跑你的真实索引，这个结论只针对代码路径；如果你机器上
installed是 false，那才是另一回事，欢迎贴一下doctor --json的 dsh 段。2.
provenance 0.0% classified是设计现状，不是开关没开、也不是需要重扫。provenance.py的CLASSIFIERS目前只有codex/claude/zcode，没有 DSH；classify()对没有分类器的 provider 直接返回UNKNOWN。所以纯 DSH 索引必然是 0%，provenance enrich --apply也补不上（合成索引上coverage同样 0.0%）。回答你那句「值得直接问作者一句这在你的机器上也是 0 吗」：是，而且原因确定 —— 不是数据坏了，是 DSH 的 origin 分类器还没写。代码注释里登记了 grok 的同类缺口（GROK_MESSAGE_PROVENANCE_COVERAGE），DSH 这条没登记，是我们漏写。3. OpenCode —— 目前支持的 8 个 provider 里确实没有它，
by_provider只有 dsh 与此一致。这属于新 provider 适配需求，不是适配器缺陷；记下了，但不在这里承诺排期。最后那两条使用提示和 README 记录一致：裸说「继续」是已知会失败的场景，点名 + 说清要找什么更稳；第一个 WorkThread 要先建起来，session start 的自动注入才有对象。谢谢补上。
HarryHeYu commentedon Nov 9, 2026
两条都处理了，但性质不同，分开说（
b55a941）。1.
NOT_FOUND_IN_CURRENT_AUDIT—— 现象是真的，归因不是路径。 我在隔离环境里只造了一个空的~/.dsh/sessions，doctor --json给的是"installed": true、"source_path": "~/.dsh/sessions"，路径判定这层是通的。真正的原因：capability_matrix.py里 DSH 的五个启动相关维度（startup_hook/dynamic_context_injection/native_session_id_at_start/native_auto_attach/live_zero_touch_continuity）静态声明就是NOT_FOUND（DSH 没有原生启动面，只有 profiles/plugins/ACP），而verify取这几个维度里最强的一个当declared。session_discovery/session_indexing其实是LIVE_VERIFIED—— 46 个会话能索引出来，和这行状态并不矛盾。这条已登记到
docs/MAINTENANCE.md已知问题 #14：命名/展示问题，不是探测失败。该改的是标签或按维度展示，不是路径判定。2.
provenance 0.0% classified—— 设计缺口，不是开关。provenance.py的CLASSIFIERS只有codex/claude/zcode；DSH 没有分类器，classify()对它一律返回UNKNOWN，provenance enrich --apply也补不上（合成索引上coverage同样 0.0%）。回答你那句"作者机器上也是 0 吗"：是，纯 DSH 索引必然 0.0%。已登记 #13。代码注释里只登记过 grok 的同类缺口（
GROK_MESSAGE_PROVENANCE_COVERAGE），DSH 这条确实漏了，谢谢你指出来。3. OpenCode 仍不在支持的 8 个 provider 内，属新适配需求，不是缺陷；记下了，不在这次范围。
另外你给的两条使用提示与 README 一致（裸"继续"是已知失败场景；先建 WorkThread，startup 注入才有对象），已在文档里。
这次没有改任何与你两条观测相关的代码 —— 一条是口径，一条需要新的分类器（要先确认 DSH 事件里有没有可判
human/provider_bootstrap的结构字段，没有就不该猜）。所以这两个 issue 我按"已确认/已登记"处理，不承诺什么时候动。SunnyRad commentedon Nov 9, 2026
看你也不怎么推进这个项目，我也没继续提交
HarryHeYu commentedon Nov 9, 2026
节奏确实慢，这点没什么可辩解的：你 10-27 提的，我今天才回，中间隔了 13 天。
不过不是"不推进"。#1 那三条今天已经修完推到 main 了（
b55a941，CI 10/10）：DSH v4 文件名、Windows stdout 编码、trigram 短词兜底都在里面；#2 的两条也登记成了 MAINTENANCE 的 #13 / #14。你那份报告质量很高——字节级证据、加索引前后的耗时、"补空格凑 3 字符"的弯路，基本把定位做完了，省了我很多时间。这个项目就是一个人慢慢做，节奏不规律：有时候两周没动静，有时候一天修三个 bug。我也不打算为了显得活跃而凑 commit 或提前发版——这次的修复现在还在
[Unreleased]里，等积累一批再发。所以不用为了保持热度而提。有真实问题再提就行，没回音不代表没看，只是慢。有新发现随时开 issue，或者在这个下面接着说都可以。
HarryHeYu commentedon Nov 9, 2026
状态更新（2026-11-09）：这条里的观测按性质拆成三类，分别有归属，不合并处理。
1.
NOT_FOUND_IN_CURRENT_AUDIT—— 命名/展示问题，不是 Windows 路径探测失败。已登记为sessionFlow的docs/MAINTENANCE.md已知问题 #14：这个状态来自 DSH 五个启动相关维度的静态声明，installed: true时也会显示它。2.
provenance 0.0% classified—— 设计缺口，已登记为 #13：CLASSIFIERS目前只覆盖 codex / claude / zcode。不是开关、不需要重扫；补 DSH 分类器要先确认事件里有没有可判human/provider_bootstrap的结构字段，没有就不猜。3. OpenCode 不在支持的 provider 内 —— 新适配需求，不是缺陷。已写成设计输入（
docs/audits/2026-11-opencode-adapter-design.md），基于上游 v1.19.5 的实际 schema；实现属于下一阶段，尚未开始。所以这条 issue 暂时保持打开：第 2、3 项确实还没有代码变化。等 DSH 分类器或 OpenCode adapter 落地后，再决定拆成独立 issue 还是关闭。
SunnyRad commentedon Nov 9, 2026
你把你的规划做好，什么阶段做什么，我有时间就给你推进就行了，提交以后，你审查合并就行
HarryHeYu commentedon Nov 10, 2026
感谢！我这边接下来会把两个仓库的路线图和可认领任务整理得更明确一些，这样你有空的时候就可以直接选感兴趣的部分推进，不用每次重新讨论整个项目的方向。
我也看到了你已经提交的 PR #5，感谢你继续深入排查。里面的
merge参数解析、--json顺序、参数边界和recent过滤问题都很有实际价值。我会优先 Review 这个 PR，并在真实 Core 环境下补跑集成测试。当前外部 PR 的 cold-start workflow 还显示action_required，我也会一起检查。后续我准备把工作大致分为两条线：
sessionFlow Core 由我继续推进，包括 v1.3.1 发布、OpenCode Adapter、Provenance、Native Resume 验证和核心接口维护。
dsh-sessionflow Plugin 则可以重点推进 Bridge/Tool 正确性、参数与错误处理、兼容性测试、真实 DSH 集成，以及后续 Evidence Verification Tool。
当然这不是固定分工。如果你对 Core 里的某个问题更感兴趣，也完全欢迎直接认领，我们通过 Issue 讨论方案即可。
我会把接下来的功能拆成相对独立的 GitHub Issues，每个 Issue 尽量写清楚背景、涉及模块、验收标准和测试要求，标记
help wanted/good first issue等标签。这样你有时间就可以挑一个做，不需要承担固定进度。协作流程就按你说的来：Issue 讨论范围 → Fork/Branch 开发 → 提交 PR → CI/Review → 合并。不需要直接往 main 提交，也不用为了活跃度凑 commit，功能和证据扎实就行。
目前我最希望先一起完成的是 PR #5 的合并，以及后续 DSH 工具契约和 Evidence Verification 的完善。#2 提到的 Provenance 和 Audit 状态问题也会拆到 Core 侧，避免在插件里重复实现核心逻辑。
再次感谢你之前那些详细的实机复现和现在的 PR，确实帮助项目发现并修复了不少只靠合成测试很难发现的问题。后面欢迎随时挑任务推进，我负责及时 Review 和维护整体架构。
HarryHeYu commentedon Nov 11, 2026
Parking this open as a pointer so the two real findings here aren't re-filed as duplicates:
NOT_FOUND_IN_CURRENT_AUDIT—doctordowngrades DSH to NOT_FOUND even though sessions were indexed from it. Tracked as sessionFlow Core maintenance debt MAINTENANCE #14: it's a startup-dimension declaration, not a path bug; the suspected cause is the Windows provider-path audit. Not a correctness loss — the data is still indexed.CLASSIFIERS; DSH and Grok currently report UNKNOWN.Neither blocks v1.3.1. They belong to the next stage (OpenCode adapter + provenance/evidence work) rather than a patch release. Keeping this open and labelled
questionas a cross-reference to those debt items.