🔒 需人类裁决：解锁 V-D 的四个字段缺口（D2/D3/D4/D5）—— 这是 CLR 到 10 分的关键路径

## 为什么现在需要你裁决

CLR 统一衡量（#814）四条 track 里，**V-D（项目对话主屏保真）是最大缺口**：rev-uiux 第 6 轮
实测 **1/10**，已迭代 6 轮，D 组仍停在 1 分。

`chat-main-fidelity-rubric.md` 十维里，**D2/D3/D4/D5 四维卡在契约缺字段**——#728 会话已经
重申过两轮「待人类裁决」。按 ADR-023，契约口径只有人能改，**agent 再迭代多少轮也解不开**。

⇒ 这四条是 CLR 到 10 分的**关键路径**，且瓶颈在裁决不在工时。

## 我核实过的现状（不看叙述，grep 真实契约）

| 维度 | 原型要什么 | 契约今天有什么 |
|---|---|---|
| D2 编制区 | 每行 = 头像 + 名字 · **角色** + **一句能力描述** + 在场态 | 只有 `duty: z.string()`（非空，I-17：「说不出职责的 agent 等于噪音」）——**一个字段要当两个用** |
| D5 消息身份 | agent 消息带 **角色 chip** + **所用 skill chip** | 同上缺角色；skill 归属未投影到消息 |
| D3 线程列表副行 | **负责 agent** · 时间 · **状态徽标**（转录中 N / N 条待复核 / 已归档） | 线程无「负责 agent」字段；`MessageBadge` 已有 `review-pending`、`archived` 已有 |
| D4 线程头部面包屑 | **项目 / 阶段 / 周次**，不是裸 id | 线程有 `projectId`；**「阶段」「周次」在项目域里根本不存在**（`ThreadPhase` 是 `onsite/research`，是会话类型不是项目阶段） |

## ⚠ 关键判断：这四个缺口性质不同，不该用同一种办法解

- **D2/D5 是「少个字段」**——概念存在（agent 确实有角色），只是契约没建模。
- **D4 是「少个概念」**——「项目阶段/周次」这个领域概念在产品里压根不存在。
凭空加字段去凑面包屑，是拿建模成本换一行 UI，而且会造出一个没人维护的假层级。
- **D3 一半一半**——「状态徽标」大部分可从已有数据派生；「负责 agent」隐含一个
「线程有归属 agent」的领域概念，今天不存在。

**本仓最忌讳的就是为了让界面像原型而造一个没有真实语义的字段**（`chat-ux-acceptance-criteria.md`
第 1 条硬性要求）。所以我不建议四条一律「加字段」。

---

## 裁决项

### D-1｜agent 的「角色」（影响 D2 + D5，两维）

| 方案 | 做法 | 优点 | 缺点/风险 |
|---|---|---|---|
| **A（推荐）** | 新增 `role: z.string()` 短标签，`duty` 保留为能力描述 | 与原型逐字对应；chip 显示短标签才好看；两个语义分开后各自可校验 | 契约变更 + 需要写入路径（谁设 role）+ 存量 agent 要回填默认值 |
| B | 复用 `duty` 当角色，不加字段 | 零契约变更，今天就能做 | `duty` 语义是「一句职责」，把一句话塞进 chip 会截断/难看；D2 要求的「角色 + 能力描述」两件事仍然只有一件 |
| C | 从 `duty` 派生短标签（截断/取首句） | 零契约变更 | **编数据**。本仓明令禁止，且派生规则一定会在某些 duty 上出洋相 |

**推荐 A**，理由：这是四条里唯一「概念真实存在、只是没建模」的一条，加字段是诚实的。
配套需要你一并定：① 谁能设 role（建 agent 时必填？admin 后台可改？）② 存量 agent 回填什么。
我的建议是**建 agent 时必填、admin 可改、存量回填为 `duty` 的前 8 字并标记待人工确认**。

### D-2｜D3 线程列表副行

| 方案 | 做法 | 优点 | 缺点/风险 |
|---|---|---|---|
| **A（推荐）** | 状态徽标**从已有数据派生**（`review-pending` 计数、`archived`、录音会话活跃态）；**不做「负责 agent」** | 全部有真实数据支撑，零新概念；D3 大部分判据能满足 | D3 严格按判据可能仍拿不到满分（少「负责 agent」一项） |
| B | 同时新增 `ownerAgentId` | 完全对齐原型 | 「线程归属某个 agent」这个概念产品里不存在，得先定义：谁指派？能改吗？跟 roster 什么关系？——这是一次产品设计，不是加字段 |
| C | 「负责 agent」= roster 第一个 / 第一个 present 的 | 零成本 | 武断，且会随 roster 变动跳来跳去，用户会认为是 bug |

**推荐 A**，并**接受 D3 暂时拿不满**。理由：为了一个副行去引入「线程归属」这个新领域概念，
代价远超收益；而且一旦引入，它会渗透到权限、通知、交接等一堆地方。

### D-3｜D4 面包屑「项目 / 阶段 / 周次」

| 方案 | 做法 | 优点 | 缺点/风险 |
|---|---|---|---|
| **A（推荐）** | 只显示**真实存在的层级**：组织 / 项目名（+ 已有的 `ThreadPhase` 如适用）；缺的层级**不显示、不占位** | 诚实；零建模成本；符合「没有真实数据支撑就不做假 UI」 | D4 严格按判据拿不满 |
| B | 建「项目阶段 / 周次」领域模型 | 完全对齐原型 | **几周的工作**，涉及项目域建模、迁移、写入路径、权限；而它服务的只是一行面包屑 |
| C | 面包屑写死成占位文案 | 零成本 | 假 UI，明令禁止 |

**推荐 A**。这条我态度最明确：**原型里的「阶段/周次」是画界面时顺手画上去的，
背后没有产品概念**——ADR-023 建立契约束签核，防的正是这种「后端契约在画界面时被顺手创造」。

---

## 如果你采纳三条推荐，会发生什么

- D2、D5 **可解**（走 D-1 方案 A，一次契约变更）
- D3、D4 **部分可解**，但**按现行判据拿不到满分**

⇒ 直接后果：**V-D 这条 track 在现行判据下到不了 10/10。**

所以还有第四个裁决项：

### D-4｜判据本身要不要调（这条只有你能定）

| 方案 | 做法 | 说明 |
|---|---|---|
| **A（推荐）** | 承认「原型有两处超出产品域」，把 D3「负责 agent」与 D4「阶段/周次」从判据中**移除或降级为可选**，并在 rubric 里写明裁决出处 | 让 10 分变成一个**可达**的目标。评分卡自己写着「认为原型不对，写进需要人类裁决一节，不要自行改判据」——这就是那一节 |
| B | 判据不动，接受 V-D 永远 8/10 封顶 | 那么 CLR 也永远到不了 10，「10 分门」失去意义 |
| C | 判据不动，按 D-2/D-3 的方案 B 全建 | 诚实且完整，但要几周，且为一行面包屑建一个项目阶段模型 |

**推荐 A**。理由：10 分门的价值在于它**可达且严格**。一个结构上不可能达到的满分，
会让所有人默认「反正到不了」，门就废了——这比降低标准更危险。

---

## 我需要你回什么

四条各回一个字母即可（A/B/C），或直接说「按推荐走」。
裁决后：D-1 我会按 ADR-023 登记契约束待签核；D-4 的判据修改由**你**改 rubric
（agent 不许改判据），我会把改动位置和措辞准备好给你确认。

Start by reading chat-main-fidelity-rubric.md, chat-ux-acceptance-criteria.md, ADR-023, and the referenced #728 and #814 discussions. Review the D2–D5 gaps and the A/B/C choices, then wait for the human ruling; done means the decisions are recorded in the contract process and any approved rubric changes are explicitly documented.

Written by the indexing model from the issue text.