0.1.5-rc.2 被误判为无法打审计标记：审批正常工作，但计数/审计恒为 0

[DobyChao]

环境

• dsh-auto-review：0.12.3（0.12.2 同样可复现）
• 宿主：@deepseek-ai/dsh 0.1.5-rc.2（npm next 标签），@deepseek-ai/dsh-session 0.1.5-rc.2
• 平台：Windows，web profile

症状

审查功能本身端到端正常：每个审批请求都会派生 auto-review: <tool> 一次性子代理，返回结构化裁决 {decision, reason, riskLevel}，提权也据此放行/拒绝。但审查面板和 /auto-review status 的计数永远为 0：

AI verdicts this turn: 0/10
All-time: 0 allows, 0 denies, 0 fallbacks, 0 never rejects (avg 0 ms per verdict).
Session-log audit is disabled on this host: its Session.append predates the
ignorable marker and unmarked audit events would make the session unresumable...

根因

src/audit.ts（编译后在 lib/index.js）中的 isUnmarkedHostVersion()：

const rc = /^0\.1\.(\d+)-rc\.(\d+)$/.exec(v);
if (rc !== null) {
    const minor = Number(rc[1]);
    const patch = Number(rc[2]);
    return minor === 0 && patch <= 8 || minor === 1 && patch <= 2 || minor >= 2;
}

对 "0.1.5-rc.2" 求值：minor >= 2 → 5 >= 2 → true（判为 unmarked host）。minor >= 2 这个分支本意应该是覆盖 0.1.2 那条不能打标记的预发布线，但它把 0.1.3 和 0.1.5 线的所有 rc 也一并捕获了。

这与函数自己的 docstring 矛盾——docstring 列出 0.1.5 线不能打标记的版本止于 0.1.5-alpha.1，并明确写道：

Non-matching (later rc, stable 0.2+, or unresolvable) versions are treated as possibly-marker-aware and verified by the append probe.

0.1.5-rc.2 命中 rc 正则，永远走不到 append probe：auditSupport 直接被 peer 版本预检置为 "unsupported"，审计 fail-closed 自行停用，autoReview/* 审计事件从不写入——而面板读的正是这些事件，于是尽管每次裁决都成功，计数恒为 0。

修复建议

两种任选：

1. 把预发布线的分类限定在 docstring 所列的确实不能打标记的集合（0.1.0-rc.、0.1.1-rc.、0.1.2 全部预发布、0.1.3-alpha.2、0.1.5-alpha.1）；
2. 或者去掉 minor >= 2 分支，让未知的 rc 线落入 append probe——probe 在运行时本来就能正确探测标记支持。

临时解决

在插件挂载配置行加 allowUnmarkedAudit: true 即可恢复审计；在 rc.2 宿主上这是安全的，因为该宿主确实会打 ignorable 标记。

[PerryLink]

感谢这份报告 —— 逐行定位很准，你确实找出了我们文件里一处真实的自相矛盾。但结论方向需要更正，而且这直接关系到你本机的会话安全，所以我把三层证据摆在这里。

1. 你说对的部分

src/audit.ts:76 的 minor >= 2 确实把 0.1.5-rc.2 归入「未打标记」一类，算术完全正确；它与同文件的 docstring 矛盾，这是我们的文档缺陷（已在第 4 节修复）。你对「计数恒为 0」的因果链也完全正确。

2. 需要更正的部分：0.1.5-rc.2 不能打标记

你写：「在 rc.2 宿主上这是安全的，因为该宿主确实会打 ignorable 标记。」

没有任何已发布版本能通过 Session.append 写入该标记，0.1.5-rc.2 也不例外。三层证据：

(a) 宿主源码 —— packages/core/session/src/index.ts:710-738：

append<T extends SessionEventType>(
  type: T,
  data: SessionEventMap[T],
  ...opts: T extends SurfaceEventType ? [opts: SurfaceIntent<T>] : []   // ← 非 surface 类型连第三参数都不接受
): SessionEvent<T> {
  const surfaceOpts: SurfaceIntent | undefined = opts[0]
  const surfaceMetadata = {
    ...surfaceOpts?.sourceEventSeqs === undefined ? {} : { sourceEventSeqs: … },
    ...surfaceOpts?.surfaceOp === undefined ? {} : { surfaceOp: … },
  }                                            // ← 只可能含这两个键
  const event = deepFreeze({ type, seq, time, data, ...surfaceMetadataSnapshot })   // ← 信封永不含 ignorable

autoReview/* 不是 surface 事件类型 ⇒ { ignorable: true } 被静默丢弃（不抛错，这大概就是它难以察觉的原因）。

(b) 全部已发布 tarball —— 我解包了 npm 上 0.1.0-rc.2/3/6/7/8、0.1.1-rc.1/2、0.1.2-alpha.2–alpha.5、0.1.2-rc.1、0.1.3-alpha.2、0.1.5-rc.1、0.1.5-rc.2 共 15 个版本，逐版读 lib/index.js 里 append 的全体 —— 每一版都是上面那段结构，ignorable 从未出现。

(c) 实机运行 —— 直接 import 宿主自己构建的 packages/core/session/lib/index.js（就是 0.1.5-rc.2 那条线），执行你描述的调用：

append('autoReview/verdict', data, { ignorable: true })  →  returned OK
returned envelope keys : ["type","seq","time","data"]
returned.ignorable     : undefined
last logged ignorable  : undefined

（对照）seed / restore 路径 ignorable : true      ← 标记只在这条路上可达

⇒ ignorable 是写日志的那个 harness 落盘时用的（供更老的 harness 读取时跳过未知类型），不是给往日志里追加事件的插件自我申报的 —— known-event-types.ts:8-20 明说事件名注册被否决。所以 isUnmarkedHostVersion('0.1.5-rc.2') === true 是正确分类，不是 over-reach。

3. ⚠️ 关于 allowUnmarkedAudit: true —— 它会让会话无法加载

这是本轮最要紧的一点，值得单独记下来。因为宿主不会补上标记：

• autoReview/* 不在 KNOWN_SESSION_EVENT_TYPES 里；
• validateStoredEvents（session-persistence/src/storage-contract.ts:75）对「未知且未标记」的事件类型直接拒绝，而它就在本地 jsonl 的普通读取路径上（session-persistence-jsonl/src/index.ts:627,758）；
• ⇒ 该选项写入的 autoReview/* 事件会让这些会话在任何校验已存事件的 harness 上无法再次加载 —— 不是「更严格的构建上」。

你看到的计数恢复，正是「事件确实写进去了」的副作用；同一次写入也让会话变得不可恢复。所以第 2 节那条结论（「在 rc.2 上是安全的」）用在本机也一样有代价，值得在原文里加一句说明，免得后来的人照着做。

如果你已经开过这个选项，请先用 dsh-permission-rules 的 scripts/repair-session-logs.mjs 看一眼（scan 只报告、不改动）：

node scripts/repair-session-logs.mjs scan
node scripts/repair-session-logs.mjs repair --dry-run
node scripts/repair-session-logs.mjs repair

它的默认目标集覆盖全部五个 autoReview/* 类型；0.1.5-rc.2 是 v3 格式，原生 v3 读取接受带标记的插件行，所以这种情况 repair 补标记即可恢复。

4. 我们改了什么（0.12.4，已发布）

没有动分类器 —— 按报告收窄会正好造成这个守卫存在的唯一理由所要防的日志污染。改的是真正错的那一半文档：

• src/audit.ts 模块 docstring：删掉「post-rc.6 会打标记」的错误陈述，写明三层证据，并注明「对全 0.1.x 返回 true 是正确分类，请勿收窄」；
• auditDisabledNotice（中/英）、运行时告警、allowUnmarkedAudit 配置文档、AGENTS.md：不再说「predates（早于）」，并明确该选项会让会话无法加载，它不是兼容开关；
• 新增回归测试：① 对全部已发布版本串断言 true（防止后人「顺手收窄」）；② 直接调用已安装 peer 的真实 Session.append 并断言返回信封不含标记 —— 一个 canary：若将来某版真的支持了，这条会失败，提醒我们有意识地重审，而不是静默放宽。

dsh-auto-review@0.12.4 已发布为 latest，CI 与 npm provenance 均通过。

5. 你的报告指向的真问题

确实存在且未解决：在任何已发布宿主上，第三方插件都没有安全的 append 路径把自定义事件写进会话日志（这正是本插件默认降级到内存镜像的原因）。相关讨论在 #918 与 #3191 —— 如果你想推动它，那两处才是正确的位置。

谢谢你做到行号级别。正是这种精度让上面这轮核对能在半小时内完成 —— 对照实验一旦跑通，结论就很硬。