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

[baozhoutao]

背景(来源:#23 UI 实测 K-2,维护者 2026-09-03 拍板立单)

方案「2026 年第 3 季度考核」中财务部、人力行政部未配置分管领导,发布前完整性检查没有拦下;两张填报单走到「领导审批中」后,两位分管领导的队列都看不到它们,流程死在该节点(本轮是靠 K-3 的岗位旁路代批才走完)。设计方案表 2 第 1 步的发布检查项为「权重合计 100%、目标值齐全、争议关闭、节点合法」,没有覆盖「每个参与主体都有人能审批」。

范围

1. src/hooks/plan.hook.ts 发布前完整性检查新增一条:方案流程含「领导审批」节点时,每个参与主体必须配置分管领导;未配置的逐条列出主体名称并拦截发布(与现有检查的逐条提示格式一致,三段式文案,无内部代号)。
2. 若流程里没有「领导审批」节点(可配置节点允许删),不做此检查。
3. 单测:补「有主体缺分管领导 → 发布被拦并逐条列出」「全部配置 → 放行」「流程无领导节点 → 不检查」。
4. 手册不改;若 README 有发布检查清单描述则同步一行。

不做

不改状态机 src/hooks/sheet.hook.ts;不改分管领导的数据模型;不做「审批人来源扩展」(V1.1 第 27 项)。

方案分级

纯新增一条检查,路径唯一,低风险,可直接开工。

验收标准

1. 软件档案空库实例:方案默认状态下点「发布方案」被拦,提示中列出「财务部」「人力行政部」缺分管领导;补齐后发布成功。
2. 默认档案实例:原演示方案的发布不受影响(其 5 个主体均有分管领导;若默认种子也有缺口,如实记录并在测试报告说明,不改种子)。
3. pnpm verify 绿;scripts/software-flow.mjs 与 scripts/e2e-flow.mjs 仍全 PASS(若脚本依赖「缺分管领导也能发布」,在脚本里补配置而非放松检查)。
4. 测试报告与符合度清单挂本单评论,截图走 acceptance-evidence。

测试计划草稿

T1 单测三用例 | T2 界面:缺分管领导发布被拦、提示逐条 | T3 界面:补齐后发布成功 | T4 默认档案发布不受影响 | T5 两脚本全 PASS | T6 pnpm verify

[baozhoutao]

认领(调度员占坑,2026-09-03)

• 会话:local_0e65d2bc-719b-4314-aae2-351176a17e5f(同批派发:流程按钮绕过岗位校验:动作体以受信任身份写入被 hook 当系统写入免检,任何岗位可越节点审批/归档 #28 / 发布前完整性检查缺「每个参与主体须配分管领导」,未配置的主体流程死在领导审批节点 #29 / 数据范围:指标下达、参与主体、审核记录等配置/审计对象按主体过滤,菜单按岗位裁剪(各部门目标值互相保密) #30 并行)
• 分支:issue-29-publish-leader-check,基线 main @ a760651293af660a8a4a13f7ec30fb3983f9a868
• 环境分配:worktree ../kpi-issue-29-publish-leader-check,dev 端口 3114,数据库 file:./.objectstack/issue-29-publish-leader-check.db
• 执行方式:按 os-project-pm-dispatch 派发独立开发子 agent(Opus);调度员只做收单核实与评审闸门,不写代码。

[baozhoutao]

需求理解与实现方式(开发子 agent,开工前确认)

会话与环境:worktree ../kpi-issue-29-publish-leader-check,分支 issue-29-publish-leader-check,基线 main @ a760651293af660a8a4a13f7ec30fb3983f9a868;dev 端口 3114,数据库 .objectstack/issue-29.db。

需求理解(逐条回读)

1. 缺陷本质:发布前完整性检查只覆盖「权重合计 100%、目标值齐全、争议关闭、节点合法」(设计方案表 2 第 1 步),没有「每个参与主体都有人能审批」。主体没配分管领导时,方案照样发得出去,填报单走到「领导审批中」两边队列都空,流程死在该节点。
2. 要补的检查:方案流程含「领导审批」节点时,每个参与主体必须配置分管领导;未配置的逐条列出主体名称并拦截发布,格式与现有检查一致(编号逐条),文案三段式、无内部代号。
3. 流程里没有「领导审批」节点(节点可删)→ 不做此检查(否则删了领导节点的方案反而发不出去)。
4. 单测三用例:有主体缺分管领导 → 拦并逐条列出;全部配齐 → 放行;无领导节点 → 不检查。
5. 手册不改;README 里没有发布检查清单的枚举(只有一句流程图注「发布(完整性检查)」),按「若有则同步」条款判定无需改 README,会在符合度清单里注明。
6. 不做:不改状态机 src/hooks/sheet.hook.ts、不改分管领导数据模型、不做审批人来源扩展。

实现方式

• 口径落在纯函数,与本文件既有做法一致(同周期唯一版本判定就是 findPublishedConflict 纯函数 + hook 取数):在 src/hooks/plan.hook.ts 新增导出 missingLeaderProblems(steps, subjects),输入方案流程节点与参与主体行,输出逐条问题文案;PlanPublishHook 在既有 problems 收集处调用它,不改任何已有检查的行为。
• 触发条件:steps.some(s => s.step_type === 'leader_approve')。节点由 loadPlanSteps 从 kpi_plan_step 读取(方案一条节点都没有时,现有「节点合法」检查已经会拦,不受本条影响)。
• 判定:参与主体行 kpi_plan_subject.leader(用户查找字段)为空即算未配置;逐条产出一行,主体名取 name(发布前由名称填充 hook 写好),兜底取主体 id。
• 文案(三段式,逐条):分管领导:主体「财务部」未配置分管领导,发布后其填报单走到「领导审批」节点将无人可审;请在方案的「参与主体与考核关系」里为该主体指定分管领导。,由既有的 发布失败,发布前完整性检查未通过: 抬头统一编号列出。
• 单测:加在 test/design-alignment.test.ts(该文件已是「设计方案口径落地校验」的纯函数取证位置,且已引用 plan.hook.js),三用例按上文。
• 脚本:scripts/software-people.mjs 的分管领导覆盖面目前是 9/11(财务部、人力行政部没配),正是本单现象的来源。会在该脚本里把这两个主体补上分管领导(复用现有两位领导账号,不新增账号,避免动到已发布的账号清单与四维汇总里「分管领导 2 位」的既有断言),使 software-flow.mjs 仍能走完发布。e2e-flow.mjs 若默认档案的演示方案受影响再评估,不预先放松检查。

风险与分级

纯新增一条检查,路径唯一(只在 draft → published 的完整性检查里多收集一类 problem),不改状态机、不改数据模型,低风险,按方案分级可直接开工。

已知取证口径

验收标准 2 提到「默认档案 5 个主体均有分管领导」——种子(src/data/index.ts)只建组织树与方案配置,leader 是用户查找字段、种子里没有赋值,默认档案很可能同样缺口。按工作项要求如实记录、在测试报告说明、不改种子。

[baozhoutao]

需求符合度清单(#29,提 PR 前门禁)

基线 main @ a760651293af660a8a4a13f7ec30fb3983f9a868,分支 issue-29-publish-leader-check,提交 c28bcef。

#	工作项要求(逐条)	态	落地位置 / 说明
1	发布前完整性检查新增一条:方案流程含「领导审批」节点时,每个参与主体必须配置分管领导	✅	src/hooks/plan.hook.ts 新增纯函数 missingLeaderProblems(steps, subjects),PlanPublishHook 在既有 problems 收集处调用
2	未配置的逐条列出主体名称	✅	每个缺口一条,带主体名称;主体名为空时退回主体标识(单测覆盖)。实测提示逐条列出「财务部」「人力行政部」
3	拦截发布(不通过不得发布)	✅	复用既有 fail(..., 'KPI_PLAN_INCOMPLETE') 整笔拒绝;实测方案仍停在「草稿」
4	与现有检查的逐条提示格式一致	✅	同一个 发布失败,发布前完整性检查未通过: 抬头下的编号列表,与权重 / 目标值 / 争议三条同格式
5	三段式文案、无内部代号	✅	「什么失败」由抬头给出(发布失败,完整性检查未通过),「为什么」= 未配置分管领导、填报单走到「领导审批」节点将无人可审,「怎么办」= 请在方案的「参与主体与考核关系」里为该主体指定分管领导;文案里只有需求术语表里的名词
6	流程里没有「领导审批」节点时不做此检查	✅	函数第一行按 step_type === 'leader_approve' 判定;单测 + 默认档案界面实测(删掉领导审批节点后,5 个主体全无分管领导仍发布成功)
7	单测:有主体缺分管领导 → 发布被拦并逐条列出	✅	test/design-alignment.test.ts 用例 1(断言逐条、断言不误伤已配置的主体、断言三段式三要素)
8	单测:全部配置 → 放行	✅	同文件用例 2
9	单测:流程无领导节点 → 不检查	✅	同文件用例 3
10	手册不改	✅	docs/ 零改动
11	README 若有发布检查清单描述则同步一行	✅(判定为不适用)	README 只有流程图里的一句「发布(完整性检查)」,没有检查项枚举;设计方案表 2 的枚举在 docs/,本单不改文档。没有可同步的清单行,故未改 README
12	不改状态机 src/hooks/sheet.hook.ts	✅	该文件零改动(只读取了它导出的 loadPlanSteps)
13	不改分管领导数据模型	✅	src/objects/plan.object.ts 零改动
14	不做「审批人来源扩展」	✅	未触碰
15	验收标准 1:软件档案空库,缺分管领导发布被拦并点名两个主体;补齐后发布成功	✅	界面实测,截图见测试报告 T2 / T3
16	验收标准 2:默认档案原演示方案发布不受影响	⚠️ 有偏差(如实记录,按工作项要求不改种子)	默认种子的 5 个参与主体同样没有分管领导(leader 是用户查找字段,种子建不了用户,也就给不了值),所以默认档案的演示方案发布现在会被本条检查拦下并逐条列出 5 个主体。工作项已预置该出口:「若默认种子也有缺口,如实记录并在测试报告说明,不改种子」——已在测试报告 T4 记录并附截图,种子零改动
17	验收标准 3:pnpm verify 绿	✅	validate / typecheck / test(94 passed)/ i18n 检查全绿
18	验收标准 3:scripts/software-flow.mjs 全 PASS	✅	54/54 PASS(脚本按需求补分管领导配置,未放松检查)
19	验收标准 3:scripts/e2e-flow.mjs 全 PASS	✅	74/74 PASS(发布前补配 5 个主体的分管领导,并把共享规则条数断言改为按方案实配推导)
20	验收标准 4:测试报告与符合度清单挂本单,截图走 acceptance-evidence	✅	本评论 + 测试报告评论;截图 commit 27e6bfb474b05ac98a9b1de410c46a67c3897784
21	新增/修改带 label 的元数据须重跑 pnpm i18n:extract	✅(不适用)	本单未新增或修改任何元数据 label,pnpm i18n:extract:check 报「与 schema 同步」,翻译包零改动

非 ✅ 条目的出口:第 16 项走的是工作项正文里维护者预置的「如实记录 + 不改种子」出口(见工作项验收标准 2 原文),不是简化实现;是否给默认种子补一位分管领导属于种子内容决策,已列入交接时的待拍板事项。

[baozhoutao]

测试报告 — #29 发布前完整性检查「每个参与主体须配分管领导」

结论

通过。 计划 6 条用例(T1~T6)全部执行、全部通过;其中 T4 按工作项预置口径记录了默认种子的既有缺口(不改种子)。缺陷现象(未配分管领导的主体发布后死在领导审批节点)在源头被拦下:界面上点「发布方案」即被拒绝并逐条点名缺口主体,方案停在「草稿」。

用例	结果	一句话
T1 单测三用例	通过	拦并逐条列出 / 全配齐放行 / 无领导节点不检查,外加主体名为空的兜底,pnpm test 94 passed
T2 界面:缺分管领导发布被拦、提示逐条	通过	软件档案实例点「发布方案」被拒,逐条列出「人力行政部」「财务部」,方案仍为草稿
T3 界面:补齐后发布成功	通过	在界面上给两个主体补上分管领导后再点「发布方案」,发布成功,生成 11 张填报单
T4 默认档案发布不受影响	通过(有发现,如实记录)	默认种子的 5 个主体同样没有分管领导,演示方案的发布现在会被拦;按工作项要求记录、不改种子
T5 两脚本全 PASS	通过	software-flow.mjs 54/54、e2e-flow.mjs 74/74
T6 pnpm verify	通过	validate / typecheck / test / i18n 全绿

环境

项	值
分支 / 提交	issue-29-publish-leader-check @ c28bcef(基线 main @ a760651)
实例	本 worktree pnpm dev,端口 3114;软件档案 OS_SEED_PROFILE=software + file:./.objectstack/issue-29.db;默认档案 file:./.objectstack/issue-29-default.db(切档案前 rm -rf dist,均为空库重建)
账号	管理员 admin@objectos.ai;岗位账号由 scripts/software-people.mjs 建立(口令统一)
浏览器	Playwright + Chromium,1440×900,zh-CN,真实界面操作(登录 → 导航 → 点按钮),非接口伪造
自测方式	同会话自测(项目启用清单 H2:暂不具备双实例条件),测试计划先于实现落盘,逐条对照

T1 单测(计分口径外的纯函数取证)

test/design-alignment.test.ts 新增 4 个用例,pnpm test 94 passed / 0 failed:

1. 三个主体中两个缺分管领导 → 返回 2 条问题,逐条点名「财务部」「人力行政部」,不误伤已配置的「销售部」;并断言文案三要素(未配置分管领导 / 领导审批 / 请在方案的「参与主体与考核关系」里为该主体指定分管领导);
2. 全部主体都配了分管领导 → 返回空数组(放行);
3. 流程节点里没有「领导审批」 → 返回空数组(不检查);
4. 主体名称为空 → 退回主体标识,不产出「主体「」」这种空名提示。

T2 界面:缺分管领导发布被拦、提示逐条

现场还原自 UI 实测的原始现场:软件档案的「2026 年第 3 季度考核」共 11 个参与主体,「财务部」「人力行政部」的分管领导为空。

在方案详情点「发布方案」→ 确认 → 被拒绝,逐条列出两个主体,方案状态仍是「草稿」:

提示原文(逐条编号,与权重 / 目标值 / 争议三条同格式):

发布失败,发布前完整性检查未通过:

1. 分管领导:主体「人力行政部」未配置分管领导,发布后其填报单走到「领导审批」节点将无人可审;请在方案的「参与主体与考核关系」里为该主体指定分管领导。
2. 分管领导:主体「财务部」未配置分管领导,发布后其填报单走到「领导审批」节点将无人可审;请在方案的「参与主体与考核关系」里为该主体指定分管领导。

T3 界面:补齐后发布成功

在界面上逐个打开两个主体记录 → 编辑 → 「分管领导」选人 → 更新(提示「参与主体更新成功」):

再点「发布方案」→ 发布成功,状态变「已发布」,发布时间与发布人落库,11 个主体各生成一张填报单(接口核对:status=published、sheets=11):

T4 默认档案:如实记录种子缺口(不改种子)

空库默认档案实例(不设档案变量),演示方案「2026 年 8 月 月度考核」的 5 个参与主体(市场部、运营部、华东 / 华南 / 华北分公司)全部没有分管领导 —— 分管领导是用户查找字段,种子只建组织树与方案配置,建不了用户,也就给不了值。因此该方案的发布现在会被本条检查拦下,提示逐条列出 5 个主体:

按工作项验收标准 2 的预置口径:如实记录、不改种子。业务上这正是本单要防的情形——没有人能审批的方案本就不该发布出去;发布前由人力审核在「参与主体与考核关系」里指定分管领导即可。是否给默认演示种子补一位分管领导(需要种子建用户)属于种子内容决策,已列为待拍板事项。

同一实例上补做「流程无领导审批节点则不检查」的界面验证:删掉方案的「领导审批」节点后(节点可配置、可删),5 个主体仍然全无分管领导,发布成功 —— 检查确实只在流程含领导审批节点时生效:

T5 两个脚本

按工作项要求「在脚本里补配置而非放松检查」:

• scripts/software-people.mjs:分管领导覆盖面由 9/11 补到 11/11(复用现有两位领导账号,不新增账号),并把「已设置」断言改为「覆盖全部主体」;{"ok":8,"failed":0};
• scripts/software-flow.mjs:54/54 PASS(含 T2a/T2b/T2c 三条既有发布拦截用例、T3 发布成功、T15d 分管领导维度汇总)。其中「分管领导只见分管主体的填报单」原先把分管范围写死成三个部门,改为按方案实配推导(分管范围会随档案调整,写死的期望值本身就是隐患);
• scripts/e2e-flow.mjs:74/74 PASS。发布前新增一步:为演示方案的 5 个参与主体配置分管领导(新增断言 T2b);共享规则条数断言由写死的 29 改为按方案实配推导(每个配了分管领导的主体 +2、每位分管领导 +1),精确性不变、不再随配置漂。

T6 门禁

pnpm verify:validate ✓、typecheck ✓、test 94 passed ✓、i18n:extract:check 与 schema 同步 ✓(本单未动任何 label,翻译包零改动)。

观察(不属本单范围,不在本单处理)

• 界面上的错误提示前缀带 KpiError:(所有 hook 报错通用,来自 src/hooks/util.ts 的错误类名),不是本单引入,本单也未改该文件(它在并行工作项的改动面上)。若要按文案红线清掉这个前缀,建议单独立项。

[baozhoutao]

交接验收侧(开发闭环结束,提 PR 即止)

• PR:https://github.com/objectstack-ai/kpi/pull/31(分支 issue-29-publish-leader-check → main;基线 main @ a760651,提交 c28bcef)
• 测试报告:见上一条评论(6 条用例全部通过,含界面截图)
• 需求符合度清单:见上上条评论(21 项,20 项 ✅,1 项 ⚠️ 走工作项预置出口)
• 截图:acceptance-evidence @ 27e6bfb474b05ac98a9b1de410c46a67c3897784,目录 issue-29/
• 状态:status:PR审查中;处理人 @baozhoutao
• 开发侧不合并 PR。

需要维护者拍板的一件事

默认演示种子(OS_SEED_PROFILE 不设时)的 5 个参与主体没有分管领导,因此默认档案的演示方案「2026 年 8 月 月度考核」在界面上直接点「发布方案」会被本条检查拦下(提示逐条列出 5 个主体)。本单按工作项验收标准 2 的预置口径如实记录、未改种子。可选处置:

• A(现状,推荐):保持不动 —— 演示时由人力审核在「参与主体与考核关系」里指定分管领导后再发布,正好演示这条检查;
• B:给默认种子补分管领导 —— 需要种子建演示用户(当前种子只建组织树),属于种子内容与档案设计决策,不在本单范围。

一条自查披露

本会话在停一个自己的 dev 实例时,除按 PID kill 外还跟了一条 pkill -f "serve --dev --port 3114"(派发纪律要求只按 PID 停进程、禁止 pkill -f)。该模式带了本会话独占的端口 3114,事后核对 3113 / 3115 / 3116 上的其他实例均存活,未波及并行会话;后续步骤已改回按 PID 停。

[baozhoutao]

合并记录(调度员,2026-09-03)

• 收单核实:PR 发布前完整性检查新增「每个参与主体须配分管领导」(#29) #31 关联本单、无自动关闭关键字;单提交、5 文件(hook 新增检查 + 单测 + 3 个脚本补配置/去写死);CI verify 绿;测试报告、需求符合度清单(唯一 ⚠️ 为默认种子缺分管领导,走验收标准 2 预置出口「如实记录不改种子」)、6 张证据图在 acceptance-evidence@27e6bfb 核对存在。全项通过。
• 评审闸门:独立评审子 agent(轻量档)结论「可合并」,🔴 0、🟡 0、⚪ 4;三处脚本改动逐处核实为「补配置 / 去写死」,无任何放松断言;评审侧独立复跑 verify 全绿、software-flow 54/54、e2e-flow 74/74、REST 探针拦截/放行/无领导节点三态均符合。
• 拍板落地:默认演示种子不补分管领导(维护者口径:应用侧种子不动;演示时由人力审核先配置分管领导再发布,正好演示本检查)。
• 纪律留痕:开发子 agent 自查披露一次误用带端口模式的 pkill -f(仅命中自身实例,事后核对并行实例存活);评审子 agent 披露一次脚本误指向他人实例端口(3116,属并行工作项的遗留实例),其数据被推进,已由调度员停掉该遗留实例。两条均已计入本批复盘。
• 已合并 PR 发布前完整性检查新增「每个参与主体须配分管领导」(#29) #31 到 main。状态切 status:PM验收中,处理人不变(验收侧)。