# Open Design 与企业 OKR 闭环差异审计

审计日期：2026-07-13  
审计范围：`frontend/public/prototype.html`、当前 Vue 路由与页面、Spring Boot 接口与业务服务、SQLite 实际库与迁移机制。

## 1. 结论

当前项目已经具备 18 个原型页面对应的路由，也具备周期、OKR、评分、申诉、沟通、归档的基础接口，但还不能认定为“完整支撑企业 OKR 闭环”。主要原因不是样式，而是以下结构性缺口：

1. 原型展示一个人可以有多个 Objective，现有主流程强制每人每周期只能提交一个 Objective。
2. 原型包含公司、部门、个人三级目标，现有前端只调用个人 OKR 提交接口；已有层级提交接口没有接入页面，且公司目标的创建权限与“CEO 设置公司目标”不一致。
3. 对齐关系同时使用 `parent_objective_id`、`aligned_objective_ids` CSV 和 `source_kr_id`，没有统一的数据真相源。
4. 执行甘特图需要 KR 起止日期，现有表没有这些字段，当前 timeline 只能根据周期范围推算，不能表达原型中的真实计划。
5. 员工无法在前端完成面谈回复，也无法查询自己的申诉；因此“发布结果 → 申诉/确认 → 面谈 → 归档”会卡住。
6. 接受申诉不会重新打开最终评分，归档校验也不检查未结申诉。
7. 周期参与人没有快照直属上级、部门和岗位，周期中组织调整会改变历史审批链和评分链。
8. SQLite `PRAGMA foreign_keys` 当前为 `0`；多个业务唯一性只由服务层查询保护，并发或重复请求可能产生重复记录。
9. 已执行迁移的版本描述与当前代码中的同版本迁移含义不一致，说明迁移版本被复用，旧数据库可能静默跳过后来改写的迁移。
10. 当前视觉只完成了设计 token 和局部组件替换。工作台、空态密度、页面层级、表格和详情结构仍与原型有明显差异。

因此，后续应按“闭环垂直切片”重构，而不是继续逐页替换 CSS。

## 2. 原型中应保留与应删除的内容

### 应保留

- Cohere 白色画布、深靛蓝与青色品牌色、240px 分组侧栏、56px 顶栏。
- 工作台的周期摘要、待办、风险、团队概览。
- 公司/部门/个人三级 OKR、承接关系、对齐树、异常项。
- KR 进度更新、计划时间轨道、进度历史。
- 自评、上级评分、结果发布、确认/申诉、绩效沟通、历史归档。
- 周期阶段轨道、绩效模板、考核维度、组织树、通知和审计日志。

### 应删除或企业化替换

- 登录页的“活跃用户、评分完成率、医院科室”等营销统计。
- “医生、护士、患者、门诊、病历、科室设备采购、全院质控”等医疗样例。
- 医院科室、主任医师、护理人员模板等行业专用组织和岗位文案。
- 原型中使用 emoji 作为正式业务图标的实现方式；使用现有 Element Plus 图标库。
- 原型登录后仍保留登录面板的展示缺陷。该问题是原型脚本/CSS 冲突，不作为目标效果。
- 没有真实数据来源的“AI 洞察”。可先使用确定性规则生成风险提示，不伪装成模型结论。

## 3. 页面差异矩阵

| 页面 | 当前状态 | 核心差异 | 后端/数据影响 |
|---|---|---|---|
| 登录 | 部分一致 | 已删除医院统计，但品牌图资源有不透明底图，版式比例与原型不一致 | 无 |
| 工作台 | 部分一致 | 当前三张统计卡纵向过高，缺少原型的 4 指标组合、成员明细表和可执行风险入口 | `workspace/overview` 需返回对象链接、完整团队统计、阶段进度 |
| 我的 OKR | 结构不一致 | 当前只支持一个 O；原型有多个 O、O 权重、描述、来源关系表 | Objective 字段和提交契约必须重构 |
| 团队 OKR | 部分一致 | 只有直属下属卡片，缺少部门级 O、成员详情页和层级下钻 | 增加成员详情路由；接口返回部门目标与成员聚合 |
| OKR 对齐 | 部分一致 | 已有 graph，但单父级、CSV 多对齐、KR 来源三套关系并存 | 规范化 alignment 表与异常规则 |
| 执行进度 | 视觉占位 | 有进度历史，但 KR 没有计划起止日期，甘特位置不是真实计划 | KR 增加 `start_date`、`due_date`；timeline 返回真实区间 |
| 我的绩效 | 部分一致 | 自评和结果混在一页可用，但工作流动作与申诉/沟通状态没有统一展示 | 聚合返回当前申诉、沟通、允许动作 |
| 历史绩效 | 部分一致 | 通过逐周期请求详情，缺少稳定的归档快照读取契约 | 提供历史摘要/详情接口，读取归档快照 |
| 绩效打分 | 部分一致 | 仅直属下属；缺少队列筛选、申诉中状态、阶段截止信息 | review queue 返回状态、截止与申诉摘要 |
| 绩效考评 | 接近但有逻辑冲突 | OKR 60、绩效维度 40、默认 60%、加扣分上限 20 已体现；HR 被显示为可评分但服务只允许直属上级 | 统一评分授权规则；结构化评分 DTO |
| 绩效申诉 | P0 不完整 | 页面仅适用于 HR；普通员工访问会被接口 403，无法查看自己的申诉进度 | 增加“我的申诉”；接受申诉后进入待修正/待重发状态 |
| 绩效沟通 | P0 不完整 | 页面仅适用于主管；员工没有回复入口，已有 `/feedback/reply` 未接入 | 增加员工视图和“我的沟通”接口 |
| 考核周期 | 部分一致 | 有状态轨道和 readiness，但缺少各阶段截止日期；允许执行阶段直接归档 | 增加阶段日期；取消绕过考评的常规归档路径 |
| 绩效模板 | P0 不完整 | 模板只有 JSON 项；岗位靠“模板名等于岗位名”隐式匹配，没有分配和实例化流程 | 模板项规范化或稳定 JSON schema；增加 assignment/instance |
| 考核维度 | P0 数据风险 | 全局维度可改；增删改后再校验总分但服务未加事务，失败时可能留下非法总分 | 事务化；按周期快照维度配置 |
| 组织架构 | 部分一致 | 已有树和循环上级校验；角色与 CEO 业务身份混在一起，周期内组织变化未快照 | 周期参与人快照审批链；区分系统权限和业务层级 |
| 消息通知 | 部分一致 | 顶栏可跳转；侧栏缺少通知入口；通知没有统一可路由的目标契约 | `ref_type/ref_id` 映射为服务端 `target_url` |
| 操作日志 | 部分一致 | 筛选与备份已存在；缺少关键状态变更前后业务摘要 | 审批、对齐、评分修正、申诉处理必须完整留痕 |

## 4. 闭环流程审计

目标流程如下：

```mermaid
flowchart LR
  A["HR 创建草稿周期"] --> B["配置参与人、阶段日期、绩效模板与维度快照"]
  B --> C["发布 OKR 对齐"]
  C --> D["CEO 创建并发布公司级 OKR"]
  D --> E["一级负责人承接并提交部门/个人 OKR"]
  E --> F["直属上级逐级审核"]
  F --> G{"全部参与人 OKR 与绩效配置就绪?"}
  G -- 否 --> E
  G -- 是 --> H["锁定并进入执行"]
  H --> I["员工更新 KR，主管跟踪风险"]
  I --> J["进入考评"]
  J --> K["员工自评"]
  K --> L["直属上级评分"]
  L --> M["发布结果"]
  M --> N{"员工确认还是申诉?"}
  N -- 确认 --> O["绩效沟通与员工回复"]
  N -- 申诉 --> P["HR 受理、必要时修正并重新发布"]
  P --> N
  O --> Q["关闭沟通"]
  Q --> R{"所有参与人完成且无未结申诉?"}
  R -- 否 --> J
  R -- 是 --> S["生成完整快照并归档"]
```

### 当前会卡住或绕过的节点

- CEO 的公司级目标：`submit-hierarchy` 仅按 HR 及以上角色判断，前端没有入口；CEO 作为组织树顶级负责人不是稳定规则。
- 多层承接：个人主流程只允许对齐直属上级 Objective，且只有单个 Objective，无法复现原型的多 O/多 KR 承接。
- 进入执行：readiness 会检查每个参与人有已审核 OKR 和锁定 KPI，但前端没有批量生成/分配并锁定个人绩效配置的完整流程。
- 员工回复面谈：后端有接口，前端没有入口，归档又要求所有参与人沟通状态为 `CLOSED`。
- 申诉：员工无法查询自己的申诉；接受申诉后不会把最终评分改为待修正；归档未检查 `OPEN` 申诉。
- 顶级负责人：自评和终评规则没有定义谁给 CEO 评分；如果 CEO 进入参与人快照，可能无法完成上级评分和面谈。
- 直接归档：当前允许 `EXECUTING -> ARCHIVED`，与“必须完成逐级评定后归档”的目标冲突。

## 5. 接口层必须统一的契约

### 周期与配置

- `POST /api/periods`：包含阶段截止日期和参与范围。
- `GET /api/periods/{id}/readiness`：返回结构化 blocker（code、count、userIds、targetUrl），不只返回文案。
- `POST /api/periods/{id}/configuration/instantiate`：把模板、维度和参与人审批链实例化到周期。
- `PUT /api/periods/{id}/status`：只允许顺序流转；生产流程不再允许执行期直接归档。

### OKR

- 用 Objective 集合提交契约替代单 Objective 提交：一个用户可有 1～5 个 O，每个 O 有 2～5 个 KR，O 权重合计 100，KR 权重在 O 内合计 100。
- 公司级 O 由组织树唯一顶级业务负责人创建；HR 负责周期管理，不默认代替 CEO 创建目标。
- 部门级 O 由部门负责人创建；个人 O 由本人创建并由周期快照中的直属上级审批。
- 对齐使用规范化关系；`parent_objective_id` 作为主要层级，额外承接关系存 `okr_alignment`，不再写 CSV。
- 详情、团队、对齐、timeline 接口都返回同一套 Objective/KR DTO。

### 绩效

- 自评、上级评分、最终结果使用显式请求 DTO，不再以自由 JSON 作为唯一明细。
- 服务端统一校验：OKR 满分 60；绩效维度满分 40；每项默认值为其满分的 60%；加分和扣分各 0～20；最终分 0～100。
- 评分人来自周期参与人快照，避免周期中调整直属上级后改变历史评分权。
- 接受申诉后最终评分进入 `APPEAL_ACCEPTED/REVISION_REQUIRED`，修正后重新发布并重新确认。
- 归档检查所有参与人都有自评、上级评分、已发布且已确认结果、已关闭沟通，并且没有未结申诉。

## 6. SQLite 目标结构与迁移要求

### 需要扩展

- `assessment_period`：增加 `okr_due_date`、`execution_end_date`、`self_review_due_date`、`manager_review_due_date`、`confirmation_due_date`。
- `period_participant`：增加 `department_id_snapshot`、`superior_id_snapshot`、`position_snapshot`、`role_snapshot`、`evaluator_id`、`template_id`。
- `okr_objective`：增加 `description`、`weight`；删除业务对 `aligned_objective_ids` CSV 的依赖。
- `kr_key_result`：增加 `start_date`、`due_date`、`unit`、`baseline_value`。
- 新增 `okr_alignment`：`objective_id`、`parent_objective_id`、`source_kr_id`、`relation_type`。
- 新增 `okr_review_record`：保留每次提交、通过、驳回、备注和版本。
- 新增 `period_dimension`：周期级维度快照，不能直接读取可变的全局维度。
- 新增 `kpi_template_assignment` 或等价周期实例表：显式关联岗位/部门/用户，不再用模板名匹配岗位。

### 必须增加的约束

- `performance_score(period_id, user_id, type, deleted)` 业务唯一。
- `performance_feedback(period_id, user_id)` 唯一。
- `kpi_config(period_id, user_id)` 唯一。
- Objective 和 KR 权重、分数、日期范围增加 `CHECK` 约束或等价服务校验。
- 开启并验证 SQLite foreign key；不能只创建无约束的 ID 字段。
- 新迁移使用未占用版本号，绝不改写历史版本。当前库内迁移 2 的描述与代码不一致，必须先增加迁移一致性测试。

## 7. 推荐实施顺序

建议采用闭环优先方案，而不是按页面目录施工：

1. **周期配置切片**：周期阶段日期、参与人/审批链快照、模板与维度实例化、readiness。
2. **三级 OKR 切片**：CEO 公司目标、多 Objective、部门/个人承接、审核、统一对齐模型。
3. **执行切片**：KR 计划日期、真实甘特、进度与风险、团队成员详情。
4. **绩效切片**：自评、主管评分、发布、默认 60%、加扣分上限、结构化明细。
5. **争议与沟通切片**：员工申诉查询、受理修正、重新发布、员工面谈回复、关闭。
6. **归档切片**：完整 readiness、不可变快照、历史查询。
7. **视觉收口**：18 页同视口对照、桌面/平板/手机验证、清理所有医疗文案和空壳按钮。

每个切片都必须包含：失败测试、数据库增量迁移、后端契约测试、前端交互测试、浏览器截图对照和单 JAR 静态资源验证。

## 8. 验收场景

最终必须用独立测试数据完成以下 E2E：

1. HR 创建周期并发布，参与人、审批链、模板和维度均被冻结。
2. CEO 创建多个公司 Objective；一级负责人承接后，员工按组织树逐级提交并逐级审核。
3. 任一参与人未审核或绩效配置未锁定时，周期不能进入执行。
4. 执行期员工更新 KR；风险和甘特使用真实日期与真实进度。
5. 进入考评后，员工先自评，直属上级再评分并发布。
6. 员工可以确认，也可以提交申诉并查看进度；接受申诉后必须修正、重发、重新确认。
7. 主管发起沟通，员工回复，主管关闭。
8. 有未结申诉、未确认结果、未关闭沟通或缺失评分时不能归档。
9. 归档后任何 OKR/KR/评分/维度/组织调整都不会改变历史详情。
10. 员工、主管、部门负责人、HR、超级管理员分别只能看到和操作授权范围内的数据。

## 9. 审计证据

- Open Design 登录页：`reference-login-viewport.png`
- 当前登录页：`current-login.png`
- Open Design 工作台：`reference-workspace.png`
- 当前工作台：`current-workspace.png`
- SQLite 实测：WAL 已启用，但 `PRAGMA foreign_keys = 0`。
- 当前实际数据：8 个用户、6 个部门、1 个周期、2 个 Objective、0 条评分。