# 质量评分

> **这份文档评的是"代码库本身"，不是"某一次改动做得好不好"。**
> 前者回答"项目在变强还是变弱"，后者用 [`sops/evaluator-rubric.md`](../sops/evaluator-rubric.md)。
>
> 更新时间：**每轮重要会话之后 / 做基准对比之前 / 清理或重构之后 / 换模型或换 agent 时**

## 怎么打分

每个领域按四项打 **强 / 中 / 弱**：

| 维度 | 问自己 |
|---|---|
| 验证状态 | 这块有验证手段吗？还是只能靠手点？ |
| Agent 可读性 | 一个新会话能只靠仓库内文件看懂这块吗？ |
| 测试稳定性 | 验证手段是稳定的，还是时好时坏？ |
| 关键缺口 | 有没有已知但没记下来的问题？ |

---

## 产品领域

### 对话协议适配（`api-chat-coordinator.ts`）

| 维度 | 评级 | 说明 |
|---|---|---|
| 验证状态 | **强** | 有对真实后端端到端验证的套路；契约测试可复现 |
| Agent 可读性 | **强** | 类型定义完整、关键决策有注释、接口契约在 `harness/docs/reference/` |
| 测试稳定性 | 中 | 验证依赖真实后端；上游不稳定时会误判（上游失败 ≠ 前端错） |
| 关键缺口 | ⚠️ **有** | "选中候选提交文本是否循环"从未验证（上游持续失败，`status: found` 未出现过）。见 `exec-plans/tech-debt-tracker.md` #1 |

### 消息渲染（`components/Chat/`）

| 维度 | 评级 | 说明 |
|---|---|---|
| 验证状态 | 中 | 顺序、换行、复制等有过针对性验证；视觉观感仍靠人工看 |
| Agent 可读性 | 中 | `BusinessRecord.vue` 体量大、状态机复杂（打字机 / scope 退出 / 行合并），新人上手成本高 |
| 测试稳定性 | 弱 | 没有自动化视觉或行为测试 |
| 关键缺口 | ⚠️ **有** | 渲染管线有多处"历史遗留的隐式行为"（如 `processPolicyTableBlock` 会把 POLICY_TABLE 之前的内容当纯文本），靠注释提示，没有测试兜底 |

### 政策卡片与详情（`PolicyMatch.vue`）

| 维度 | 评级 | 说明 |
|---|---|---|
| 验证状态 | 中 | 字段映射有验证；筛选行为按用户要求**刻意保持**旧实现 |
| Agent 可读性 | 中 | 单文件体量大；"哪些是刻意保持的"只在 `tech-debt.md` 里说明 |
| 测试稳定性 | 弱 | 无自动化测试 |
| 关键缺口 | 有 | 部门筛选在新数据下筛不出结果（刻意，见 `tech-debt.md` #4） |

### 补问问卷（`QuestionCard.vue`）

| 维度 | 评级 | 说明 |
|---|---|---|
| 验证状态 | **强** | 四种 `kind`+`status` 形态有断言；提交映射有覆盖 |
| Agent 可读性 | 中 | 新增的 `freeformInputOnTop` 等字段有注释；但 `message` 字段定义了却没渲染 |
| 测试稳定性 | 中 | 静态断言稳定；真实交互仍靠手点 |
| 关键缺口 | 有 | `status: failed` 与"无 status"两种只有静态断言，未在真实后端遇到过 |

### 文件上传（待定）

| 维度 | 评级 | 说明 |
|---|---|---|
| 验证状态 | **弱** | 入口已隐藏，未开始 |
| Agent 可读性 | 中 | 原实现参数有文档（legacy 快照） |
| 测试稳定性 | — | 未开始 |
| 关键缺口 | ⚠️ **有** | 后端方案未定，无法开工（见 `tech-debt.md` #3） |

---

## 架构层

| 层 | 边界执行 | Agent 可读性 | 说明 |
|---|---|---|---|
| 协议适配层 | **强** | **强** | 职责单一：事件 → 内容标记。渲染层不感知协议，边界清晰 |
| 渲染层 | 中 | 中 | 边界靠约定维持，无强制手段 |
| 网络层（`network/api/`） | 中 | **强** | 文件少、职责清楚 |
| 状态层 | 中 | 中 | 无状态库，状态散在组合式函数 + localStorage；跨会话恢复靠 localStorage |

---

## 当前总评

**整体在变强**。协议适配层的引入把一个高变动风险（接口协议）隔离在了单一文件里，
这是这段时间最有价值的改动。

**最弱的一环是"验证"**：除了协议适配层，其余部分基本没有自动化验证手段，
依赖人工查看。`tools/` 目录建起来之后，鼓励把一次性的验证脚本沉淀下来。

**最需要盯的缺口**：`tech-debt.md` #1 —— 那是一个可能表现为"死循环"的风险，
且因为上游持续失败而**从未被验证过**。上游一恢复就该补测。