演示档案补三名分公司填报人员,分公司填报单由本人填(#39)

[baozhoutao]

关联工作项 #39。

为什么

分公司在方案里既是被考核主体、又是核对方,而按《设计方案》§3 表 1,分公司核对人员只能「确认无误 / 提出争议」、改不了数值。演示档案此前只为三家分公司建了核对人员,分公司自己那张填报单于是在界面上无人可填 —— UI 实测时只能由管理员代填,被记为「分公司主体没有填报人」。

本单先验证「分公司填报人员应当能填本分公司的单」这一判断,再补数据。判断成立:填报单的可见性来自方案发布时按参与主体写入的共享规则(src/services/sharing-service.ts,收件方 unit_and_subordinates、accessLevel: edit),三家分公司本身就是本方案的参与主体,所以本分公司成员天然拿到本单的可编辑共享。权限集与共享规则一行未改,src/ 完全没有触碰。

改了什么

• scripts/software-people.mjs —— 华东 / 华南 / 华北各补 1 名「分公司填报人员」(沈月 / 黄鹤 / 秦朗,岗位 kpi_dept_reporter,组织归属为本分公司)。先查后写,幂等;账号清单输出同步(15 → 18 个账号)。
• scripts/software-flow.mjs —— 三张分公司填报单改由本分公司的填报人员登录后填报并提交,不再由管理员代填;新增 T11b 断言这一条。断言带空列表护栏:共享展开是异步的,先 waitUntil 本单明细可见、再要求非空,避免「空数组每一行都填好了」的假通过。原有 54 条断言一条未改、未删、未放松。
• README.md —— 「演示种子档案」一节补充三家分公司各有「填报 + 核对」两名账号、为什么必须分开、数据范围来自哪里。

验证

• pnpm verify exit 0(validate / typecheck / vitest 139 passed / i18n in sync)。
• 空库重跑 software-people.mjs + software-flow.mjs:55/55(原 54 + 新增 T11b)。
• 真实界面实测(Playwright,截图见工作项):分公司填报人员只见本分公司的 1 张单 / 4 行明细,填数保存即出分(合计 106.12),提交后进入「分公司核对中」;越权访问他司填报单与明细均 404 / 403;分公司核对人员双击实际值不进入编辑、REST 403,核对任务侧照常。
• software-people.mjs 连跑两遍:第二遍 新增 0 条,幂等成立。

测试报告与需求符合度清单挂在工作项评论上;截图在孤儿分支 acceptance-evidence 的 issue-39/(commit 0cede6ecbdaeae53889b1cbafa325e90f7e7b22b)。

Excel 导入闭环(本单只验证、不改代码)

闭环走通了,但不是以填报人员的身份:

• 导出 2 击可得 XLSX;原样文件导入被向导硬停(缺两个必填 lookup 列);手工补两列后完整闭环 9 击,更新 4 条、即时重算得分、无脏行。
• 填报人员岗位的工具条上没有「导入」按钮 —— 平台把该按钮挂在 allowCreate 上,而 kpi_dept_reporter_set 对 kpi_entry_line 有意声明 allowCreate: false(手工新建的明细没有冻结目标值与权重,算不出分)。
• 只读列被一并改掉时,只读列本身不落库,但得分与计算说明按错值算出来并落库,记录自相矛盾且无任何报错。

两处成因都在平台,按「只上报不修复」已上报:objectstack-ai/objectstack#16344、objectstack-ai/objectstack#16345。本 PR 不含任何针对它们的绕行或补丁。

待确认

software-flow.mjs 的断言总数从 54 变成 55 —— 原 54 条全绿且一条未放松,+1 来自按本单要求改为分公司填报人员填报后增补的 T11b。若要求严格保持 54,删掉 T11b 即可恢复,但会失去「非管理员代填」的可回归证据。

🤖 Generated with Claude Code

[baozhoutao]

代码评审报告(os-project-dev-review)

档位:轻量档(依据:工作项 #39「方案分级:纯数据脚本 + 验证,低风险,直接开工」;src/ 零改动,diff 3 文件 +72/-8)
评审对象:head 5b54b56,base d1abec7(= 当前 main tip),单 commit
独立实跑:临时 clone 分支 → pnpm install --frozen-lockfile → pnpm verify → 空库(OS_SEED_PROFILE=software,独立端口与独立库文件)→ software-people.mjs ×2 → software-flow.mjs → REST 数据范围抽查。评审子 agent 冷启动,只读工作项全文、PR diff、需求符合度清单三样输入,未读开发方测试报告与对话记录。

结论:可合并

---

通用质量(/code-review 常规档)

无阻塞级、无应修级发现。3 个记录级观察见下方发现清单。

改动逻辑复核:pushToApproved 拆成「分公司主体走填报人员登录态」与「部门主体维持原管理员路径」两支,else 分支与 base 逐语句等价(仅把 String(target.subject) 提成局部变量 subject);函数尾部的核对/审批推进段未改。身份切换后无条件 asAdmin() 复位,不会把填报人员的登录态泄漏到后续断言;signIn 在 scripts/lib/kpi-api.mjs 里登录失败即抛错、不保留旧 cookie,所以「静默退回管理员代填」在机制上不可能发生。

专属核查

1 改动面越界:✅ 无越界
GitHub 文件清单与本地按 merge-base 复核一致,仅 3 文件:README.md、scripts/software-flow.mjs、scripts/software-people.mjs,全部落在调度员划定的允许面内。src/、docs/、CLAUDE.md、scripts/e2e-flow.mjs、package.json、pnpm-lock.yaml 的 diff 均为空。software-flow.mjs 的改动逐处判定:

• ACCOUNT 表 +3 行 → 补配置;
• BRANCH_REPORTER / filledByBranchReporter 声明 + 注释 → 补配置;
• pushToApproved 内的 if/else 拆分 → 换填报身份(唯一一处修改既有代码,正是工作项验收标准 1「若脚本以管理员代填分公司单,改为由分公司填报人员填」的直接要求);
• log('T11b', …) → 新增断言。
  无放松既有断言的改动。

2 降级对账:✅ 清单相符(2 条 ⚠️ 描述与代码/实测一致)

• 清单 1.1~1.6(账号 / 岗位 / 组织归属 / 中文姓名 / 幂等 / 清单输出):实跑复现。第一遍 8 步全 OK、18 个账号;第二遍 8 步全 OK、组织归属已分配 — 新增 0 条、流程岗位已分配 — 新增 0 条、到人分工与承接项 新增 0,两遍的「岗位账号清单」输出逐字相同 → 幂等成立。清单里三行为 沈月 / 华东分公司填报人员、黄鹤 / 华南分公司填报人员、秦朗 / 华北分公司填报人员,组织单元列分别为华东 / 华南 / 华北分公司。
• 清单 2.2~2.7(数据范围):REST 独立抽查复现。以 east.reporter@kpi.demo 登录:可见填报单 1 张(华东分公司)、可见明细 4 条且全部属该单;GET 华南填报单 404、GET 华南明细 404、PATCH 华南明细 403 PERMISSION_DENIED。以 east.checker@kpi.demo 登录:PATCH 本分公司明细 403 PERMISSION_DENIED(只能核对不能填)。管理员复核华东四行实际值为 520 / 94.5 / 93 / 1760,与脚本 ACTUALS.bu_sw_east 完全一致 → 数值确由填报人员本人写入,不是管理员补写。
• 清单 2.8 / N.3(判断成立、不改权限集与共享规则):代码侧核实成立。src/services/sharing-service.ts 对每个参与主体写 kpi_entry_sheet 的 unit_and_subordinates + 可写共享,三家分公司本身即 11 个参与主体之一,故本分公司成员天然拿到可编辑共享;src/ 未改一行,与该结论一致。
• ⚠️ 3.3(导入回去在填报人员身份不可达):代码侧有据。src/security/index.ts 的 kpi_dept_reporter_set 对 kpi_entry_line 显式声明 allowCreate: false(注释写明「手工新建的明细没有冻结目标值与权重,算不出分」),与清单描述一致;上报的平台单 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 存在、状态 open、标题与清单所述现象(导入按钮挂在 allowCreate 上、导出文件向导不收、往返不可达)一致。
• ⚠️ 3.8(只读列被改后得分按错值落库):上报的平台单 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 存在、状态 open、标题与清单所述现象(只读字段被剥离持久化但仍进 beforeUpdate,hook 派生列按行里并不存在的数据算出并落库)一致。
• 本次评审按调度员口径未重走导入向导,仅核其上报单存在且描述自洽;结论「导入闭环部分可用、归属平台」有据。
• 全 diff 无 TODO / FIXME、无被注释掉的校验、无比需求少的分支。

3 三禁痕迹:✅ 无
diff 不含 node_modules/ 或任何平台包路径,无 patch 类文件,无 patchedDependencies / resolutions 改动。绕行专项核查:脚本没有用管理员身份冒充分公司填报人员——填报与提交两步在 signIn(reporter) 之后执行,asAdmin() 只用于事后复核读取;T11b 的判据里 own.length > 0(填报人员自己看到的行数)与 filledAll(管理员复核全部有值)双侧都要成立,「空列表每行都填好了」的假通过被显式堵住。

4 硬拍板落地:✅
本 PR 未新建 / 修改任何对象字段,数字字段四件套无适用面。新增用户可见文案过 std-copy 四条红线:姓名「沈月 / 黄鹤 / 秦朗」、岗位显示名「华东(南 / 北)分公司填报人员」全部为中文业务名词,无内部代号、无异常原文;脚本控制台的「流程岗位」列走 POSITION_LABEL 映射输出中文「部门填报人员」,机器名不外露。README 新增段落中出现的 kpi_dept_reporter / kpi_branch_checker 位于面向开发者的「演示种子档案」小节(该节既有内容同样列环境变量与源码路径),不属于用户界面文案,不计红线。

断言 54 → 55 的独立核实

对 base 与 head 的 software-flow.mjs 做断言块级逐字节比对(按 log( 起始、到 ); 结束整块提取):base 54 块、head 55 块;base 的 54 块在 head 中全部存在且逐字节相同(编号、标题、断言表达式、detail 一处未动),差集只有新增的 T11b。开发方「原 54 条一条未改、未删、未放松」属实,+1 为加严方向。实跑 55 PASS / 0 FAIL,其中 T11 仍要求其余 10 张单全部 approved,T11b 要求三家分公司均由本分公司填报人员完成。调度员已裁定接受 55。

发现清单

级别	位置	问题	处置出口
⚪ 记录	scripts/software-flow.mjs pushToApproved 内注释「填不了或提交不了会让这里直接抛错」	scripts/lib/kpi-api.mjs 的 waitUntil 超时只返回 false 并打印一行,不抛错;真正兜底的是 T11b 的 own.length > 0 && filledAll 护栏与 T11 的 approved 断言。注释比实现说得绝对	留痕,不阻塞;下次动该文件时顺手改注释
⚪ 记录	scripts/software-flow.mjs T11b 判据 after.status !== 'draft'	比「必须进入分公司核对中」宽一档;当前流程下两者等价,但语义上不如显式目标状态严	留痕,不阻塞
⚪ 记录	scripts/software-flow.mjs waitUntil 谓词与紧随其后的 own 各列一次明细	多一次 REST 往返,可复用谓词结果	留痕,不阻塞

阻塞(🔴):无。应修(🟡):无。

实跑证据摘要

• pnpm verify exit 0 —— validate / typecheck / vitest 139 passed (7 files) / i18n 528 key 与 schema in sync。
• node scripts/software-people.mjs 第一遍 {"ok":8,"failed":0}、18 个账号;第二遍 {"ok":8,"failed":0} 且各步 新增 0 条。
• node scripts/software-flow.mjs —— 55 PASS / 0 FAIL;T11 十张单全 approved(华东 106.12 / 华南 91.76 / 华北 105.57),T11b 三家分公司均由本分公司填报人员完成。
• REST 抽查见上「专属核查 2」。临时实例与临时目录已清理,dev 进程按 PID 停止。