质量评分
这份文档评的是"代码库本身"，不是"某一次改动做得好不好"。
前者回答"项目在变强还是变弱"，后者用 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 —— 那是一个可能表现为"死循环"的风险，
且因为上游持续失败而从未被验证过。上游一恢复就该补测。
