现象
#3447 P2 的 decisionOutputs（审批人在做决定时提交结构化数据）服务端已经完整可用，但两个决策入口都接不上，导致这个能力在 Console 里事实上无法使用。
服务端侧确认正常（本地 17.0.0-rc.0 实测抓包）：节点声明
decisionOutputs: [{ key: 'parallel_positions', label: '并行会审岗位', type: 'position', multiple: true }]GET /api/v1/approvals/requests 返回的请求行上确实带着
"decision_outputs": ["parallel_positions"],
"decision_output_defs": [{"key":"parallel_positions","label":"并行会审岗位","type":"position","multiple":true}]① 审批中心（ApprovalsInboxPage）不读 decision_output_defs，把带类型的选择器降级成"填记录 ID"文本框
审批中心的决策抽屉只消费旧的 decision_outputs（裸键名数组），为每个键渲染一个纯文本输入框，占位提示「<标签> 的记录 ID」。objectui#2831 的 typed 选择器（user / department / position / team 的记录选择器）只接进了 DeclaredActionsBar，没有接进审批中心。
结果：审批人要选人 / 选岗位时只能去别处复制记录 ID 再粘回来，实际不可用；流程作者声明的 type / multiple 形同虚设。
② 业务记录详情页的「批准 / 驳回」按钮完全不采集 decisionOutputs
useRecordApprovals 的 decide 只发 { actorId, comment }，既不读 decision_output_defs 也不发 outputs。审批中心侧已经有「本审批需要填写决策输出，请打开详情再决策」的快捷通道守卫（#2829），记录页侧没有对应守卫。
结果：节点一旦声明了 decisionOutputs，审批人从业务单据详情页点「批准」会静默跳过这些输入 —— 后续节点读 vars.<nodeId>.<key> 直接缺键，expression 审批人抛 EXPRESSION_FAILED 让节点硬失败，或（若作者写了 has() 兜底）落进 onEmptyApprovers。审批人和流程作者都不会收到任何提示。
复现
- 任一
record_change 流的 approval 节点上声明上面那个 decisionOutputs；
- 提交一条单据进入该节点；
- 审批中心 → 打开该请求 → 点「通过」：弹窗里「并行会审岗位」是纯文本框，提示填记录 ID（期望：
sys_position 多选选择器）；
- 业务单据详情页 → 点页头「批准」：直接通过、没有任何弹窗，
sys_approval_action 上没有 outputs（期望：要么弹出决策输入，要么像审批中心一样禁用并提示去详情决策）。
期望
- 审批中心的决策弹窗按
decision_output_defs 渲染对应的记录选择器（复用 DeclaredActionsBar 里已经做好的那套 widget 映射），multiple: true 收集 id 数组；
- 记录详情页的审批按钮要么同样采集
decisionOutputs，要么在节点声明了 decisionOutputs 时禁用并提示"请到审批中心决策"，不要静默跳过。
附带一个能力缺口（可另议）
DecisionOutputDef 没有 required，Console 合成参数时也把 required: false 写死了，所以作者无法要求"审批人必须选了才能通过"。我们只能退而用 onEmptyApprovers: 'admin_rescue' 兜底（漏选就卡住等管理员转签），而不是在弹窗里硬拦。如果 decisionOutputs 的定位是"路由下一步审批人"，required 会很有用。
环境
平台 17.0.0-rc.0（@objectstack/* 全套），Console 随该版本内置；本地 dev（SQLite / 单租户）。
发现于业务项目 QIF/NCR 三级审批回归 #3447 原始要求的过程中；我们最终绕开了 decisionOutputs 通道，改为"审批人在单据字段上选 + 下一节点用 expression 审批人读记录实时值"，所以不阻塞我们，但这个能力目前在 Console 里等于没有入口。
现象
#3447 P2 的
decisionOutputs（审批人在做决定时提交结构化数据）服务端已经完整可用，但两个决策入口都接不上，导致这个能力在 Console 里事实上无法使用。服务端侧确认正常（本地 17.0.0-rc.0 实测抓包）：节点声明
GET /api/v1/approvals/requests返回的请求行上确实带着① 审批中心（ApprovalsInboxPage）不读
decision_output_defs，把带类型的选择器降级成"填记录 ID"文本框审批中心的决策抽屉只消费旧的
decision_outputs（裸键名数组），为每个键渲染一个纯文本输入框，占位提示「<标签> 的记录 ID」。objectui#2831 的 typed 选择器（user / department / position / team 的记录选择器）只接进了DeclaredActionsBar，没有接进审批中心。结果：审批人要选人 / 选岗位时只能去别处复制记录 ID 再粘回来，实际不可用；流程作者声明的
type/multiple形同虚设。② 业务记录详情页的「批准 / 驳回」按钮完全不采集
decisionOutputsuseRecordApprovals的 decide 只发{ actorId, comment }，既不读decision_output_defs也不发outputs。审批中心侧已经有「本审批需要填写决策输出，请打开详情再决策」的快捷通道守卫（#2829），记录页侧没有对应守卫。结果：节点一旦声明了
decisionOutputs，审批人从业务单据详情页点「批准」会静默跳过这些输入 —— 后续节点读vars.<nodeId>.<key>直接缺键，expression审批人抛EXPRESSION_FAILED让节点硬失败，或（若作者写了has()兜底）落进onEmptyApprovers。审批人和流程作者都不会收到任何提示。复现
record_change流的 approval 节点上声明上面那个decisionOutputs；sys_position多选选择器）；sys_approval_action上没有 outputs（期望：要么弹出决策输入，要么像审批中心一样禁用并提示去详情决策）。期望
decision_output_defs渲染对应的记录选择器（复用DeclaredActionsBar里已经做好的那套 widget 映射），multiple: true收集 id 数组；decisionOutputs，要么在节点声明了decisionOutputs时禁用并提示"请到审批中心决策"，不要静默跳过。附带一个能力缺口（可另议）
DecisionOutputDef没有required，Console 合成参数时也把required: false写死了，所以作者无法要求"审批人必须选了才能通过"。我们只能退而用onEmptyApprovers: 'admin_rescue'兜底（漏选就卡住等管理员转签），而不是在弹窗里硬拦。如果decisionOutputs的定位是"路由下一步审批人"，required会很有用。环境
平台 17.0.0-rc.0（
@objectstack/*全套），Console 随该版本内置；本地 dev（SQLite / 单租户）。发现于业务项目 QIF/NCR 三级审批回归 #3447 原始要求的过程中；我们最终绕开了
decisionOutputs通道，改为"审批人在单据字段上选 + 下一节点用expression审批人读记录实时值"，所以不阻塞我们，但这个能力目前在 Console 里等于没有入口。