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

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

1. 结论

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

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

目标流程如下：

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. 推荐实施顺序

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

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

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

8. 验收场景

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

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

full-gap-audit.md 14 KB Állandó hivatkozás Előzmények Nyers