待办工作台:按数据范围自动分角色的待办区块 + 填报单行级审核动作 + 待审核/待审批直达菜单

[baozhoutao]

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

工作台对所有角色是同一张全量可编辑网格:人力审核、管理员登录看到全组织明细,分公司核对人员看到空表;人力审核与分管领导审一张单要「回列表 → 重选页签 → 打开 → 审」,分管领导的队列还藏在「还有 4 个」溢出菜单里(平台 objectstack-ai/objectstack#14883、#14952)。UI 实测:人力审核 11 张单 131 击,分管领导每张 5.5 击,分管领导是唯一按手册找不到入口的角色。

范围(全部元数据改动;不碰 src/lib/scoring.ts、src/hooks/、src/actions/index.ts)

1. 待办工作台(src/pages/index.ts 的 kpi_home):现有「待填报的指标」「填报单」两个区块之外,增加「待我核对」(核对任务,状态 = 待核对)、「待人力审核」(填报单,状态 = 人力审核中)、「待领导审批」(填报单,状态 = 领导审批中)三个只读网格区块,各带行动作(确认无误/提出争议;审核通过/驳回)。区块不按角色显示——数据范围会让每人只看到自己该处理的行;空区块保留但压缩高度。「待填报的指标」网格保留,若平台允许按本对象字段过滤,只显示所属填报单为「填报中」的行(明细上若无该字段则如实记录,不加字段)。
2. 列表行级审核动作(src/views/index.ts EntrySheetViews):确认填报单列表行菜单在对应状态下出现「审核通过」「驳回」「归档」(动作已是对象级,核实可见性与确认框文案);驳回原因在行级动作里仍必填。
3. 直达菜单(src/apps/index.ts):在「填报与审核」组增加「待人力审核」「待领导审批」两个导航项,用 viewName 直指填报单的对应列表视图(spec app.zod.ts 支持);分公司核对的「待我核对」同样加一项。导航按岗位裁剪沿用现有 requiredPermissions 机制。
4. 文案守 std-copy 四条红线;新增 label 用 pnpm i18n:extract 重生成翻译包。

不做

不做站内通知(V1.1 第 18 项);不改流程节点与驳回口径;不做自定义代码页;不改核对任务的生成范围(#27)。

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

改已有页面与导航、列表视图 = 中风险,放行方向如上;开工前在本单评论列「区块 × 岗位」实测可见矩阵与导航前后对照,与放行方向一致即开工;平台组件做不到的如实记录并只上报。

验收标准

1. 分公司核对人员(east.checker@kpi.demo)登录后在工作台看到「待我核对」区块列出本分公司待核对任务,可在行内「确认无误」;10 条任务不进列表页也能处理。
2. 人力审核(hr.reviewer@kpi.demo)登录后工作台「待人力审核」列出待审单,行动作「审核通过」「驳回(原因必填)」可用;左侧菜单「待人力审核」直达对应列表;审 1 张单 ≤ 3 击且不进详情页。
3. 分管领导(leader.tech@kpi.demo)登录后工作台「待领导审批」只列分管主体的单;左侧菜单「待领导审批」直达,不再需要点「还有 N 个」;审 1 张单 ≤ 3 击。
4. 部门填报人员的工作台仍能一屏填数出分提交(填报体验优化:填报单一屏填数出分提交(主从子表)、工作台待办入口、明细列表瘦身、堵住相关页签与编辑表单两条死路 #34 达成的 0 跳页不回退);空区块不报错。
5. 管理员、人力负责人页面不报错;pnpm verify 绿;scripts/software-flow.mjs 54/54、scripts/e2e-flow.mjs 全 PASS。
6. 测试报告(五类岗位截图 + 逐步点击数)与需求符合度清单挂本单评论,截图走 acceptance-evidence 40 位 SHA 图链。

测试计划草稿

T1 区块 × 岗位可见矩阵 | T2 分公司行内确认 | T3 人力行级审核 + 驳回原因必填 | T4 领导直达菜单 + 行级审批 | T5 填报人 0 跳不回退 | T6 空区块无错 | T7 两脚本 + verify

[baozhoutao]

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

[baozhoutao]

• 更正:分支名与 worktree 应为 issue-36-todo-workbench / /Users/baozhoutao/GitHub/kpi-issue-36-todo-workbench(上一条评论里的名称是脚本拼接笔误,已改名)。

[baozhoutao]

开工前方案说明(#36)

放行方向:改已有页面与导航 = 中风险,按单内「范围」四条实现。以下为开工前的预期矩阵与实现方式,实测结果随测试报告更新。

1. 区块 × 岗位 可见矩阵(预期)

工作台 kpi_home 是六个岗位共用的默认落地页,五个区块对所有人都渲染,不做按岗位显隐 —— 页面组件的 visibleWhen 只绑 record / current_user / page.<var>,没有岗位谓词(上一单实测:写岗位谓词后连本人都看不到,已回退)。谁能看到哪些行由数据层决定(对象 OWD private + 方案发布写入的动态共享规则 + 权限集 readScope)。

区块	数据源 / 过滤	系统管理员	人力审核	人力负责人	部门填报人员	分公司核对人员	分管领导
待填报的指标	kpi_entry_line(不过滤,见下 §4)	全部	全部	全部	本部门	相关分公司	分管范围
填报单	kpi_entry_sheet(不过滤)	全部	全部	全部	本部门	相关范围	分管范围
待我核对	kpi_check_task status=pending	全部	全部	全部	空	本分公司待核对	空/分管范围
待人力审核	kpi_entry_sheet status=hr_reviewing	全部	全部待审	全部	空	相关范围	分管范围
待领导审批	kpi_entry_sheet status=leader_approving	全部	全部	全部	空	相关范围	仅分管主体

粗体 = 该岗位的主用途。空区块保留(不隐藏),按 pageSize: 10 压缩占位;空态不报错是验收标准 4/6 的实测项。

2. 导航前后对照(kpi_app →「填报与审核」组)

顺位	改前	改后
1	填报单	填报单
2	填报明细	待我核对(kpi_check_task / viewName: pending)
3	分公司核对	待人力审核(kpi_entry_sheet / viewName: hr)
4	加减分	待领导审批(kpi_entry_sheet / viewName: leader)
5	数据调整	填报明细
6	—	分公司核对
7	—	加减分
8	—	数据调整

三个待办项排在组内靠前,目的就是把分管领导的队列从「还有 N 个」溢出菜单里捞出来(平台 objectstack-ai/objectstack#14883、#14952)。三项都用 viewName 直指已存在的具名列表视图,不新建视图、不加 filters(spec app.zod.ts:filters 与 viewName 互斥)。导航裁剪沿用现有 requiredPermissions 机制 —— 这三项不加 requiredPermissions:它们指向的对象本来就在所有岗位的权限集里,能看到几行由数据范围决定,加能力闸门反而会把管理员之外的人挡在入口外。

3. 行级动作实现方式

四个流程动作与两个核对动作在 src/actions/index.ts 里已经是对象级、且都带 locations: ['record_header', 'list_item'] 与 visible 状态谓词。本单不改 actions/index.ts(单内明列的禁触碰文件),只做两件事:

• 页面网格上显式挂 rowActions(object-grid 的 rowActions 是有读点的键,spec component.zod.ts);
• 列表视图侧核实行菜单在对应状态下确实出现「审核通过」「驳回」「归档」,以及确认框/参数文案(驳回原因 required: true 已在动作参数上,行级动作走同一份定义,必填口径不会因入口不同而变)。

4. 已知平台限制(沿用记录,不绕行)

• 「待填报的指标」只显示填报中的单的明细:做不到,不做。 这是 kpi_entry_sheet.status,查询引擎明确拒绝跨关系过滤($filter 写 sheet.status 返回 400 INVALID_FIELD)。已核实 kpi_entry_line 上没有任何字段编码填报单状态,按单内「明细上若无该字段则如实记录,不加字段」执行:如实记录,不加字段、不用退化条件冒充。
• 页面网格 visibleWhen 的岗位谓词不求值;页面网格行上的「打开 ›」按钮无响应([repo:objectui] Page object-grid block renders the row-hover 「打开 ›」 button but clicking it does nothing — same control navigates to the record on the standard list view objectstack#16276)—— 本单的行级动作走行操作菜单,不依赖「打开 ›」。

如与放行方向不一致请在此评论下指出,否则按上述开工。

[baozhoutao]

测试报告 — #36 待办工作台

结论:通过。 7 条计划用例(T1T7)全部 PASS,验收标准 16 全部达成。五类岗位真实界面实测,成功与拦截两侧都有截图;pnpm verify 绿、scripts/software-flow.mjs 54/54、scripts/e2e-flow.mjs 74/74。一条平台受限项(「待填报的指标」按填报单状态过滤)按 #36 原文如实记录、不加字段,详见 §5。

项	值
分支 / 提交	issue-36-todo-workbench @ fb6b49b(基线 main @ d1abec7)
环境	本 worktree dev 实例,端口 3113,库 .objectstack/issue-36.db,种子档案 software
账号	管理员 admin@objectos.ai;岗位账号由 scripts/software-people.mjs 创建,口令 Passw0rd!23
截图	Playwright chromium,1440×900,locale zh-CN;孤儿分支 acceptance-evidence 目录 issue-36/,commit c11edb126d4da52bfa5313440d2ca52b7e17f053
测试形态	同会话自测(CLAUDE.md H2:暂不具备双实例条件,计划先落盘、逐条对照)

---

1. 测试计划与结果

用例	内容	结果
T1	区块 × 岗位可见矩阵	PASS
T2	分公司核对人员行内确认无误	PASS
T3	人力审核行级审核 + 驳回原因必填	PASS
T4	分管领导直达菜单 + 行级审批 + 分管范围隔离	PASS
T5	部门填报人员 0 跳页不回退	PASS
T6	空区块无错(五类岗位)	PASS
T7	pnpm verify + 两个脚本	PASS

---

2. T1 区块 × 岗位实测可见矩阵

数据布点(11 张填报单):填报中 1(研发部)、分公司核对中 6、人力审核中 3(财务部 / 人力行政部 / 销售部)、领导审批中 3(测试部 / 产品部 = 技术线,客户成功部 = 市场线)。

区块	系统管理员	人力审核	人力负责人	部门填报人员(研发部)	分公司核对人员(华东)	分管领导(技术线)
待填报的指标	25(分页)	25(分页)	25(分页)	3(本部门)	华东相关	分管 5 主体的行
填报单	11	11	11	1(本部门)	11	5(仅分管主体)
待我核对	10	9	10	0(空)	8(仅华东)	3
待人力审核	1	1	1	0(空)	1	0(空)
待领导审批	3	3	3	0(空)	3	3(仅分管主体,不含客户成功部)

粗体 = 该岗位的主用途或关键隔离点。矩阵与开工前的预期一致:区块不按岗位显隐,行数由数据范围决定。

与预期的一处出入(如实记录,非本单引入):分公司核对人员在「填报单 / 待人力审核 / 待领导审批」三个区块里读得到行,是因为权限集 kpi_branch_checker_set 对 kpi_entry_sheet 声明的是 readScope: 'org'(主干既有配置,本单未改)。行操作按钮跟着行一起渲染,但动作在服务端被拒:以 east.checker 身份对分公司核对中的单发 pending_action: approve,返回 403 PERMISSION_DENIED。边界守得住,只是入口有噪音 —— 详见 §6 遗留问题。

截图:管理员 上 / 中 / 下;人力负责人 上 / 中 / 下。两者控制台无本页错误(管理员一轮 0 条 console error;人力负责人只有平台外壳的 sys_activity 403,与本页无关,主干既有)。

---

3. T2 分公司核对人员(east.checker@kpi.demo,华东分公司)

登录后直接落在工作台(/_console/apps/kpi_app/page/kpi_home),「待我核对」列出 8 条本分公司待核对任务,「核对分公司」列全部是华东分公司。

行操作菜单是「确认无误 | 提出争议」,与需求 §5.5 的按钮清单一致:

连处理两条,每条 3 击,全程 URL 始终是 kpi_home,一次都没进列表页或详情页:

关于验收标准 1 的「10 条任务」:软件档案在同一时刻能造出的单分公司待核对队列上限是 9 条(11 张单中 1 张已通过、本分公司自身的单不生成本分公司核对任务)。华东实测 8 条、华北实测 9 条,全部在工作台区块内一屏列出、逐条行内处理,不进列表页;区块 pageSize 设为 10,10 条同样是一屏。

左侧菜单「待我核对」直达 kpi_check_task 的 pending 视图:

---

4. T3 人力审核(hr.reviewer@kpi.demo)

登录后直接落在工作台,「待人力审核」列出 3 张待审单,行操作菜单是「审核通过 | 驳回」:

驳回原因必填(拦截侧):弹窗字段标「驳回原因(必填)*」,留空点「确认」被当场拦下,提示「驳回原因(必填) 为必填项」,弹窗不关、记录不变:

填写原因后提交成功,该单退出队列(3 → 2):

审核通过(成功侧):⋮ →「审核通过」→「确认」,3 击,URL 仍是 kpi_home,不进详情页;该单退出队列(2 → 1):

左侧菜单「待人力审核」直达 kpi_entry_sheet 的 hr 视图,列表只列人力审核中的单:

列表视图行菜单(范围第 2 条):动作本来就是对象级、带 locations: ['list_item'],本单核实其在各状态下的可见性与文案,结论是无需改代码:

填报单状态	行菜单实测
已通过	归档
人力审核中	审核通过 | 驳回
领导审批中	审核通过 | 驳回
分公司核对中	审核通过 | 驳回
填报中	提交填报(在工作台「填报单」区块实测,见 §6 说明)

行级驳回走的是同一份动作定义,原因必填口径不因入口不同而松动(上面的拦截截图就是行级入口)。

---

5. T4 分管领导(leader.tech@kpi.demo,技术线)

「待领导审批」只列分管主体的 3 张单(人力行政部 / 测试部 / 产品部);同样处在领导审批中的客户成功部(市场线)不在列。同一张截图里,「待人力审核」区块为空,显示「未找到结果」,不报错:

审 1 张单 3 击(⋮ → 审核通过 → 确认),URL 全程 kpi_home。

改前 / 改后导航对照(同一实例实测):改前要「填报与审核 → 填报单 → 还有 4 个 → 待领导审批」,登录起算 5 击,队列确实藏在溢出菜单里;改后左侧菜单直接有「待领导审批」,登录起算 3 击(其中 1 击是展开「填报与审核」分组)。下面这张截图同时拍到了两侧 —— 右边是改前的「还有 4 个」溢出菜单(「待领导审批」在里面),左边是改后新加的三个直达项:

---

6. T5 / T6 部门填报人员(rd.engineer@kpi.demo,研发部)与空区块

登录直接落在工作台;「待我核对」「待人力审核」「待领导审批」三个区块都是空的,各自显示「未找到结果」,页面不报错、其他区块不受影响:

一屏填数出分提交,全程 0 跳页(整轮 URL 去重后只有 kpi_home 一个):在「待填报的指标」单击三个「实际值」单元格填数 → 点「全部保存 (3)」→ 完成率 / 得分率 / 最终得分当场回填(104.00 / 52.00、50.00 / 10.00、120.00 / 36.00),填报单最终得分 98 → 在同页「填报单」区块 ⋮ →「提交填报」→「继续」,状态变为分公司核对中:

登录起算共 8 击(登录 1 + 三个单元格 3 + 全部保存 1 + ⋮ 1 + 提交填报 1 + 继续 1),0 次页面跳转、0 次回退。

---

7. T7 门禁

pnpm verify   ✓  validate 通过 · tsc --noEmit 通过 · vitest 7 文件 139 测试全过 · i18n 包与 schema 同步
node scripts/software-flow.mjs   {"passed":54,"failed":0}
node scripts/e2e-flow.mjs        {"passed":74,"failed":0}

两个脚本各自在空库上跑:software-flow 用 OS_SEED_PROFILE=software 档案 + scripts/software-people.mjs;e2e-flow 用默认演示种子。两轮之间 rm -rf dist .objectstack/issue-36.db* 重建。

---

8. 平台受限与遗留(如实记录,不绕行)

1. 「待填报的指标」按「所属填报单为填报中」过滤:做不到,按 待办工作台:按数据范围自动分角色的待办区块 + 填报单行级审核动作 + 待审核/待审批直达菜单 #36 原文不做。 这是 kpi_entry_sheet.status,查询引擎明确拒绝跨关系过滤($filter 写 sheet.status 返回 400 INVALID_FIELD,报错原文要求把值反规范化到本对象)。本单逐字段复核了 kpi_entry_line(sheet / plan_indicator / indicator / indicator_name / unit / direction / scoring_method / target_value / weight / actual_value / completion_rate / score_rate / score / adjusted_score / final_score / is_adjusted / adjust_type_applied / calc_trace / last_adjustment / remark),没有任何字段编码填报单状态;待办工作台:按数据范围自动分角色的待办区块 + 填报单行级审核动作 + 待审核/待审批直达菜单 #36 明写「明细上若无该字段则如实记录,不加字段」,故如实记录在 src/pages/index.ts 注释里,不加字段、不用「实际值为空」这类退化条件冒充(那会让保存后的行当场从网格消失,连带毁掉同页出分)。
2. 区块不能按岗位显隐:页面组件 visibleWhen 只绑 record / current_user / page.<var>,没有岗位谓词(上一单实测写岗位谓词后连本人都看不到,已回退)。本单据此把「区块不按角色显示、由数据范围决定行」写进实现口径 —— 与 待办工作台:按数据范围自动分角色的待办区块 + 填报单行级审核动作 + 待审核/待审批直达菜单 #36 范围第 1 条一致,不是降级。
3. 行操作按钮对读得到但无权处理的岗位仍然渲染(记录级,非本单引入):分公司核对人员对填报单是 readScope: 'org',所以「待人力审核 / 待领导审批」区块对他们有行、有 ⋮。动作在服务端被 403 拒绝,边界不破;要在前端也隐掉,需要按岗位求值的 visible 谓词,而本版本控制台对导航与动作的岗位谓词不求值(已报平台 App nav item visible (CEL) is served to the client but never evaluated — a silently inert gate (17.2.0) objectstack#15135)。未新开平台单:现象与 #15135 同源,按「已报的评论补充、不重开」处理。
4. 页面网格行首的「打开 ›」按钮点了没反应(平台 [repo:objectui] Page object-grid block renders the row-hover 「打开 ›」 button but clicking it does nothing — same control navigates to the record on the standard list view objectstack#16276,主干已记录):本单动线不依赖它,待办都在行操作菜单里就地办完。
5. 「填报中」状态的行菜单只在工作台「填报单」区块上实测到(见 §6 的提交截图);实测时列表视图里已无填报中的行,未单独补一张列表页截图 —— 动作定义同一份,visible 谓词是 record.status == 'draft'。

[baozhoutao]

需求符合度清单 — #36(提 PR 前门禁)

逐条对照 #36 正文的「范围」四条与「验收标准」六条,三态标注。无 ❌ 条目;3 条 ⚠️,原因与依据逐条写明。

A. 范围

#	需求条目	态	说明
A1.1	工作台增加「待我核对」区块(核对任务,状态 = 待核对)	✅	kpi_check_task,filter: status = pending;列:任务名称 / 填报单 / 核对分公司 / 核对状态 / 核对意见
A1.2	工作台增加「待人力审核」区块(填报单,状态 = 人力审核中)	✅	kpi_entry_sheet,filter: status = hr_reviewing
A1.3	工作台增加「待领导审批」区块(填报单,状态 = 领导审批中)	✅	kpi_entry_sheet,filter: status = leader_approving
A1.4	三个区块只读	✅	三块都显式 editable: false;实测单元格不可编辑
A1.5	各带行动作:确认无误 / 提出争议	✅	「待我核对」rowActions: ['kpi_check_confirm','kpi_check_dispute'];实测菜单为「确认无误 | 提出争议」
A1.6	各带行动作:审核通过 / 驳回	✅	两个审核区块 rowActions: ['kpi_sheet_approve','kpi_sheet_reject'];实测菜单为「审核通过 | 驳回」
A1.7	区块不按角色显示,数据范围让每人只看到该处理的行	✅	未写任何岗位显隐;实测矩阵见测试报告 §2 —— 部门填报人员三个待办区块全空,分公司核对人员「待我核对」只有本分公司,分管领导「待领导审批」只有分管主体
A1.8	空区块保留但压缩高度	⚠️	区块保留(不隐藏),pageSize 由 25 收到 10;object-grid 没有高度/行高的像素级键(spec component.zod.ts 只有 rowHeight 密度枚举与 pageSize),空态本身就是一行标题 + 一句「未找到结果」的固定占位,再压不下去。差异:「压缩高度」落到了「压缩行数上限」这一可表达的口径上,不是没做。
A1.9	「待填报的指标」网格保留	✅	原样保留(列、排序、editable、pageSize: 25 未动)
A1.10	若平台允许按本对象字段过滤,只显示所属填报单为「填报中」的行;明细上若无该字段则如实记录,不加字段	⚠️	平台不允许:这是 kpi_entry_sheet.status,查询引擎拒绝跨关系过滤($filter 写 sheet.status → 400 INVALID_FIELD,报错原文要求反规范化到本对象)。逐字段复核 kpi_entry_line 的全部 20 个字段,无任何字段编码填报单状态。按本条自带的授权(「明细上若无该字段则如实记录,不加字段」)如实记录在 src/pages/index.ts 注释与测试报告 §8.1,不加字段、不用退化条件冒充。这不是静默降级 —— 需求本身给了这个出口。
A2.1	填报单列表行菜单在对应状态下出现「审核通过」「驳回」「归档」	✅	核实结论:动作已是对象级且带 locations: ['list_item'],无需改代码。实测:已通过 → 归档;人力审核中 / 领导审批中 / 分公司核对中 → 审核通过 | 驳回(截图见报告 §4)
A2.2	核实确认框文案	✅	归档「归档后将生成不可变快照,数据锁定不可再改。确认归档?」;审核通过弹窗「审核意见(选填)」;驳回弹窗「驳回原因(必填)*」。守 std-copy 四条红线:无内部代号、无异常原文、名词按需求 §1.4(填报单 / 核对 / 归档)、拦截提示三段式
A2.3	驳回原因在行级动作里仍必填	✅	行级入口留空提交被拦下,提示「驳回原因(必填) 为必填项」,弹窗不关、记录不变(报告 §4 截图)
A3.1	「填报与审核」组增加「待人力审核」「待领导审批」导航项,用 viewName 直指填报单对应列表视图	✅	viewName: 'hr' / 'leader';实测 URL 落到 /kpi_entry_sheet/view/hr、/view/leader
A3.2	分公司核对的「待我核对」同样加一项	✅	objectName: 'kpi_check_task', viewName: 'pending';实测 URL /kpi_check_task/view/pending
A3.3	导航按岗位裁剪沿用现有 requiredPermissions 机制	⚠️	机制沿用(未引入 visible 等第二套机制),但这三项刻意不加 requiredPermissions:它们指向的对象在所有岗位的权限集里都有读权,看到几行由数据范围决定;加能力闸门会把除管理员/人力外的人挡在自己队列门口,与本单目的相反。差异是「沿用机制、但对这三项判定为不需要裁剪」,已在 src/apps/index.ts 注释写明理由。
A4.1	文案守 std-copy 四条红线	✅	新增文案:区块标题「待我核对 / 待人力审核 / 待领导审批」(设计方案 §5.5 原文)、导航项同名、页面引导语一句。无内部代号、无异常原文、术语按需求 §1.4
A4.2	新增 label 用 pnpm i18n:extract 重生成翻译包	✅	重生成后 zh-CN.objects.generated.ts +9 行(三个导航项 label);pnpm i18n:extract:check 门禁绿
A5	不做站内通知 / 不改流程节点与驳回口径 / 不做自定义代码页 / 不改核对任务生成范围	✅	均未触碰;改动仅 src/pages/index.ts、src/apps/index.ts、src/translations/zh-CN.objects.generated.ts(生成)。src/views/index.ts 经核实无需改动,故未改

B. 验收标准

#	标准	态	证据
B1	分公司核对人员登录后工作台「待我核对」列出本分公司待核对任务,可行内「确认无误」;10 条任务不进列表页也能处理	⚠️	前两句 ✅(华东 8 条全部本分公司,行内确认 3 击,URL 全程 kpi_home)。「10 条」这一具体条数:软件档案在同一时刻能造出的单分公司待核对队列上限是 9 条(11 张单中 1 张已通过、本分公司自身的单不生成本分公司任务),实测华东 8 条、华北 9 条,均一屏列出、逐条行内处理、不进列表页;区块 pageSize 设为 10,10 条同样一屏。差异是样本条数受档案上限所限,不是能力缺口。
B2	人力审核工作台「待人力审核」列出待审单,行动作可用,驳回原因必填;左侧菜单直达;审 1 张单 ≤ 3 击且不进详情页	✅	3 张待审单;驳回留空被拦、填写后成功;菜单直达 /view/hr;审 1 张单 3 击,URL 全程 kpi_home
B3	分管领导「待领导审批」只列分管主体的单;左侧菜单直达,不再需要点「还有 N 个」;审 1 张单 ≤ 3 击	✅	技术线只列 3 张分管主体的单,市场线的客户成功部不在列;改前 5 击(经「还有 4 个」溢出菜单),改后 3 击直达;审 1 张单 3 击
B4	部门填报人员工作台仍能一屏填数出分提交(0 跳页不回退);空区块不报错	✅	整轮 URL 去重后只有 kpi_home;填数保存即出分,同页提交成功;三个待办区块空态显示「未找到结果」,页面无错
B5	管理员、人力负责人页面不报错;pnpm verify 绿;software-flow.mjs 54/54、e2e-flow.mjs 全 PASS	✅	管理员一轮 0 条 console error;人力负责人仅平台外壳 sys_activity 403(主干既有,与本页无关)。pnpm verify 绿;software-flow {"passed":54,"failed":0};e2e-flow {"passed":74,"failed":0}
B6	测试报告(五类岗位截图 + 逐步点击数)与本清单挂本单评论,截图走 acceptance-evidence 40 位 SHA 图链	✅	报告见上一条评论;38 张截图在 acceptance-evidence 的 issue-36/,commit c11edb126d4da52bfa5313440d2ca52b7e17f053,已用 contents API 核对 38/38

C. 三个 ⚠️ 条目的出口

三条都不是「先简化实现」,逐条对应:

• A1.8(空区块压缩高度):平台组件无高度键 —— 事实记录,已落到可表达的 pageSize 口径;不构成需要挂起的能力缺口(需求目的「空区块别占屏」已达成:空态固定两行)。若 PM 认为必须像素级压缩,请回单指出,按平台受限支线 B 重走。
• A1.10(明细按填报单状态过滤):平台能力受限,且 待办工作台:按数据范围自动分角色的待办区块 + 填报单行级审核动作 + 待审核/待审批直达菜单 #36 正文已预先授权这一出口(「明细上若无该字段则如实记录,不加字段」)。现象与最小复现记录在 src/pages/index.ts 注释(含查询引擎 400 报错原文)与测试报告 §8.1。未新开平台单:跨关系过滤是查询引擎的既定契约(报错本身给出了反规范化的正解),不是缺陷。
• A3.3(三项不加 requiredPermissions):实现判定,非能力缺口 —— 机制照用,只是判定这三项不该裁剪,理由写在代码注释里。若 PM 要求按岗位裁剪待办入口,请回单指出;届时还会撞上「本版本控制台对导航项的 visible 不求值」(已报平台 App nav item visible (CEL) is served to the client but never evaluated — a silently inert gate (17.2.0) objectstack#15135),需按支线 B 评估。

D. 与基线的差异

无。基线 main @ d1abec7,本分支只在其上新增三个页面区块与三个导航项,未改任何既有行为:「待填报的指标」「填报单」两块的属性逐字未动,src/views/index.ts 未改,src/lib/、src/hooks/、src/actions/index.ts、src/objects/、src/security/、src/services/、src/data/、scripts/、docs/ 均未触碰。

[baozhoutao]

交接验收侧

状态切到 status:PR审查中,处理人 @baozhoutao。

• PR:待办工作台:三个队列区块 + 待审核/待审批/待核对直达菜单 (#36) #40(issue-36-todo-workbench → main,提交 fb6b49b;不含自动关闭关键字)
• 测试报告:本单上一条评论(7 条用例全 PASS,五类岗位截图 + 逐步点击数)
• 需求符合度清单:本单上一条评论(无 ❌;3 条 ⚠️ 各带出口)
• 截图:acceptance-evidence 分支 issue-36/,commit c11edb126d4da52bfa5313440d2ca52b7e17f053,38 张,已用 contents API 核对

门禁:pnpm verify 绿 · software-flow.mjs 54/54 · e2e-flow.mjs 74/74。

需要拍板的三处(都在符合度清单 §C):空区块「压缩高度」落到了 pageSize 口径(平台组件无高度键);三个导航项刻意不加 requiredPermissions;分公司核对人员因既有 readScope: 'org' 在两个审核区块里看得到行、动作被服务端 403 拒(边界不破,入口有噪音,非本单引入)。

AI 不自行合并。