Six implementation findings with fix proposals (0.1.1-rc.2, Windows)

[mmybfs]

Discussion: 六个已定位的实现缺陷与修复建议（0.1.1-rc.2 实测 / master 对照）

在自托管 DSH（0.1.1-rc.2，Windows）上做商用加固审查时定位的问题。其中三个已附带 git format-patch 补丁，三个建议官方实现。全部经 master（2026-08-27）源码对照核实。

1. fs 写围栏在 ino=0 文件系统上可被绕过（附补丁）

packages/fs/fs-sandbox/src/containment.ts 的 sameIdentity 用 dev+ino 相等判定目标位于可写根之下。FAT/exFAT 与部分网络共享卷的 ino 恒为 0，导致任意已存在祖先都与工作区根"身份相同"，isPathUnder 恒真，write/edit 工具可越过工作区边界。
建议：ino === 0n 时返回 false（补丁 fix-fs-sandbox-ino-zero）。

2. token 估算对中文低估约 4 倍（附补丁）

packages/llm/token-meter/src/estimate.ts 固定 CHARS_PER_TOKEN = 4。中文约 1 字/token，导致压缩阈值延迟触发、上下文预算偏斜。assistant 消息有服务端 usage 锚定，漂移集中在工具结果增量——但大段中文工具结果场景下影响显著。
建议：按 Unicode 块加权（CJK 区 1 字/token，其余维持 4 字符/token；补丁 fix-token-meter-cjk）。

3. --dump-config 无条件重写 profile 根文件，沙箱内 EPERM 崩溃（附补丁）

apps/cli/src/profile-boot.ts 的 prepareProfile 每次调用都重写 cordis.yml。诊断命令在沙箱内执行时（$DSH_HOME 在工作区外）直接 EPERM 退出，只读诊断不可用。
建议：内容已等于模板时跳过写入（补丁 fix-dump-config-readonly-write）。

4. JSONL 后端无 loadStoredFrom，冷读全量解压（建议官方实现）

packages/session/session-persistence-jsonl/src/index.ts 注释明示无跳读钩子，readFrom 退化为全文件读入+全帧解压（实测单会话 25MB 压缩）。SQLite 后端已有实现。
建议：利用现有分帧容器做帧级跳读。

5. 动态插件 invoke 无调用方会话校验（master 已部分修）

管理动词已线程化 agent 并校验归属（owned()），但 @Remote('invoke') 仍只校验 pluginRunId，配合 inventory() 可跨会话枚举并调用私有 Host handler。
建议：invoke 载荷携带发起者身份并校验 sessionId；inventory 按会话过滤。

6. compaction 同生命周期 unmatched start 永久 busy（master 已部分修）

进程死在 compaction/start 与 compaction/end 之间时，同生命周期内无后续 end-seed 覆盖，会话压缩永久 busy。master 已处理跨生命周期陈旧标记，同生命周期场景仍在。
建议：恢复加载时按 turn 闭合性补写 compaction/end 或判定 inactive。

---

（另：Windows ACL 沙箱受限令牌下 SChannel TLS 全面不可用（Edge/.NET/git SEC_E_NO_CREDENTIALS），Node 自带 TLS 不受影响——作为已知限制记录，供文档化参考。）

[argszero]

全部六条源码核实完毕（本地 0.1.2-alpha.1 = cd5ef81；你对照的 master 2026-08-27 相关文件与本地一致）。你的定位全部准确，逐条给行号 + 少量补充：

① fs-sandbox ino=0 绕过（确认）：containment.ts:42-43 sameIdentity = dev===dev && ino===ino，:71 祖先链判定用同一函数，全文件仅此一个身份判定点（76 行）。FAT/exFAT 与部分网络卷 ino=0 时任意祖先都与根"同身份" → isPathUnder 恒真 → 写逃逸。ino === 0n → false 是正确的最小修。补一点：Windows 上 dev 同样可能不可靠（多卷/重解析点），建议在 ino-0 守卫之外把"路径规范化比较"作为第二道身份判定（跟 c5d8a2f7/d9f5a3c7 家族的 samePath 模式一致）——但 ino-0 守卫本身已消除最危险的误放行面，可独立先合。

② token 估算中文低估（确认）：estimate.ts:13 CHARS_PER_TOKEN = 4 硬编码，:29/:43/:46-47 三处 Math.ceil(len/4) 无语言加权。消费方 = token-meter 包内 route-pricing/index/surface-fold——即压缩阈值与定价共用同一个估算，低估同时影响"压缩触发偏晚"和"定价偏低"，比帖子里说的面更广一点。CJK 块加权（1 字/token）方向正确，注意把 CJK 扩展区（Ext A-F, U+3400-U+9FFF 段全部 + 兼容表意）一并纳入，别只算基本区。

③ --dump-config 无条件重写（确认）：profile-boot.ts:118-120 prepareProfile 无条件 writeFileSync(join(profile.dir, 'cordis.yml'), PROFILE_ROOT_CONFIG)——每次调用都写。只读诊断在沙箱内 EPERM 符合预期。内容相等跳过写入是干净修法；建议顺带把"仅当文件缺失或内容不等时写"提到公共 helper，避免未来别的调用点重犯。

④ JSONL 无 loadStoredFrom（确认）：session-persistence-jsonl/src/index.ts:206-208 注释原文 "JSONL is sequential media: no loadStoredFrom hook"，readFrom 直接委派 coordinator 全量读。分帧容器存在（同仓库的 format.ts 帧结构），帧级跳读在结构上可行——与你判断一致。这条与 SQLite 后端的能力差距属于性能域（非损坏域），但 25MB 冷读对巨型会话（#5165 的 342MB zstd 家族）是实打实的放大项。

⑤ invoke 无调用方会话校验（确认，比你说的更彻底）：cordis-host-runner/src/index.ts:740-766 的 invoke(pluginId, pluginRunId, method, args) 签名里根本没有 sessionId 参数——不是"没校验"而是"载荷里就没携带"；run.pluginRunId !== pluginRunId（:750）只验证 run 新鲜度，任何会话只要知道 run id 就能调。管理动词确有 owned() 门（:1079/:1105/:1234 按 plugin.sessionId 归属）——所以你的建议（invoke 载荷带发起者身份 + 校验 sessionId）方向完全正确，且 inventory()（:524-528 返回 agentId=plugin.sessionId）确实为跨会话枚举提供了把手。这条与 c6e9f8d4（reverse-proxy 特权 RPC 欺骗家族）同型：远程可达的 host 能力缺发起方身份验证。

⑥ compaction 同生命周期 unmatched start 永久 busy（确认）：region.ts:282-300 assertCompactionInactive 只认 latestEndSeedSeq > unmatchedCompactionStart.seq（新生命周期 end-seed）这一条解锁路径；同生命周期内崩溃（start 已落盘、end 未落盘）且无 end-seed → 永远 busy。设计注释（:141-143 "a failed close deliberately leaves the unmatched start detectable"）说明"可检测"是刻意的——但检测方只有 assertCompactionInactive 的拒绝分支，没有恢复消费者。补丁方向建议：加载/恢复时扫描同生命周期 unmatched start → 自动补写 compaction/end { error: 'interrupted' }（与 :225 的失败 end 形状一致）或判定 inactive，而不是等断言拒绝。

（附注：Windows ACL 沙箱 SChannel TLS 不可用那条作为已知限制记录很有价值——Node 自带 TLS 不受影响即默认路径安全，文档化即可。）

三条补丁方向全部正确，可直接作为上游 PR 素材（通道恢复后）。