ADR：常驻角色元数据收敛为单源（registry.yaml 权威，roles/*.yaml 生成）

## 现状（2026-09-09 盘点，B1）

`kind` / `areas` / `reports_to` 在两处各手写一遍，6 个 role 全部如此：

- `.harness/agents/registry.yaml`（身份的单一事实源，头部注释自己写着「改动走 PR review」）
- `.harness/agents/roles/.yaml`（portable role 表面，`gen-subagents` 的输入）

原有 `role-freeze-doctor` 只校验 `name` 在不在 registry 里，两份副本的**内容**从没被比对过。

## 已落地（本 issue 不重复做）

PR 里加了 `findRoleMetadataDrift`：逐字段比对，不一致 ⇒ **FAIL**（不是 WARN——元数据漂移会让派工按错误的 areas/kind 走）。缺省 `reports_to` 与显式 `null` 等价；`areas` 逐项按顺序比。今天 6/6 一致，门控绿。

## 待决（本 issue 追踪的终局方案）

把 registry.yaml 作为**唯一**手写来源，`roles/*.yaml` 改为生成产物（同 `gen-subagents` 生成 `.claude/agents` / `.codex/agents` 的做法），生成结果与提交内容不一致 ⇒ CI 红。

需要 ADR 决定的点：

1. `roles/*.yaml` 里 registry 没有的字段（`description` / `merge_authority` / `dispatch_authority` / `developer_instructions`）往哪放——扩 registry schema，还是 role 文件保留「只写 registry 没有的字段」的补充形态？
2. registry 有 4 个身份没有对应 role 文件（`coord-chat-e2e` / `coord-agent-auth` / `dev-platform-baseline` / `dev-auth`）——生成器是给它们全都生成，还是按 `active` 或某个显式开关筛？
3. 生成产物要不要进仓库（现在 role 文件是进仓库的、被人读的）。

在 ADR 落地前，一致性断言就是这条规则的机械门控。

Read .harness/agents/registry.yaml and the files under .harness/agents/roles/, then inspect gen-subagents and findRoleMetadataDrift. Resolve the ADR questions about extra fields, inactive identities, and committed generated files. Done means registry.yaml is the sole hand-edited source and generation plus CI reject inconsistent committed output.

Written by the indexing model from the issue text.