背景
承 plugin-approvals：记录处于待审批时，控制台会为审批人注入 Approve / Reject 动作。但在真实应用里发现，审批人打开待审批记录时，页头主按钮是 app 自定义动作（如“申请关闭商机”），而 Approve / Reject 沉在 ⋯ 溢出菜单里，审批人第一眼看不到该做的决策。
问题（两点）
-
系统审批动作永远排在 app record_header 动作之后。 实测某待审批商机，页头动作解析顺序为：
申请关闭商机(主按钮) → 发起出差 → 打印商务方案 → Approve → Reject → 编辑/分享/删除
即系统 Approve / Reject 被追加在所有 app 动作后面。
-
记录页头只把“第一个 visible 的 record_header 动作”渲染为唯一主按钮，其余全部进 ⋯ 菜单。于是只要有任意 app record_header 动作可见，它就占据主按钮位，把审批决策挤走。
结果：审批人必须点开 ⋯ 才能找到 Approve / Reject。
复现
- 记录进入待审批（存在 pending approval，且当前登录用户是审批人）。
- 打开记录详情 → 页头主按钮是某个 app 动作，Approve / Reject 在 ⋯ 菜单里。
目前的绕法（应用层，别扭）
在每个 app 动作的 visible 里加“审批中则隐藏”，把所有 app record_header 动作（含打印等）都藏起来，Approve 才会顶上来成为主按钮。问题：
- 要逐个动作加条件，还得把第三方/打印动作一起藏；
- 审批期间这些动作彻底不可见，而不是“排在 Approve / Reject 之后”——因为控制台无法把 app 动作排到系统审批动作之后。
建议
- 待审批且当前用户是审批人时，控制台应优先/显著渲染 Approve / Reject（例如作为主按钮，或独立的“审批决策”区），不被 app 动作挤进溢出菜单。
- 更通用地：给 Action 增加显式的排序/优先级（
order / priority，或 primary: true）。目前“谁当主按钮”完全取决于 defineStack({ actions }) 合并数组里的注册顺序（跨文件）——要调整只能全局重排 spread，脆弱且把不相关的功能耦合起来。有了显式优先级即可声明式地让审批决策（或任一关键动作）稳定占据主位，而不必靠隐藏其它动作来“腾位”。
环境
ObjectStack + 内置 objectui 控制台（vendored bundle）。若已在较新 objectui 修复，烦请指个 issue / PR，我这边核实。
背景
承 plugin-approvals：记录处于待审批时，控制台会为审批人注入 Approve / Reject 动作。但在真实应用里发现，审批人打开待审批记录时，页头主按钮是 app 自定义动作（如“申请关闭商机”），而 Approve / Reject 沉在 ⋯ 溢出菜单里，审批人第一眼看不到该做的决策。
问题（两点）
系统审批动作永远排在 app
record_header动作之后。 实测某待审批商机，页头动作解析顺序为：申请关闭商机(主按钮) → 发起出差 → 打印商务方案 → Approve → Reject → 编辑/分享/删除即系统 Approve / Reject 被追加在所有 app 动作后面。
记录页头只把“第一个 visible 的
record_header动作”渲染为唯一主按钮，其余全部进 ⋯ 菜单。于是只要有任意 apprecord_header动作可见，它就占据主按钮位，把审批决策挤走。结果：审批人必须点开 ⋯ 才能找到 Approve / Reject。
复现
目前的绕法（应用层，别扭）
在每个 app 动作的
visible里加“审批中则隐藏”，把所有 apprecord_header动作（含打印等）都藏起来，Approve 才会顶上来成为主按钮。问题：建议
order/priority，或primary: true）。目前“谁当主按钮”完全取决于defineStack({ actions })合并数组里的注册顺序（跨文件）——要调整只能全局重排 spread，脆弱且把不相关的功能耦合起来。有了显式优先级即可声明式地让审批决策（或任一关键动作）稳定占据主位，而不必靠隐藏其它动作来“腾位”。环境
ObjectStack + 内置 objectui 控制台（vendored bundle）。若已在较新 objectui 修复，烦请指个 issue / PR，我这边核实。