# 2026-09-12 只读预览版验收

交付版本：`0.1.0-alpha.1`。目标：先验证核心可用性，交付一个 SCM/USA 只读版本；保留原 M1–M5 未达成的验收项，不用延期、关闭 issue 或重新命名制造“全部完成”。

## 实际环境与方法

- 最新发布宿主：从 npm 重新安装 `@deepseek-ai/dsh@0.1.5-rc.2`，隔离 DSH_HOME；npm latest 当时仍指向 rc.1。
- 实际模型：DeepSeek 官方 `deepseek-flash`，直接连接测试和真实 DSH 模型服务均返回 `ERP_MODEL_OK`；业务验收使用真实宿主代理循环。
- 系统：Linux x64、Node 24.18.0、SQLite 3.53.1、Playwright 1.63.0 / 固定 Chromium。测试容器通过 Xvfb 提供桌面，显式关闭浏览器沙箱；产品默认启用。
- 站点公开报告使用 `usa-old` 别名。账号由用户提供，具有管理权限；本轮为客户端限定只读，并非服务端只读角色认证。没有执行 ERP 业务写入。
- 独立基线先用浏览器登录、查看菜单和商品/库存页面，再按已观察的前端查询契约读取订单详情。商品从首屏商品与有库存商品交集中随机选取，随后冻结样本；并非所有商品的随机代表性抽样。
- 主验收通过已打包安装的插件运行。独立操作员仅在浏览器填写登录与验证码，确认来自用户本轮授权；不向模型提供账号密码或登录令牌。运行前核对已安装关键 JS 与构建产物一致。
- 原始证据、站点、账号、模型会话均在本地忽略目录；不随源码、PR 或发布资产公开。

## 验证发现与修正

1. **登录态假设错误**：sessionStorage 中的令牌及专用请求头是本目标必要条件。原临时页面复制 Cookie/localStorage 的策略不能直接使用，现增加固定 SCM 查询适配器，凭据留在工作进程。
2. **业务关联需要 SKU 桥接**：库存是 SPU 共享余额；商品通过工作台 skus[].id 与订单 items[].skuId 关联。直接用 productId 搜索订单明细会误报缺失；按 SKU 重复累计库存也不成立。
3. **菜单发现与业务理解分开**：初始接口返回 331 个节点、8 个根，其中 67 个缺少名称；恢复后的菜单名称有变化。并存两套商品模块，不能按名称相似就自动合并业务对象。
4. **原失败保留**：组合查询初版多传外层参数被 IPC 拒绝，已只传协议字段并增加边界测试。JSON 证据空格差异造成引用失败，改为一致的 JSON 文本，提供字面引用及正确关系方向提示。
5. **安装测试需要核实版本内容**：同版本同路径 tgz 可能被 pnpm 缓存。开发验收采用内容哈希路径，并比对安装文件；正式发布资产保持不可变。
6. **真实故障**：约 22:15（Asia/Shanghai）ERP API 返回 502，静态首页仍为 200，浏览器与独立请求均复现。模型在未登录情况下拒绝读取、没有编造知识，将任务标为 blocked。之后服务恢复，另起完整验收，故障记录见 [#26](https://github.com/GuoMonth/dsh-erp/issues/26)。

## 独立任务基线

随机样本的独立读取覆盖商品工作台、1 条 SPU 库存记录、当时 66 张采购单及 43 张销售单的详情。按 SKU ID 找到 3 张关联采购单和 7 张关联销售单。销售样本包含取消、草稿及已执行的不同状态，不把关联数等同于已出入库单据数。

上述数据是特定时刻、特定账号的样本，未声称全企业/全历史覆盖。API 查询不是事务快照；静态界面和 API 结果分别保留来源。字段完整枚举、所有权限与页面行为仍为未知。

## 已安装产物最终实时运行

完成浏览器登录后，由真实 deepseek-flash 通过原生工具执行，未用测试模型替代：

- 全局菜单读取及图谱导入成功，最终 API 快照为 216 个节点、8 个根、61 个缺失名称；初始独立快照是 331 个节点、67 个缺失名称。差异发生在站点恢复后的不同轮次，未确认后端具体变更原因，不把它视为插件丢失节点，也不以单一分母宣称全局覆盖。
- 建立商品、库存、采购、销售四个领域及 menu supports domain 关系；通过 direction=in 从库存域反查菜单成功。
- 商品链完整读取当时 66/66 张采购单及 43/43 张销售单，找到 3/7 张关联单据，与独立基线一致；证据按每个请求入库。
- 重复库存查询与商品链中的库存记录一致；不存在商品的查询返回 total=0、list=[]。
- 学习轮次按顺序记录完成和证据，未把元数据发现冒充全部页面访问。查询没有调用 ERP 写入接口。独立读取本地存储核实：117 条观察、117 个证据文件、1 个学习轮次；12 条 AI 领域/字段/关系记录与菜单图谱分别保存。

**语义审查保留的问题**：模型尝试从订单状态与 qtyIn/qtyOut 推导“已执行流转合计”。样本里取消单仍保留历史数量，退货单也有独立符号和状态；尚未验证完整库存流水及单位换算。因此原始关联查询通过，而库存对账和取消/退货语义不能视为通过。工具返回与使用说明已强调该边界；这属于 [#27](https://github.com/GuoMonth/dsh-erp/issues/27) 的后续领域核验范围。另用真实 DSH 模型读取反例并将该规则从 v1 修订为 v2、标 needs-review，原版本保留，未伪造用户确认。

真实宿主还完成了知识导出（436 条当前记录、未截断）、一致性备份和完整性检查（无缺失/损坏/孤立证据）；退出重启后可读取知识并修订。

另外在隔离应用目录、PATH 不含项目 node_modules 的条件下，从 npm exec 自动准备 dsh+pnpm，完成本地 tgz 安装和卸载；复用了机器已有系统库和 npm 缓存，不宣称是全新操作系统镜像。

自动化验证：`npm run verify`（63 个测试、类型检查、独立安装产物与真实 CLI 固定模型冒烟）通过；有界面 Chromium 的 22 个测试通过。覆盖固定请求与凭据隔离、重定向拒绝、许可/接管、精确 SKU 关联、有限/空查询、菜单移动及退休、跨范围隔离、任务重启恢复，以及已有存储、知识与浏览器回归。自动化结果不替代上面的实时证据。

## M1–M5 处置

| 阶段 | 本版交付 | 未完成或延期 |
| --- | --- | --- |
| M1 | 全局菜单元数据导入、版本化层次、AI 领域与菜单关联、持久化先广后深任务、证据与 Markdown/JSON 视图 | 所有菜单页面的自动访问、动态发现/预算插队调度仍未完成（#9–#11） |
| M2 | 商品/库存/采购/销售的结构化字段与关联解释；原始观察、修订、直接失效依赖；菜单移动/移除修订测试 | 通用 Tab/按钮/子窗口探索、真实多跳变化后自主修复未完成（#12–#13） |
| M3 | 固定版本参数化商品链、分页上限、精确 SKU 关联、原始状态、采集时间、证据和部分覆盖说明 | 通用动态能力生命周期、不同参数的充分验证与真实字段变化自修复未完成（#14–#15） |
| M4 | 插件不注册业务写入能力；合成测试验证非法查询、重定向、过期/错误许可和接管的拒绝 | 用户指定 Read only，原真实写入/回读及写入超时恢复延期，未标通过（#16–#17） |
| M5 | 预编译安装包、固定依赖、资源自动准备、宿主退出清理、SQLite 备份恢复及本地知识导出 | Windows/macOS 桌面、企业代理/证书矩阵、完整用户卸载界面及综合效果对照未完成（#18–#19） |

这些剩余项不是都需要用户提供信息：大部分是后续工程范围。真实业务写入需要另一个明确允许写入且可复位的验收案例；当前只读授权不能替代它。原 Epic 保留，预览版发布不代表原 M1–M5 全部验收通过。

## 发布判断

仅声明 SCM/USA 只读预览范围。没有完成 browser-use 同条件对照，也未建立市面产品对照基线，因此不能客观声称“已持平市面效果”。当前验证用于证明所列具体链路可行、能保存依据及暴露失败，不外推为通用 ERP 智能体。