# Workspace：War Room 与 Case Workspace 功能对比

本文档基于 2026-08-07 仓库中的当前实现，描述 `war_room` 与 `case_workspace` 的实际功能差异。它反映的是现状，不代表最终产品定义。

## 1. 总览

两种 Workspace 共用同一套数据模型、API、状态流转和详情页。当前实现中，War Room 更偏向需要即时协同和恢复确认的事故处理场景；Case Workspace 更偏向低频更新、可不依赖即时协作群的持续跟进场景。

| 功能 | War Room | Case Workspace |
| --- | --- | --- |
| 类型值 | `war_room` | `case_workspace` |
| Web 列表入口 | `War Rooms` | `Case Workspaces` |
| Web 创建入口 | 支持从 Jira Issue 或手工输入创建 | 支持从 Jira Issue 创建 |
| 后端创建 API | 支持从 Jira Issue 或手工输入创建 | 仅支持从 Jira Issue 创建 |
| 初始化时的 Lark 群 | 必须新建或关联一个 Lark 群 | 可新建、关联，也可不绑定 Lark 群 |
| 默认概览消息间隔 | 30 分钟 | 180 分钟 |
| 新成员 Check-in 私信 | 发送 | 不发送 |
| P1 初始化 Advice | 创建 2 条 Add Task Advice | 不创建 |
| Cluster 恢复确认任务 | 自动维护 | 不自动维护 |
| 普通任务、Affected Scope、Collaboration、Timeline | 支持 | 支持 |
| 状态流转 | `firing -> recovered -> archived` | `firing -> recovered -> archived` |

## 2. 创建与 Lark 群

两种 Workspace 共用同一个初始化 API，但允许的创建来源不同：

- `from_issue`：War Room 和 Case Workspace 都支持。系统读取 Jira Issue 的标题和 Assignee，并自动绑定该 Issue；
- `from_input`：仅 War Room 支持。调用方直接提供名称、描述和 Owner，不自动绑定 Issue；
- 当 `from_input.type=case_workspace` 时，参数检查会拒绝请求。Case Workspace 必须通过 `from_issue` 创建。

初始化请求中的 `create_lark_group` 对两种类型都是必填字段，调用方必须显式传入 `true` 或 `false`，其约束如下：

- War Room 必须设置为新建 Lark 群，或者提供 `link_lark_group_id` 关联已有群；
- Case Workspace 可以设置 `create_lark_group=false`，同时不提供 `link_lark_group_id`，以无群方式创建；
- 两种类型都不能同时新建群和关联已有群。

Web 端在 War Rooms 和 Case Workspaces 列表均提供创建按钮。War Room 创建窗口支持从 Jira Issue 或手工输入创建，并要求新建或关联 Lark 群；Case Workspace 创建窗口仅支持从 Jira Issue 创建，Lark 群可选择不绑定、新建或关联，默认不绑定。

创建请求中的 `severity` 字段是可选字段，但会根据 Workspace 类型执行不同规则：

- War Room 必须显式提供 `P1`、`P2`、`P3` 或 `P4`；
- Case Workspace 可以显式提供上述值；未提供时，系统读取初始 Jira Issue 的 Severity，并按照 `S1 -> P1`、`S2 -> P2`、`S3 -> P3`、`S4 -> P4` 映射；
- Jira Issue Severity 缺失或不是 `S1` 至 `S4` 时，Case Workspace 创建失败，不进行默认降级。

## 3. 概览消息与成员通知

Workspace 创建时会根据类型填充默认的 `send_overview_message_interval_minutes`：

- War Room：30 分钟；
- Case Workspace：180 分钟；
- 两种类型都可以后续修改该配置，设置为 `0` 时停止定时发送概览消息。

只要 Workspace 存在 Primary Lark Chat Group，两种类型都可以发送概览消息，也都会在任务完成后向 Primary Chat Group 发送消息。

成员 Check-in 是 War Room 专属行为：创建或绑定 Primary Lark Chat Group，以及后续新增 Workspace 成员时，系统只会为 War Room 的新成员发送包含角色和入群链接的私信。Case Workspace 即使绑定了 Primary Lark Chat Group，也不会发送该 Check-in 私信。

创建普通任务时，系统会直接向 Operator 和 Backup 发送任务指派私信；这段逻辑不区分 Workspace 类型。

## 4. Advice

### 4.1 初始化 Advice

系统仅在同时满足以下条件时创建初始化 Advice：

```text
Severity == P1 && Type == WorkspaceTypeWarRoom
```

满足条件时会创建两条 Add Task Advice：

1. `Update Status Page`
2. `Configure Console Banner`

两条 Advice 生成的任务优先级都是 `P0`，任务分组为 `External Communication`，Creator 为 `system`，Workspace Owner 为 Operator。

因此：

- P1 War Room：创建初始化 Advice；
- P2-P4 War Room：不创建；
- 任意 Severity 的 Case Workspace：均不创建。

### 4.2 Lark 消息触发的 Advice

Add Task、Bind Lark Meeting、Bind Lark Document Advisor 的 Lark Chat 注册逻辑不区分 Workspace 类型。只要 Workspace 处于 `firing` 状态并绑定了 Lark Chat，两种类型都可以进入相同的消息分析和 Advice 流程，具体 Advisor 还需在配置中启用。

无 Lark Chat 的 Case Workspace 不会进入这类基于群消息的 Advice 流程。

## 5. 任务与恢复流程

两种 Workspace 都有独立 Task List，并支持相同的普通任务查询、创建、修改、完成和删除能力。

War Room 会根据关联的 Cluster 自动维护 `Confirm Customer Recovery` 分组下的恢复确认任务：

- 每个关联 Cluster 对应一个系统任务；
- Cluster 绑定变化时自动新增、去重或删除任务；
- 任务默认由 Workspace Owner 负责；
- 所有未完成的恢复确认任务都会阻止 Workspace 从 `firing` 进入 `recovered`。

Case Workspace 会跳过恢复确认任务同步。恢复操作仍经过同一段状态流转逻辑，但正常情况下不会存在系统自动生成的 `Confirm Customer Recovery` 任务，因此不会受到这类任务的恢复前置约束。

## 6. 两种类型共用的能力

除上述差异外，以下能力当前共用同一套实现：

- Workspace 字段：名称、描述、Severity、成员、配置；
- Workspace 状态：`firing`、`recovered`、`archived`；
- Jira Issue、Alert、Tenant、Cluster 等 Affected Scope 绑定；
- 普通任务管理与任务指派通知；
- Lark Group、Meeting、Document 等 Collaboration Resource 管理；
- Timeline 收集、摘要编辑与详情展示；
- Overview、Tasks、Affected Scope、Collaboration、Timeline 五个详情页 Tab；
- Workspace 更新、恢复和归档操作。

Web 端通过 `type` 参数分别加载两种 Workspace，并使用不同的列表名称和详情路由：

| 类型 | 列表路由 | 详情路由 |
| --- | --- | --- |
| War Room | `/war-rooms` | `/workspaces/:workspaceId` |
| Case Workspace | `/case-workspaces` | `/case-workspaces/:workspaceId` |

## 7. 当前实现中的 Case Workspace 限制

以下行为来自共享实现，目前尚未完全按 Case Workspace 做产品化区分：

1. Overview 页面仍使用 DevOps Incident 的 `war_room_id` 查询 Associated Incident，Case Workspace 没有独立的 Incident 关联语义。
2. Lark Overview Card 的空状态文案仍使用 `War Room`。
3. Lark 消息中的 Workspace 链接仍统一指向 `/workspaces/:id`。对 Case Workspace 来说，该链接会进入 War Room 详情路由，而不是 `/case-workspaces/:id`。
4. Case Workspace 若不绑定 Lark Chat，将无法使用概览群消息、任务完成群通知以及基于群消息的 Advice，但不影响 Web 端的任务、Affected Scope、Collaboration 和 Timeline 功能。

## 8. 主要实现位置

- Workspace 类型与默认配置：`packages/sdk-go/contracts/entity/ticket-manager/workspace/workspace.go`
- 初始化参数及 Lark 群约束：`services/ticket-manager/internal/services/workspace/api/workspace.go`
- Workspace 初始化流程：`services/ticket-manager/internal/services/workspace/workspace.go`
- 初始化 Advice：`services/ticket-manager/internal/services/workspace/advice/advisor/addtask/add_task_advisor.go`
- 成员 Check-in：`services/ticket-manager/internal/services/workspace/behavior/workspace/member_check_in.go`
- Cluster 恢复确认任务：`services/ticket-manager/internal/services/workspace/task.go`
- Lark Overview Card：`services/ticket-manager/internal/services/workspace/behavior/workspace/lark_message.go`
- Web 路由与入口：`apps/web/ticket-manager/src/App.tsx`
- Web Workspace 列表与创建：`apps/web/ticket-manager/src/pages/workspace/list.tsx`
- Web Workspace 详情：`apps/web/ticket-manager/src/pages/workspace/detail.tsx`