Repository navigation
软件公司岗位 KPI 演示数据集(独立种子档案 + 岗位人员脚本)与全流程实测 #23
Description
背景与目标
维护者 2026-09-03 要求:以软件公司为纬度,为各个岗位做 KPI 考核,按此要求做一套基础数据,并测试一遍。
现有演示种子(市场部/运营部/人力资源部 + 4 家分公司)是通用企业样例,操作手册 62 张截图依赖它,不能替换。本单新增一套「软件公司」基础数据档案,并用它把第 4 章全流程真实跑通一遍,作为后续演示、验收用例与数据准备阶段的样板。
口径决定(调度员假设,维护者可推翻;推翻即打回本单)
- 独立种子档案,不替换默认:新增
software档案,以环境变量OS_SEED_PROFILE=software启用;不设变量时行为与当前 main 完全一致(手册截图依赖默认档案)。 - 「各岗位」在一期口径下通过「到人分工 + 个人承接项」表达(设计方案 §8 到人口径):员工按岗位挂到部门板块,承接本岗位典型指标。个人考核单是设计方案 V1.1 第 24 项,客户未确认,不做。
- 用户不可种子(CLAUDE.md D4):岗位人员账号、流程岗位分配、到人分工、分管领导(均引用
sys_user)由运行期脚本创建,不进种子。 - 分公司保留 3 家(华东/华南/华北,销售型分公司),用来让「分公司核对(并行)」节点有真实业务含义:销售相关下达以分公司为核对方。
范围
A. 种子档案(src/data/ 下新增档案模块,src/data/index.ts 按 OS_SEED_PROFILE 选档)
- 组织树:总公司 + 部门 ≥ 8(研发部、产品部、测试部、销售部、市场部、客户成功部、人力行政部、财务部)+ 分公司 3 家(华东/华南/华北)。编码唯一、上级存在。
- 指标库:每部门 ≥ 3 项,整体覆盖四种计分方式(线性/阶梯/区间/公式)、两种方向、三种数据来源;阶梯指标带完整区间表;公式指标只用
actual / target / weight / 完成率;名称与口径说明按软件公司实际(如:版本按期交付率、线上严重故障数、需求交付周期、缺陷逃逸率、自动化测试覆盖率、签约金额完成率、回款率、线索数、获客成本、续费率、客户满意度、工单响应及时率、关键岗位招聘完成率、离职率、费用预算偏差率、报表准时率——由开发方按部门职责定,名称按需求 §1.4 术语与 std-copy 四条红线)。数字字段四件套显式声明。 - 方案:「2026 年第 3 季度考核」(季度,2026-07-01 ~ 2026-09-30),四节点默认流程(部门填报 → 分公司核对(并行)→ 人力审核 → 领导审批);参与主体 = 全部部门 + 3 分公司,主体权重齐全;指标下达每主体权重合计 100,目标值取软件公司合理量级;销售相关下达的核对方为对应分公司。
- 夹具覆盖:
src/data/align-demo-units.ts的租户对齐夹具按DEMO_UNIT_IDS工作(Sharing rules with a business-unit recipient silently grant nothing when the unit row has organization_id = NULL objectstack#14547 的临时夹具),新档案的组织单元 id 必须一并进入夹具覆盖范围,否则按方案的共享规则对新单元静默失效。
B. 运行期数据脚本(scripts/ 下新增,或扩展现有 e2e-flow.mjs 的档案参数)
- 创建岗位账号(业务岗位 ≥ 8:研发工程师、测试工程师、产品经理、销售经理、市场专员、客户成功经理、HRBP、财务专员;流程岗位六类各 ≥ 1)并分配流程岗位;
- 为业务岗位人员建到人分工(员工 × 部门板块 × 分工权重 × 个人系数,系数含 ≠1 的样例)与个人承接项(每人 ≥ 1,承接本岗位典型指标);
- 为方案设置分管领导(≥ 2 位,分管范围不同);
- 脚本可重复执行(幂等或明确要求空库)。
C. 全流程实测(本单交付的核心)
- API 脚本:发布 → 各主体填报实际值(含超额、未达、临界三类样本)→ 提交 → 分公司核对(含一处争议及其处理)→ 人力审核(含一次驳回与重提)→ 领导审批 → 加减分(提出 + 审批)→ 数据调整(源数据、结果各一)→ 四维汇总 → 归档;每步断言;得分断言按设计方案 §7 表 4 手算预期,不从实现反推。
- UI 实测:用岗位账号(部门填报人员、分公司核对人员、人力审核、人力负责人、分管领导)在浏览器走关键步骤,截图 ≥ 12 张,覆盖成功与拦截分支(未填不能提交、驳回原因必填、归档后不可改)。
- 数据范围断言:部门填报人员只见本部门填报单;分公司核对人员只见本分公司核对任务;分管领导只见分管主体;到人结果只见本人。
D. 文档
- README 或 CLAUDE.md 补一行档案启用方式与脚本用法;操作手册不改。
不做
个人考核单、通知/待办、指标模板库(均属 V1.1 待确认项);修改默认演示种子;修改 src/lib/scoring.ts 与 src/hooks/sheet.hook.ts;修复平台问题(界面英文标签、页签溢出、相对日期等已单独上报平台,截图中出现照实记录即可)。
验收标准
OS_SEED_PROFILE=software pnpm dev空库启动后,指标库、方案、参与主体、指标下达全部可见且数据完整;不设变量启动与 main 行为一致;pnpm verify绿。- 方案发布前完整性检查通过(权重合计 100、目标齐全、争议关闭、节点合法);发布后填报单数 = 参与主体数,每张填报单明细行带目标/权重/计分规则冻结副本。
- 全流程脚本一次跑完,断言全部 PASS;至少 3 条得分断言给出手算过程(线性封顶、阶梯、区间插值各一)。
- 四维结果均非空且排名正确;到人得分 = Σ(部门板块得分 × 分工权重 × 个人系数)+ Σ(承接项得分率 × 承接权重);分管领导得分 = 分管主体按主体权重加权平均。
- 三类岗位账号的数据范围断言通过(越权访问被明确拒绝)。
- 测试报告按 os-project-dev-test 模板挂本单评论,截图走孤儿分支
acceptance-evidence、40 位 commit SHA 图链;需求符合度清单挂本单评论,逐条三态。 - 全部用户可见文案过 std-copy 四条红线;数字字段四件套齐全;
pnpm validate零错。
测试计划草稿(细化自证)
T1 空库按档案启动、种子计数 | T2 未设变量启动 = 默认档案 | T3 发布检查:故意抹掉一个目标值 → 拦截并逐条提示 | T4 发布成功、填报单/明细计数 | T5 填报保存即出分 + 计算说明 | T6 未填不能提交 | T7 提交冻结 | T8 分公司并行核对、争议阻断、处理后推进 | T9 人力驳回(原因必填)退回上一节点、重提 | T10 领导审批通过 → 四维结果生成 | T11 加减分审批后重算 | T12 源数据调整触发重算 / 结果调整标记「已调整」 | T13 归档快照校验和、归档后改数被拒 | T14 岗位账号数据范围 | T15 pnpm verify
依赖与风险
- 依赖:无(基线 main)。
- 风险:分管领导、到人分工引用用户,只能脚本建 → 已按口径 3 处理;夹具覆盖遗漏 → 已列入范围 A;第 4 章流程在默认四节点下人力驳回只能退到分公司核对(见交接记录第四节),脚本按现状走「退回上一节点」,不改状态机。
交付物
种子档案模块 + 运行期脚本 + 全流程脚本断言输出 + 带截图测试报告 + 需求符合度清单 + 一行文档 + PR。
Activity
baozhoutao commentedon Sep 3, 2026
认领(调度员占坑,2026-09-03)
local_0e65d2bc-719b-4314-aae2-351176a17e5f(派发 | 软件公司岗位KPI数据集+全流程实测 | 0903)issue-23-software-dataset,基线 main @4a02994d837bcc4641555520a4da0a95f1cc8bed../kpi-issue-23-software-dataset,dev 端口3111,数据库file:./.objectstack/issue-23.dbbaozhoutao commentedon Sep 3, 2026
需求理解与实现方式(方案要点 · 开工前)
分支
issue-23-software-dataset,基线 main @ 4a02994。需求理解(一句话)
在不动默认演示种子、不动计分引擎与状态机的前提下,新增一套「软件公司」独立种子档案(
OS_SEED_PROFILE=software启用),配套运行期岗位人员脚本与全流程实测脚本,把第 4 章四节点流程用这套数据真跑一遍。风险分级:低(主体纯新增,路径唯一)
src/data/software-profile.ts(种子档案)、scripts/software-people.mjs(岗位人员/到人分工/分管领导)、scripts/software-flow.mjs(全流程断言)。src/data/index.ts:只加档案选择逻辑,默认档案的记录内容一字不改。改法 = 文件末尾把KpiSeedData由固定数组改为按process.env.OS_SEED_PROFILE选档;不设变量 → 与 main 完全一致的默认数组。DEMO_UNIT_IDS(同文件导出,喂align-demo-units.ts的租户对齐夹具)改为默认档案 id ∪ 软件档案 id 的并集,与档案变量无关。理由:夹具按id IN (...)且organization_id IS NULL查,默认档案下软件单元根本不存在 → 查不出行 → 行为与 main 逐字一致;而并集写法避免「切档案忘了切夹具」这一类静默失效。夹具本身(Sharing rules with a business-unit recipient silently grant nothing when the unit row has organization_id = NULL objectstack#14547 的临时夹具)语义不改。src/lib/scoring.ts、src/hooks/sheet.hook.ts、默认档案数据、docs/手册/。数据集设计要点
bu_sw_,编码SW-*唯一。actual / target / weight。数字字段四件套(小数位 / 最小值 / 最大值 / 单位)在对象层已显式声明,种子只给取值。已知口径差异(不自行选边,报验收侧)
「销售相关下达的核对方为对应分公司」:一期实现里没有「每条下达指定核对方」这一字段——⚠️ 列出。
分公司核对(并行)节点由SheetAfterTransitionHook按方案里全部分公司主体统一生成并行核对任务(自己那张单除外),这是 main 的既有状态机行为,本单不改。本档案把 3 家分公司放进参与主体,使该节点对销售类下达有真实业务含义;实际效果是每张部门填报单都由 3 家分公司并行核对。符合度清单里按交付顺序
种子档案 → 岗位人员脚本 → 全流程 API 断言(得分断言按设计方案 §7 表 4 手算)→ UI 实测截图 → 测试报告 + 符合度清单挂本单 → PR。
baozhoutao commentedon Sep 3, 2026
objectstack-ai/objectstack#23 软件公司岗位 KPI 演示数据集 测试报告
1. 结论
结论:❌ 存在问题
共 17 条用例:通过 16、没通过 1。
未通过的一条是平台控制台的按钮可见性问题(不在本单交付物范围内,本单按「只上报不修复」处理),数据集与全流程本身 16 条全部通过。
问题清单
关键截图
图 1 「签约金额完成率」明细页:实际值 5,000.0000、目标值 4,000.0000、完成率 125.00、得分率 120.00、指标得分 60.00、最终得分 60.00;计算说明栏写「实际 5000 / 目标 4000(越高越好)→ 完成率 125%;权重 50%;线性:得分率 = 完成率限定在 [0%, 120%] = 120%;得分 = 50% × 120% = 60」。
图 2 「考核结果」列表共 21 条记录,汇总维度列出现「部门 / 分公司 / 到人 / 分管领导」四种取值;华东分公司 106.12 排名 1、市场部 106.08 排名 1、赵敏 165.60 排名 1、徐涛 100.43 排名 1,各维度排名从 1 起独立编号。
图 3 「归档快照」列表出现一条「2026 年第 3 季度考核 · 销售部 · 归档快照」,带校验和与归档总分。
2. 测试环境与账号
issue-23-software-dataset,已合入 origin/main(含 zh-CN 翻译包);dev 实例在合入后rm -rf dist重启,启动日志Seeds: com.objectstack.kpi 99 rows与→ ./.objectstack/issue-23.db可核实 serving 的是本分支与本档案http://localhost:3111,控制台/_console/,数据库.objectstack/issue-23.db(空库启动)OS_SEED_PROFILE=software种子档案(99 行)+node scripts/software-people.mjs(15 个账号、组织归属、六类流程岗位、8 条到人分工、8 项个人承接项、2 位分管领导)测试账号(口令统一
Passw0rd!23;管理员admin@objectos.ai / admin123)3. 测试计划与结果总表
计划取自工作项「测试计划草稿」T1~T15,补 T16(汇总口径)与 T17(界面录入入口)。
pnpm verify(含新增的 i18n 同步门禁)4. 逐用例明细
T1:空库按档案启动、种子计数与内容
OS_SEED_PROFILE=software。rm -rf dist && OS_PORT=3111 OS_DATABASE_URL=file:./.objectstack/issue-23.db OS_SEED_PROFILE=software pnpm dev;2) 控制台依次打开「指标库」「方案版本 → 2026 年第 3 季度考核」「参与主体」「指标下达」「到人分工」。Seeds: com.objectstack.kpi 99 rows;2) 指标库列表底部「24 条记录」,计分方式列出现「完成率线性 / 阶梯计分 / 区间插值」,公式指标见 API 断言 T1d;3) 方案详情页状态「草稿」,参与主体数 11、下达指标数 36、未关闭争议数 0;4) 参与主体列表 11 条、指标下达 36 条、到人分工 8 条(个人系数 1.10 / 1.20 / 0.90 / 0.95 / 1.00 均出现)。T2:未设变量启动 = 默认档案
.objectstack/issue-23-default.db,不设OS_SEED_PROFILE,先rm -rf dist。Seeds: com.objectstack.kpi 46 rows;units 8 bu_east,bu_hq,bu_hr,bu_market,bu_north,bu_ops,bu_south,bu_west;indicators 6 TRAIN,SAFE,COST,PROFIT,REV,CSAT;plans 2026 年 8 月 月度考核;subjects 5 plan_indicators 18。逐项与 main 相同。T3:发布前完整性检查
resolved_at有值。T4:发布成功、填报单与明细计数、发布后冻结
T5:填报保存即出分 + 计算说明
T6:有指标未填不能提交
T7:提交与提交后冻结
T8:分公司并行核对、争议阻断、处理后推进
T9:人力驳回(原因必填)退回上一节点、重提
T10:领导审批通过 → 四维结果生成
T11:加减分登记与审批后重算
T12:数据调整(源数据 / 计算结果各一)
is_adjusted = true。T13:归档快照与归档后拦截
T14:岗位账号数据范围
T15:
pnpm verifyvalidate零错、tsc --noEmit无输出、vitest 6 文件 90 用例通过、i18n:extract:check报「1 bundle(s) are in sync with the schema」。T16:到人 / 分管领导汇总口径与排名
T17:部门填报人员在界面录入实际值
PATCH /data/kpi_entry_line/{id}写实际值是成功的(T5 的完成率/得分断言就是用该账号写入后读回的)。「填报明细」网格的「行内编辑」开关点开后单击/双击/回车都未进入单元格编辑态,管理员账号表现相同,故该路径本轮未能取证。5. 问题记录
OS_SEED_PROFILE=software启动 →node scripts/software-people.mjs→ 管理员发布方案 → 用 sales.manager@kpi.demo / Passw0rd!23 登录 → 填报明细 → 打开「签约金额完成率」记录页 → 右上角无「编辑」writeScope,未把记录级共享算进去(填报单 OWD 为 private,本部门可见性由方案发布写入的动态共享规则放宽)。按 CLAUDE.md「平台问题只上报不修复」,本单不改代码;建议维护者授权后向 objectstack-ai/objectstack 提一条上报单,附本条最小复现6. 平台侧观察(照实记录,不计入用例判定)
Jun 30/Sep 29,库里存的是2026-07-01/2026-09-30(显示比实际早一天;API 断言 T1e 读到的值是正确的)KpiError:(平台 toast 拼接的错误类名)7. 附录:API 全流程断言输出(54 条,全部 PASS)
执行命令:
OS_PORT=3111 node scripts/software-flow.mjs(空库 +scripts/software-people.mjs之后)。8. 附录:
pnpm verify输出9. 附录:
scripts/software-people.mjs幂等性同一实例连跑两次,第二次全部步骤仍 OK 且「新增 0 条」:
截图提交在孤儿分支
acceptance-evidence,commitf17e50058f4ef0086c9990f89ac24b23d21ac802,路径issue-23/。baozhoutao commentedon Sep 3, 2026
objectstack-ai/objectstack#23 需求符合度清单(逐条三态)
对照工作项正文的「范围 A/B/C/D」「不做」「验收标准」逐条核对。分支⚠️ = 实现了但有出入(附差异与原因 + 出口);❌ = 未实现(附原因 + 出口)。
issue-23-software-dataset,已合入 origin/main。✅ = 与需求逐字相符;
A. 种子档案
src/data/下新增档案模块,src/data/index.ts按OS_SEED_PROFILE选档src/data/software-profile.ts;src/data/index.ts只在文件末尾加选档逻辑,默认档案记录内容一字未改SW-*12 个互不重复,全部挂在bu_sw_hq下(API 断言 T1a)actual / target / weight / 完成率actual == 0.0 ? weight : (actual <= 2.0 ? weight * 0.5 : 0.0),只用actual与weight(T1d)kpi_indicator/kpi_plan_indicator字段定义上已显式声明(scale/min/max);档案侧对 24 个指标逐项显式给出「计量单位」与「数值小数位」(0/1/2 按指标性质),没有靠平台默认period_type=quarter、year=2026、period_no=3、周期 2026-07-01 ~ 2026-09-30(T1e)src/hooks/sheet.hook.ts按方案里全部分公司主体统一生成并行核对任务(自己那张单除外),这是 main 的既有状态机行为。本档案的做法:把 3 家销售型分公司放进参与主体,让销售/客户成功/市场口径的下达确实由 3 家分公司并行核对(T8a:销售部填报单生成 3 条核对任务);副作用是非销售部门的填报单也由这 3 家核对。原因:改成「按下达路由核对方」必须动src/hooks/sheet.hook.ts,而本单明确禁触碰该文件。出口:实现困难 → 已升级给验收侧裁定,列在返回报告「基准差异」与「需拍板事项」;未自行选边、未改状态机DEMO_UNIT_IDS改为两套档案单元 id 的并集(与档案变量无关);实测 12 个bu_sw_*单元启动后全部补上组织归属(T1f)B. 运行期数据脚本
kpi_admin」没有另建账号。原因:平台内置的组织 owner(admin@objectos.ai)自动等同该岗位(README「角色与岗位」表已载明),再建一个重复的管理员账号只会让演示数据多一条噪声。出口:口径待确认 → 已列入返回报告「需拍板事项」,由验收侧裁定是否要求脚本另建一个显式的kpi_admin账号;不自行改判C. 全流程实测
scripts/software-flow.mjs共 54 条断言,一次跑完全部 PASS(测试报告 §7)D. 文档
OS_SEED_PROFILE)」一节:两套档案对照表 + 三行命令 + 「换档案必须先删dist」的坑 + 脚本前置条件docs/手册/零改动不做项(核对未越界)
src/data/index.ts里默认档案的记录内容一字未改,只在末尾加了选档逻辑与DEMO_UNIT_IDS取并集;不设变量启动的行为经 T2 实测与 main 一致src/lib/scoring.ts与src/hooks/sheet.hook.tsgit diff origin/main -- src/lib/scoring.ts src/hooks/sheet.hook.ts为空)验收标准
OS_SEED_PROFILE=software空库启动后数据完整;不设变量与 main 一致;pnpm verify绿acceptance-evidence的f17e50058f4ef0086c9990f89ac24b23d21ac802,图链用 40 位 SHA,已用 contents API 抽查存在;本清单即符合度清单pnpm validate零错pnpm validate零错本轮新发现(不属本单交付物,记录在案)
writeScope、未把记录级共享算进去。按「平台问题只上报不修复」,本单未改代码;建议维护者授权后向 objectstack-ai/objectstack 提上报单。详见测试报告 T17 与 §52026-07-01显示为Jun 30)baozhoutao commentedon Sep 3, 2026
已提 PR:#26
issue-23-software-dataset,已合入 origin/main(含 zh-CN 翻译包),合入后rm -rf dist重启、空库重跑了 API 全流程与全部 UI 截图。acceptance-evidence的 commitf17e50058f4ef0086c9990f89ac24b23d21ac802,路径issue-23/。kpi_admin沿用平台内置管理员账号、脚本未另建。Merge pull request #26: software-company KPI demo dataset and full-fl…
baozhoutao commentedon Sep 3, 2026
合并记录(调度员,2026-09-03)
acceptance-evidence@f17e500均核对存在。全项通过。ced65ed修复;复查轮结论「可合并」,应修清零,评审侧独立复跑 people 8/8、flow 54/54、verify 全绿。记录级 5 条留痕不阻塞。editshare (sys_record_share) sees no Edit button while PATCH on the same record succeeds objectui#10107。status:PM验收中,处理人不变(验收侧)。功能是否达标归验收线判定。OS_SEED_PROFILE=software(空库 + 独立数据库文件),再依次运行node scripts/software-people.mjs与node scripts/software-flow.mjs,见 README「演示种子档案」一节。baozhoutao commentedon Sep 3, 2026
UI 实测与操作量统计(软件公司档案,2026-09-03)
① 结论
以「软件公司」演示档案(8 个总公司部门 + 华东/华南/华北 3 家分公司,24 条指标、36 条指标下达)做了一轮分角色正式界面实测:全部业务动作都在浏览器里用各岗位本人账号点出来,接口只用于 GET 核对结果与最后统计。主流程从方案发布一路走到归档,全程走通——方案发布生成 11 张填报单,8 个部门各自填报提交,3 家分公司提交,30 条核对任务全部确认(含 1 次争议→数据调整→复核闭环),人力审核 11 张(含 1 次驳回返工),加减分 2 条与数据调整 2 条(源数据 1 条 + 结果 1 条)全部审批落地,分管领导审批 9 张,最终 3 张归档 + 8 张停在「已通过」,四个维度共生成 21 条考核结果。
但**「走得通」不等于「好用」**。本轮实测发现的最重的三件事,都不在功能有没有上,而在活该谁干、要点多少下:
操作量上,最重的是分公司核对人员(单人 47~90 次点击,其中 30 次花在与自己无关的单子上),最容易迷路的是分管领导(「待领导审批」页签藏在「还有 4 个」溢出入口里,每审完一张被弹回列表都要重新展开一次)。
数据全部保留,未删任何记录,未重置库,未运行
scripts/software-flow.mjs。② 逐角色任务表
2.1 人力审核 · 马丽(hr.reviewer@kpi.demo)
单位操作量:发布方案 = 3 击(发布方案 → 继续,含确认窗口);单张填报单人力审核 = 4 击 + 1 次页面跳转(回列表 → 选页签 → 打开单 → 审核通过 → 确认);单条加减分登记 = 约 5 击 + 4 输入;归档单张 = 4 击。
图 1 马丽登录后的「方案版本」列表:2026 年第 3 季度考核,状态「草稿」,参与主体 11 / 下达指标 36 / 未关闭争议 0
图 2 方案详情页,状态条停在「草稿」,右上角「发布方案」对人力审核岗位可见(不需要换管理员)。注意「周期开始 6月30日 / 周期结束 9月29日」——库里是 2026-07-01 / 2026-09-30,日期显示早一天(已知问题)
图 3 「发布方案」确认窗口:发布前将做完整性检查;通过后方案冻结,并为每个参与主体生成填报单
图 4 发布成功:右下角提示「方案已发布,填报单已生成。」,状态条推进到「已发布」,发布人=马丽
图 5 「待人力审核」队列:11 张填报单全部到齐
图 6 拦截证据:驳回原因不填点「确认」,红字「驳回原因(必填) 为必填项」
图 7 驳回研发部后,状态回到「分公司核对中」(当前节点序号 2),不是「填报中」——一期口径,「最近驳回原因」已写入
图 8 「审核通过」窗口,审核意见选填
图 9 拦截证据:新建数据调整时状态直接选「待审批」,被拦下——「调整申请只能按「草稿 → 待审批 → 已批准 / 已否决」推进。」下拉却把这三个非法值都列了出来
图 10 「归档」确认窗口:归档后将生成不可变快照,数据锁定不可再改
图 11 归档后的「归档快照」列表:研发部 91.58 / 华东分公司 103.95 / 销售部 101.67,各带校验和
图 12 审计查询「审核记录」:96 条全流程留痕。注意「新状态」列显示的是内部状态值(draft/branch_checking…),经办人列显示用户 id(已知问题)
2.2 部门填报人员 · 8 人
先说三条录入路径的实测结果(已知平台问题 objectstack-ai/objectui#10107 的现场核对):
一个坑:「行内编辑」是开关按钮,默认已开。第一次误以为要点它才能编辑,点下去反而关掉了,此后点单元格就变成跳记录页——排查掉这个误判花了 3 次尝试。
单位操作量:单张 3 行填报单从登录到提交 = 11 次点击 + 5 次输入 + 4 次页面跳转(登录 2 输入 1 击;菜单 2 击到「填报明细」;3 行 × (1 击 + 1 输入);全部保存 1 击;菜单 1 击回「填报单」;打开单 1 击;提交填报 1 击;继续 1 击)。行内编辑本身很顺——每行只要 1 击 + 1 输入,保存后完成率/得分率/得分即时算出。
样本设计(超额 / 未达 / 临界三类齐全):研发部 98%(超额)/ 故障 1 次(未达)/ 15 天(临界);产品部 93 / 90(未达)/ 60(临界);测试部 98(临界)/ 75(超额)/ 3(未达);销售部 68(超额)/ 3600(未达)/ 90(临界);市场部 1720(超额)/ 880(未达)/ 100(临界);客户成功部 97(超额)/ 88(未达)/ 90(临界);人力行政部 6(超额)/ 92(未达)/ 100(临界);财务部 55(超额)/ 4.5(未达)/ 100(临界)。
图 13 张伟的「填报明细」:研发部 3 行,实际值列全为「—」。列头全部中文(手册里写的 Actual / Completion (%) 英文列头在本版本已修复)
图 14 填入 98 / 1 保存后:完成率 103.16、得分率 103.16 即时算出;工具条「行内编辑」为默认开启态
图 15 拦截证据:还有 1 个指标未填就提交,右下角「KpiError: 提交失败:还有 1 个指标未填写实际值。请补齐后再提交。」——KpiError 前缀外露(已知问题)
图 16 用「未填实际值」队列页签精确筛出唯一未填的那一行
图 17 填报明细记录页的「计算说明」。同时可见:记录页右上角没有「编辑」按钮,只有「…」与刷新
图 18 补齐后提交成功,状态条推进到「分公司核对中」
图 19 王强(产品部)提交成功,toast「填报单已提交,进入核对与审核流程。」。注意右上角:部门填报人员在自己的单上看到了「审核通过」「驳回」两个本该属于审核岗的按钮
图 20 拦截证据:赵敏在已提交的销售部单上把「新签客户数」改成 61 并保存,红字「保存失败: 修改填报明细失败:填报单已提交,数据已冻结。」;改动行留在网格里标红,需点「全部取消」才清掉
图 21 拦截证据:销售部已归档后再改实际值,同样被拦(提示文案仍写「填报单已提交」,未区分「已归档」)
图 22 部门填报人员看到的「新建数据调整」窗口:除业务字段外,还暴露了「状态(可选已批准/已否决)」「审批人」「审批时间」「审批意见」「落地时间」等审批侧字段
图 23 拦截证据 / 卡点:业务字段全填好点「创建」被拦——「状态不能为空」。必填、无默认值,手册 §3.6 也没写要选;同时可见「调整前值」并没有像手册说的那样自动带出(保存后才由系统写入)
2.3 分公司核对人员 · 陈东(华东)/ 林南(华南)/ 高北(华北)
核对量的口径问题(照实计数):每张填报单一提交,就给 3 家分公司各生成 1 条核对任务。11 张单共生成 30 条核对任务(8 个部门 × 3 = 24,3 家分公司互核 3 × 2 = 6),每位核对人各 10 条。其中:
单位操作量:单条核对 = 3 次点击(行「更多操作」→「确认无误」→ 弹窗「确认」),不填意见时无输入;单条争议 = 4 次点击 + 1 次输入;一位核对人清空 10 条队列 ≈ 34 次点击。人力驳回 1 张研发部,直接让三位核对人各返工 1 次(3 × 7 = 21 次点击),而被驳回的部门填报人员因数据已冻结根本改不了数。
图 24 陈东(分公司核对人员)在「填报单」里看到全部 11 张单,不止华东
图 25 路径①失败:陈东点华东分公司「签约金额完成率」的实际值单元格,不出输入框,直接跳到记录页;记录页右上角没有「编辑」,实际值为空、计算说明写「实际 空 / 目标 1600」
图 26 路径②失败:记录页「…」菜单里只有「分享」,没有「编辑」
图 27 路径③失败:陈东的「填报明细」工具条上没有「导入」按钮(对比图 13 张伟的列表右上角有「新建」「导入」)
图 28 华东填报单「相关」页签:审核记录里「新状态」显示内部值 draft、「经办人」显示用户 id(已知问题)
图 29 绕行证据:三条路径都不通后,由管理员(admin@objectos.ai)代填。代填前 3 家分公司 12 行实际值为空
*图 30 绕行证据:管理员在网格里一次填入 12 个实际值并保存(16 击 / 14 输入)。这 12 个值是「代填」,不是分公司自己录的
图 31 陈东的「待我核对」队列:10 条,其中「华南分公司 · 华东分公司 核对」「华北分公司 · 华东分公司 核对」两条与华东业务无关
图 32 林南的「待我核对」视图:整列没有勾选框,无法批量确认,10 条只能逐条点
图 33 核对任务的行操作菜单:确认无误 / 提出争议
图 34 拦截证据:「提出争议」不填内容点确认,红字「争议内容(必填) 为必填项」(字段标签里已经带了「(必填)」,报错文案又拼了一次,读起来是「争议内容(必填) 为必填项」)
图 35 「确认无误」窗口,核对意见选填
图 36 「有争议」队列:销售部那条,核对意见完整保留了陈东写的差异说明与依据
图 37 人力驳回研发部后,研发部的核对任务重新回到陈东的「待我核对」队列(三家都要重做一遍)
2.4 人力负责人 · 何平(hr.head@kpi.demo)
单位操作量:单条加减分审批 = 3 击(更多操作 → 批准 → 无二次确认);单条数据调整审批 = 4 击 + 1 输入(更多操作 → 批准并落地 → 写审批意见 → 确认)。这是全部六个角色里操作最轻、路径最短的一个。
图 38 何平的数据调整「待审批」队列
图 39 「批准并落地」窗口的审批意见
图 40 加减分「待审批」队列:销售部加 3 分、市场部扣 2 分
图 41 加减分行操作菜单:批准 / 否决
图 42 两条调整全部批准落地后的数据调整列表
2.5 分管领导 · 徐涛(技术线)/ 冯薇(市场线)
单位操作量:单张领导审批 ≈ 5.5 击 + 1 次页面跳转(回列表 → 点「还有 4 个」→ 点「待领导审批」→ 打开单 → 审核通过 → 确认)。比人力审核的 4 击更重,多出来的 2 击全花在每次都要重新展开溢出菜单上。
图 43 「待领导审批」不在可见页签里,要先点「还有 4 个」展开
图 44 数据范围证据:徐涛的「待领导审批」队列只有测试部、产品部、研发部 3 张(技术线),看不到市场线与分公司
图 45 数据范围证据:冯薇的队列 6 张——销售部、市场部、客户成功部 + 华东/华南/华北 3 家分公司
图 46 领导审批的「审核通过」窗口
图 47 徐涛在「考核结果」里可见 4 条(3 个部门 + 本人分管领导维度)。页签只有「部门」「分公司」「到人」三个,没有手册 §6.3 写的「分管领导」页签
图 48 徐涛的结果看板:部门 3 条平均 92.20、分管领导 1 条 92.11。人员轴显示的是用户 id
lBR6jz…,认不出是谁(已知问题)图 49 冯薇的结果看板:分公司 3 条平均 100.73、部门 3 条平均 99.25、分管领导 1 条 100.29
2.6 数据范围抽查
图 50 数据范围证据:赵敏在「填报单」里只有销售部 1 张
图 51 数据范围证据:张伟在「到人得分」里只有 1 行(本人,121.37)。人员列显示用户 id
图 52 越权证据:部门填报人员张伟展开左侧菜单——方案版本、指标下达、参与主体、到人分工、指标争议、指标库、归档快照、审计查询全都在,和人力审核看到的一样
图 53 越权证据:张伟打开「指标下达」,36 条(全部 11 个主体的目标值与权重)全部可读
图 54 越权证据:部门填报人员周雪在自己「已通过」的填报单上看到「归档」按钮(手册 §2.12 归档是人力审核的动作)
图 55 财务部与人力行政部在方案里没有配分管领导,两位领导的队列都看不到它们,卡在「领导审批中」;马丽(人力审核)却能看到并且有「审核通过」按钮
图 56 越权证据(已生效):马丽点「审核通过」后人力行政部推进到「已通过」,最终审批人写的是马丽——hook 没有按当前节点的岗位拦下
③ 角色汇总与跨角色对比
3.1 各角色总量
3.2 单位动作操作量横比
3.3 谁最重、谁最容易迷路
④ 卡点与绕行清单
4.1 新发现(本轮实测发现,不在已知清单里)
4.2 已知问题(照实复核,不当新发现)
⑤ 改进建议(5 条)
应用侧可改
给分公司主体配置填报人(P1,对应 K-1)。 两种选法二选一:① 新增「分公司填报人员」岗位并绑定分公司主体;② 让「分公司核对人员」对本分公司主体的填报单具备录入权(对别家的单仍只读)。当前状态是「有提交按钮、无录入手段」,演示时一定会被问到。
核对任务按相关性收敛 + 加批量确认(P1,对应 K-5 与队列口径)。 ① 生成核对任务时按「该填报单是否含与本分公司相关的指标」过滤,而不是每单给每家都发一条(现在 30 条里至少 6 条是分公司互核,业务上说不通);② 「待我核对」视图开勾选列 + 批量「确认无误」,把清空队列的 30 击压到 3~4 击。
按当前节点岗位收敛操作按钮,并把校验落到 hook(P1,对应 K-3、K-2)。 「审核通过 / 驳回」只对当前节点的审核岗位显示且只对该岗位放行;「归档」只对人力审核显示;同时在方案发布的完整性检查里加一条——参与主体必须都配了分管领导,否则拦下(现在两张单能走到无人认领的死角)。
表单只暴露该角色该填的字段(P2,对应 K-6、K-7)。 数据调整 / 加减分的新建表单隐藏「状态、审批人、审批时间、审批意见、落地时间」,状态由 hook 置为「草稿」;「调整前值」在选完指标明细时就回填到表单上(现在是保存后才写);新建成功后不弹记录抽屉、直接回列表。顺带把「争议内容(必填)」这类标签里的「(必填)」去掉,交给 * 号和报错文案。
平台行为(只上报,不在应用侧修)
editshare (sys_record_share) sees no Edit button while PATCH on the same record succeeds objectui#10107 相邻,可放在同一批里。⑥ 测试后系统数据快照(2026-09-03 实测结束时)
6.1 各对象记录数与状态分布
6.2 各主体最终得分
到人维度 8 条:赵敏 158.80、孙磊 126.08、张伟 121.37、吴刚 120.00、周雪 119.20、王强 110.02、李娜 110.00、郑洁 106.51。
分管领导维度 2 条:冯薇 100.29、徐涛 92.11(财务部、人力行政部无分管领导,不进任何领导维度)。
6.3 维护者可以去看什么(页面 → 看什么)
登录 http://localhost:3111/_console/ ,进入「KPI 考核管理」应用。
⑦ 账号与环境
/Users/baozhoutao/GitHub/kpi-software-demo(main @ a760651,只读,未改任何代码);数据库.objectstack/software.db,种子档案software。实例全程未重启、未换库、未删记录、未运行scripts/software-flow.mjs。Accept-Language: zh-CN,无头模式。所有业务动作都是界面点击;接口只用于 GET 核对结果与本报告 ⑥ 的统计。Passw0rd!23;管理员 admin@objectos.ai / admin123):acceptance-evidence的issue-23-ui/目录,commit2ce5f7eb9ec78fac12fb883757209726c6cbe76e。本报告中所有图链均指向该 SHA,已用 contents API 逐一核对存在。baozhoutao commentedon Sep 3, 2026
调度员对 UI 实测发现 K-3 的成因核实(2026-09-03)
现象:人力审核(马丽,仅持
kpi_hr_reviewer岗位,组织成员角色member)对处于「领导审批中」的两张填报单点「审核通过」真的生效,审核记录的经办人是马丽本人(记录 idJzgQ4yGWH0fHl_QS、nk380Ccs9ABAMyd9)。方案流程节点 4 的审核岗位是kpi_exec_leader,src/hooks/sheet.hook.ts的requiredPositionFor会算出该岗位,hasPosition本应拒绝。成因:四个流程按钮(提交/审核通过/驳回/归档)是带
api.write能力的 JS 动作体,用ctx.api.object('kpi_entry_sheet').update({ pending_action })写入。平台 17.2.0 运行时对动作体的说明(buildActionEngineFacade,objectstack#2849)明确:动作体以「受信任」方式执行,不携带调用者的 ExecutionContext,安全中间件跳过 RLS / FLS / CRUD 检查;因此写入到达 hook 时ctx.session.isSystem === true,hasPosition第一行if (isSystem(ctx) || !position) return true直接放行,「非系统写入不得直改 status」等其它以isSystem为闸的规则同样失效。经办人仍能记成马丽,是因为actorId(ctx)从ctx.user取到了发起人。影响面:凡是通过这四个按钮发起的动作,状态机的岗位校验形同虚设——部门填报人员在自己单上看到的「归档」「审核通过」「驳回」按钮(K-3 另两处现场)点下去同样会生效。经 REST 直接 PATCH
pending_action的路径不受影响(hook 正常拦截,#23 全流程脚本的岗位断言就是这样过的)。修法方向(供立单时分级,不在本单修):
isSystem免检,而是「只要pending_action由按钮/用户写入(ctx.user存在)就按发起人校验岗位」,isSystem免检仅保留给没有发起用户的纯系统写入(发布生成、重算);同时按钮的visibleWhen按当前节点岗位收敛。runAs: 'user'落地后把四个按钮改为以用户身份执行。平台方向已写在源码注释里,但无时间表,只上报不等待。K-2(未配分管领导也能发布)与 K-3 叠加,是本轮流程能「走通」的真正原因:两张无人审批的单是靠这个旁路代批的。建议两条一并立单,优先级 P1。