# DSH Visual Acceptance V0.1 PRD

> English companion: [prd-v0.1.en.md](prd-v0.1.en.md). 产品范围变更时，两个版本必须同次同步。

> 文档状态：产品权威 PRD；`0.1.2-beta.1` 已作为 GitHub Pre-release 发布，用于安装试用与验证真实使用价值；不等于稳定版或插件市场验收完成
> 日期：2026-08-27
> 产品范围：DeepSeek Harness 会话级、本地 Web 原型验收  
> 依据：[技术 Spike 报告](spike-report.md) · [技术架构](architecture.md) · [对抗式审查](adversarial-review.md) · [首切片验收](first-slice-acceptance.md)

## 发布前摘要：它是什么

**DSH Visual Acceptance 是一个本地优先的 Web 原型验收与复验工作台。**

它服务于使用 DSH 或 Codex 生成、修改本地 Web 页面的人：在 Agent 说“完成”之后，用户可以声明要检查的页面、视口、主题和状态，运行真实浏览器检查，保留截图与异常事实；再由用户决定哪些候选问题正式进入 Issue、是否允许修改，并在修改后按同一 Matrix 复验。

它不是通用视觉问答工具，不是自动修图或自动改代码工具，也不以一个“视觉评分”替代验收结论。系统只生成浏览器事实和候选关系；是否成为 Issue、是否允许修改、是否已解决，始终由人确认。

```text
本地页面 / localhost
  → 声明验收 Matrix
  → 浏览器事实 + 截图
  → Finding Candidate
  → 人工立为 Issue / 作出 Decision
  → 复制只读修改包给 Agent
  → 原 Matrix Retest
  → 人工确认解决、未解决或回归
```

### 当前 Beta 能做什么

- 检查 localhost 或当前 DSH 会话工作区内的 HTML；不接受公网 URL；
- 用快速、标准、页面断点或最多 8 个自定义 Checkpoint，采集 Ready、运行异常、响应式质量事实和内容有效的 PNG 截图；
- 将异常事实和状态未到达保存为 Finding Candidate，而不是自动宣告产品有问题；
- 由用户明确创建项目级 Issue、追加人工 Decision，并仅在 `approved-fix` 后生成可复制的本地 Markdown/JSON 修改包；
- 从基线 Run 复制不可变 Matrix 创建 Retest；系统只给出候选关系，`resolved` 必须由用户确认；
- 在插件关闭时取消运行并释放浏览器、路由和监听器。

### 当前 Beta 不承诺什么

- 不比较参考设计图，不做 OCR、视觉定位、VLM 推理或“AI 模板感”判定；Retest Pixel Diff 只记录同 Matrix 变化 Candidate；
- 不自动发现页面、点击第三方站点、复现未声明的交互状态或测试公网 URL；
- 不自动修改项目，不会把修改包发送给 DSH/Codex Agent；
- 不以 `reached`、截图生成成功或 0 个异常信号宣称“页面视觉通过”或“可交付”；
- 不宣称已完成真实项目 5 项试点、主观视觉判断 Eval 或 DSH Desktop 全兼容。

### 用户得到的最小结果

每次 Run 都回答验收四问：**检查对象是否正确、范围是否覆盖、发现会影响什么、下一步由谁决定。**

`Ready 已满足` 只表示该 Checkpoint 的声明条件已满足；`Finding Candidate` 只表示存在值得人工查看的浏览器证据；`Issue`、`approved-fix` 和 `resolved` 都必须有用户动作与可追溯历史。

## 0. 当前实现边界

`0.1.1-closed-loop-beta` 已验证确定性底座与最小人工闭环，不是 PRD 全量完成：

| 能力 | 状态 | 当前证据 |
|---|---|---|
| 会话级 `conversation.view` 工作台 | 已实现、已实测 | 真实 DSH Web 非空会话 |
| 手工 Target / Matrix | 已实现、已实测 | localhost + 桌面/390px 两检查点 |
| 浏览器事实与截图 | 已实现、已实测 | 2/2 Ready 满足；状态观测一致；信号可展开追溯 |
| 工作区 Run 存储 | 已实现、已实测 | 原子 manifest；目录 `0700`；manifest/PNG `0600` |
| 取消与关闭释放 | 已实现、已实测 | `cancelled`、Host `disposed`、无残留验收 Chrome |
| Finding Candidate 与项目级 Issue | 已实现、已实测 | Fixture 字体 Candidate 经用户明确立为 Issue；手工视觉 Issue API/UI 已实现 |
| Decision 历史与修改包 | 已实现、已实测 | `approved-fix` 追加保存；本地 Markdown/JSON 生成并复制；未自动发送 Agent |
| 原 Matrix Retest 与人工确认 | 已实现、已实测 | Retest 固定复用基线 Matrix；`still-detected` 经人工确认为 `unresolved` |
| 合并 / 拆分 / 否决 | 已实现、自动测试 | Host API 与项目级存储已覆盖；尚未纳入真实项目试点 |
| 响应式覆盖计划与断点发现 | 已实现、已实测 | Quick/Standard/Breakpoint/Custom 已在 DSH Web 核对；Fixture 完整发现 `640px / 900px` |
| 确定性质量与状态配方 | 已实现、专项 Spike | 基础质量规则、截图内容校验、六类受控动作；不等于 WCAG/真实设备 |
| Retest Pixel Diff | 已实现、专项 Spike | 仅原 Matrix 基线/当前/Diff；变化只生成 Candidate |
| 参考设计图比较 | 尚未实现 | 参考图身份、对齐和视觉判断仍为目标设计 |
| Provider 图片推理 | 尚未实现 | 仅 CLI 探测与契约 Spike |
| 自动 Agent 会话注入 | 明确后置 | 当前只允许用户复制只读修改包 |

### 0.1.2 本轮增量：Responsive Acceptance（源码候选已实现）

本轮不把更多尺寸直接堆成复选按钮，而把响应式覆盖组织为四种可解释的方案：

| 覆盖方案 | Matrix | 用途 |
|---|---|---|
| 快速验收 | `390×844` + `1280×800`，主主题 | 每次 Agent 修改后的低成本复验 |
| 标准验收 | 6 个布局视口跑主主题；`390×844`、`1280×800` 补副主题，共 8 项 | 发布前常规覆盖 |
| 页面断点验收 | 读取页面可访问样式表中的真实 Media Query，在断点两侧生成最多 8 项 | 查找断点切换处的布局问题 |
| 自定义 | 用户声明 1–8 个 Checkpoint | 特殊页面、状态和尺寸 |

标准布局视口为 `360×800 / 390×844 / 768×1024 / 1024×768 / 1280×800 / 1440×900`。`320×568` 和 `1920×1080` 只作为可选边界，不默认扩大 Matrix。

这些档位是确定性的 CSS 布局视口，不是具体手机、平板或真实设备。没有 UA、触摸、DPR、移动 Safari 或真实设备证据时，界面和文档不得使用“iPhone 已通过”“移动设备兼容”等表述。

本轮同时补齐三层能力，但保持事实边界：

1. **确定性质量信号**：Viewport Meta、图片替代文本、表单标签、按钮可访问名称、重复 ID、横向越界交互元素和截图内容有效性；它们是规则证据，不等于完整 WCAG 审计。
2. **视觉基线候选**：Retest 在原 Matrix 下比较基线和当前截图，保存变化比例与 Diff 证据；视觉变化只生成 Candidate，不自动创建 Issue 或写入 `resolved`。
3. **受控状态配方**：Checkpoint 可保存 `click / fill / select / press / wait / assert-ready`，不接受任意 JavaScript；步骤和结果进入不可变 Matrix 与复现证据。

## 0.1.2 业务模型与交互图

### 核心业务框架

```mermaid
flowchart LR
    U[AI 产品经理 / 构建者] --> W[DSH Visual Acceptance]
    W --> C[覆盖方案与不可变 Matrix]
    C --> R[本地 Chrome Runner]
    R --> E[运行事实 / 响应式截图 / Diff 候选]
    E --> H[人工 Issue 与 Decision]
    H --> P[只读修改包]
    P --> A[DSH 或 Codex Agent]
    A --> T[原 Matrix Retest]
    T --> H
    V[可选视觉 Provider] -. 后置适配 .-> E
```

### 业务实体关系

```mermaid
classDiagram
    class CoveragePreset {
      +id
      +version
      +layoutViewports
    }
    class BreakpointDiscovery {
      +source
      +widths
      +completeness
    }
    class Checkpoint {
      +path
      +state
      +viewport
      +theme
      +actions
      +ready
    }
    class AcceptanceRun {
      +runId
      +matrixFingerprint
      +runKind
    }
    class RuntimeEvidence {
      +facts
      +screenshot
      +visualComparison
    }
    class Issue {
      +lifecycle
      +decisionHistory
      +verificationHistory
    }
    CoveragePreset "0..1" --> "1..8" Checkpoint : 生成临时 Matrix
    BreakpointDiscovery "0..1" --> "1..8" Checkpoint : 建议临时 Matrix
    AcceptanceRun "1" *-- "1..8" Checkpoint : 持久化快照
    AcceptanceRun "1" *-- "0..8" RuntimeEvidence : 持久化
    Issue "0..*" --> "1..*" RuntimeEvidence : 引用
```

`CoveragePreset` 与运行前的断点建议属于临时配置；Run、Evidence、Issue、Decision 和 Verification 为工作区持久化对象。该图不表示数据库表结构。

### 关键业务时序

```mermaid
sequenceDiagram
    actor U as 用户
    participant W as 验收工作台
    participant B as 本地浏览器
    participant A as Agent
    U->>W: 输入 Target，选择覆盖方案
    opt 页面断点验收
      W->>B: 只读发现 Media Query
      B-->>W: 断点及完整性
      W-->>U: 展示并等待确认
    end
    U->>W: 确认 Matrix 并运行
    W->>B: 按 Checkpoint 重放状态配方
    alt 取消、Ready 未到达或证据无效
      B-->>W: cancelled / unreached / failed
      W-->>U: 保留失败证据，不宣告通过
    else 完成
      B-->>W: 事实、截图、可选 Diff
      W-->>U: Candidate 与响应式总览
      U->>W: 立为 Issue / 批准修改
      W-->>U: 复制只读修改包
      U->>A: 用户自行交给 Agent
      A-->>U: 完成修改
      U->>W: 按原 Matrix Retest
      W-->>U: 候选关系
      U->>W: 人工确认解决、仍存在或回归
    end
```

### 最终用户交互流

```mermaid
flowchart TD
    A[打开视觉验收] --> B[输入本地 Target]
    B --> C{选择覆盖方案}
    C -->|快速| D[2 项 Matrix]
    C -->|标准| E[8 项 Matrix]
    C -->|页面断点| F[发现断点]
    F --> G{发现是否完整}
    G -->|完整或接受部分结果| H[确认断点两侧 Matrix]
    G -->|失败| C
    C -->|自定义| I[声明页面、状态、配方和 Ready]
    D --> J[确认范围并运行]
    E --> J
    H --> J
    I --> J
    J --> K{运行结果}
    K -->|取消/失败/unreached| L[显示可恢复原因]
    L --> C
    K -->|完成| M[响应式证据总览]
    M --> N{是否需要跟踪}
    N -->|否| O[保留 Run]
    N -->|是| P[创建 Issue 与 Decision]
    P --> Q[用户交给 Agent 修改]
    Q --> R[原 Matrix Retest]
    R --> S[人工确认关系]
```

因此，本文的 FR/AC 继续作为 V0.1 目标；未在上表标记“已实现”的接口和流程不得在 README、演示或发布说明中写成现有能力。

## 1. 产品结论

V0.1 要交付的不是另一套视觉工具，而是一次可复验的验收闭环：

```text
确认对象 → 声明矩阵 → 到达状态 → 收集事实/候选判断
→ 人工决定 → 复制获批修改包 → 用户交给 Agent 修改 → 同条件复验
```

## 2. 问题与为什么使用 AI

### 用户问题

AI 生成页面后，用户仍要人工拼接浏览器检查、截图比较、审美判断、业务状态检查和修改记录。缺少统一对象和历史，导致“生成完成”被误认为“可以交付”。

### 为什么不是全部使用 AI

以下问题有确定性答案，必须由规则和浏览器提供：

- 页面是否打开；
- 资源与字体是否加载；
- 控制台和请求是否报错；
- 是否横向溢出；
- URL、Selector 和状态是否到达。

AI 只用于规则难以完整表达的候选判断：

- 信息层级；
- 内容密度；
- 视觉自然度和模板感；
- 产品状态或业务表达可能缺失。

AI 不是最终裁判，也不能覆盖确定性失败。

## 3. 目标用户与核心 JTBD

### 目标用户

使用 DSH 生成或修改本地 Web 产品的个人构建者、AI 产品经理和小团队负责人。

### JTBD

当 Agent 完成页面修改后，我需要按指定页面、视口、主题和状态快速找出有证据的问题，决定哪些允许修改，并确认修改后没有引入回归。

## 4. 产品目标

- O1：任何验收结论都能追溯到 Target、Checkpoint 和 Evidence；
- O2：明确区分运行事实、视觉事实、体验候选和产品候选；
- O3：人工拥有允许修改、接受风险和驳回的最终决定权；
- O4：同一矩阵可以重放，同一 Issue 可以复验；
- O5：视觉 Provider 缺失时仍可完成运行事实验收。

## 5. 非目标

- 通用图片问答、图片生成和视频验收；
- 自动发现所有页面与业务状态；
- 未经确认自动修改用户项目；
- 自动作最终审美决定；
- 单一综合分数；
- CI/CD、团队协作和云端 Dashboard；
- 原生 App 和真实移动设备测试；
- Codex Skill；
- 与现有三个个人插件强耦合。

## 6. 核心概念

### Acceptance Project

同一个本地项目的验收配置与历史。

### Acceptance Run

一次不可变的验收执行，包含目标快照、环境、矩阵、证据和 Issue 结果。

### Checkpoint

页面 × 状态 × 视口 × 主题的最小检查单元，必须有 Ready 条件。

### Issue

可追踪的问题记录。Issue 不等于模型输出；只有标准化 Finding 才能进入 Issue。

## 7. 信息架构

完整 V0.1 目标包含五类信息。当前 Beta 将其压缩进同一会话级结果区，避免新增复杂页面：

1. **对象与范围**：参考图、目标地址、构建指纹、Matrix；
2. **运行状态**：运行中、Ready 满足、Ready 未满足、运行失败；
3. **问题与决定**：当前使用折叠项目级 Issue 账本；复杂筛选后置；
4. **证据详情**：当前提供完整截图与浏览器事实；局部裁剪和 Provider 后置；
5. **复验关系**：当前显示六类候选关系，并由人工确认或否决。

V0.1 不占用 DSH `details`，也不依赖全局导航。

## 8. 主流程

### 8.1 创建验收

1. 用户打开当前会话的“视觉验收”View；
2. 输入本地 HTML 或 localhost；
3. 选择快速覆盖，或手工添加 Checkpoint；
4. 核对 Target 与 Matrix 摘要；
5. 系统校验 Ready 条件配置。参考截图与 Target 构建指纹后置。

### 8.2 执行

1. Host 启动一次性 Runner；
2. Runner 对每个 Checkpoint 固定 CSS 视口和主题；
3. 到达 Ready 条件；
4. 收集浏览器事实和截图；
5. 生成确定性 Finding Candidate。视觉 Provider 调用后置。

### 8.3 人工决定

每个问题必须回答：

1. 检查对象是否正确；
2. 检查范围是否覆盖；
3. 问题会影响什么；
4. 下一步由谁决定。

用户可选择：

- `approved-fix`；
- `accepted-risk`；
- `dismissed`；
- `deferred`。

### 8.4 修改与复验

系统只为 `approved-fix` Issue 生成包含目标、证据、影响和修改边界的本地只读 Markdown/JSON。当前由用户复制给 Agent，不自动发送。修改完成后重放同一 Matrix，系统生成 `new-candidate / still-detected / possibly-resolved / regressed / not-verifiable / needs-human-review`，只有人工确认才能写 `resolved`。

## 9. 功能需求

### Target 与 Matrix

- **FR-001** 用户可以创建工作区本地 Acceptance Project。
- **FR-002** 用户必须确认参考图、目标地址和目标指纹。
- **FR-003** 用户可以手工声明页面、状态、视口、主题和 Ready 条件；非默认状态必须使用可区分的 Ready Selector/Text。
- **FR-004** 系统不得自动把未声明页面计入覆盖范围。
- **FR-005** Ready 失败必须记为 `unreached`，不得记为通过。
- **FR-006** 系统必须提供版本化的快速、标准、页面断点和自定义覆盖方案，并在运行前列出最终 Checkpoint。
- **FR-007** 标准方案必须在单次 8 项上限内覆盖 6 个布局视口和 2 个副主题锚点，不能静默生成笛卡尔积。
- **FR-008** 页面断点方案必须记录断点来源、发现宽度和完整性；无法读取的样式表必须显示为部分发现。
- **FR-009** 覆盖方案只生成运行前 Matrix；Run 创建后必须保存确切 Checkpoint，后续 Preset 变化不得改变旧 Run 或 Retest。

### 确定性检查

- **FR-010** 系统必须记录浏览器、OS、请求视口、Layout/Visual Viewport 和主题。
- **FR-011** 系统必须收集 console error 与 uncaught exception。
- **FR-012** 系统必须收集请求失败和 HTTP 4xx/5xx。
- **FR-013** 系统必须记录图片加载状态和 `naturalWidth`。
- **FR-014** 系统必须计算相对请求 CSS 视口的横向溢出。
- **FR-015** 系统必须为每个已执行 Checkpoint 生成截图。
- **FR-016** 截图必须通过格式、尺寸和内容有效性检查；疑似空白时重试一次，仍为空白则生成明确 Candidate，不得静默进入报告。
- **FR-017** 系统必须记录 Viewport Meta 与基础可访问性规则信号，并明确标注“自动规则不等于完整无障碍审计”。
- **FR-018** 系统必须识别横向越界的可见交互元素并保存定位证据；页面正常纵向滚动不得误报。
- **FR-019** 多视口结果必须按 Checkpoint 展示，并可按规则聚合 Candidate；聚合不得自动合并正式 Issue。

### Provider 与 AI 判断

- **FR-020** 系统必须先探测 Provider 可用性和版本。
- **FR-021** Provider 必须可取消并设置超时。
- **FR-022** Provider 输出必须带来源、版本和能力声明。
- **FR-023** Provider 缺失时运行事实仍可执行。
- **FR-024** AI 体验/产品判断默认进入 `needs-human-review`。
- **FR-025** AI 判断不得覆盖确定性浏览器事实。
- **FR-026** Retest 必须在同尺寸截图间产生可追溯的视觉比较结果，记录算法、阈值、变化像素和 Diff 证据。
- **FR-027** 尺寸不一致、基线缺失、截图无效或环境不可比时，视觉比较必须为 `not-comparable`，不得生成“视觉已解决”。
- **FR-028** 视觉 Diff 只能生成 Finding Candidate；任何正式 Issue、基线接受和解决状态仍需人工动作。
- **FR-029** 参考设计比较与历史回归基线必须使用不同类型；本轮只实现原 Matrix Retest 的历史截图比较。

### Issue 与证据

- **FR-030** Issue 必须包含 ID、Target、Finding、Evidence、Impact、Suggestion 和 Decision Owner。
- **FR-031** Issue 必须分别保存 lifecycle、decision、verification。
- **FR-032** 系统必须给出 Issue 候选指纹。
- **FR-033** 用户可以纠正 Issue 合并、拆分和回归关系。
- **FR-034** 人工决定不得被后续 Run 自动覆盖。

### Agent 交接与复验

- **FR-040** 只有 `approved-fix` Issue 可以进入修改包。
- **FR-041** 修改包必须包含允许修改范围和不得修改范围。
- **FR-042** 系统不得直接修改目标项目。
- **FR-043** 用户可以按原 Matrix 创建 Retest Run。
- **FR-044** Retest 必须区分新增候选、仍检出、疑似已解决、回归、无法验证和需人工复核；`resolved` 只能由人工确认写入。
- **FR-045** Checkpoint 可以保存有限状态配方：`click / fill / select / press / wait / assert-ready`。
- **FR-046** 状态配方不得接受任意 JavaScript、Shell、跨域导航、文件上传或凭据读取。
- **FR-047** 每个动作必须记录顺序、结果和失败原因；动作失败使 Checkpoint `unreached`，不得继续伪造目标状态。
- **FR-048** `fill` 与 `select` 值属于用户声明的测试数据，进入修改包前必须脱敏或只标记“存在值”。
- **FR-049** 状态配方必须进入 Checkpoint Key 与 Matrix Fingerprint，Retest 继续执行原配方。

### 本地数据与生命周期

- **FR-050** Run、Issue、Decision 和 Evidence 默认保存在工作区本地。
- **FR-051** 插件关闭时必须释放 Chrome、端口、监听器和临时目录。
- **FR-052** 插件禁用后不得影响 DSH 原生会话。
- **FR-053** 数据 Schema 必须带版本并支持未来迁移。

## 10. UX of uncertainty

界面必须显式展示四类来源：

| 类型 | UI 表达 | 是否可自动判定 |
|---|---|---|
| 运行事实 | “浏览器检查”+ 原始值 | 是 |
| 视觉事实 | “Diff/定位证据”+ Provider | 依能力而定 |
| 体验判断 | “AI 候选”+ 理由/不确定性 | 否 |
| 产品判断 | “待产品确认”+ 缺失状态依据 | 否 |

禁止使用没有校准意义的百分比置信度。Provider 未提供可靠置信区间时，只显示来源、证据充分性和 `needs-human-review`。

## 11. 模型方案

V0.1 不训练模型。采用可替换 Provider：

- 结构化 OCR/布局/语义：优先 CLI Provider；
- 精确位置和像素：使用确定性工具或具有明确坐标契约的 Provider；
- 体验/产品判断：使用多模态模型生成候选 Finding；
- Prompt 固定包含验收四问、证据引用和禁止过度声明规则。

模型不能写入正式 Decision，也不能自行把 Issue 标记为 resolved。

## 12. 质量门槛与 Eval

### 确定性层发布门槛

- 固定 Fixture 中已知 console/request/image/overflow 问题漏检为 0；
- 正常状态误报为 0；
- 相同环境连续两次运行事实一致；
- `unreached` 状态识别率 100%；
- 截图有效性失败必须显式报错。

### Issue 复验门槛

- 受控语料中的同问题 ID 保留率 100%；
- 人工 Decision 保留率 100%；
- 真实试点中所有自动关联均可人工纠正；
- 不以自动关联准确率未达标为理由覆盖历史。

### AI 候选判断门槛

建立至少 20 个固定样例的盲测集。建议上线门槛：

- P1/P2 候选被人工保留的精度 ≥ 80%；
- 证据引用完整率 100%；
- 确定性事实冲突率 0；
- 同输入重复三次的核心 Finding 一致率 ≥ 80%。

未达到时，V0.1 只发布确定性事实和手工 Issue，不发布主观 AI 判断。

## 13. Guardrails 与隐私

系统绝不能：

- 未经确认修改用户项目；
- 把 Provider 声明能力写成已执行事实；
- 把 `unreached` 写成通过；
- 把静态检查写成浏览器验证；
- 上传完整页面、Cookie、Token 或输入框内容；
- 用综合分数隐藏具体失败；
- 在 Provider 失败时生成伪造结果。

默认所有 Run、截图和决定保存在本地。若未来使用远程模型，必须逐次显示将上传的图片范围和 Provider。

## 14. Fallback

| 故障 | 行为 |
|---|---|
| Provider 不存在 | 跳过视觉/AI 层，继续运行事实 |
| Provider 超时 | 标记 unavailable，不重试付费调用 |
| 状态未到达 | 标记 `unreached`，保留失败证据 |
| 截图空白 | 重试一次，仍失败则阻断该 Checkpoint 视觉结论 |
| Chrome 启动失败 | 整个 Run 失败，不退化为静态扫描并冒充浏览器检查 |
| Issue 关联不确定 | 创建候选关联，交给人工确认 |
| DSH Client 不兼容 | 禁用 UI Adapter，保留本地数据，不影响宿主会话 |

## 15. 性能、成本与延迟

### 本地确定性检查

- 建议目标：4 个 Checkpoint 的 p95 ≤ 90 秒；
- 单个 Checkpoint Ready 默认超时 10 秒，可由用户调整；
- 同一 Run 默认最多 8 个 Checkpoint，避免无意创建大规模爬取任务。

当前 Spike 在 4 个 Checkpoint × 2 轮下约 20–23 秒，但这是 Fixture 环境，不作为真实项目性能事实。

### Provider

- 默认关闭远程付费推理；
- 调用前显示 Provider、图片数量和是否可能产生费用；
- V0.1 不设虚假的固定成本，需在首个真实 Provider Spike 后补充；
- 建议单 Checkpoint AI 分析 p95 ≤ 30 秒，超时即降级。

## 16. 数据反馈闭环

本地记录：

- AI Candidate 被保留、驳回或修改；
- Issue 被合并或拆分；
- 自动关联被纠正；
- 哪类问题最终进入修改。

这些数据默认只用于本地 Eval，不自动上传。未来任何聚合都必须单独征得同意并去除项目内容。

## 17. Rollout

### Phase 0：内部 Fixture（闭环 Beta 已完成）

- 已完成真实 DSH Web 的 Run → Candidate → Issue → Decision → 修改包 → 原 Matrix Retest → 人工确认；
- 补 Desktop 壳层深浅色、关闭重开；
- 建立 20 个 AI Eval 样例。

### Phase 1：5 个真实本地项目

- 每个项目至少两轮复验；
- 只开放本地 HTML/localhost；
- 默认关闭远程 Provider；
- 每次 Run 收集人工纠错。

### Phase 2：有限发布

- 满足确定性、Issue 和 Client 生命周期 Gate；
- 开放一个经过验证的视觉 Provider；
- 保留关闭 AI 层的 Kill Switch。

### 回滚触发

- 插件影响 DSH 原生会话加载；
- 出现无法释放的 Chrome/端口；
- 自动修改绕过人工确认；
- `unreached` 或 Provider 失败被误写为通过；
- 用户项目内容未经确认被上传。

## 18. V0.1 验收标准

### AC-001 完整闭环

给定一个包含默认、空和错误状态的本地项目，当用户完成两轮 Run 时，系统必须展示矩阵覆盖、证据、人工决定以及新增/未解决/已解决/回归分类。

### AC-002 确定性与 AI 分层

浏览器事实和 AI Candidate 必须有不同来源标签；关闭 Provider 后，浏览器验收仍可完成。

### AC-003 人工控制

未经 `approved-fix` 的 Issue 不得生成修改包；`accepted-risk` 与 `dismissed` 在复验中保持。当前修改包只允许复制，不自动发送到 Agent。

### AC-004 生命周期

插件安装、关闭、禁用和重开不得产生重复 View、残留 Chrome、端口或监听器。

### AC-005 声明边界

状态未到达、截图无效或 Provider 失败时，报告必须明确显示失败，不能输出“已通过”。

### AC-006 响应式覆盖

快速方案生成 2 个、标准方案生成恰好 8 个 Checkpoint；页面断点方案显示发现来源和完整性，并在运行前展示确切断点两侧宽度。旧 Run 不因 Preset 更新而变化。

### AC-007 确定性质量

Fixture 中缺少 Viewport Meta、图片替代文本、表单标签、按钮名称、重复 ID 和横向越界控件分别生成可追溯 Candidate；正常 Fixture 不产生对应误报。自动结果不得写成“完整 WCAG 通过”。

### AC-008 视觉比较

原 Matrix Retest 对同尺寸截图生成基线、当前和 Diff 证据；相同截图变化为 0，受控视觉变化产生 Candidate，尺寸或证据不可比时明确降级。视觉变化不得自动创建 Issue 或写 `resolved`。

### AC-009 状态配方

受控 Fixture 能通过 `click / fill / select / press / wait / assert-ready` 到达目标状态；非法 Selector、动作失败、取消和超时均保存失败步骤并进入 `unreached` 或 Run 取消，不能继续宣告状态已复现。

## 19. 发布前待确认

1. 首个真实视觉 Provider 选择 ModLens、Agent Vision Toolkit CLI 或其他实现；当前仍后置；
2. 工作区数据目录是否默认加入 `.gitignore`；
3. 远程 URL 是否进入后续版本，当前继续后置；
4. AI Candidate Eval 的 20 个样例由哪些真实页面组成；
5. 真实设备与 WebKit/Firefox 是否通过外部 Provider 进入，而不是扩张本地 Chromium Runner。