[feature][roadmap] 节点增加「团队」维度 — node.team 归属信息 + 详细方案

[s2agi]

Author

Agent: 通信龙 — Vincent telegram 5848 + 5849

目标（后续迭代的长期目标）

每个节点新增一个维度的信息 —— 团队（team）：这个节点属于哪个团队。

当前 anet 节点有 alias / node_id / runtime / network / model / channels 等维度，但没有「团队归属」概念。Vincent 希望把团队作为节点的一等维度信息。

例：通信工程马 ∈「anet 迭代小组」、通信IM马/通信IM牛 ∈「IM 接入组」、N站马 ∈「Dashboard 组」……

价值

• 组织架构可视化 —— team 是 org-chart 的天然分组键，直接喂给 [feature][dashboard] Dashboard 组织架构视图 — 经典公司 org-chart 展示（总指挥/副指挥 → 多团队 → 成员） #170（Dashboard 组织架构视图）、[ux][dashboard] Topology 区域左上角固定展示负责人节点 #163（负责人节点）。
• 团队级操作 / 团队 roster / 团队级 dashboard 分组与过滤。
• 比现在「靠 alias 前缀猜团队」更可靠 —— 前缀分组是 hack，team 字段才是 source of truth。

范围（需详细方案 / RFC 定）

跨层 feature，需要一份详细方案（RFC 级）覆盖：

1. 数据模型 —— team 存哪？config.json 的 node.team 字段？还是 commhub 侧 teams 表？team 是自由文本还是受控枚举？一个节点能否属于多个团队？
2. CLI —— anet node create --team <name>；anet node set-team？是否要 anet team 命令族（list / create / assign）？
3. commhub —— team 进 registration / status payload；是否需要 team-scoped 查询。
4. Dashboard —— 按 team 分组 / 过滤；喂 [feature][dashboard] Dashboard 组织架构视图 — 经典公司 org-chart 展示（总指挥/副指挥 → 多团队 → 成员） #170 org-chart。
5. 迁移 —— 现有节点如何回填 team（默认值 / 交互 / 批量）。

优先级 / 节奏

后续迭代目标（Vincent 5849 明确「作为后面迭代的一个目标」），非当前 sprint。先开 issue 占位 + 收敛方案，不抢当前 preview.4 / rename #146 / #173-A / #174 的资源。

Related

• [feature][dashboard] Dashboard 组织架构视图 — 经典公司 org-chart 展示（总指挥/副指挥 → 多团队 → 成员） #170 — Dashboard 组织架构视图（org-chart，本维度的主要消费方）
• [ux][dashboard] Topology 区域左上角固定展示负责人节点 #163 — Topology 负责人节点（同 org 结构方向）

Agent Assignment

详细方案 / RFC 待派（候选 通信工程马 / 通信SDK马）—— 当前 preview.4 + 测试 crunch 过后由通信龙安排。

[s2agi]

RFC-019 草稿完成 — scope 扩为 team + role

按 Vincent 2026-05-22 指示，本 issue 的节点「团队」维度扩展为 team + role 两个组织维度，由通信工程马产出 RFC：

📄 docs/rfcs/RFC-019-node-team-role.md（已推 main，commit f704c4e）

关键调研发现：Profile 接口已有 team?: string + role 字段（RFC-008 sci-team demo 引入的 demo-only 元数据，saveProfile 已持久化）。本 RFC 不是从零加字段，而是把它们从 demo 元数据提升为一等组织维度 —— 实施成本低于预期。

RFC 覆盖：数据模型 / CLI / commhub / Dashboard / 迁移 / 分期 + 9 个待 Vincent 拍板的决策点。

主要设计推荐（待 review + Vincent 拍）：

• role = 软枚举（自由文本 + 内置推荐集：负责人 / 工程师 / 测试 / 设计 / 文档 / 运营）。
• team / role 单值（org-chart 需树形结构）。
• config.json = source of truth，commhub 存投影副本。
• 团队「涌现」模型 —— 无独立 teams 注册表，team 由节点字段聚合涌现，anet team ls/show 只读。
• 明确区分 node.role（团队职能角色）vs 网络成员 role（权限层级）。

流程：通信牛 review 中 → review 过 → 通信龙转 Vincent 拍板（§9 决策点）→ 分期实施（P1 CLI / 数据模型 → P2 commhub → P3 Dashboard → P4 anet team 命令）。

[s2agi]

RFC-019 review 通过 — 待 Vincent 拍 6 个决策点

通信牛 review verdict = APPROVE WITH NITS，无阻塞架构问题。

• 6 条 nits 全是实现层 refinement，已全部 fold 进 RFC-019 + commit b4bb96a（推 main）：§3.6 字段约束 / §4.2 重启同步语义 / §4.3 团队命令数据源 / §5.1 env / §6.2 负责人冲突规则 / §8 release 节奏。

§9 的 6 个决策点已整理成清单转 Vincent：

1. role 内置推荐角色集 — 需 Vincent 实拍（提议 负责人/工程师/测试/设计/文档/运营，软枚举、表外可加）。
2. role 软枚举 vs 硬枚举 — 推荐软枚举（通信牛 ✓）。
3. team/role 单值 vs 多值 — 推荐单值（通信牛 ✓）。
4. 团队涌现模型 vs 显式注册表 — 推荐涌现、无 anet team create（通信牛 ✓）。
5. node.role vs 网络成员 role 命名 — 推荐「团队角色」vs「成员角色」（通信牛 ✓）。
6. P1 单发 vs P1+P2 一起 — 推荐 P1+P2 一起（通信牛建议 B）。

Vincent 拍完 → 工程马 finalize RFC-019 为 Accepted → 排实施（P1 CLI + 数据模型 → P2 commhub → P3 Dashboard → P4 anet team 命令）。