软件公司岗位 KPI 演示数据集(独立种子档案 + 岗位人员脚本)与全流程实测

[baozhoutao]

背景与目标

维护者 2026-09-03 要求:以软件公司为纬度,为各个岗位做 KPI 考核,按此要求做一套基础数据,并测试一遍。
现有演示种子(市场部/运营部/人力资源部 + 4 家分公司)是通用企业样例,操作手册 62 张截图依赖它,不能替换。本单新增一套「软件公司」基础数据档案,并用它把第 4 章全流程真实跑通一遍,作为后续演示、验收用例与数据准备阶段的样板。

口径决定(调度员假设,维护者可推翻;推翻即打回本单)

1. 独立种子档案,不替换默认:新增 software 档案,以环境变量 OS_SEED_PROFILE=software 启用;不设变量时行为与当前 main 完全一致(手册截图依赖默认档案)。
2. 「各岗位」在一期口径下通过「到人分工 + 个人承接项」表达(设计方案 §8 到人口径):员工按岗位挂到部门板块,承接本岗位典型指标。个人考核单是设计方案 V1.1 第 24 项,客户未确认,不做。
3. 用户不可种子(CLAUDE.md D4):岗位人员账号、流程岗位分配、到人分工、分管领导(均引用 sys_user)由运行期脚本创建,不进种子。
4. 分公司保留 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;修复平台问题(界面英文标签、页签溢出、相对日期等已单独上报平台,截图中出现照实记录即可)。

验收标准

1. OS_SEED_PROFILE=software pnpm dev 空库启动后,指标库、方案、参与主体、指标下达全部可见且数据完整;不设变量启动与 main 行为一致;pnpm verify 绿。
2. 方案发布前完整性检查通过(权重合计 100、目标齐全、争议关闭、节点合法);发布后填报单数 = 参与主体数,每张填报单明细行带目标/权重/计分规则冻结副本。
3. 全流程脚本一次跑完,断言全部 PASS;至少 3 条得分断言给出手算过程(线性封顶、阶梯、区间插值各一)。
4. 四维结果均非空且排名正确;到人得分 = Σ(部门板块得分 × 分工权重 × 个人系数)+ Σ(承接项得分率 × 承接权重);分管领导得分 = 分管主体按主体权重加权平均。
5. 三类岗位账号的数据范围断言通过(越权访问被明确拒绝)。
6. 测试报告按 os-project-dev-test 模板挂本单评论,截图走孤儿分支 acceptance-evidence、40 位 commit SHA 图链;需求符合度清单挂本单评论,逐条三态。
7. 全部用户可见文案过 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。

[baozhoutao]

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

• 会话:local_0e65d2bc-719b-4314-aae2-351176a17e5f(派发 | 软件公司岗位KPI数据集+全流程实测 | 0903)
• 分支:issue-23-software-dataset,基线 main @ 4a02994d837bcc4641555520a4da0a95f1cc8bed
• 环境分配:worktree ../kpi-issue-23-software-dataset,dev 端口 3111,数据库 file:./.objectstack/issue-23.db
• 执行方式:按 os-project-pm-dispatch 派发独立开发子 agent(Opus)在上述 worktree 开发;调度员只做收单核实与评审闸门,不写代码。

[baozhoutao]

需求理解与实现方式(方案要点 · 开工前)

分支 issue-23-software-dataset,基线 main @ 4a02994。

需求理解(一句话)

在不动默认演示种子、不动计分引擎与状态机的前提下,新增一套「软件公司」独立种子档案(OS_SEED_PROFILE=software 启用),配套运行期岗位人员脚本与全流程实测脚本,把第 4 章四节点流程用这套数据真跑一遍。

风险分级:低(主体纯新增,路径唯一)

• 纯新增:src/data/software-profile.ts(种子档案)、scripts/software-people.mjs(岗位人员/到人分工/分管领导)、scripts/software-flow.mjs(全流程断言)。
• 改已有文件(两处,最小改动、默认行为不变):
  1. src/data/index.ts:只加档案选择逻辑,默认档案的记录内容一字不改。改法 = 文件末尾把 KpiSeedData 由固定数组改为按 process.env.OS_SEED_PROFILE 选档;不设变量 → 与 main 完全一致的默认数组。
  2. 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/手册/。

数据集设计要点

• 组织树:总公司 + 8 部门(研发/产品/测试/销售/市场/客户成功/人力行政/财务)+ 3 家销售型分公司(华东/华南/华北),id 前缀 bu_sw_,编码 SW-* 唯一。
• 指标库:24 项(每部门 3 项),覆盖四种计分方式(线性 / 阶梯 / 区间插值 / 公式)、两种方向(越高越好 / 越低越好)、三种数据来源(人工填报 / 批量导入 / 系统计算);阶梯指标带完整区间表;公式指标只用 actual / target / weight。数字字段四件套(小数位 / 最小值 / 最大值 / 单位)在对象层已显式声明,种子只给取值。
• 方案:「2026 年第 3 季度考核」(季度,2026-07-01 ~ 2026-09-30),四节点默认流程;参与主体 11 个(8 部门 + 3 分公司),主体权重合计 100;指标下达 36 条,每主体权重合计 100;分公司下达的是销售 / 客户成功口径指标。
• 用户不可种子(CLAUDE.md D4):15 个岗位账号、流程岗位分配、到人分工、个人承接项、分管领导全部由运行期脚本创建,不进种子。

已知口径差异(不自行选边,报验收侧)

「销售相关下达的核对方为对应分公司」:一期实现里没有「每条下达指定核对方」这一字段——分公司核对(并行) 节点由 SheetAfterTransitionHook 按方案里全部分公司主体统一生成并行核对任务(自己那张单除外),这是 main 的既有状态机行为,本单不改。本档案把 3 家分公司放进参与主体,使该节点对销售类下达有真实业务含义;实际效果是每张部门填报单都由 3 家分公司并行核对。符合度清单里按 ⚠️ 列出。

交付顺序

种子档案 → 岗位人员脚本 → 全流程 API 断言(得分断言按设计方案 §7 表 4 手算)→ UI 实测截图 → 测试报告 + 符合度清单挂本单 → PR。

[baozhoutao]

#23 软件公司岗位 KPI 演示数据集 测试报告

1. 结论

结论:❌ 存在问题

共 17 条用例:通过 16、没通过 1。

未通过的一条是平台控制台的按钮可见性问题(不在本单交付物范围内,本单按「只上报不修复」处理),数据集与全流程本身 16 条全部通过。

问题清单

用例	现象(预期 vs 实际)	截图
T17 部门填报人员在界面录入实际值	预期:填报单处于「填报中」时,部门填报人员能在界面上把实际值填进「填报明细」。实际:该账号的填报明细记录页没有「编辑」入口(同一条记录管理员有),而同一账号经 REST 写实际值是成功的(T5 的 API 断言用的就是该账号)。「填报明细」网格的「行内编辑」本轮自动化浏览器点不动(管理员账号同样点不动),因此该路径未能取证。	13

关键截图

图 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 的是本分支与本档案
环境	本机 dev 实例 http://localhost:3111,控制台 /_console/,数据库 .objectstack/issue-23.db(空库启动)
端	PC 端浏览器(Chromium,1600×1000)
前置数据	OS_SEED_PROFILE=software 种子档案(99 行)+ node scripts/software-people.mjs(15 个账号、组织归属、六类流程岗位、8 条到人分工、8 项个人承接项、2 位分管领导)
测试日期	2026-09-03

测试账号(口令统一 Passw0rd!23;管理员 admin@objectos.ai / admin123)

姓名	岗位	账号	组织单元	流程岗位
张伟	研发工程师	rd.engineer@kpi.demo	研发部	部门填报人员
王强	产品经理	pd.manager@kpi.demo	产品部	部门填报人员
李娜	测试工程师	qa.engineer@kpi.demo	测试部	部门填报人员
赵敏	销售经理	sales.manager@kpi.demo	销售部	部门填报人员
孙磊	市场专员	mkt.specialist@kpi.demo	市场部	部门填报人员
周雪	客户成功经理	cs.manager@kpi.demo	客户成功部	部门填报人员
吴刚	HRBP	hrbp@kpi.demo	人力行政部	部门填报人员
郑洁	财务专员	fin.specialist@kpi.demo	财务部	部门填报人员
陈东	华东分公司核对人员	east.checker@kpi.demo	华东分公司	分公司核对人员
林南	华南分公司核对人员	south.checker@kpi.demo	华南分公司	分公司核对人员
高北	华北分公司核对人员	north.checker@kpi.demo	华北分公司	分公司核对人员
马丽	人力审核	hr.reviewer@kpi.demo	人力行政部	人力审核
何平	人力负责人	hr.head@kpi.demo	人力行政部	人力负责人
徐涛	分管领导(技术线)	leader.tech@kpi.demo	—	分管领导
冯薇	分管领导(市场线)	leader.gtm@kpi.demo	—	分管领导

3. 测试计划与结果总表

计划取自工作项「测试计划草稿」T1~T15,补 T16(汇总口径)与 T17(界面录入入口)。

编号	标题	类型	端	角色	结果	证据
T1	空库按档案启动、种子计数与内容	主流程	PC	管理员	✅	03/04/05/06/07 + API T1a~T1g
T2	未设变量启动 = 默认档案(与 main 一致)	边界	—	管理员	✅	启动日志 46 行 + 组织/指标/方案清单
T3	发布前完整性检查:目标值缺失 / 权重≠100 / 争议未关闭	异常	PC	管理员	✅	08 + API T2a/T2b/T2c/T2d
T4	发布成功、填报单与明细计数、发布后冻结	主流程	PC	管理员	✅	09/10 + API T3/T4a/T4b/T4c
T5	填报保存即出分 + 计算说明(超额 / 未达 / 临界三类样本)	主流程	PC	管理员、销售经理	✅	11/12/13 + API T5b/T5c/T5d/T5e
T6	有指标未填不能提交	异常	PC	销售经理	✅	15 + API T6
T7	提交后数据冻结	异常	PC	销售经理	✅	16 + API T7a/T7b
T8	分公司并行核对、争议阻断、处理后推进	主流程/异常	PC	分公司核对人员	✅	17/18/19/20/21 + API T8a~T8f
T9	人力驳回(原因必填)退回上一节点、重提	异常/主流程	PC	人力审核	✅	22/23/24 + API T9a~T9d
T10	领导审批通过 → 四维结果生成	主流程	PC	分管领导	✅	25/26/29/30 + API T10/T15a
T11	加减分登记与审批后重算	主流程	PC	人力审核、人力负责人	✅	27/28 + API T13a/T13b
T12	源数据调整触发重算 / 结果调整标记「已调整」	主流程	—	部门填报人员、人力审核	✅	API T14a/T14b/T15e
T13	归档快照校验和、归档后改数被拒	主流程/异常	PC	人力审核	✅	31/32/33 + API T16a~T16d
T14	岗位账号数据范围(部门 / 分公司 / 分管 / 到人)	权限	PC	5 类账号	✅	13/14/17/25/34/35 + API T17a~T17d
T15	pnpm verify(含新增的 i18n 同步门禁)	主流程	—	—	✅	见 §6
T16	到人 / 分管领导汇总口径与排名	主流程	PC	管理员	✅	29 + API T15b/T15c/T15d
T17	部门填报人员在界面录入实际值	主流程	PC	销售经理	❌	13(记录页无「编辑」入口)

4. 逐用例明细

T1:空库按档案启动、种子计数与内容

• 前置条件:空库,OS_SEED_PROFILE=software。
• 操作步骤:1) rm -rf dist && OS_PORT=3111 OS_DATABASE_URL=file:./.objectstack/issue-23.db OS_SEED_PROFILE=software pnpm dev;2) 控制台依次打开「指标库」「方案版本 → 2026 年第 3 季度考核」「参与主体」「指标下达」「到人分工」。
• 预期结果:1) 启动日志种子行数 = 99;2) 指标库 24 条,四种计分方式齐;3) 方案为草稿、参与主体 11、下达指标 36、未关闭争议 0;4) 参与主体 11 条、指标下达 36 条、到人分工 8 条。
• 实际观察:1) 日志 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 均出现)。
• 结果:✅
• 截图:
  • 03-zhibiaoku-24xiang:指标库列表,可见 SWCS01~SWQA02 等编码与「经营业绩/管理效能/服务质量」类别,底部「24 条记录」。
  • 04-fangan-caogao:方案详情,状态条停在「草稿」,参与主体数 11、下达指标数 36、未关闭争议数 0。
  • 05-canyu-zhuti-11ge:参与主体列表,8 个「总公司部门」+ 3 个「分公司」,主体权重列有值。
  • 06-zhibiao-xiada-36tiao:指标下达列表,底部「36 条记录」。
  • 07-daoren-fengong:到人分工列表,8 条,含个人系数列。

T2:未设变量启动 = 默认档案

• 前置条件:另一空库文件 .objectstack/issue-23-default.db,不设 OS_SEED_PROFILE,先 rm -rf dist。
• 操作步骤:启动 dev,经 REST 读组织单元、指标、方案、参与主体、指标下达计数。
• 预期结果:与 main 完全一致 —— 种子 46 行、8 个组织单元(bu_hq/bu_market/…)、6 个指标(REV/PROFIT/COST/CSAT/SAFE/TRAIN)、方案「2026 年 8 月 月度考核」、参与主体 5、指标下达 18。
• 实际观察:日志 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:发布前完整性检查

• 前置条件:方案草稿、配置完整。
• 操作步骤:1) 把「签约金额完成率 · 销售部」的目标值置空,在方案详情点「发布方案」→「继续」;2) 恢复目标值,把「回款率 · 销售部」权重改成 10,再发布;3) 恢复权重,对「签约金额完成率 · 华东分公司」提一条指标争议,再发布;4) 处理该争议(不采纳 + 处理结论)。
• 预期结果:1)~3) 每次发布被拒绝并逐条列出问题;4) 争议关闭、盖处理时间。
• 实际观察:1) 提示「发布失败,发布前完整性检查未通过:1. 指标下达:「签约金额完成率 · 销售部」未设置目标值」;2) 「1. 指标下达:主体「销售部」的权重合计为 80%,必须等于 100%」;3) 「1. 指标争议:还有 1 项指标争议未关闭」;4) 争议状态变「已驳回」,resolved_at 有值。
• 结果:✅
• 截图:08-fabu-jiancha-butongguo:点「发布方案」后弹出「确认操作 —— 发布前将做完整性检查;通过后方案冻结,并为每个参与主体生成填报单。确认发布?」。

T4:发布成功、填报单与明细计数、发布后冻结

• 操作步骤:方案详情点「发布方案」→「继续」;打开「填报单」列表。
• 预期结果:方案状态变「已发布」;填报单 11 张(= 参与主体数),全部「填报中」;明细 36 行,每行带目标值 / 权重 / 计分方式 / 指标方向的冻结副本;发布后改指标下达被拒。
• 实际观察:方案状态条停在「已发布」;填报单列表 11 张;明细 36 行,列出目标值、权重(%)、计分方式、指标方向;改权重返回「修改失败:方案已发布,配置已冻结。如需调整指标、权重、目标或流程,请新建方案版本。」
• 结果:✅
• 截图:09-fabu-chenggong、10-tianbaodan-liebiao-11zhang。

T5:填报保存即出分 + 计算说明

• 操作步骤:管理员打开「签约金额完成率 · 销售部」明细 → 「编辑」→ 实际值填 5000 → 「更新」;其余两行由脚本写入(回款率 72、新签客户数 60)。
• 预期结果(手算,《设计方案》V1.0 §7 表 4):
  1. 签约金额完成率:5000 ÷ 4000 = 125%,线性封顶 120% → 得分率 120% → 得分 = 50% × 120% = 60.00(超额样本);
  2. 回款率:72 ÷ 90 = 80%,区间插值下限 60%→0、100%→100%,(80−60)÷(100−60) = 50% → 得分 = 30% × 50% = 15.00(未达样本);
  3. 新签客户数:60 ÷ 60 = 100% → 得分率 100% → 得分 = 20% × 100% = 20.00(临界样本);
  4. 指标得分合计 = 60 + 15 + 20 = 95.00,权重合计 100。
• 实际观察:1) 完成率 125.00、得分率 120.00、指标得分 60.00,计算说明「实际 5000 / 目标 4000(越高越好)→ 完成率 125%;权重 50%;线性:得分率 = 完成率限定在 [0%, 120%] = 120%;得分 = 50% × 120% = 60」;2) 完成率 80.00、得分率 50.00、指标得分 15.00;3) 完成率 100.00、得分率 100.00、指标得分 20.00;4) 填报单「指标得分合计 95」「权重合计(%) 100」。
• 结果:✅
• 截图:11-luru-shijizhi(编辑弹窗里实际值输入 5000)、12-baocun-jishi-chufen(保存后的完成率/得分率/得分与计算说明)、13-bumen-tianbao-renyuan-mingxi(销售经理看到的三行:完成率 80.00 / 100.00 / 125.00,得分率 50.00 / 100.00 / 120.00,指标得分 15.00 / 20.00 / 60.00)。

T6:有指标未填不能提交

• 操作步骤:先清空「新签客户数」的实际值,销售经理在填报单点「提交填报」。
• 预期结果:提交被拒绝,提示还差几项。
• 实际观察:右下角提示「提交失败:还有 1 个指标未填写实际值。请补齐后再提交。」,状态条仍停在「填报中」。
• 结果:✅
• 截图:15-weitian-buneng-tijiao。

T7:提交与提交后冻结

• 操作步骤:补齐实际值,销售经理点「提交填报」→「继续」;随后尝试改实际值。
• 预期结果:状态进「分公司核对中」,提交时间与提交人盖章;改实际值被拒。
• 实际观察:状态条停在「分公司核对中」;改实际值返回「修改填报明细失败:填报单已提交,数据已冻结。如需更正,请发起数据调整申请。」
• 结果:✅
• 截图:16-tijiao-chenggong-fengongsi-hedui。

T8:分公司并行核对、争议阻断、处理后推进

• 操作步骤:1) 陈东(华东)打开「分公司核对」列表;2) 打开本分公司任务点「提出争议」,争议内容留空点「确认」;3) 填写争议内容后提交;4) 管理员在填报单点「审核通过」;5) 陈东改为「确认无误」,林南、高北各自确认。
• 预期结果:1) 只看到本分公司任务;2) 争议内容必填被拦;3) 争议提出成功;4) 有争议时不能推进;5) 三家全确认后自动进「人力审核中」。
• 实际观察:1) 列表只有「华东分公司」的任务(10 条,分公司列全部华东);2) 弹窗内提示「争议内容(必填) 为必填项」;3) 任务状态变「有争议」;4) 提示「推进失败:还有 2 家分公司未核对、1 家分公司有争议未解决。请待全部确认后再推进。」;5) 三家确认后填报单状态条停在「人力审核中」。
• 结果:✅
• 截图:17、18、19、20、21。

T9:人力驳回(原因必填)退回上一节点、重提

• 操作步骤:马丽(人力审核)点「驳回」,原因留空点「确认」;填原因「新签客户数请附客户清单后重报。」再驳回;三家分公司重新确认;马丽点「审核通过」。
• 预期结果:原因必填被拦;驳回后退回上一节点(分公司核对中)、核对任务重置为待核对、原因留痕;重新确认后回到人力审核中;审核通过后进「领导审批中」。
• 实际观察:弹窗提示「驳回原因(必填) 为必填项」;驳回后状态条停在「分公司核对中」,三条核对任务状态全部「待核对」,「最近驳回原因」= 新签客户数请附客户清单后重报。;重新确认后回到「人力审核中」;审核通过后状态条停在「领导审批中」。
• 结果:✅
• 截图:22、23、24。

说明:默认四节点流程下,人力审核的上一节点就是「分公司核对」,所以驳回退到分公司核对而不是部门填报 —— 与《设计方案》第 4 章「驳回退回上一节点」一致,本单不改状态机。

T10:领导审批通过 → 四维结果生成

• 操作步骤:冯薇(市场线分管领导)打开填报单点「审核通过」;管理员打开「考核结果」与「结果看板」。
• 预期结果:填报单进「已通过」并盖审批时间/审批人;考核结果出现部门 / 分公司 / 到人 / 分管领导四个维度。
• 实际观察:状态条停在「已通过」;考核结果列表 21 条,汇总维度四种取值齐;结果看板出现各维度图表。
• 结果:✅
• 截图:26、29、30。

T11:加减分登记与审批后重算

• 操作步骤:马丽(人力审核)登记加分「重大项目中标」3 分;何平(人力负责人)在加减分记录点「批准」。
• 预期结果:批准后填报单加减分合计 = 3,最终得分 = 95 + 3 = 98.00;人力审核本人不能批准自己登记的加减分。
• 实际观察:批准后填报单「加减分合计 3」「最终得分 98」;人力审核账号点批准被拒:「审批加减分失败:只有人力负责人岗位可以审批加减分。请转交人力负责人处理。」(API 断言 T13a)。
• 结果:✅
• 截图:27、28。

T12:数据调整(源数据 / 计算结果各一)

• 前置条件:填报单已通过。本用例在 API 全流程脚本里执行(见 §6 的 T14a / T14b / T15e)。
• 操作步骤:1) 销售经理对「新签客户数」发起源数据调整 60 → 66,人力审核提交并批准;2) 管理员对客户成功部「工单响应及时率」发起计算结果调整,得分 24 → 20,提交并批准。
• 预期结果:1) 调整前值记录为 60,落地后实际值 66、完成率 110%、得分 = 20% × 110% = 22.00,填报单最终得分 = 98 + 2 = 100.00;2) 该行「已调整」= 是、调整类型 = 计算结果、最终得分 20.00,未调整行保持否,客户成功部最终得分 40 + 31.5 + 20 = 91.50,考核结果的计算明细里该指标行 is_adjusted = true。
• 实际观察:与预期逐条一致(T14a / T14b / T15e 全部 PASS,输出见 §6)。
• 结果:✅

T13:归档快照与归档后拦截

• 操作步骤:马丽点「归档」;管理员打开「归档快照」;再尝试改已归档填报单的明细实际值。
• 预期结果:填报单进「已归档」;生成一条带 64 位校验和的快照,总分与填报单一致;改明细被拒。
• 实际观察:状态条停在「已归档」;归档快照列表一条「2026 年第 3 季度考核 · 销售部 · 归档快照」,总分 98;改明细弹窗顶部与右下角同时提示「修改填报明细失败:填报单已提交,数据已冻结。如需更正,请发起数据调整申请。」;API 断言另证快照不可改、不可删,归档后加减分与调整申请均被拒。
• 结果:✅
• 截图:31、32、33。

T14:岗位账号数据范围

• 操作步骤:分别用销售经理、华东核对人员、市场线分管领导、技术线分管领导登录,打开「填报单」「填报明细」「分公司核对」「考核结果」。
• 预期结果:部门填报人员只见本部门填报单与明细、越权打开别的部门填报单被拒;分公司核对人员只见本分公司核对任务;分管领导只见分管主体;到人结果只见本人。
• 实际观察:销售经理填报单列表只有「销售部」1 张、填报明细只有本部门 3 行,直接 GET 研发部填报单返回 404;华东核对人员核对任务 10 条,分公司列全部「华东分公司」;市场线分管领导只见销售/市场/客户成功/华东/华南/华北;技术线分管领导只见研发部、测试部、产品部 3 张,GET 销售部填报单返回 404;销售经理的考核结果里「到人」维度只有本人 1 条。
• 结果:✅
• 截图:13、14、17、25、34、35。

T15:pnpm verify

• 实际观察:见 §6。validate 零错、tsc --noEmit 无输出、vitest 6 文件 90 用例通过、i18n:extract:check 报「1 bundle(s) are in sync with the schema」。
• 结果:✅

T16:到人 / 分管领导汇总口径与排名

• 预期结果(《设计方案》V1.0 §8 表 6,脚本内按公式独立实现一遍再比对):
  • 到人得分 = Σ(部门板块得分 × 分工权重% × 个人系数) + Σ(承接项得分率% × 承接权重%);
  • 分管领导得分 = 分管主体最终得分按主体权重加权平均;
  • 各维度组内按得分降序排名,同分同名次。
• 实际观察(界面数值,UI 轮次):赵敏 = 98.00 × 100% × 1.20 + 120% × 40% = 117.60 + 48.00 = 165.60,界面 165.60 排名 1;徐涛 =(98.00×12 + 102.75×8 + 101.75×8)÷ 28 = 100.43,界面 100.43;冯薇 =(98.00×14 + 106.08×8 + 95.50×10 + 106.12×12 + 91.76×9 + 105.57×7)÷ 60 = 100.23,界面 100.23。API 轮次的 8 条到人、2 条分管领导逐条与公式重算值相等(T15c / T15d)。
• 结果:✅
• 截图:29。

T17:部门填报人员在界面录入实际值

• 前置条件:销售部填报单处于「填报中」。
• 操作步骤:销售经理打开「填报明细」中本部门任一行的记录页,找编辑入口。
• 预期结果:能在界面上把实际值填进去(部门填报人员的核心操作)。
• 实际观察:该记录页右上角只有「…」与刷新,没有「编辑」按钮;同一条记录用管理员打开时有「编辑」。同一销售经理账号经 REST PATCH /data/kpi_entry_line/{id} 写实际值是成功的(T5 的完成率/得分断言就是用该账号写入后读回的)。「填报明细」网格的「行内编辑」开关点开后单击/双击/回车都未进入单元格编辑态,管理员账号表现相同,故该路径本轮未能取证。
• 结果:❌
• 截图:13-bumen-tianbao-renyuan-mingxi。

5. 问题记录

#	用例	现象	复现步骤	截图	处置
1	T17	部门填报人员在「填报明细」记录页看不到「编辑」入口,管理员看得到;服务端对同一账号的写入是放行的	空库 + OS_SEED_PROFILE=software 启动 → node scripts/software-people.mjs → 管理员发布方案 → 用 sales.manager@kpi.demo / Passw0rd!23 登录 → 填报明细 → 打开「签约金额完成率」记录页 → 右上角无「编辑」	13	待定:疑似平台控制台按钮可见性只看对象级 writeScope,未把记录级共享算进去(填报单 OWD 为 private,本部门可见性由方案发布写入的动态共享规则放宽)。按 CLAUDE.md「平台问题只上报不修复」,本单不改代码;建议维护者授权后向 objectstack-ai/objectstack 提一条上报单,附本条最小复现

6. 平台侧观察(照实记录,不计入用例判定)

#	现象	位置
O1	方案详情「周期开始 / 周期结束」显示为 Jun 30 / Sep 29,库里存的是 2026-07-01 / 2026-09-30(显示比实际早一天;API 断言 T1e 读到的值是正确的)	04-fangan-caogao
O2	错误提示前缀带 KpiError:(平台 toast 拼接的错误类名)	15-weitian-buneng-tijiao
O3	已归档填报单再改明细,提示文案是「填报单已提交,数据已冻结」而不是「已归档」——拦截行为正确,文案可更精确(应用侧文案,记入遗留问题)	33-guidang-hou-gaishu-beiju

7. 附录:API 全流程断言输出(54 条,全部 PASS)

执行命令:OS_PORT=3111 node scripts/software-flow.mjs(空库 + scripts/software-people.mjs 之后)。

- PASS T0 管理员登录
- PASS T1a 软件档案组织树:1 家总公司 + 8 个部门 + 3 家分公司,编码唯一、上级存在
- PASS T1b 指标库:24 项,每部门 ≥3 项,四种计分方式 / 两种方向 / 三种数据来源全覆盖
- PASS T1c 阶梯指标带完整区间表(首段从 0 起、段间不留缝、末段无上限)
- PASS T1d 公式指标只使用 actual / target / weight 变量
- PASS T1e 方案:季度周期、四节点流程、11 个参与主体、36 条下达;每主体权重合计 100,主体权重合计 100
- PASS T1f 软件档案的组织单元已进入租户对齐夹具覆盖范围(objectstack-ai/objectstack#14547 的临时夹具)
- PASS T1g 运行期脚本产物就位:8 条到人分工(含个人系数 ≠1 的样例)、≥2 位分管领导
- PASS T2a 抹掉一个目标值后发布被拦截,并逐条列出问题
- PASS T2b 主体权重合计 ≠ 100 时发布被拦截并点名主体与实际合计
- PASS T2c 有未关闭的指标争议时发布被拦截
- PASS T2d 争议处理后关闭(处理结论必填、状态留痕)
- PASS T3 完整性检查通过后发布成功
- PASS T4a 发布生成的填报单数 = 参与主体数(11)
- PASS T4b 明细行数 = 指标下达数(36),每行带目标 / 权重 / 计分规则的冻结副本
- PASS T4c 发布后修改指标下达被冻结拒绝
- PASS T5a 发布把填报单的数据范围展开成逐人记录共享行
- PASS T6 仍有指标未填实际值时提交被拒绝并说明缺几项
- PASS T5b 线性封顶(超额):签约金额 5000/4000 = 125% → 封顶 120% → 得分 50 × 120% = 60.00
- PASS T5c 区间插值(未达):回款率 72/90 = 80% → (80−60)/(100−60) = 50% → 得分 30 × 50% = 15.00
- PASS T5d 临界:新签客户数 60/60 = 100% → 得分率 100% → 得分 20 × 100% = 20.00
- PASS T5e 填报单指标得分合计 = 60 + 15 + 20 = 95.00(手算,《设计方案》§7 表 4)
- PASS T7a 销售经理提交本部门填报单 → 进入分公司核对中
- PASS T7b 提交后修改实际值被冻结拒绝(更正须走数据调整申请)
- PASS T8a 按方案里的 3 家分公司生成并行核对任务
- PASS T8b 提出争议但未写核对意见被拒绝
- PASS T8c 分公司核对人员提出争议(意见必填)成功
- PASS T8d 有分公司争议未解决时不能推进到下一节点
- PASS T8e 争议处理后改为确认无误
- PASS T8f 3 家分公司全部确认后自动推进到人力审核中
- PASS T9a 驳回原因为空被拒绝
- PASS T9b 人力审核驳回 → 退回上一节点(分公司核对),核对任务重置为待核对,原因留痕
- PASS T9c 重新核对后再次推进到人力审核中
- PASS T9d 人力审核通过 → 领导审批中
- PASS T10 分管领导审批通过 → 已通过并盖章
- PASS T11 其余 10 张填报单全部推进到已通过
- PASS T12 阶梯计分:客户满意度 87.3/90 = 97% → 命中「达标」区间得分率 90% → 得分 35 × 90% = 31.50
- PASS T13a 人力审核登记加减分成功;同一账号自批被岗位判定拒绝(职责分离)
- PASS T13b 人力负责人批准加减分后计入最终得分:95.00 + 3 = 98.00
- PASS T14a 源数据调整落地并触发重算:新签客户数 60 → 66,完成率 110%,得分 20 × 110% = 22.00;最终得分 100.00
- PASS T14b 计算结果调整只改被调整指标的得分并标记「已调整」,未调整行保持否
- PASS T15a 四维结果均非空:部门 8、分公司 3、到人 8、分管领导 2,且各维度组内排名正确
- PASS T15b 部门维度得分等于填报单最终得分,加权得分 = 得分 × 主体权重
- PASS T15c 到人得分 = Σ(部门板块得分 × 分工权重 × 个人系数) + Σ(承接项得分率 × 承接权重)
- PASS T15d 分管领导得分 = 分管主体最终得分按主体权重加权平均
- PASS T15e 结果的计算明细逐指标带「已调整」标记,可钻取回被调整的那一行
- PASS T16a 归档生成带校验和的不可变快照(总分与填报单一致)
- PASS T16b 归档快照不可修改、不可删除
- PASS T16c 归档后填报明细、加减分、数据调整一律被拒绝
- PASS T16d 审核记录完整留痕(生成 / 提交 / 争议 / 确认 / 驳回 / 通过 / 调整 / 归档)且不可篡改
- PASS T17a 部门填报人员只见本部门填报单,打开其他部门的填报单被拒绝
- PASS T17b 到人结果只见本人
- PASS T17c 分公司核对人员只见本分公司的核对任务
- PASS T17d 分管领导只见分管主体的填报单,打开非分管主体的填报单被拒绝
{"passed":54,"failed":0}

8. 附录:pnpm verify 输出

✓ Validation passed
  Data: 17 Objects  184 Fields
  UI: 1 Apps  17 Views  1 Pages  2 Dashboards  3 Reports  16 Actions
  Security: 6 Positions  6 Permissions

> tsc --noEmit        (无输出)

 Test Files  6 passed (6)
      Tests  90 passed (90)

> objectstack i18n extract --locales=zh-CN … --check
  Skeleton summary
    zh-CN      529 key(s)  (of 529 expected)
  ✓ 1 bundle(s) are in sync with the schema

9. 附录:scripts/software-people.mjs 幂等性

同一实例连跑两次,第二次全部步骤仍 OK 且「新增 0 条」:

===== RUN 1 =====
 OK  岗位账号已创建 — 15 个账号,统一口令 Passw0rd!23
 OK  组织归属已分配 — 新增 13 条,应有 13 条
 OK  流程岗位已分配 — 新增 15 条
 OK  到人分工已建立 — 8 条(新增 8);个人系数样本 0.95 / 1.2 / 0.9 / 1 / 1.1,含 ≠1 的样例:true
 OK  个人承接项已建立 — 8 条(新增 8),每人至少 1 项
 OK  分管领导已设置 — 2 位领导,覆盖 9 个主体(技术线 3 + 市场线 6),分管范围不重叠
===== RUN 2(幂等)=====
 OK  组织归属已分配 — 新增 0 条,应有 13 条
 OK  流程岗位已分配 — 新增 0 条
 OK  到人分工已建立 — 8 条(新增 0)
 OK  个人承接项已建立 — 8 条(新增 0),每人至少 1 项
{"ok":8,"failed":0}

---

截图提交在孤儿分支 acceptance-evidence,commit f17e50058f4ef0086c9990f89ac24b23d21ac802,路径 issue-23/。

[baozhoutao]

#23 需求符合度清单(逐条三态)

对照工作项正文的「范围 A/B/C/D」「不做」「验收标准」逐条核对。分支 issue-23-software-dataset,已合入 origin/main。
✅ = 与需求逐字相符;⚠️ = 实现了但有出入(附差异与原因 + 出口);❌ = 未实现(附原因 + 出口)。

A. 种子档案

#	需求条目	态	说明
A1	src/data/ 下新增档案模块,src/data/index.ts 按 OS_SEED_PROFILE 选档	✅	新增 src/data/software-profile.ts;src/data/index.ts 只在文件末尾加选档逻辑,默认档案记录内容一字未改
A2	组织树:总公司 + 部门 ≥8 + 分公司 3 家,编码唯一、上级存在	✅	软件总公司 + 研发/产品/测试/销售/市场/客户成功/人力行政/财务 8 个部门 + 华东/华南/华北 3 家分公司;编码 SW-* 12 个互不重复,全部挂在 bu_sw_hq 下(API 断言 T1a)
A3	指标库每部门 ≥3 项	✅	24 项 = 8 个部门 × 3 项(T1b)
A4	覆盖四种计分方式(线性/阶梯/区间/公式)	✅	linear 17 项、step 3 项、range 3 项、formula 1 项(T1b)
A5	覆盖两种指标方向	✅	positive / negative 均有(T1b)
A6	覆盖三种数据来源	✅	manual / import / system 均有(T1b)
A7	阶梯指标带完整区间表	✅	3 项阶梯指标共 11 段;首段从 0 起、段间不留缝、末段无上限(T1c)
A8	公式指标只用 actual / target / weight / 完成率	✅	唯一的公式指标「线上严重故障数」= actual == 0.0 ? weight : (actual <= 2.0 ? weight * 0.5 : 0.0),只用 actual 与 weight(T1d)
A9	名称与口径说明按软件公司实际,遵需求 §1.4 术语与 std-copy 四条红线	✅	版本按期交付率、线上严重故障数、需求交付周期、缺陷逃逸率、自动化测试覆盖率、签约金额完成率、回款率、有效线索数、获客成本、客户续费率、客户满意度、工单响应及时率、关键岗位招聘完成率、关键人员离职率、费用预算偏差率、报表准时率等;口径说明为业务语言,无内部代号、无异常原文;「部门板块」「指标下达」「到人分工」「个人承接项」「考核主体」等名词按 §1.4 术语表
A10	数字字段四件套(小数位/最小值/最大值/单位)显式声明	✅	本单不新增任何字段,四件套在既有 kpi_indicator / kpi_plan_indicator 字段定义上已显式声明(scale / min / max);档案侧对 24 个指标逐项显式给出「计量单位」与「数值小数位」(0/1/2 按指标性质),没有靠平台默认
A11	方案「2026 年第 3 季度考核」(季度,2026-07-01 ~ 2026-09-30)	✅	period_type=quarter、year=2026、period_no=3、周期 2026-07-01 ~ 2026-09-30(T1e)
A12	四节点默认流程(部门填报 → 分公司核对(并行)→ 人力审核 → 领导审批)	✅	4 个流程节点,类型与审核岗位与默认流程一致(T1e)
A13	参与主体 = 全部部门 + 3 分公司,主体权重齐全	✅	11 个主体,权重逐条非零,合计 100(T1e)
A14	指标下达每主体权重合计 100	✅	36 条下达,11 个主体的权重合计逐个等于 100(T1e)
A15	目标值取软件公司合理量级	✅	如签约金额 4,000 万元(分公司 900~1,600 万元)、有效线索 1,500 条、需求交付周期 15 天、获客成本 800 元、满意度 90 分
A16	销售相关下达的核对方为对应分公司	⚠️	差异:一期实现里没有「每条指标下达指定核对方」这个字段;「分公司核对(并行)」节点由 src/hooks/sheet.hook.ts 按方案里全部分公司主体统一生成并行核对任务(自己那张单除外),这是 main 的既有状态机行为。本档案的做法:把 3 家销售型分公司放进参与主体,让销售/客户成功/市场口径的下达确实由 3 家分公司并行核对(T8a:销售部填报单生成 3 条核对任务);副作用是非销售部门的填报单也由这 3 家核对。原因:改成「按下达路由核对方」必须动 src/hooks/sheet.hook.ts,而本单明确禁触碰该文件。出口:实现困难 → 已升级给验收侧裁定,列在返回报告「基准差异」与「需拍板事项」;未自行选边、未改状态机
A17	新档案的组织单元 id 进入租户对齐夹具覆盖范围	✅	DEMO_UNIT_IDS 改为两套档案单元 id 的并集(与档案变量无关);实测 12 个 bu_sw_* 单元启动后全部补上组织归属(T1f)

B. 运行期数据脚本

#	需求条目	态	说明
B1	业务岗位账号 ≥8(研发/测试/产品/销售/市场/客户成功/HRBP/财务)	✅	8 个,逐一对应上述岗位,账号与口令见测试报告 §2
B2	流程岗位六类各 ≥1	⚠️	差异:脚本建齐了五类持有人 —— 部门填报人员 8、分公司核对人员 3、人力审核 1、人力负责人 1、分管领导 2;第六类「考核系统管理员 kpi_admin」没有另建账号。原因:平台内置的组织 owner(admin@objectos.ai)自动等同该岗位(README「角色与岗位」表已载明),再建一个重复的管理员账号只会让演示数据多一条噪声。出口:口径待确认 → 已列入返回报告「需拍板事项」,由验收侧裁定是否要求脚本另建一个显式的 kpi_admin 账号;不自行改判
B3	到人分工(员工 × 部门板块 × 分工权重 × 个人系数,含系数 ≠1 的样例)	✅	8 条,系数取 1.10 / 1.20 / 0.90 / 0.95 / 1.00,含 ≠1 的样例;分工权重含 100 与 80 两种(T1g)
B4	个人承接项每人 ≥1,承接本岗位典型指标	✅	8 项,每人 1 项,承接本部门本岗位的典型指标(研发→版本按期交付率、测试→自动化测试覆盖率、销售→签约金额完成率等)
B5	方案设置分管领导 ≥2 位,分管范围不同	✅	徐涛(技术线:研发/产品/测试)、冯薇(市场线:销售/市场/客户成功 + 3 家分公司),范围不重叠,共覆盖 9 个主体(T1g)
B6	脚本可重复执行	✅	连跑两次第二次全部「新增 0 条」且仍 OK(测试报告 §9);方案已发布时脚本主动报错退出并说明原因

C. 全流程实测

#	需求条目	态	说明
C1	API 脚本走完发布→填报→提交→核对(含争议及处理)→人力审核(含驳回与重提)→领导审批→加减分→数据调整(源/结果各一)→四维汇总→归档,每步断言	✅	scripts/software-flow.mjs 共 54 条断言,一次跑完全部 PASS(测试报告 §7)
C2	填报含超额、未达、临界三类样本	✅	签约金额 125%(超额封顶)、回款率 80%(未达)、新签客户数 100%(临界)(T5b/T5c/T5d)
C3	得分断言按 §7 表 4 手算,不从实现反推;≥3 条给手算过程	✅	线性封顶 50%×120%=60.00、区间插值 (80−60)/(100−60)=50% → 30%×50%=15.00、阶梯命中「达标」90% → 35%×90%=31.50,三条手算过程写在测试报告 T5 与 T12
C4	UI 实测:岗位账号在浏览器走关键步骤,截图 ≥12 张,覆盖成功与拦截分支	✅	35 张,岗位账号覆盖部门填报人员、分公司核对人员、人力审核、人力负责人、分管领导(两位)与管理员;拦截分支含未填不能提交、争议意见必填、有争议不能推进、驳回原因必填、归档后不可改
C5	数据范围断言:部门只见本部门、分公司只见本分公司核对任务、分管领导只见分管主体、到人结果只见本人	✅	四条全部通过,越权读取返回 404(T17a~T17d + 截图 13/14/17/25/34/35)

D. 文档

#	需求条目	态	说明
D1	README 或 CLAUDE.md 补档案启用方式与脚本用法	✅	README「演示种子档案(OS_SEED_PROFILE)」一节:两套档案对照表 + 三行命令 + 「换档案必须先删 dist」的坑 + 脚本前置条件
D2	操作手册不改	✅	docs/手册/ 零改动

不做项(核对未越界)

#	条目	态	说明
N1	个人考核单、通知/待办、指标模板库	✅ 未做	均未触碰
N2	不修改默认演示种子	✅ 未做	src/data/index.ts 里默认档案的记录内容一字未改,只在末尾加了选档逻辑与 DEMO_UNIT_IDS 取并集;不设变量启动的行为经 T2 实测与 main 一致
N3	不修改 src/lib/scoring.ts 与 src/hooks/sheet.hook.ts	✅ 未做	两文件零改动(git diff origin/main -- src/lib/scoring.ts src/hooks/sheet.hook.ts 为空)
N4	不修复平台问题	✅ 未做	界面英文标签在合入 main 的 zh-CN 翻译包后已消失;新发现的「部门填报人员记录页无编辑入口」按只上报不修复处理,未改任何平台包与应用代码

验收标准

#	标准	态	说明
S1	OS_SEED_PROFILE=software 空库启动后数据完整;不设变量与 main 一致;pnpm verify 绿	✅	T1(99 行种子、四类配置齐)、T2(46 行、组织/指标/方案/主体/下达逐项与 main 相同)、T15(validate + typecheck + vitest 90 + i18n 同步检查全绿)
S2	发布前完整性检查通过(权重、目标、争议、节点);发布后填报单数 = 参与主体数,明细带冻结副本	✅	T3(三类问题各被拦一次并逐条列出)、T4(11 张填报单 = 11 个主体;36 行明细带目标/权重/计分方式/方向的冻结副本)
S3	全流程脚本一次跑完断言全 PASS;≥3 条得分断言给手算过程	✅	54/54 PASS;三条手算(线性封顶、区间插值、阶梯)见测试报告
S4	四维结果均非空且排名正确;到人与分管领导口径符合 §8 表 6	✅	部门 8 / 分公司 3 / 到人 8 / 分管领导 2,组内降序排名、同分同名次;到人与分管领导得分逐条与按公式独立重算的值相等(T15a/T15c/T15d)
S5	三类岗位账号的数据范围断言通过(越权被明确拒绝)	✅	部门填报人员、分公司核对人员、分管领导三类均通过,越权读取 404(T17a/T17c/T17d),另加到人结果只见本人(T17b)
S6	测试报告按 dev-test 模板挂本单;截图走孤儿分支 40 位 SHA 图链;需求符合度清单逐条三态	✅	测试报告已挂本单;截图在 acceptance-evidence 的 f17e50058f4ef0086c9990f89ac24b23d21ac802,图链用 40 位 SHA,已用 contents API 抽查存在;本清单即符合度清单
S7	全部用户可见文案过 std-copy 四条红线;数字四件套齐;pnpm validate 零错	✅	档案里的指标名与口径说明为业务语言、无内部代号与异常原文、名词按 §1.4;脚本产出的中文提示同样;pnpm validate 零错

本轮新发现(不属本单交付物,记录在案)

#	现象	处置
1	部门填报人员在「填报明细」记录页没有「编辑」入口(管理员有),而同一账号经 REST 写实际值是放行的;「行内编辑」网格本轮自动化未能驱动(管理员同样)	疑似平台控制台按钮可见性只看对象级 writeScope、未把记录级共享算进去。按「平台问题只上报不修复」,本单未改代码;建议维护者授权后向 objectstack-ai/objectstack 提上报单。详见测试报告 T17 与 §5
2	方案详情的周期日期显示比库中值早一天(2026-07-01 显示为 Jun 30)	显示层问题,库中值与 API 读回值正确;记入测试报告 §6 平台侧观察
3	已归档填报单再改明细的提示文案是「填报单已提交,数据已冻结」,不是「已归档」	应用侧文案可更精确,拦截行为正确;记入返回报告「遗留问题」,不在本单修

[baozhoutao]

已提 PR:#26

• 分支 issue-23-software-dataset,已合入 origin/main(含 zh-CN 翻译包),合入后 rm -rf dist 重启、空库重跑了 API 全流程与全部 UI 截图。
• 测试报告与需求符合度清单见上面两条评论;35 张 UI 实测截图在孤儿分支 acceptance-evidence 的 commit f17e50058f4ef0086c9990f89ac24b23d21ac802,路径 issue-23/。
• 状态已切「status:PR审查中」,交接验收侧:工作项创建人 @baozhoutao(已是本单处理人)。开发侧到此为止,不自行合并 PR。
• 两处需要验收侧拍板的事项写在 PR 正文末尾与符合度清单里:① A16「销售相关下达的核对方为对应分公司」按 ⚠️ 交付(改成按下达路由核对方必须动本单禁触碰的状态机);② B2 第六类岗位 kpi_admin 沿用平台内置管理员账号、脚本未另建。