---
id: multi-channel-device-naming
title: Multi-Channel (RPS One) Device Naming — Per-Channel Rename
doc_type: design-record
status: requirement-analysis
target_release: TBD
last_updated: 2026-08-20
sources:
  - { type: jira, ref: "FB-10315", url: "https://tvunetworks.atlassian.net/browse/FB-10315" }
  - { type: jira, ref: "V4-2375", url: "https://tvunetworks.atlassian.net/browse/V4-2375" }
  - { type: slack, ref: "PM DM thread (Trevor Yao) 2026-08-20", url: "https://tvunetworks.slack.com/archives/DTM79RVFD/p1787196706109069?thread_ts=1787163063.966899&cid=DTM79RVFD" }
  - { type: slack, ref: "CC 改名逻辑同步 thread (Mike Peng) 2026-08-20", url: "https://tvunetworks.slack.com/archives/CU54F5TRP/p1787195873753279?thread_ts=1787195564.378739&cid=CU54F5TRP" }
figma: null
---

# Design Record — 多路设备（RPS One）逐路命名（FB-10315 / V4-2375）

- **JIRA**：[FB-10315](https://tvunetworks.atlassian.net/browse/FB-10315)（`Product Feature Request`，Polaris）→ 实现单 [V4-2375](https://tvunetworks.atlassian.net/browse/V4-2375)（`To Do`，assignee = Nancy Zeng，无 fixVersion，无 due date）
- **Reporter**：Lorenzo Lipscomb（客户 ABC）　**催办**：Jeremy Hudson　**PM**：Trevor Yao　**Designer**：Nancy Zeng
- **Scope 候选**：CC（Command Center）· TPC　**不涉及 pack 端 LCD / Config-T**
- **Status**：需求与现状已核实，**方案与改动范围未定**（等 Trevor + Sunny Yin 确认）　**日期**：2026-08-20

## 1. 客户要求

ABC 要求 **RPS One（TM1100，一台四路）的每一路可以按他们自己的约定命名**，而不是被系统强制的数字序号后缀（`_1/_2/_3/_4`）绑住。他们保留 `_X / _Y / _Z` 作为副路后缀，且后缀与 SDI 序号严格对应：

| 名称 | 对应输入 |
|---|---|
| `NY_PACK_401` | SDI 1 |
| `NY_PACK_401_X` | SDI 2 |
| `NY_PACK_401_Y` | SDI 3 |
| `NY_PACK_401_Z` | SDI 4 |

> Jira 标题（"names being preced with _1 or _2"）措辞含混，**实际诉求在 description**：不是要加 `_1/_2`，而是要摆脱它、换成自家后缀。

**场景**：ABC 台内已有既成的命名/调度约定，下游系统与 MCR 按 `_X/_Y/_Z` 识别"同一台背包的副路"。改我们的命名规则比改他们的流程便宜，所以成本被推给我们。**商业压力低但在被催**：8/04 报单时明说「愿意跟我们的排期，无 due date」；8/19 Jeremy 追进度，说 ABC 在问。

## 2. 现状核实（2026-08-20 实测，⛔ 含一次自我纠错）

### 2.1 命名规则真源
- **副路（从设备）名称由主设备名自动生成**，规则由**前端**处理 —— 前端传什么，后台就记什么。
- **老规则**：主设备无后缀或以 `_1` 结尾 → 从设备只能是 `_2/_3/_4`。
- **新规则**（累加式）：主设备可以以 `_05` 这样结尾 → 从设备变 `_06/_07/_08`（即 `N+1/2/3`），默认 `_01`。
  - **TPC 最新版应已支持此累加规则，但是否上线未确认** → 待跟 Summer Chen 对齐。

### 2.2 CC 侧实测结论
- CC 界面上把多路设备**显示成多个独立设备**，但改名时会校验是否为主设备：**非主设备不允许改名**。
  - ⛔ **纠错**：先前判断「CC 把多路当独立设备管理，可独立修改从设备名称」是**错的**，实测已推翻。下个 session 勿沿用。
- CC 目前**只支持改主设备名**，且主路名默认以 `_01` 结尾；**改成其他结尾不生效，但界面仍提示"修改成功"** —— 误导性提示，建议一并修掉。
  - 独立复现：Mike Peng 同日报同一现象（主 peerid 改成后缀 `_11` 显示成功但实际不生效，后续 peerid 未跟着变 12/13/14）。

### 2.3 因此
**当前 CC 与 TPC 都不能满足 FB-10315** —— 从设备名不可独立编辑，且后缀必须是数字序号累加，无法是 `_X/_Y/_Z`。

## 3. PM 态度演变

| 时间 | 场合 | 态度 |
|---|---|---|
| 2026-08-19 | Jira FB-10315 评论 | **反对**："We designed it this way for convenience… it'll be messier if we do what they ask" |
| 2026-08-19 | Jira（Jeremy 回应） | Jeremy 提折中：加 opt-in 开关（戏称 "sloppy name"），愿意乱命名的客户自己开，默认不打扰其他客户。Trevor 未在 Jira 回此条 |
| 2026-08-20 02:11 → 11:32 | Slack DM thread | **软化为原则上不反对**："I'm a little worried about other side effects" + "But I can't think of any at the moment"。**既未正式批准，也未否掉** |

**回应 side-effect 担忧的技术依据**（已在 thread 里给 Trevor）：目前命名方式与规则都是**前端处理**（前端传什么后台记什么）。
- 好处：**一处的修改不会影响其他系统**（所以"改 CC 会连带影响 TPC/pack"这类副作用不成立）。
- 坏处：**命名规则可能不统一**（各系统各自为政，这是真实代价）。

## 4. 改动落点（两条路，未定）

1. **只在 CC 放开逐路改名** —— CC 侧改动。已在 CC thread 同步给 Sunny Yin / Mike Peng，cc Click Mao / augustli，并 @Trevor + @Sunny 确认范围。
2. **TPC 也要支持** —— 改 TPC 逻辑：**默认仍给从设备自动生成名称，但允许用户手动修改从设备名**。

两条路都落成「默认自动名 + 允许手动覆盖」的话，**Jeremy 提的额外 opt-in 开关就不必做**（手动覆盖本身即 opt-in，不改就沿用旧行为）。

## 5. 未决点（阻塞设计）

1. **改动范围**：CC only 还是 CC + TPC？→ 等 Trevor Yao + Sunny Yin 确认。
2. **TPC 的 `N+1` 累加新规则是否已上线**？→ 问 Summer Chen。
3. **CC 的误导性"修改成功"提示是否一并修**？（建议修；Mike Peng 已独立复现，属可单列的 bug）
4. **客户的 `_X/_Y/_Z` 是纯自由文本，还是仍需与 SDI 序号严格绑定**？Jira 上没向客户问过。这一点决定放开的是「整名自由编辑」还是「只放开后缀字符集、保留『主名 + 后缀』结构（从而保留归组能力）」—— 后者能同时消掉 Trevor 最初担心的"归组失效"。
5. **显示同源**：改后的名要在 CC / TPC / Receiver / MLink / SaaS 哪几端一致回显？重名冲突如何校验？

## 6. 对外沟通状态

- **Jira 未回、Slack 未再发**（2026-08-20 用户明确指示本轮不回）。待方案定了再回 FB-10315 / V4-2375。
- 已发出的只有 Slack 两处：PM DM thread 的现状说明，以及 CC thread 里那条「CC 需先支持逐路命名」的同步 + 范围确认请求。

## 7. 决策记录

- **2026-08-20** · FB-10315 / V4-2375 · 需求与现状核实 —— 客户诉求 = 副路后缀自定义（`_X/_Y/_Z`）而非摆脱不掉的数字累加；实测 CC 只能改主设备名且非 `_01` 结尾不生效却假报成功；TPC 累加新规则上线状态待确认；PM 由反对软化为"担心副作用但想不出具体的"；技术依据 = 命名规则在前端，一处改不影响其他系统，代价是规则可能不统一。**方案与范围未定，不动手画 mockup。**