Repository navigation
分公司填报人员:补演示账号并验证数据范围;Excel 导入闭环验证 #39
Description
Activity
- 认领(调度员占坑,2026-09-06):会话 local_0e65d2bc-719b-4314-aae2-351176a17e5f,分支
issue-39-branch-reporter,worktree/Users/baozhoutao/GitHub/kpi-issue-39-branch-reporter,基线 main @ d1abec7。派发开发子 agent(Opus)。
- 认领(调度员占坑,2026-09-06):会话 local_0e65d2bc-719b-4314-aae2-351176a17e5f,分支
需求理解与验证计划(开发侧接单)
分级:纯数据脚本 + 验证,不改
src/,低风险,直接开工(与本单「方案分级」一致)。需求理解(逐条复述)
scripts/software-people.mjs里,三家分公司只有「分公司核对人员」(陈东/林南/高北,岗位kpi_branch_checker),没有挂在分公司组织下的「部门填报人员」;于是三张分公司填报单在 UI 上无人可填,只能管理员代填。本单要补三名分公司填报人员账号(岗位kpi_dept_reporter,组织归属分别为华东/华南/华北分公司),幂等,账号清单输出同步。- 先验证判断再补数据:按现有数据范围规则,填报单的可见性来自方案发布时按「参与主体」写入的共享规则(
src/services/sharing-service.ts,收件方unit_and_subordinates、accessLevel: edit),三家分公司本身就是本方案的参与主体,所以本分公司成员理应拿到本单的可编辑共享;kpi_dept_reporter_set对kpi_entry_sheet/kpi_entry_line给的是allowEdit+readScope: own,靠共享放宽。判断成立则补数据,不成立则停手写「需拍板事项」,不动权限集与共享规则。 - Excel 导入闭环:以某部门填报人员在「填报明细」列表走真实界面的导出 → 只改「实际值」列 → 导入向导回写,记录逐步点击数、校验提示、写入结果、即时算分,以及改只读列/多行/缺行的拦截行为。不改代码,只出结论,问题按应用/平台分别归属。
- README「演示种子档案」一节的账号说明同步。
验证计划(测试口径先于实现)
编号 场景 判据 V1 空库 + OS_SEED_PROFILE=software起实例,跑node scripts/software-people.mjs三名新账号建成,岗位与组织归属正确;再跑一遍步骤全 OK 且不新增行(幂等) V2 发布方案后,以华东分公司填报人员登录工作台/填报明细 只见华东分公司的填报单与明细;华南/华北的单与明细不可见 V3 同一账号在本分公司填报单上填实际值 保存即出分(完成率/得分率/得分/计算说明齐全),能提交,单据进入下一节点 V4 同一账号直接访问他司填报单/明细的详情 URL 与 REST 拒绝(404/403),不泄露记录 V5 分公司核对人员账号(陈东)在同一张分公司填报单上试图改实际值 被拒(权限集无 allowEdit),核对任务照常可操作V6 node scripts/software-flow.mjs仍 54/54;分公司三张单改由分公司填报人员填,断言不放松 V7 Excel 导入闭环:导出 → 改实际值 → 导入 逐步点击数、校验提示、写入结果、即时算分记录成表;改只读列 / 多行 / 缺行三种异常的拦截行为如实记录 V8 pnpm verify绿 V2~V5、V7 走真实浏览器界面截图取证,证据挂
acceptance-evidence孤儿分支issue-39/。若 V2/V3 不通过(分公司填报人员看不到或填不了)→ 按本单正文停手,把现象与成因写进「需拍板事项」,不在本单改权限集与共享规则。
测试报告 — 分公司填报人员数据范围 + Excel 导入闭环
结论
项 结论 分公司填报人员补数据与数据范围 通过 —— 本单的判断成立:三名账号建成后只见本分公司、能填能提交、越权 404,不需要改权限集与共享规则 分公司核对人员仍不能填数 通过 —— 界面无编辑入口、REST 403;核对任务侧照常可操作 scripts/software-people.mjs幂等通过 —— 第二遍步骤全 OK 且新增 0 条 scripts/software-flow.mjs通过 —— 55/55(原 54 条一条未改、未放松;新增 T11b 断言分公司单非管理员代填) Excel 导入闭环 部分可用 —— 按角色走不通(填报人员岗位看不到「导入」);按管理员走得通,但导出的文件必须手工补两列才收。两处成因均在平台,已上报 pnpm verify通过(exit 0) 测试环境
项 值 分支 / 提交 issue-39-branch-reporter@5b54b56worktree kpi-issue-39-branch-reporterdev 实例 http://localhost:3114,OS_SEED_PROFILE=software数据库 UI 实测 .objectstack/issue-39.db;流程断言另起空库.objectstack/issue-39-flow.db平台版本 @objectstack/*17.2.0账号 管理员 admin@objectos.ai;岗位账号统一口令 Passw0rd!23 取证方式 Playwright(chromium,1440×900,zh-CN)驱动真实界面;截图 commit 0cede6e(孤儿分支acceptance-evidence,目录issue-39/)降级声明:本项目暂不具备双实例条件,按 CLAUDE.md「H2 测试执行」在同会话自测 —— 测试计划先落盘(见本单上一条评论)再逐条对照执行,不是先做完再补计划。
逐条结果
V1 账号建立与幂等 — 通过
第一遍
node scripts/software-people.mjs:OK 岗位账号已创建 — 18 个账号,统一口令 Passw0rd!23 OK 组织归属已分配 — 新增 16 条,应有 16 条 OK 流程岗位已分配 — 新增 18 条;本档案分配 5 类岗位:部门填报人员 11 人、分公司核对人员 3 人、人力审核 1 人、人力负责人 1 人、分管领导 2 人第二遍:8 步仍全 OK,
新增 0 条/新增 0 条,{"ok":8,"failed":0}—— 幂等成立。新增的三名账号(岗位均为「部门填报人员」
kpi_dept_reporter,组织归属为各自分公司):姓名 岗位显示名 账号 组织单元 沈月 华东分公司填报人员 east.reporter@kpi.demo 华东分公司 黄鹤 华南分公司填报人员 south.reporter@kpi.demo 华南分公司 秦朗 华北分公司填报人员 north.reporter@kpi.demo 华北分公司 V2 数据范围:只见本分公司 — 通过
沈月登录后,工作台「待填报的指标」只有 4 行、全部属于「2026 年第 3 季度考核 · 华东分公司」;「填报单」区只有 1 张;「填报明细」列表页脚
4 条记录。库里同一方案共 11 张填报单、36 行明细。
V3 填数、保存出分、提交 — 通过
在工作台可编辑网格里逐格双击填入实际值 →「全部保存」→ 保存即出分:
指标 实际值 / 目标值 完成率 得分率 得分 回款率 94.5 / 90 105.00% 105.00 31.50 客户续费率 93 / 92 101.09% 101.09 20.22 有效线索数 520 / 500 104.00% 104.00 10.40 签约金额完成率 1760 / 1600 110.00% 110.00 44.00 合计 106.12 
「更多操作 → 提交填报」→ 确认 → 单据由「填报中」进入「分公司核对中」。
V4 越权访问他司记录 — 通过
沈月直接访问华南分公司填报单 / 填报明细的详情 URL,两处均为「未找到记录 · 您查找的记录不存在或已被删除」。REST 同步复核:
GET /data/kpi_entry_sheet/<华南单> → 404 RECORD_NOT_FOUND PATCH /data/kpi_entry_line/<华南明细> → 403 PERMISSION_DENIED 「requires edit access to its master record (master 'kpi_entry_sheet' not editable by this user)」
V5 分公司核对人员不能填数 — 通过
分公司核对人员登录后,工作台网格里双击「实际值」单元格不进入编辑(无输入框、无「全部保存」按钮);REST 复核
PATCH /data/kpi_entry_line/<id>返回 403 PERMISSION_DENIED。核对任务侧照常:待核对 1 条、「更多操作」可用。
V6 全流程断言 — 通过(55/55)
空库重跑
software-people.mjs+software-flow.mjs:{"passed":55,"failed":0}。原有 54 条一条未改、未放松;三张分公司填报单改由本分公司填报人员登录后填报并提交,并新增一条断言:PASS T11b 三张分公司填报单由本分公司的填报人员本人填报并提交(不是管理员代填) — 由分公司填报人员完成:bu_sw_east, bu_sw_north, bu_sw_south该断言带空列表护栏:共享规则展开成逐人记录共享行是异步的,脚本先
waitUntil本单明细可见、再要求own.length > 0,不会出现「空数组每一行都填好了」这种假通过。V7 Excel 导入闭环 — 部分可用(详见下一节)
V8 门禁 — 通过
pnpm verifyexit 0:pnpm validate/tsc --noEmit/vitest 139 passed (139)/ i18n1 bundle(s) are in sync with the schema。
Excel 导入闭环报告
逐步点击数
步骤 操作 点击数 结果 导出 「导出」→「导出为 XLSX」 2 得到 填报明细-<时间戳>.xlsx,10 列 4 行改数 在文件里只改「实际值」列 — — 导入(填报人员) 在工具条上找「导入」 — 工具条上没有「导入」按钮,路径到此为止 导入(管理员,原样文件) 「导入」→ 选文件 2 第 2 步硬停:必填字段未映射 导入(管理员,手工补两列后) 导入 → 选文件 → 下一步 → 展开匹配模式 → 选「更新已有(无匹配则跳过)」 → 勾「所属填报单」 → 勾「来源下达」 → 校验数据 → 导入 4 行 9 全部 4 行均有效→导入完成 · 更新 4 条补两列后闭环成立:导入后华南分公司填报单四行实际值全部回写,得分同步重算(85.80 / 92.60 / 95.00 / 95.00,指标得分合计 91.76),全库明细行数不变(36 → 36,无新建脏行)。
拦截行为表
场景 实测行为 评价 填报人员岗位想导入 工具条只有「导出」,没有「导入」。同一账号在「数据调整」(该对象 allowCreate: true)上就有「新建 + 导入」 —— 闸门跟着allowCreate走,不跟着allowEdit走不合理,已上报平台 原样导出文件直接导入 第 2 步硬停:「无法继续——以下必填字段未映射:所属填报单 (sheet), 来源下达 (plan_indicator)。请在文件中添加对应的列,或返回上一步重新上传包含该列的文件。」 提示准确、可执行;但导出根本不产出这两列,闭环断在这里 只读列被一并改掉(目标值 / 权重 / 得分率 / 最终得分 改成异常值) 校验 全部 4 行均有效→更新 4 条,不报错、不提示。落库后:目标值 / 权重仍是原值(只读剥离生效),但得分与计算说明是按错值算出来的、并且已落库 —— 一条自相矛盾的记录(界面上目标值 400、权重 10,而计算说明写着「目标 1、权重 1%」、得分 1.20)不合理,已上报平台 缺行(文件里少一行) 库里那一行原样不动,不报错、不清空 合理 多行(文件里多一行,「来源下达」不存在) 逐行校验「3 条有效,1 条有错误」→「第 4 行:来源下达: 找不到匹配 "凭空多出的下达 · 华南分公司" 的记录」;结果 更新 3 条 · 已跳过 1 条,全库行数不变、无脏行合理(小瑕疵:按钮文案仍是「导入 4 行」,不随有效行数变化) 更新模式但没选匹配字段 校验拦下: writeMode "update" requires a non-empty matchFields[]拦得住,但报错是英文内部原文,不是三段式中文 
问题按归属分列
平台侧(按「只上报不修复」已上报,本单不改代码)
- Update-side: a readonly field is stripped from persistence but still reaches beforeUpdate, so hook-derived columns persist values computed from data the row never contains objectstack#16344 —— 只读字段在更新路径上不落库(剥离生效),但会进入
beforeUpdate钩子看到的记录;应用的计分钩子据此算分,算出的派生字段(完成率 / 得分率 / 得分 / 计算说明)会落库,记录自相矛盾且无任何报错。最小复现是一次纯 REST PATCH,与导入无关 —— 导入向导只是同一条路径的批量入口。 - Console list: the 「导入」 button is gated on allowCreate although the wizard can update, and 「导出」 emits a file the wizard refuses — the export→edit→import round trip is unreachable objectstack#16345 —— ① 列表工具条把「导入」的闸门挂在
allowCreate上,而向导本身支持「更新已有」;于是持有allowEdit却没有allowCreate的填报人员岗位看不到「导入」,只有管理员用得上。② 「导出」只导视图可见列,不带记录 id、也不带对象的两个必填 lookup,导出的文件导入向导不收 —— 同一个工具条的两半对「一行是什么」意见不一致。「导入 N 行」文案与英文原文报错这两条小瑕疵已并入该 issue 的观察记录。
应用侧(本单范围外,只记录不改)
- 权限集
kpi_dept_reporter_set对kpi_entry_line声明allowCreate: false—— 这是有意为之(手工新建的明细没有冻结的目标值与权重,算不出分,是注定作废的行),声明本身没问题;问题在平台把「导入」挂在了allowCreate上。平台修 Console list: the 「导入」 button is gated on allowCreate although the wizard can update, and 「导出」 emits a file the wizard refuses — the export→edit→import round trip is unreachable objectstack#16345 后应用侧零改动即可打通;若要更早打通,唯一选项是给填报人员开allowCreate来换导入入口,那会把「新建明细」这条死路重新放出来,不建议,也超出本单范围。 - 工作台网格里「指标得分合计」显示
91.75999999999999(浮点尾数),同一行「最终得分」显示91.76。汇总字段未按 2 位小数收敛;在src/内,本单禁止改动,记为遗留。
遗留问题
# 问题 归属 出口 1 只读字段进入钩子,派生字段落错值 平台 objectstack-ai/objectstack#16344 2 「导入」挂在 allowCreate;「导出」文件不可回导 平台 objectstack-ai/objectstack#16345 3 「导入 N 行」按钮文案不随有效行数变化 平台 已并入 objectstack-ai/objectstack#16345 4 未选匹配字段的报错是英文内部原文 平台 已并入 objectstack-ai/objectstack#16345 5 指标得分合计浮点尾数 91.75999999999999应用 本单禁改 src/,建议另立工作项- Update-side: a readonly field is stripped from persistence but still reaches beforeUpdate, so hook-derived columns persist values computed from data the row never contains objectstack#16344 —— 只读字段在更新路径上不落库(剥离生效),但会进入
需求符合度清单(提 PR 前硬门禁)
逐条对照本单正文的「范围 / 不做 / 验收标准」,三态标注。
范围 1 ——
scripts/software-people.mjs补三名分公司填报人员# 需求条目 态 证据 / 说明 1.1 为华东 / 华南 / 华北各建 1 名「分公司填报人员」账号 ✅ 沈月 east.reporter@kpi.demo、黄鹤 south.reporter@kpi.demo、秦朗 north.reporter@kpi.demo 1.2 岗位 kpi_dept_reporter✅ 脚本输出「流程岗位已分配 … 部门填报人员 11 人」(原 8 人 + 3) 1.3 组织归属为该分公司 ✅ 账号清单列「组织单元」分别为 华东分公司 / 华南分公司 / 华北分公司;脚本断言「组织归属已分配 — 新增 16 条,应有 16 条」 1.4 中文姓名与岗位显示名 ✅ 姓名 沈月 / 黄鹤 / 秦朗; job为「华东(南 / 北)分公司填报人员」1.5 幂等 ✅ 第二遍执行 8 步全 OK、 新增 0 条、{"ok":8,"failed":0}1.6 账号清单输出同步 ✅ 脚本末尾「岗位账号清单」新增三行,含姓名 / 岗位 / 账号 / 组织单元 / 流程岗位 范围 2 —— 数据范围验证
# 需求条目 态 证据 / 说明 2.1 以新账号登录 ✅ 真实界面登录(Playwright chromium 1440×900 zh-CN) 2.2 工作台 / 填报明细只见本分公司的单与明细 ✅ 工作台 4 行明细 + 1 张单,全部为华东分公司;填报明细列表 4 条记录(库内同方案共 11 张单 / 36 行)2.3 能填数 ✅ 工作台可编辑网格双击填入 →「全部保存」成功 2.4 保存出分 ✅ 四行完成率 / 得分率 / 得分 / 计算说明齐全,指标得分合计 106.12 2.5 能提交 ✅ 「提交填报」→ 状态由「填报中」进入「分公司核对中」 2.6 越权访问他司记录 404 ✅ 界面「未找到记录」;REST GET华南单 404 RECORD_NOT_FOUND、PATCH华南明细 403 PERMISSION_DENIED2.7 分公司核对人员仍只能核对不能填 ✅ 双击实际值不进入编辑(无输入框 / 无「全部保存」);REST 403;核对任务侧待核对 1 条、可操作 2.8 验证不通过则停手写「需拍板事项」、不改权限集与共享规则 ✅ 验证全部通过,该分支未触发; src/零改动(git status仅 3 个允许文件)范围 3 —— Excel 导入闭环验证
# 需求条目 态 证据 / 说明 3.1 以某部门填报人员在「填报明细」列表「导出」本部门明细 ✅ 分公司填报人员(黄鹤)导出成功,2 次点击,得 10 列 4 行 XLSX 3.2 在导出文件里只改「实际值」列 ✅ 仅第 5 列改动 3.3 「导入」回去 ⚠️ 偏差:导入这一步无法以填报人员身份完成,只能换管理员。填报人员的工具条上没有「导入」按钮 —— 平台把该按钮的闸门挂在 allowCreate上,而kpi_dept_reporter_set对kpi_entry_line有意声明allowCreate: false。且原样导出的文件导入向导不收(缺两个必填 lookup 列),必须手工补列。出口:平台能力受限 → objectstack-ai/objectstack#16345(本单正文明令「不改代码,只出结论」,故不在此修)3.4 记录校验提示 ✅ 未映射必填列 / 未选匹配字段 / 逐行匹配失败三类提示均已原文记录 3.5 记录写入结果 ✅ 全部 4 行均有效→「导入完成 · 更新 4 条」;缺行多行场景「更新 3 条 · 已跳过 1 条」,全库行数 36 → 363.6 记录即时算分 ✅ 导入后四行得分同步重算(85.80 / 92.60 / 95.00 / 95.00),指标得分合计 91.76,填报人员工作台即时可见 3.7 记录导入向导逐步点击数 ✅ 导出 2 击;原样文件导入 2 击后被拦;补列后完整闭环 9 击(表见测试报告) 3.8 记录「改了只读列会怎样」 ✅ 校验全绿、导入成功、不报错;只读列本身不落库,但得分与计算说明按错值算并落库,记录自相矛盾 → objectstack-ai/objectstack#16344 3.9 记录「多行 / 缺行会怎样」 ✅ 多行:逐行报错「第 4 行:来源下达: 找不到匹配 … 的记录」并跳过,无脏行;缺行:该行原样不动,不报错不清空 3.10 不改代码 ✅ 导入闭环全程零代码改动; src/未触碰3.11 问题按平台 / 应用归属分别列出 ✅ 测试报告「问题按归属分列」:平台 2 条(已上报 objectstack-ai/objectstack#16344 / objectstack-ai/objectstack#16345)、应用 2 条(均在 src/,本单禁改,已记为遗留)范围 4 —— README 同步
# 需求条目 态 证据 / 说明 4.1 「演示种子档案」一节账号说明同步 ✅ 账号数 15 → 18;新增一段说明三家分公司各有「填报 + 核对」两名账号、为什么必须分开、数据范围来自哪里 不做
# 约束 态 说明 N.1 不改 src/✅ git status仅README.md/scripts/software-flow.mjs/scripts/software-people.mjsN.2 不改手册 ✅ docs/零改动N.3 权限集 / 共享规则若挡路只报告不修 ✅ 未挡路(判断成立),两者均未改 验收标准
# 验收标准 态 证据 / 说明 A.1 三名账号建立, software-people.mjs幂等✅ 见 1.1 / 1.5 A.2 software-flow.mjs仍 54/54;分公司单改由分公司填报人员填,断言不放松⚠️ 偏差:总数从 54 变成 55。原有 54 条一条未改、未删、未放松,全部 PASS;分公司三张单已改由本分公司填报人员登录后填报并提交;在此基础上新增 T11b 断言「不是管理员代填」,总数因此 +1。差异方向是加严不是放松,故未走退回 / 挂起 / 升级三出口,仅在此登记为基准差异待验收侧确认 A.3 分公司填报人员实测:只见本分公司、填数出分提交成功、越权 404、核对人员不能填(截图) ✅ 见 2.2~2.7,截图 9 张( acceptance-evidence@0cede6e)A.4 Excel 导入闭环报告:逐步点击数与拦截行为表;问题按应用 / 平台归属列出 ✅ 见测试报告「Excel 导入闭环报告」;闭环本身的可达性偏差已在 3.3 单列 A.5 测试报告与符合度清单挂本单评论,截图走 acceptance-evidence✅ 本清单 + 上一条测试报告;截图 commit 0cede6ecbdaeae53889b1cbafa325e90f7e7b22b,23 个文件经 contents API 核对在位A.6 pnpm verify绿✅ exit 0(validate / typecheck / vitest 139 passed / i18n in sync) 非 ✅ 条目汇总(共 2 条,各带出口)
条目 态 出口 3.3 「导入」回去 —— 填报人员身份不可达,须换管理员且须手工补列 ⚠️ 平台能力受限,已上报 objectstack-ai/objectstack#16345(现象 / 最小复现 / 期望能力 / 平台版本 17.2.0 齐备)。本单正文明令「不改代码,只出结论」,应用侧无合法修法(唯一选项是给填报人员开 allowCreate,会重新放出「新建明细」死路,不建议且超范围)A.2 software-flow.mjs55/55 而非 54/54⚠️ 基准差异,待验收侧确认。原 54 条一条未放松;差异来自按本单要求「改为由分公司填报人员填」后增补的一条断言 T11b。若验收侧要求严格保持 54 条,删掉 T11b 即可恢复,但那会失去「非管理员代填」的可回归证据 交接验收侧
PR 已提:#41 (
issue-39-branch-reporter→main,基线d1abec7,提交5b54b56)状态切「status:PR审查中」,处理人 @baozhoutao。开发侧不自行合并。
- 测试报告:分公司填报人员:补演示账号并验证数据范围;Excel 导入闭环验证 #39 (comment)
- 需求符合度清单:分公司填报人员:补演示账号并验证数据范围;Excel 导入闭环验证 #39 (comment)
- 截图:孤儿分支
acceptance-evidence,目录issue-39/,commit0cede6ecbdaeae53889b1cbafa325e90f7e7b22b(23 张,已经 contents API 核对在位)
需拍板 1 条:
software-flow.mjs断言总数 54 → 55。原 54 条一条未改未放松、全绿;+1 是按本单要求把分公司单改由分公司填报人员填之后增补的 T11b「不是管理员代填」。要严格保持 54,删掉 T11b 即可,但会失去这条可回归证据。平台上报 2 条(只上报不修复,本 PR 无绕行):objectstack-ai/objectstack#16344(只读字段进入 beforeUpdate,派生字段落错值)、objectstack-ai/objectstack#16345(「导入」按钮挂在 allowCreate;「导出」文件不可回导)。
应用侧遗留 2 条(在
src/内,本单禁改,建议另立工作项):填报人员岗位因allowCreate: false够不到导入入口(等平台修 objectstack-ai/objectstack#16345 后零改动即通);工作台「指标得分合计」显示浮点尾数91.75999999999999,同行「最终得分」显示91.76。- added a commit that references this issue
on Sep 6, 2026 合并记录(调度员,2026-09-06)
- 收单核实:PR 演示档案补三名分公司填报人员,分公司填报单由本人填(#39) #41 关联本单、无自动关闭关键字;单提交、3 文件(README / software-people / software-flow)均在允许面,
src/、docs/、e2e-flow.mjs零改动;CI 绿;测试报告、需求符合度清单(2 条⚠️ 均带出口)、23 张证据图核对存在。全项通过。 - 评审闸门(轻量档):「可合并」,阻塞 0 / 应修 0 / 记录 3;评审侧对
software-flow.mjs做断言块级逐字节比对,基线 54 条在 head 中全部逐字节相同,+1 为新增 T11b「分公司单不是管理员代填」,加严方向;实跑 55/55、verify 绿;分公司填报人员只见本分公司、越权 404/403 复现。 - 拍板落地:断言 54→55 调度员接受(加严);导入闭环「部分可用」按平台受限记录,出口 Update-side: a readonly field is stripped from persistence but still reaches beforeUpdate, so hook-derived columns persist values computed from data the row never contains objectstack#16344(只读字段进入 beforeUpdate 致派生值错落)、#16345(导入闸门挂 allowCreate、导出文件不可回导)。本单核心判断成立:分公司填报人员按现有数据范围规则即可填本分公司的单,权限集与共享规则未改。
- 遗留:得分合计浮点尾数显示已并入 文案与盖章小批:审核记录状态中文、核对任务盖章、归档提示、看板人员姓名、归档拒绝节点名、必填叠字、禁止手工新建填报单 #38 第 8 条。
- 已合并 PR 演示档案补三名分公司填报人员,分公司填报单由本人填(#39) #41 到 main。状态切
status:PM验收中,处理人不变(验收侧)。
- 收单核实:PR 演示档案补三名分公司填报人员,分公司填报单由本人填(#39) #41 关联本单、无自动关闭关键字;单提交、3 文件(README / software-people / software-flow)均在允许面,
背景(来源:#23 UI 实测 K-1 与调度员 2026-09-06 复核,维护者以 /os-project-pm-dispatch 放行本批)
UI 实测中三家分公司的填报单无人能填,只能管理员代填,被记为「分公司主体没有填报人」。复核发现演示数据脚本
scripts/software-people.mjs只为分公司建了「分公司核对人员」,没建挂在分公司组织下的「部门填报人员」;按现有数据范围规则(填报人员按所属组织单元看本单元填报单),分公司填报人员应当能填本分公司的单。本单先验证这一判断,再补数据;同时把一直没走通验证的 Excel 导入路径做一次闭环。范围
scripts/software-people.mjs:为华东/华南/华北各建 1 名「分公司填报人员」账号(岗位kpi_dept_reporter,组织归属为该分公司,中文姓名与岗位显示名),幂等;账号清单输出同步。不做
不改
src/(除非验证发现分公司填报人员被权限集/共享规则挡住——那也不在本单修,只报告);不改手册。方案分级
纯数据脚本 + 验证,低风险,直接开工。
验收标准
node scripts/software-people.mjs幂等;scripts/software-flow.mjs仍 54/54(若脚本以管理员代填分公司单,改为由分公司填报人员填,断言不放松)。acceptance-evidence;pnpm verify绿。