发布前完整性检查新增「每个参与主体须配分管领导」(#29)

[baozhoutao]

工作项

#29(P1)—— 发布前完整性检查缺「每个参与主体须配分管领导」,未配置的主体流程死在领导审批节点。

改了什么

流程配了「领导审批」节点、却有主体没配分管领导时,方案照样能发布:填报单走到该节点后不会出现在任何人的队列里,流程死在这一步。发布前完整性检查补上这一条。

• src/hooks/plan.hook.ts:新增导出纯函数 missingLeaderProblems(steps, subjects) —— 流程含「领导审批」节点时,逐条列出未配分管领导的主体名称;没有该节点(节点可配置、可删)时不检查。PlanPublishHook 在既有 problems 收集处调用,与权重 / 目标值 / 争议三条同一编号列表、同一格式,三段式文案;
• test/design-alignment.test.ts:三条要求用例(缺配置被拦并逐条列出 / 全配齐放行 / 无领导节点不检查)+ 主体名为空的兜底用例;
• 演示脚本按需求补配置,不放松检查:software-people.mjs 把分管领导覆盖面从 9/11 补到 11/11(复用现有两位领导账号,不新增账号);e2e-flow.mjs 在发布前为 5 个参与主体配置分管领导;两处写死的期望值(分管范围、共享规则条数)改为按方案实配推导。

不改状态机、不改分管领导数据模型、不做审批人来源扩展;docs/ 与种子零改动。

自测

• pnpm verify 全绿(validate / typecheck / test 94 passed / i18n 与 schema 同步,本单未动 label);
• scripts/software-flow.mjs 54/54 PASS,scripts/e2e-flow.mjs 74/74 PASS;
• 界面实测(Playwright + Chromium,1440×900,zh-CN):缺分管领导发布被拦并逐条点名、界面补齐后发布成功生成 11 张填报单、默认档案种子缺口如实记录、删掉领导审批节点后不做此检查。

测试报告与需求符合度清单挂在 #29 评论上,截图在 acceptance-evidence 分支 commit 27e6bfb474b05ac98a9b1de410c46a67c3897784 的 issue-29/ 目录。

已知偏差(工作项预置出口):默认演示种子的 5 个参与主体本身没有分管领导(分管领导是用户查找字段,种子建不了用户),该演示方案的发布现在会被本条检查拦下并逐条列出 5 个主体。按工作项验收标准 2 的口径如实记录、不改种子;是否给默认种子补一位分管领导需维护者拍板。

🤖 Generated with Claude Code

[baozhoutao]

代码评审报告(os-project-dev-review)

档位:轻量(依据:工作项 #29「方案分级:纯新增一条检查,路径唯一,低风险,可直接开工」+ 调度员放行直接开工;因 diff 触及 3 个脚本,对脚本改动额外做了逐处核实与实跑复核)
基线:a760651;评审对象:分支 issue-29-publish-leader-check 单提交 c28bcef,5 个文件(src/hooks/plan.hook.ts +32、test/design-alignment.test.ts +37/-1、scripts/e2e-flow.mjs +16/-3、scripts/software-flow.mjs +5/-3、scripts/software-people.mjs +10/-3)

结论:可合并

通用质量

无阻塞/应修级发现。新增逻辑是一个纯函数 missingLeaderProblems(steps, subjects) + hook 内一行调用,插在既有 problems 收集链中,复用既有 fail(..., 'KPI_PLAN_INCOMPLETE') 整笔拒绝;空值处理(leader 为 null / 空串 / 全空格均判为未配置)、steps/subjects 为空的防御(?? [])都在。检查只挂在 draft → published 这一段,发布后方案配置由既有冻结规则锁死,不存在「发布后清空分管领导」的绕行口子。「方案一个流程节点都没有」的场景由既有 validateSteps(至少需要一个流程节点)先行拦下,不会退化成「没节点 = 不检查、运行期却按默认流程走到领导审批」的漏判。

专属核查

1. 改动面越界:✅ 无越界(附 1 条记录级说明)。禁触碰面(src/hooks/sheet.hook.ts、src/hooks/util.ts、其它 hook、src/actions/、src/services/sharing-service.ts、src/security/、src/apps/、src/data/、docs/、CLAUDE.md)diff 全为空;元数据、对象定义、种子内容零改动。scripts/software-flow.mjs 不在明示允许清单内,但也不在禁触碰面,且改动已在返回报告披露、属新检查引发的确需(见下「脚本改动核实」)——记为记录级,不阻塞。
2. 降级对账:✅ 清单相符。清单 21 条逐条落到代码:新增检查确在 PlanPublishHook 的 problems 链上(不是只写了个纯函数没接线);「逐条列出主体名称」为每个缺口一条独立提示;「无领导审批节点不检查」由函数首行 steps.some(s => s.step_type === 'leader_approve') 判定。三条单测均为真实断言(条数 2、点名两个缺口主体、断言不误伤已配置主体、断言三段式三要素、断言无节点场景确实不含该节点),非恒真。无 TODO/FIXME、无被注释掉的校验、无比需求少的分支。实跑复核(空库实例,REST):缺 2 个主体的分管领导 → 发布 422 并逐条点名「运营部」「华北分公司」;补齐后发布 200;删掉领导审批节点且全部主体不配分管领导 → 发布 200 不受检查影响。清单第 16 项标 ⚠️ 与代码一致(见记录级 R1)。
3. 三禁痕迹:✅ 无。diff 未触碰依赖/平台目录,无 patch 类文件,无绕开平台机制的自造实现,package.json / lockfile 零改动。
4. 硬拍板落地:✅。本单未新增或修改数字字段(四件套不适用),元数据 label 零改动(i18n:extract:check 报与 schema 同步)。新增唯一一条用户可见文案过 std-copy 红线:无内部代号(用主体显示名,实测输出「运营部」「华北分公司」)、无异常原文、三段式齐全(什么失败=抬头「发布失败,发布前完整性检查未通过」+「主体未配置分管领导」/ 为什么=「填报单走到『领导审批』节点将无人可审」/ 怎么办=「请在方案的『参与主体与考核关系』里为该主体指定分管领导」)、术语用需求术语表词(参与主体、分管领导、领导审批),指路的「参与主体与考核关系」与界面上该子表标题一致。

脚本改动核实(3 处逐处)

文件	改了什么	核实结论
scripts/software-people.mjs(明示允许)	演示档案的分管范围由「技术线 3 个主体」扩到「+ 财务部、人力行政部」共 5 个,使 11 个参与主体被 2 位领导全覆盖;断言由 covered === 9 改为 覆盖数 === 主体总数	补配置,不是放松:新断言要求主体全覆盖(比原来的固定 9 更严),仍保留「2 位领导、范围不重叠」
scripts/software-flow.mjs(确需)	T17d 分管范围由写死的 3 个机器名改为「按方案里实际配置的分管领导推导」,并把断言由「可见张数 > 0 且都在范围内」改为「可见张数 == 分管主体数且都在范围内」	去写死 + 收紧,不是放松:①写死值会因上一条补配置而假失败;②新断言多了张数精确相等一条;③关键的「被拦」预期原样保留——越权打开非分管主体填报单仍要求 403/404,实跑为 404
scripts/e2e-flow.mjs(允许确需)	①发布前把 5 个主体的分管领导补成管理员账号(新增 T2b);②T39 的共享规则条数由写死 29 改为按方案实配推导	补配置 + 等价推导:新公式代回原场景(仅市场部配领导)= 20+2+1+2+4 = 29,与原写死值一致,不是把等值断言改成下限;规则条数仍是精确相等,且原有的「市场部单元规则」「领导本人规则」两条具体断言原样保留

无任何一处把「被拦」改成「放行」,无断言被删除或降为宽松比较。

实跑复核(评审侧独立执行,非采信开发方报告)

• pnpm install --frozen-lockfile + pnpm verify:validate / typecheck / vitest 94 passed / i18n check 全绿。
• 软件档案空库实例 → scripts/software-people.mjs 8/8 OK、scripts/software-flow.mjs 54/54 PASS(含 T17d)。
• 默认档案空库实例 → scripts/e2e-flow.mjs 74/74 PASS。
• 手工 REST 探针:见上「降级对账」三条实测。

发现清单

级别	位置	问题	处置出口
⚪ 记录 R1	默认演示种子(src/data/,本单未改)	默认档案的 5 个参与主体本就没有分管领导(leader 是用户查找字段,种子给不了值),新检查生效后,默认档案的演示方案在人工补配分管领导前发布会被拦。开发方按工作项验收标准 2 预置出口「如实记录、不改种子」处理,与清单第 16 项一致,不属静默降级	是否给默认档案补一位分管领导(或改由脚本补)属种子内容决策,列决策清单请维护者拍板;不阻塞本次合并
⚪ 记录 R2	scripts/software-flow.mjs	该文件不在本单明示允许改动清单内,改动属新检查引发的确需并已披露	留痕即可,无需动作
⚪ 记录 R3	scripts/e2e-flow.mjs T39 / scripts/software-flow.mjs T17d	期望值改为从方案实配数据推导,理论上「配置本身错了」时期望会跟着错;本例中「全部主体必配分管领导」已由新检查在发布口强制,期望塌缩的风险被堵住	留痕;后续若放宽发布检查需回看这两处
⚪ 记录 R4	src/hooks/plan.hook.ts missingLeaderProblems	检查只判「分管领导字段非空」,不判该用户是否仍持有分管领导岗位/在职;主体名称为空时提示回退到主体标识(与既有「指标下达」类提示同款处理)	前者属「审批人来源扩展」,工作项明确不做;后者与既有文案一致,留痕不改

阻塞(🔴)0 项,应修(🟡)0 项 —— 清零,可合并。