# DSH Visual Acceptance 第一性原理与对抗式审查

> 审查对象：[项目立项](project-brief.md)、[技术架构](architecture.md)、[V0.1 PRD](prd-v0.1.md)  
> 证据基线：[技术 Spike 报告](spike-report.md)

## 1. 结论

项目可以继续，但竞争力仍是待验证假设。Spike 证明“闭环可实现”，没有证明“用户愿意持续使用”或“主观判断可信”。

最危险的失败方式不是代码做不出来，而是产品退化为：

> 一份看起来很完整、用户只看一次的 AI 检查报告。

## 2. 是否只是检查清单包装？

### 反方论点

资源、控制台、溢出、空状态和截图都是常见检查项，换成 Issue 卡片并不自动产生新产品。

### 证据与修正

浏览器 Spike 已经证明简单检查项也存在语义陷阱：favicon 污染、移动缩放掩盖溢出、Layout Viewport 漏检和空白截图。真正的价值不在列出检查项，而在证据校准、范围复现和跨 Run 复验。

### 判定

风险仍成立。V0.1 必须把“人工决定 + 同问题复验”设为主流程，不能把报告下载设为完成态。

### Kill Test

若 5 个试点用户中多数只生成一次报告、不创建第二次 Run，应停止扩展 UI 和 Provider。

## 3. 是否会被 Vision Toolkit 补齐？

### 反方论点

现有视觉插件可快速增加截图比较、浏览器工具和 Issue 输出。

### 判定

成立。视觉算法和工具数量没有防御力。

### 应对

只投入以下核心：

- 验收 Schema；
- 状态矩阵；
- Evidence Provenance；
- Issue 身份；
- 人工 Decision；
- Retest 与 Agent Handoff。

若外部工具提供稳定 API，应接入而不是复制。若外部工具完整实现上述闭环，应重新评估独立插件价值。

## 4. 主观视觉判断是否不可信？

### 反方论点

不同模型、提示词和采样会对“AI 模板感”“自然度”“层级”给出不一致结论。

### 判定

成立，且本轮没有实测准确率。

### 产品约束

- 主观判断永远标记为候选；
- 必须展示证据裁剪、规则和不确定性；
- 不参与自动通过；
- 不直接触发修改；
- 用户驳回应进入匿名本地 Eval 数据，而不是被系统忽略。

## 5. DSH API 是否造成高维护成本？

### 证据

- Host 生命周期在当前版本通过；
- Client 已在真实 DSH Web 非空会话完成 Run；
- Desktop 壳层只由用户确认 Tab 可见，尚未完成自动化深浅色与重开；
- DSH 仍处于快速变化阶段。

### 判定

高风险。

### 应对

- 只保留一个 DSH Adapter；
- 使用 `conversation.view` 正式 Slot；
- Core 不导入 DSH 类型；
- 为每个支持版本跑 Host/Client 契约；
- API 变化时允许关闭 UI Adapter，保留本地 Run 数据。

## 6. 跨 Harness 是否过早？

### 判定

双端产品过早，核心中立合理。

当前不做 Codex Skill、不做第二套 UI、不承诺通用 MCP。只有当本地 Runner 和 Schema 在真实项目中稳定后，才把 CLI 暴露给其他 Harness。

## 7. Issue 指纹是否会误导？

### 反方论点

DOM 重构会导致同问题换 ID；过度规范化又可能把两个问题合并。

### 判定

成立。当前只在受控 Fixture 通过。

### 应对

- 指纹只是候选关联，不是绝对事实；
- UI 提供合并、拆分和“不是同一问题”；
- 保留旧新指纹映射；
- 回归状态允许人工改判。

## 8. 浏览器结果是否可重复？

### 反方论点

字体、动画、浏览器版本、网络和硬件会制造噪声。

### 应对

- 保存 Browser/OS/Viewport/Theme/Scale；
- 动画与时间冻结后置为可配置项；
- 同环境复验优先；
- 环境不一致时不自动得出像素回归；
- Pixel Diff 与运行事实分开。

## 9. 更简单的替代方案

最简单替代是一个 CLI 生成 Markdown/JSON 报告，不做 DSH UI。

如果真实用户不需要在会话里确认、交接和复验，CLI 更便宜、更稳定。DSH 工作台只有在“人工决定与 Agent 修改发生在同一会话”显著减少上下文切换时才成立。

## 10. 最终审查意见

允许继续 V0.1。首个 Gate 已部分满足，但仍保留四个发布 Gate：

1. DSH Web 已通过；补齐 Desktop 壳层深浅色与重开生命周期；
2. 至少 5 个真实项目的第二轮复验；
3. Issue 自动关联允许人工纠错；
4. 主观 AI 判断通过固定 Eval，且永不成为自动 Gate。

## 11. `0.1.1-closed-loop-beta` 对抗式复审

### 11.1 是否仍只是检查清单

已经不只是一次性检查清单：当前 Fixture 实测跑通了 `Candidate → 人工立项 → Decision → 本地修改包 → 原 Matrix Retest → 人工确认`，而且重启后 Decision 和复验历史仍存在。但这只证明机制可行，尚未证明用户会持续使用。若 5 个真实项目大多只跑首次检查，不进入第二次复验，应停止扩展。

### 11.2 是否会出现假性解决

Host 不信任 Client 提交的复验动作；`not-verifiable`、Matrix 变更、规则未执行、Run 失败/取消、手工 Issue 和关联不确定都不能写入 `resolved`。`possibly-resolved` 也只是候选关系，只有人工点击确认才改变 lifecycle。自动测试已覆盖这些边界；真实修改后的 `possibly-resolved` UI 路径尚未手工跑通。

### 11.3 生命周期是否只在理想路径下成立

实测暴露过一个真实竞态：Runner 先写 `completed`，Client 停止轮询，Host 后写复验关系，UI 会误报“没有可比较项”。现已改为 Host 在返回完成态 Retest 前确保关系已落盘，并通过真实 DSH Web 重跑。这说明当前闭环需要继续以真实宿主生命周期为 Gate，不能只看 Core 单测。

### 11.4 DSH 与存储维护风险

- 只有 `0.1.1-rc.2` 获得 Host/Web E3 实测，DSH API 变更仍是高风险；
- 同一 Host 进程内的 Issue 写入已串行化，但没有跨进程文件锁；当前不能让两个 DSH 进程同时修改同一 Profile/工作区；
- 应继续保持单一 DSH Adapter；若新版本不兼容，允许暂停 UI Adapter，不迁移或破坏本地 Run/Issue 数据。

### 11.5 交互是否过重

Issue 台账、Decision、Retest 和合并/拆分都收在同一结果面的折叠区，首屏仍是现有快速验收。这降低了默认负担，却不能证明用户理解了“Candidate 不等于 Issue”和“复制不等于发送”。试点必须记录：立项成功率、修改包复制率、二次 Retest 达成率和误以为已发送的次数。

### 11.6 复审结论

允许进入有界试点，不允许据此宣称 V0.1 已产品化。下一 Gate 是 5 个真实项目，其中至少 3 个完成实际修改和原 Matrix Retest，且不出现假性 `resolved`。Provider、OCR、Pixel Diff、参考图比较、自动 Agent 注入和第二套 Harness UI 仍严格后置。

## 12. 两个本地真实项目部分试点：对象正确性复审

### 发现

首次用 localhost 目标做部分试点时，发现 Checkpoint 路径为 `/` 会把 `http://127.0.0.1:<port>/overview.html` 静默导航为站点根页。这是 P0：截图、运行事实和“Ready 已满足”可能都正确，却属于错误对象。

### 修正与证据

Runner 已改为根路径保留 Target 的确切 pathname/query，显式非根路径才切换站内页面；新增单测覆盖 `overview.html?mode=qa` 的保留和 `/reports.html` 的显式切换。Client 同时展示实际打开路径。修复后两个有效默认态 Run 的最终 URL 分别为 `index.html?state=default&theme=light` 与 `overview.html?state=default&theme=light`；修复前的错误对象 Run 不计入试点。

### 状态复现边界

`overview.html` 的 `empty` 状态无法仅由 `state=empty` 查询参数复现，Runner 正确记录为 `unreached` 并生成 Candidate。它不证明目标页面缺少空状态，也不是自动 Issue；下一步应由项目提供可声明的状态入口或由产品后续评估受限 Trigger Adapter，而不是在 V0.1 引入任意脚本点击。