[zhaoweicmd]

工作台用途

律案工作台（LawCase）把法律案件材料整理成可追溯的台账：材料版本与定版、事实出处（精确定位到页/段）、条款级审核意见、五道验收、交付包。它只做「记账与验收」，法律判断仍由律师作出。

主要界面：案件列表 + 概览 / 材料 / 条款 / 意见 / 验收五页；合同审核案支持条款索引、逐条意见（可选「只批注」或「改正文」），生成的 Word 带红线与批注。

本机验收结果

• Desktop 版本：DSH Desktop (Workbench) v0.13.0
• 平台：macOS · darwin-arm64
• 安装方式：从本 Release 包（lawcase-workbench.tgz，2.58.0，0.32 MiB）安装到本机 profile，插件成功加载：plugin-ready v2.58.0 · 65 tools
• 界面：已在最终安装版本上实际打开并截图（即本条目 screenshots 首图）
• 包校验：dsh.bundle.patch、exports["./client"]、dsh.client.inject: ["dsh-desktop-workbenches"] 均已核对；≤ 8 MiB

安装来源

GitHub Release，固定文件名 lawcase-workbench.tgz（不带版本号）：
https://github.com/zhaoweicmd/lawdesktop/releases/latest/download/lawcase-workbench.tgz

---

⚠️ 当前门禁状态：Workbench security review 未通过

Trusted catalog probe 已通过。剩下一项我已在本地复现并定位到具体代码，特此说明，供维护者判断：

scripts/llm-review.mjs：

export const MAX_BATCH_SIZE = 350_000
if (batches.length > 80) throw new Error('完整审核超过 80 个分块，需人工处理')

• 本仓库参与审查的源文件 77 个
• lib/client.js（300 KB，>60 000 字符）按规则切成约 8–9 片（每片 40 000 字符、重叠 2 000）
• 合计约 93 个分块 > 80 上限 → 抛出「需人工处理」

这不是体积问题（包只有 0.32 MiB），而是文件数量问题：本包是「无构建、源码即产物」结构，lib/core/ 下有 52 个职责单一的小模块。

我没有采用的方案

为满足块数上限而把 52 个 lib/core/*.js 合并成少数几个大文件。那会破坏模块划分，纯粹为通过检查而妥协，对使用者无益，因此未擅自改动。

想请教

1. 能否为此类「模块拆分较细、无构建」的插件放宽块数上限？
2. 或由维护者人工审阅代码后放行？
3. 或有其它推荐做法？

外部依赖与数据位置

• 无外部工具链，纯 JS 包。
• .doc（97-2003）解析：macOS 用系统 textutil；Windows 需本机安装 Microsoft Word（通过 PowerShell + Word COM）。.docx 不受影响，未装时给出明确提示。
• 网络：仅「企业查询（企查查）」「法条权威原文（北大法宝）」两项由用户主动触发时联网；解析（含 OCR）全部在本机完成。
• 数据位置：案件目录由用户在界面选择，全部落在该目录下（.lawcase/ 台账、out/ 产物、交付包_yyyymmdd-hhmm/）；不在用户主目录或仓库内静默创建目录。

未验证项

• Windows 实机安装：仅做代码层跨平台处理与单元测试，未在 Windows 上实跑。
• 截图目前 1 张（规范允许 1–5 张，满足最低要求）。

[github-actions]

❌ 工作台安全与规范审查未通过 (46146ed)

你好！感谢你为 DSH 工作台生态提交的贡献。在本次自动化安全与规范审查中，门禁检测到部分需要调整的问题，暂未能自动合并。请参考以下详情进行调整：

📌 问题原因：

client 必须注入 dsh-desktop-workbenches

💡 解决问题建议：

1. 请根据上述具体错误原因检查条目配置及远程仓库发布资产。
2. 修复后直接推送新提交至当前 PR 分支即可重新触发审核。

---

💬 后续指引：完成上述调整后，直接将改动推送到当前 PR 分支即可，系统将自动重新执行完整安全门禁。如果在修改过程中有任何疑问，欢迎在评论区随时留言沟通！

[github-actions]

❌ 工作台安全与规范审查未通过 (2aade44)

你好！感谢你为 DSH 工作台生态提交的贡献。在本次自动化安全与规范审查中，门禁检测到部分需要调整的问题，暂未能自动合并。请参考以下详情进行调整：

📌 问题原因：

Release 包检查失败：文本审核材料超过完整审查上限或包含二进制，需人工处理

💡 解决问题建议：

1. 请根据上述具体错误原因检查条目配置及远程仓库发布资产。
2. 修复后直接推送新提交至当前 PR 分支即可重新触发审核。

---

💬 后续指引：完成上述调整后，直接将改动推送到当前 PR 分支即可，系统将自动重新执行完整安全门禁。如果在修改过程中有任何疑问，欢迎在评论区随时留言沟通！

[github-actions]

❌ 工作台安全与规范审查未通过 (56d7f4c)

你好！感谢你为 DSH 工作台生态提交的贡献。在本次自动化安全与规范审查中，门禁检测到部分需要调整的问题，暂未能自动合并。请参考以下详情进行调整：

📌 问题原因：

Release 包检查失败：文本审核材料超过完整审查上限或包含二进制，需人工处理

💡 解决问题建议：

1. 请根据上述具体错误原因检查条目配置及远程仓库发布资产。
2. 修复后直接推送新提交至当前 PR 分支即可重新触发审核。

---

💬 后续指引：完成上述调整后，直接将改动推送到当前 PR 分支即可，系统将自动重新执行完整安全门禁。如果在修改过程中有任何疑问，欢迎在评论区随时留言沟通！

[github-actions]

❌ 工作台安全与规范审查未通过 (c01fe36)

你好！感谢你为 DSH 工作台生态提交的贡献。在本次自动化安全与规范审查中，门禁检测到部分需要调整的问题，暂未能自动合并。请参考以下详情进行调整：

📌 问题原因：

Release 包检查失败：文本审核材料超过完整审查上限或包含二进制，需人工处理

💡 解决问题建议：

1. 请根据上述具体错误原因检查条目配置及远程仓库发布资产。
2. 修复后直接推送新提交至当前 PR 分支即可重新触发审核。

---

💬 后续指引：完成上述调整后，直接将改动推送到当前 PR 分支即可，系统将自动重新执行完整安全门禁。如果在修改过程中有任何疑问，欢迎在评论区随时留言沟通！

[zhaoweicmd]

关于 Workbench security review 未通过的说明

感谢自动门禁的详细反馈。已修复第一个阻塞项：

• ✅ client 必须注入 dsh-desktop-workbenches —— 源码 package.json 已补上该字段（原先为本地开发留空），Trusted catalog probe 现已通过。
• ✅ 清理了仓库根目录误放的截图文件；README 也改为面向使用者的说明（移除了开发过程记录）。

剩下的阻塞项是：

Release 包检查失败：文本审核材料超过完整审查上限或包含二进制，需人工处理

我按 scripts/llm-review.mjs 的规则在本地复现了材料收集过程，定位到原因：

MAX_BATCH_SIZE = 350_000
if (batches.length > 80) throw new Error('完整审核超过 80 个分块，需人工处理')

本仓库参与审查的源文件共 77 个，其中 lib/client.js（300 KB）会被切成约 8–9 个片段；按该规则估算总块数约 93 块，超过 80 块上限。

需要请教的是：这种情况是否有推荐做法？

我想到但不希望采用的方案是：把 52 个 lib/core/*.js 合并成少数几个大文件来压低文件数——但那纯粹是为了满足检查而破坏代码结构，对使用者没有任何好处，所以我没有擅自这么做。

请问：

1. 是否可以为「无构建、源码即产物、模块化拆分较细」的插件放宽块数上限，或
2. 由维护者人工审阅本 PR 的代码，或
3. 您建议的其它方式？

补充说明本包的工程现状，便于评估：643 条单元测试（642 通过 / 1 跳过）；包体 0.32 MiB（上限 8 MiB）；dsh.bundle.patch、exports["./client"]、dsh.client.inject 均已核对；已在 DSH Desktop (Workbench) v0.13.0 / macOS arm64 实机安装并打开界面（截图即该版本实拍）。