核对任务批量确认;数据调整与加减分表单只留业务字段、状态默认草稿、新建后不弹抽屉

[baozhoutao]

背景(来源:调度员 2026-09-06 产品走查,维护者以 /os-project-pm-dispatch 放行本批)

分公司核对人员清空「待我核对」队列要逐条走「更多操作 → 确认无误 → 确认」,10 条 30 击,三人合计 90 击(UI 实测 K-5);数据调整、加减分的新建表单把「状态、审批人、审批时间、审批意见、落地时间」暴露给填报人员,「状态」必填无默认值且下拉列出会被 hook 拒绝的值,要试错两次才能建出草稿(K-6),新建成功后弹出记录抽屉挡住「新建」(K-7)。

范围

1. 核对任务批量确认(src/views/index.ts CheckTaskViews.pending):开启多选,bulkActions 挂「确认无误」(spec view.zod.ts 支持 bulkActions: ['<action>'] 逐记录派发);「提出争议」保持单条(理由必填)。若现有确认动作不适合逐记录派发,新增一个同语义动作,状态推进仍走 hook。
2. 数据调整表单收敛(src/views/index.ts AdjustmentViews.formViews):新建/编辑表单只留 填报单、调整的指标明细、调整类型、调整后值、申请理由;status、requested_by、decided_by、decided_at、decision_reason、applied_at、old_value 从可编辑字段移出(记录页只读展示);status 默认「草稿」由 src/hooks/adjustment.hook.ts 在 beforeInsert 补齐(仅当输入未带 status);「调整前值」在保存时由 hook 回填(现状)并在表单选中明细后即时显示——若平台表单不支持联动带出,如实记录。
3. 加减分表单收敛(BonusViews.formViews 与 src/hooks/bonus.hook.ts):同 2,只留 填报单、事项、类型、分值、依据;状态默认草稿;审批字段只读。
4. 新建后不弹记录抽屉:查平台表单 afterSubmit/onSuccess 类配置(spec FormViewSchema 尾部「What happens after a successful submit」),设为回列表;不支持则如实记录并只上报。
5. 文案守 std-copy;新增 label 走 pnpm i18n:extract。

不做

不改核对任务生成范围(#27);不改加减分/调整的审批口径(第 10 章第 6 项);不动 src/hooks/sheet.hook.ts 与计分。

方案分级与放行(调度员)

改已有视图 + 两个 hook 的 beforeInsert 默认值 = 中风险;hook 改动只允许「输入未带 status 时置草稿」这一条,不得改状态机规则。开工前在本单评论列表单字段前后对照与 hook 改动 diff 说明,一致即开工。

验收标准

1. 分公司核对人员在「待我核对」勾选多条一次「确认无误」,10 条 ≤ 4 击;争议仍必须单条填理由;批量确认后核对任务的处理人/处理时间按现状规则(若现状不盖章,如实记录,不在本单修)。
2. 填报人员新建数据调整只填业务字段一次成功,状态为草稿,再「提交审批」;人力审核/负责人审批路径不变;scripts/software-flow.mjs 的调整用例仍 PASS。
3. 人力审核登记加减分同上;负责人审批不变。
4. 新建后不弹抽屉或如实记录平台缺口。
5. pnpm verify 绿;两脚本全 PASS;测试报告(岗位截图 + 点击数前后)与符合度清单挂本单评论,截图走 acceptance-evidence。

测试计划草稿

T1 批量确认 10 条计击 | T2 争议单条必填 | T3 调整表单一次成功 + 审批链 | T4 加减分表单一次成功 + 审批链 | T5 抽屉行为 | T6 两脚本 + verify

[baozhoutao]

• 认领(调度员占坑,2026-09-06):会话 local_0e65d2bc-719b-4314-aae2-351176a17e5f,分支 issue-37 bulk-confirm-forms-,worktree /Users/baozhoutao/GitHub/kpi-issue-37 bulk-confirm-forms-,基线 main @ c197bf4。派发开发子 agent(Opus)。

[baozhoutao]

• 更正:分支名与 worktree 为 issue-37-bulk-confirm-forms / /Users/baozhoutao/GitHub/kpi-issue-37-bulk-confirm-forms(上一条认领评论的名称为脚本拼接笔误)。

[baozhoutao]

开工前方案说明(#37)

基线 main @ c197bf4;worktree issue-37-bulk-confirm-forms,dev 端口 3113,档案 software。下面三段(批量动作实现方式 / 表单字段前后对照 / hook 改动 diff)与本单放行方向核对一致即开工。

0. 改前实测基线(先跑一遍现状,数字不是从需求抄的)

档案数据:方案发布 → 11 张填报单全部填数提交 → 每名分公司核对人员得 10 条「待我核对」(与本单 K-5 的 10 条一致)。

场景	账号	实测击数(改前)	逐步
「待我核对」确认 10 条	高北(华北分公司核对人员)	30	每条 3 击 ×10:①行「更多操作」②「确认无误」③弹窗「确认」
新建数据调整	赵敏(销售经理 / 部门填报人员)	12	①新建 ②填报单选择 ③选中 ④指标明细选择 ⑤选中 ⑥调整类型 ⑦选项 ⑧调整后值 ⑨调整原因 ⑩状态下拉 ⑪选「草稿」 ⑫创建
新建加减分	马丽(人力审核)	11	①新建 ②填报单选择 ③选中 ④事项 ⑤类型下拉 ⑥选「加分」 ⑦分值 ⑧依据 ⑨状态下拉 ⑩选「待审批」 ⑪创建

「状态」下拉在两张表单上都实测到本单说的问题:数据调整列出 草稿 / 待审批 / 已批准 / 已否决,加减分列出 待审批 / 已批准 / 已否决 —— 后两项都会被状态机(initialStates: ['draft'])拒掉,填报人员只有第一项是能建出来的。

K-7 也复现,但表现分两种,由平台按对象字段数决定,不是本项目配的:加减分(10 个字段)新建成功后弹记录抽屉盖住列表和「新建」;数据调整(15 个字段)新建成功后整页跳到记录页。两种都离开了列表。

1. 核对任务批量确认 —— 实现方式

src/views/index.ts 的 CheckTaskViews.listViews.pending 上加两个键:

selection: { type: 'multiple' },
bulkActions: ['kpi_check_confirm'],

• 复用现有动作,不新增。 spec ui/view.zod.ts 的 bulkActions 裸字符串形式就是「逐记录派发」:渲染器按名字在对象动作里找到 kpi_check_confirm,带上它自己的 label、params(核对意见,选填)、visible 谓词,对勾选的每条记录各发一次,recordId 由该行记录带出。动作体一个字没改,状态推进仍然全部落在 src/hooks/check-task.hook.ts(岗位校验、填报单状态校验、盖章、留痕、全部确认后自动推进)—— 本单不动这个 hook。
• visible 谓词 record.status != 'confirmed' 会在派发前逐条过滤,列表已投影 status 列,谓词求得出值。
• 「提出争议」不进 bulkActions,保持行内单条 + 争议内容必填。
• bulkActionDefs 用不上:那是给「一次调用覆盖整个选区」的聚合动作(execution: 'aggregate')和纯数据面批改用的,本项要的是逐条走 hook。

预期改后击数:全选(1)+「确认无误」(1)+ 弹窗执行(1)= 3 击,满足「10 条 ≤ 4 击」。

2. 数据调整表单字段前后对照(AdjustmentViews.formViews.form)

字段	改前(新建/编辑表单)	改后	说明
填报单 sheet	✅ 必填	✅ 必填	保留
调整的指标明细 line	✅ 必填	✅ 必填	保留
调整类型 adjust_type	✅ 必填	✅ 必填	保留
调整后值 new_value	✅ 必填	✅ 必填	保留
调整原因 reason	✅ 必填	✅ 必填	保留
调整前值 old_value	⬜ 表单上有(禁用空框)	❌ 移出	保存时由 hook 按明细回填,记录页只读展示
状态 status	⚠️ 必填下拉、无默认、列非法值	❌ 移出	由 hook beforeInsert 补「草稿」
申请人 requested_by	⬜ 表单上有	❌ 移出	hook 已写当前用户
审批人 decided_by	⬜ 表单上有(禁用)	❌ 移出	记录页只读展示
审批时间 decided_at	⬜ 表单上有(禁用)	❌ 移出	同上
审批意见 decision_reason	⚠️ 可编辑(填报人员能改)	❌ 移出	审批意见由「批准并落地 / 否决」按钮写,不该在申请表单上
落地时间 applied_at	⬜ 表单上有(禁用)	❌ 移出	记录页只读展示

改后表单剩 5 个字段,分区从「调整申请 + 审批」两段收敛成一段。移出 ≠ 删掉:记录详情页的字段清单来自对象定义、不来自表单视图(与此前收敛填报明细表单时同一条路),已实测记录页仍完整显示 调整前值 / 状态 / 审批人 / 审批时间 / 落地时间。

「调整前值」选完明细即时带出:平台做不到,如实记录。 实测选中指标明细后,表单里的「调整前值」仍是空(改前改后都一样)—— 控制台表单没有「按 lookup 选中值回查另一对象字段并回填本表单」的联动能力,ObjectStack 表达这类派生值的正规做法是对象上的公式/汇总字段,而本单「不新增字段」。所以维持现状:保存时由 hook 回填,记录页看得到。这一条会在符合度清单里标 ⚠️ 并挂平台上报链接。

3. 加减分表单字段前后对照(BonusViews.formViews.form)

字段	改前	改后	说明
所属填报单 sheet	✅ 必填	✅ 必填	保留
事项 title	✅ 必填	✅ 必填	保留
类型 bonus_type	✅ 必填	✅ 必填	保留
分值 points	✅ 必填	✅ 必填	保留
依据 reason	✅ 必填	✅ 必填	保留
状态 status	⚠️ 必填下拉、列非法值	❌ 移出	由 hook beforeInsert 补「待审批」(机器值 draft)
计入分值 signed_points	⬜ 表单上有	❌ 移出	hook 按类型算符号,记录页只读展示
审批人 approved_by	⬜ 表单上有(禁用)	❌ 移出	记录页只读展示
审批时间 approved_at	⬜ 表单上有(禁用)	❌ 移出	同上

4. hook 改动 diff(只加「输入未带 status 时置默认」一条,状态机规则一个字不动)

src/hooks/adjustment.hook.ts,beforeInsert 分支内、现有赋值旁边加一行:

     if (ctx.event === 'beforeInsert') {
       input.sheet = line.sheet;
       input.plan = sheet?.plan ?? null;
       input.subject = sheet?.subject ?? null;
       input.old_value = row.adjust_type === 'result' ? toNumber(line.final_score) : toNumber(line.actual_value);
       if (!input.requested_by) input.requested_by = actorId(ctx);
+      if (!input.status) input.status = 'draft';
       return;
     }

src/hooks/bonus.hook.ts,handler 里岗位校验之前加:

     const points = toNumber(row.points) ?? 0;
     input.signed_points = row.bonus_type === 'deduct' ? -points : points;
+    if (ctx.event === 'beforeInsert' && !input.status) input.status = 'draft';

两处都是「仅当输入未带 status」才置值 —— 带了 status 的写入(按钮、脚本、导入)行为完全不变,状态机 transitions / initialStates、岗位校验、归档锁、已批准锁一律不动。requiredBonusPosition() 这个纯函数(单元测试点)也不改。

5. 新建后不弹抽屉 —— 先说结论,实现时以实测为准

查了平台侧:spec FormViewSchema.submitBehavior(thank-you / redirect / continue / next-record)只在表单自己决定跳转时生效;而控制台列表页的「新建」走的是应用外壳的模态表单,它给表单传了 onSuccess 回调,按源码 onSuccess 优先于 submitBehavior,且这个回调的去向由对象的可见字段数算出来(≥12 → 记录页,否则 → 记录抽屉),既不读 submitBehavior,也不读列表视图的 navigation。也就是说本单第 4 项在 17.2.0 上没有元数据开关。

按项目纪律:不绕行(不靠给对象加字段去凑字段数、不改平台包),如实记录 + 只上报 objectstack-ai/objectstack(现象 / 最小复现 / 期望能力 / 平台版本 17.2.0),符合度清单该条标 ⚠️ 并引用上报链接。动手时会再用实测复核一遍这个结论,复核结果照实写进测试报告。

改动面

只动:src/views/index.ts 的 CheckTaskViews / AdjustmentViews / BonusViews 三段、src/hooks/adjustment.hook.ts、src/hooks/bonus.hook.ts、翻译包重生成。不动 src/actions/index.ts(复用现有动作,不需要新增)、不动 sheet.hook.ts / check-task.hook.ts / entry-line.hook.ts / src/lib / src/objects / scripts / docs。

[baozhoutao]

测试报告 · #37 核对任务批量确认;数据调整与加减分表单只留业务字段、状态默认草稿

结论:通过(1 项平台受限,已上报并如实记录)。 6 条测试计划全部执行,T1–T4、T6 通过;T5「新建后不弹抽屉」在 17.2.0 上没有元数据开关,平台侧问题已提 objectstack-ai/objectstack#16381,本单不绕行、不打补丁。

项	值
分支 / 提交	issue-37-bulk-confirm-forms @ b27d441(基线 main @ c197bf4)
环境	本 worktree dev 实例,端口 3113,OS_SEED_PROFILE=software,SQLite 本实例库(截图轮为空库重建)
浏览器	Playwright Chromium 1440×900,locale=zh-CN
账号	陈东 / 林南 / 高北(分公司核对人员)、赵敏(销售经理 · 部门填报人员)、马丽(人力审核)、何平(人力负责人),口令 Passw0rd!23
证据	孤儿分支 acceptance-evidence,目录 issue-37/,commit 4ae42dd6fbaa856f548c8d68f3ce2e174897641e(26 张,已用 contents API 复核)
自测形态	同会话自测(CLAUDE.md H2 声明的降级档:项目暂不具备双实例条件)

点击数前后对照(各自从列表页起计,不含登录)

场景	改前	改后	省
「待我核对」确认 10 条	30 击	4 击	26
新建数据调整(部门填报人员)	12 击	10 击	2
登记加减分(人力审核)	11 击	9 击	2

• 改前 30 击(高北,每条 3 击 ×10):①行「更多操作」②菜单「确认无误」③弹窗「确认」。
• 改后 4 击(陈东,队列 10 条):①表头「全选」②批量条「确认无误」③弹窗「下一步」(核对意见留空)④弹窗「执行」。
• 改前 12 击(赵敏):①新建 ②填报单「选择…」③选中 ④指标明细「选择…」⑤选中 ⑥调整类型下拉 ⑦选项 ⑧调整后值 ⑨调整原因 ⑩状态下拉 ⑪选「草稿」⑫创建。改后 10 击:去掉 ⑩⑪ —— 「状态」不再出现在表单上。
• 改前 11 击(马丽):①新建 ②填报单「选择…」③选中 ④事项 ⑤类型下拉 ⑥选「加分」⑦分值 ⑧依据 ⑨状态下拉 ⑩选「待审批」⑪创建。改后 9 击:去掉 ⑨⑩。

---

T1 批量确认 10 条 —— 通过

改前:列表没有多选框,只有行尾「更多操作」。

改后:表头出现全选框,勾选后底部批量条出现「确认无误」;弹窗先收「核对意见(选填)」,再列出受影响的 10 条二次确认,执行后队列清空。

数据面复核(管理员 REST):华东 10 条全部 confirmed,处理人与处理时间逐条盖章(核对人 陈东 / 核对时间 2026-09-06 12:52),审核记录逐条写入 confirm;3 家分公司全部确认的 7 张填报单自动推进到「人力审核中」—— 批量走的是与单条完全相同的 hook 路径,一条规则也没绕开。

T2 争议仍是单条 + 理由必填 —— 通过

勾选记录后批量条上只有「确认无误」,没有「提出争议」;行内「提出争议」仍是单条弹窗,内容留空点「确认」被当场拦下(「争议内容(必填) 为必填项」),填写后提交成功,意见与处理人一并留痕。

T3 数据调整表单一次成功 + 审批链 —— 通过

改前表单 12 个字段(含状态、申请人、审批人、审批时间、审批意见、落地时间),「状态」必填无默认值,下拉里列着会被状态机拒掉的「已批准」「已否决」;「审批意见」在申请表单上还是可编辑的。

改后只剩 填报单 / 调整的指标明细 / 调整类型 / 调整后值 / 调整原因 五项,一次填完即建成草稿;记录页上「调整前值」已由 hook 按所选明细回填为 60.0000,状态、审批人、审批时间、落地时间照常只读可见。

审批链未变:赵敏「提交审批」→ 待审批 → 马丽(人力审核)「批准并落地」→ 已批准;审批人 / 审批时间 / 落地时间 / 审批意见全部落库。

T4 加减分表单一次成功 + 审批链 —— 通过

改前 9 个字段;改后只剩 所属填报单 / 事项 / 类型 / 分值 / 依据 五项,一次建成「待审批」,计入分值由 hook 按类型算出。何平(人力负责人)批准后盖章,岗位分离规则未变。

状态机没有被放宽(负面用例,REST 直发):

调整   · 带 status=approved 直接新建 → 400 invalid_initial_state「调整申请只能按「草稿 → 待审批 → 已批准 / 已否决」推进。」
调整   · 不带 status 新建            → 201 状态=draft
加减分 · 带 status=approved 直接登记 → 400 invalid_initial_state「加减分只能从「待审批」变为「已批准」或「已否决」。」
加减分 · 不带 status 登记            → 201 状态=draft,计入分值=-2

hook 只补空缺,带了状态的写入行为一个字没变。

T5 新建后的抽屉行为 —— 平台受限,如实记录

改前实测两种表现,都由平台按对象的可见字段数决定:加减分(10 个字段)新建后弹记录抽屉盖住列表与「新建」;数据调整(15 个字段)新建后整页跳记录页。

按本单第 4 项查了 spec 的 FormViewSchema.submitBehavior,并实测验证:在 BonusViews.formViews.form 上显式声明 submitBehavior: { kind: 'continue' },pnpm validate 通过且无告警,重启后新建加减分照样弹抽屉,声明完全无效(该探针已回滚,不在提交里)。

读 @objectstack/console@17.2.0 产物可以对上:列表「新建」由应用外壳渲染成 formType: 'modal' 并传入 onSuccess,而表单的提交处理是 if (e.onSuccess) … else if (e.submitBehavior) … —— onSuccess 短路了 submitBehavior;那个 onSuccess 的去向由 recordSurface(objectDef) 按「可见字段数 ≥ 12 → 记录页,否则 → 抽屉」算出,既不读 submitBehavior,也不读列表视图的 navigation。没有任何元数据开关。

按项目纪律停手:不改平台包、不给对象凑字段数绕行、不降级冒充完成。已上报 objectstack-ai/objectstack#16381(现象 / 最小复现 / 期望能力 / 平台版本 17.2.0)。改后行为与改前一致,没有回退。

T6 两脚本 + verify —— 通过

pnpm verify               → validate ✓ / typecheck ✓ / vitest 139 passed (7 files) ✓ / i18n 新鲜度 ✓
scripts/software-flow.mjs → {"passed":55,"failed":0}   (含 T13a/b 加减分、T14a/b 数据调整用例)
scripts/e2e-flow.mjs      → {"passed":74,"failed":0}

两脚本各在空库重建的实例上跑(software 与默认两个档案各重建一次,rm -rf dist 后重启)。

回归:待办工作台

工作台「待我核对」区块(待办工作台的产物)不受影响:10 条待办正常列出,行操作菜单照常。

未覆盖 / 需要说明

• 「调整前值」在选中明细后不即时带出(保存后才有值)。改前改后一致,不是本次引入;控制台表单没有跨对象联动回填能力,而本单不新增字段。详见符合度清单第 2.4 条。
• 批量确认的「核对意见」是一份意见套给整个选区(动作自身的选填参数),本轮实测留空执行;需要逐条不同意见时仍可走行内单条。

[baozhoutao]

需求符合度清单 · #37

逐条对照本单正文的每个要求(触发操作、每个字段、每条校验、输出反馈、每条验收标准),三态标注。测试报告见上一条评论。

1. 核对任务批量确认(正文 §范围 1)

#	要求	态	说明
1.1	CheckTaskViews.pending 开启多选	✅	selection: { type: 'multiple' };实测表头出现全选框,底部出现「已选择 N 项」批量条
1.2	bulkActions 挂「确认无误」	✅	bulkActions: ['kpi_check_confirm'],spec 的裸字符串形式(逐记录派发)
1.3	逐记录派发(不是聚合调用)	✅	未用 bulkActionDefs;实测 10 条各自落库,decided_by / decided_at 逐条盖章,审核记录逐条写入
1.4	「提出争议」保持单条、理由必填	✅	未进 bulkActions;批量条上只有「确认无误」;行内单条弹窗,内容留空被拦下
1.5	状态推进仍走 hook	✅	动作体一个字未改,check-task.hook.ts 未改;岗位校验 / 填报单状态校验 / 盖章 / 留痕 / 全部确认后自动推进全部照常(7 张填报单自动进入「人力审核中」)
1.6	「若现有动作不适合逐记录派发,新增同语义动作」	✅	现有 kpi_check_confirm 适合逐记录派发,故未新增动作,src/actions/index.ts 零改动 —— 正文允许的两条路里选了不新增的那条

2. 数据调整表单收敛(正文 §范围 2)

#	要求	态	说明
2.1	新建/编辑表单只留 填报单、调整的指标明细、调整类型、调整后值、申请理由	✅	实测表单 label 恰为这五项
2.2	status / requested_by / decided_by / decided_at / decision_reason / applied_at / old_value 移出可编辑字段	✅	七项全部移出;decision_reason 原来在申请表单上可编辑,一并移出
2.3	上述字段在记录页只读展示	✅	记录详情页字段清单来自对象定义,不来自表单视图;实测记录页仍显示 调整前值 60.0000 / 状态 / 审批人 / 审批时间 / 落地时间 / 审批意见
2.4	「调整前值」在表单选中明细后即时显示	⚠️	平台做不到,如实记录(正文明确允许这一出口)。控制台表单没有「按 lookup 选中值回查另一对象字段并回填本表单」的联动能力;实测选中明细后该框仍为空,改动前后一致,不是本次引入。ObjectStack 表达这类派生值的正规做法是对象上的公式/汇总字段,而本单「不新增字段」。维持现状:保存时由 hook 回填,记录页只读展示(2.3 已验)。出口:正文 §范围 2 的「若平台表单不支持联动带出,如实记录」
2.5	status 默认「草稿」由 adjustment.hook.ts 在 beforeInsert 补齐	✅	加一行 if (!input.status) input.status = 'draft';
2.6	仅当输入未带 status 时补	✅	负面用例:带 status=approved 直接新建仍被状态机以 invalid_initial_state 拒(400)

3. 加减分表单收敛(正文 §范围 3)

#	要求	态	说明
3.1	表单只留 填报单、事项、类型、分值、依据	✅	实测表单 label 恰为这五项
3.2	状态默认草稿	✅	bonus.hook.ts beforeInsert 补 draft(界面文案「待审批」);实测一次建成
3.3	审批字段只读	✅	status / signed_points / approved_by / approved_at 移出表单,记录页只读可见
3.4	仅当输入未带 status 时补	✅	负面用例:带 status=approved 直接登记仍被拒(400)

4. 新建后不弹记录抽屉(正文 §范围 4)

#	要求	态	说明
4.1	查平台表单 afterSubmit/onSuccess 类配置,设为回列表	❌	平台能力受限,不绕行、只上报。17.2.0 上列表「新建」这条路径不读 form view 的 submitBehavior:实测显式声明 submitBehavior: { kind: 'continue' },pnpm validate 通过且无告警,新建后照样弹抽屉(截图见测试报告 T5)。去向由 recordSurface(objectDef) 按「对象可见字段数 ≥ 12 → 记录页,否则 → 抽屉」算出,既不读 submitBehavior 也不读列表视图 navigation,没有元数据开关。出口 = 平台能力受限 → 上报记录:objectstack-ai/objectstack#16381(含现象、最小复现、期望能力、平台版本 17.2.0)。正文本项已写明「不支持则如实记录并只上报」
4.2	不因此回退现有行为	✅	改后与改前一致(加减分弹抽屉、数据调整跳记录页),没有新增回退

5. 文案与元数据规范(正文 §范围 5)

#	要求	态	说明
5.1	文案守 std-copy 四条红线	✅	本次未新增任何用户可见文案:批量按钮直接复用动作已有的中文 label「确认无误」与参数 label「核对意见(选填)」;表单只做字段删减,未改 label
5.2	新增 label 走 pnpm i18n:extract	✅	已重新生成 src/translations/zh-CN.objects.generated.ts(删掉随「审批」分区一起消失的 3 个词条),pnpm i18n:extract:check 新鲜度门禁通过
5.3	数字字段四件套	✅	本单不新增字段,src/objects/ 零改动

6. 不做清单(正文 §不做)

#	要求	态	说明
6.1	不改核对任务生成范围	✅	sheet.hook.ts 零改动
6.2	不改加减分/调整的审批口径(第 10 章第 6 项)	✅	requiredBonusPosition() 与两个 hook 的审批分支一字未动;e2e 的 T59/T66/T68 岗位分离用例全 PASS
6.3	不动 sheet.hook.ts 与计分	✅	src/lib/scoring.ts、sheet.hook.ts 零改动

7. 验收标准逐条

#	验收标准	态	说明
7.1	勾选多条一次「确认无误」,10 条 ≤ 4 击	✅	实测 4 击(改前 30)
7.2	争议仍必须单条填理由	✅	批量条不含争议;单条留空被拦下
7.3	批量确认后处理人/处理时间按现状规则	✅	逐条盖章(核对人 陈东 / 核对时间),现状规则就盖章,无需在本单修
7.4	填报人员新建数据调整只填业务字段一次成功、状态为草稿,再「提交审批」	✅	10 击一次建成草稿,提交审批成功
7.5	人力审核/负责人审批路径不变	✅	调整由人力审核「批准并落地」;加减分由人力负责人批准;两条链实测走通
7.6	scripts/software-flow.mjs 的调整用例仍 PASS	✅	55/55 全 PASS(T14a 源数据调整、T14b 结果调整均 PASS)
7.7	人力审核登记加减分同上;负责人审批不变	✅	9 击一次建成待审批;何平批准成功
7.8	新建后不弹抽屉,或如实记录平台缺口	⚠️	走「如实记录」这一支,上报 objectstack-ai/objectstack#16381(同 4.1)
7.9	pnpm verify 绿	✅	validate / typecheck / vitest 139 / i18n 新鲜度 全过
7.10	两脚本全 PASS	✅	software-flow 55/55、e2e-flow 74/74
7.11	测试报告与符合度清单挂本单评论,截图走 acceptance-evidence	✅	本条与上一条评论;证据 commit 4ae42dd6fbaa856f548c8d68f3ce2e174897641e,26 张,已用 contents API 复核

非 ✅ 条目汇总(共 2 条,同一个根因,同一个出口)

条目	态	出口	记录链接
2.4 「调整前值」选中明细后即时显示	⚠️	平台能力受限 → 如实记录(正文明确允许)	objectstack-ai/objectstack#16381 一并覆盖表单侧的联动缺口;现状「保存时回填 + 记录页只读展示」已验证可用,不影响业务闭环
4.1 / 7.8 新建后不弹记录抽屉	❌ / ⚠️	平台能力受限 → 只上报,不绕行	objectstack-ai/objectstack#16381(现象 + 最小复现 + 期望能力 + 版本 17.2.0);最小复现已在本地实测验证(声明 submitBehavior 后行为无变化)

两条都不是「先简化实现」:2.4 的现状能力(保存时回填 + 记录页展示)是本单正文点名认可的兜底;4.1 在 17.2.0 上不存在任何合法的元数据路径,唯一的替代是改平台包或给对象凑字段数,都是本项目明令禁止的绕行。

[baozhoutao]

交接验收侧 @baozhoutao。

PR:https://github.com/objectstack-ai/kpi/pull/42(分支 issue-37-bulk-confirm-forms @ b27d441,基线 main @ c197bf4;正文不含自动关闭关键字,开发侧不自行合并)
状态:status:自测报告中 → status:PR审查中

• 测试报告:核对任务批量确认;数据调整与加减分表单只留业务字段、状态默认草稿、新建后不弹抽屉 #37 (comment)
• 需求符合度清单:核对任务批量确认;数据调整与加减分表单只留业务字段、状态默认草稿、新建后不弹抽屉 #37 (comment)
• 证据:acceptance-evidence 分支 issue-37/,commit 4ae42dd6fbaa856f548c8d68f3ce2e174897641e(26 张)

需要验收侧留意的一项:正文第 4 项「新建后不弹记录抽屉」在平台 17.2.0 上没有元数据开关(实测声明 submitBehavior 无效),已按纪律停手并上报 objectstack-ai/objectstack#16381,本单未绕行、未回退。符合度清单里标为非 ✅ 并附了出口。