Skip to content

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

Open
Open
核对任务批量确认;数据调整与加减分表单只留业务字段、状态默认草稿、新建后不弹抽屉#37
Assignees
baozhoutao
Labels
P2status:PM验收中

Description

@baozhoutao
baozhoutao
opened on Sep 6, 2026

背景(来源:调度员 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

Activity

  1. baozhoutao
    self-assigned this
    on Sep 6, 2026
  2. baozhoutao
    added
    status:待开发
    P2
    status:AI开发中
    and removed
    status:待开发
    on Sep 6, 2026

  3. baozhoutao commented on Sep 6, 2026

    @baozhoutao
    baozhoutao
    on Sep 6, 2026
    ContributorAuthor
    • 认领(调度员占坑,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)。

  4. baozhoutao commented on Sep 6, 2026

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

  5. baozhoutao commented on Sep 6, 2026

    @baozhoutao
    baozhoutao
    on Sep 6, 2026
    ContributorAuthor

    开工前方案说明(#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。

  6. baozhoutao commented on Sep 6, 2026

    @baozhoutao
    baozhoutao
    on Sep 6, 2026
    ContributorAuthor

    测试报告 · #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 条二次确认,执行后队列清空。

    改后-已开多选
    改后-全选10条
    改后-核对意见选填
    改后-受影响10条二次确认
    改后-4击后队列清空

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

    改后-10条全部已确认并盖章

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

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

    批量条不含提出争议
    提出争议仍是单条弹窗
    争议内容留空被拦下

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

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

    改前-数据调整表单12字段
    改前-状态下拉含非法值

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

    改后-只剩5个业务字段
    改后-一次建成草稿-调整前值已回填

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

    数据调整审批链-已批准并落地

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

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

    改前-加减分表单9字段
    改前-状态下拉含非法值
    改后-只剩5个业务字段
    改后-一次建成待审批
    由人力负责人批准

    状态机没有被放宽(负面用例,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 通过且无告警,重启后新建加减分照样弹抽屉,声明完全无效(该探针已回滚,不在提交里)。

    声明submitBehavior-continue后仍弹抽屉

    读 @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 条。
    • 批量确认的「核对意见」是一份意见套给整个选区(动作自身的选填参数),本轮实测留空执行;需要逐条不同意见时仍可走行内单条。

  7. baozhoutao commented on Sep 6, 2026

    @baozhoutao
    baozhoutao
    on Sep 6, 2026
    ContributorAuthor

    需求符合度清单 · #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 上不存在任何合法的元数据路径,唯一的替代是改平台包或给对象凑字段数,都是本项目明令禁止的绕行。

  8. baozhoutao
    added
    status:自测报告中
    status:PR审查中
    and removed
    status:AI开发中
    status:自测报告中
    on Sep 6, 2026

  9. baozhoutao commented on Sep 6, 2026

    @baozhoutao
    baozhoutao
    on Sep 6, 2026
    ContributorAuthor

    交接验收侧 @baozhoutao。

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

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

  10. baozhoutao
    added a commit that references this issue on Sep 6, 2026

    Merge pull request #42: bulk check confirmation; adjustment and bonus…

    b94a4a6

  11. baozhoutao commented on Sep 6, 2026

    @baozhoutao
    baozhoutao
    on Sep 6, 2026
    ContributorAuthor

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

  12. baozhoutao
    added
    status:PM验收中
    and removed
    status:PR审查中
    on Sep 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P2status:PM验收中

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions