分公司填报人员:补演示账号并验证数据范围;Excel 导入闭环验证

背景(来源:#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,组织归属为该分公司,中文姓名与岗位显示名),幂等;账号清单输出同步。
验证:以新账号登录,工作台/填报明细只见本分公司的单与明细,能填数、保存出分、提交;分公司核对人员账号仍只能核对不能填。若验证不通过(填不了或越权可见),停手把现象与成因写进本单「需拍板事项」,不改权限集与共享规则(那是另一单的事)。
Excel 导入闭环:以某部门填报人员在「填报明细」列表「导出」本部门明细 → 在导出文件里只改「实际值」列 → 「导入」回去 → 校验提示、写入结果、即时算分;记录导入向导逐步点击数与拦截(改了只读列会怎样、多行/缺行会怎样)。不改代码,只出结论;导入不可用或行为不合理的部分如实记录并按平台/应用归属分别列出。
README「演示种子档案」一节的账号说明同步(若有)。

不做

不改 src/(除非验证发现分公司填报人员被权限集/共享规则挡住——那也不在本单修,只报告);不改手册。

方案分级

纯数据脚本 + 验证,低风险,直接开工。

验收标准

三名分公司填报人员账号建立,node scripts/software-people.mjs 幂等;scripts/software-flow.mjs 仍 54/54(若脚本以管理员代填分公司单,改为由分公司填报人员填,断言不放松)。
分公司填报人员实测:只见本分公司填报单/明细,填数、出分、提交成功;越权访问他司记录 404;分公司核对人员不能填数(截图)。
Excel 导入闭环报告:导出 → 改实际值 → 导入 → 出分,逐步点击数与拦截行为表;问题按应用/平台归属列出。
测试报告与符合度清单挂本单评论,截图走 acceptance-evidence;pnpm verify 绿。

认领(调度员占坑,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)。

需求理解与验证计划(开发侧接单)

分级:纯数据脚本 + 验证,不改 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` @ `5b54b56`
worktree	`kpi-issue-39-branch-reporter`
dev 实例	`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 verify exit 0:pnpm validate / tsc --noEmit / vitest 139 passed (139) / i18n 1 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/`,建议另立工作项

需求符合度清单(提 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_DENIED
2.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 → 36
3.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.mjs`
N.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.mjs` 55/55 而非 54/54	⚠️	基准差异,待验收侧确认。原 54 条一条未放松;差异来自按本单要求「改为由分公司填报人员填」后增补的一条断言 T11b。若验收侧要求严格保持 54 条,删掉 T11b 即可恢复,但那会失去「非管理员代填」的可回归证据

@baozhoutao

交接验收侧

PR 已提:#41 (issue-39-branch-reporter → main,基线 d1abec7,提交 5b54b56)

状态切「status:PR审查中」,处理人 @baozhoutao。开发侧不自行合并。

测试报告:分公司填报人员:补演示账号并验证数据范围;Excel 导入闭环验证 #39 (comment)
需求符合度清单:分公司填报人员:补演示账号并验证数据范围;Excel 导入闭环验证 #39 (comment)
截图:孤儿分支 acceptance-evidence,目录 issue-39/,commit 0cede6ecbdaeae53889b1cbafa325e90f7e7b22b(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。

Merge pull request #41: branch reporter accounts in the demo dataset;…

合并记录(调度员,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验收中,处理人不变(验收侧)。

分公司填报人员:补演示账号并验证数据范围;Excel 导入闭环验证 #39

Description

背景(来源:#23 UI 实测 K-1 与调度员 2026-09-06 复核,维护者以 /os-project-pm-dispatch 放行本批)

范围

不做

方案分级

验收标准

Activity

baozhoutao commented on Sep 6, 2026

baozhoutao commented on Sep 6, 2026

需求理解与验证计划(开发侧接单)

需求理解(逐条复述)

验证计划(测试口径先于实现)

baozhoutao commented on Sep 6, 2026

测试报告 — 分公司填报人员数据范围 + Excel 导入闭环

结论

测试环境

逐条结果

V1 账号建立与幂等 — 通过

V2 数据范围:只见本分公司 — 通过

V3 填数、保存出分、提交 — 通过

V4 越权访问他司记录 — 通过

V5 分公司核对人员不能填数 — 通过

V6 全流程断言 — 通过(55/55)

V7 Excel 导入闭环 — 部分可用(详见下一节)

V8 门禁 — 通过

Excel 导入闭环报告

逐步点击数

拦截行为表

问题按归属分列

遗留问题

baozhoutao commented on Sep 6, 2026

需求符合度清单(提 PR 前硬门禁)

范围 1 —— scripts/software-people.mjs 补三名分公司填报人员

范围 2 —— 数据范围验证

范围 3 —— Excel 导入闭环验证

范围 4 —— README 同步

不做

验收标准

非 ✅ 条目汇总(共 2 条,各带出口)

baozhoutao commented on Sep 6, 2026

交接验收侧

baozhoutao commented on Sep 6, 2026

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

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

范围 1 —— `scripts/software-people.mjs` 补三名分公司填报人员