---
# 需求溯源索引 frontmatter（必填；design-record 与 handoff 两类文档都带）。
# 同一需求的多篇文档共用同一 id → build-request-index.mjs 据此归组。
id: <slug>                       # [a-z0-9-] 稳定 slug，需求级主键（非 Jira key）
title: <Feature Name>
doc_type: design-record          # design-record | handoff
status: in-dev                   # requirement | in-dev | QA | delivered
target_release: "<8.x>"          # 可选；无则删本行
last_updated: YYYY-MM-DD
sources:                         # 0..N；type ∈ jira|slack|miro|bug|email|verbal|doc|other；ref 必填、url 可选
  - { type: jira, ref: "<KEY>", url: "https://tvunetworks.atlassian.net/browse/<KEY>" }
figma:                           # 可选；无则删本段
  file: <fileKey>
  nodes:
    - { id: "<node-id>", label: "<用途>", url: "<figma url>" }
---

# Feature Design Record — <Feature Name> (<JIRA-KEY>)

> 每个功能需求一份。命名 `docs/specs/YYYY-MM-DD-<jira>-design-record.md`。
> 目的：把"为什么这么设计 + 设计了什么 + 谁负责"沉淀成可追溯文档，供后续迭代 / 维护 / 其他 UX 设计师复用同一逻辑。
> 本模板由 tvu-design-system 维护；新 consumer 经 `setup-tvu-consumer` scaffold 自动带。
> **顶部 frontmatter 必填**（需求溯源索引，见 design-process.md § 需求溯源索引）；改动后跑 `node docs/scripts/build-request-index.mjs` 重生成 `docs/REQUEST-INDEX.md`。

---

- **JIRA**：[<KEY>](https://tvunetworks.atlassian.net/browse/<KEY>)　**Scope**：Config-T / V3 LCD / V4 LCD / …
- **Owner(dev)**：<name>　**PM**：<name>　**Designer**：<name>
- **Status**：草稿 / 待 review / 已交付　**日期**：YYYY-MM-DD

## 1. 问题与根因
从 ticket description + 评论链 + Slack 解码出的真实问题与根因（区分"bug"还是"预期行为/限制"）。

## 2. Scope & Non-goals
做什么；明确不做什么（哪些界面/产品不在本需求范围）。

## 3. Baseline 参考
对齐的现有设计（Figma node-id 列表 + 一句用途）。M21 sibling 视觉契约来源。

## 4. 设计 — 状态与指示模型
各 state（含 normal / 异常 / 收起态等）+ 视觉指示规则（颜色/边框/遮罩/图标语义）。沿用设备原生范式，不自造。

## 5. UX 交付
- 产品 UI 文案（设备语言单语，M33）
- 注释层（双语，M23）
- 组件来源（库组件 key / file-local clone / 原生范式）

## 6. 决策记录
本需求拍板的关键决策（# | 决策 | 理由）。

## 7. 依赖 / 待办
固件接口 / 跨团队确认 / 字体等环境约束。

## 8. 交付链接
Figma Section node-id（整份交付物包在一个 Section）、spec / handoff 链接。

## 9. 路由与评审
- Assignee（按 scope 路由）/ Reviewer（PM）/ FYI 名单
- JIRA 回复评论链接（@PM review + Figma link + @相关人 FYI）