归档审批退回动作收敛任务 [09-04-approval-return-reject-actions]

.trellis/tasks/archive/2026-09/09-04-approval-return-reject-actions/implement.md

@@ -62,3 +62,11 @@ git diff --check
 - 实施后先做只读 review；用户批准后才能提交。
 - push、生产部署和生产数据检查均需分别获得明确授权。
 - 无 migration/schema/seed/flag/生产数据写入；回滚到上一构建即可。
+
+## 生产收口
+
+- 业务提交 `8551601`，任务元数据提交 `acada24`；provenance 证明 `HEAD`、`origin/main` 与候选完整 SHA 一致。
+- 生产已发布 `acada24adc8b`：部署前 UI strict 0 findings，13/13 聚合体检、pre/post migration `pending=none`、rollback window OPEN/0、init、runtime/external smoke、公网 bundle marker/文案扫描与备份合同刷新全部通过。
+- 公网真实 bundle 配合合成 API 的审批回归 11/11 通过：报销只显示“通过 / 退回修改”，请假、补卡、采购、差旅仍保留各自既有驳回动作。
+- 生产只读核验确认 B2 仍为 `force_on + global`，三个目标报销仍全部为 `rejected`，本任务未写入业务数据。
+- 历史 rejected 兼容证据为 48/48 后端回归、未改动的列表/详情/打印/时间线映射及三张生产单据状态；因无 live-smoke 登录凭据，没有冒充真实账号逐页打开。该真实 UI 样本随父任务 AC11 员工打开原单一并验证，不另做生产写入或账号重置。

.trellis/tasks/archive/2026-09/09-04-approval-return-reject-actions/prd.md

@@ -74,18 +74,18 @@
 
 ## Acceptance Criteria
 
-- [ ] AC1：服务端测试逐项证明 reimbursement=`approve,return[,transfer]`、leave/purchase/travel=`approve,reject,return[,transfer]`、attendance_correction=`approve,reject[,transfer]`；无权限或已处理任务仍返回空动作。
-- [ ] AC2：报销 PC 和移动 fixture 的 `allowedActions` 及可见 UI 均不含 reject；页面上“驳回”“确认驳回”按钮数为 0。
-- [ ] AC3：PC 报销右栏“通过 / 退回修改”同处一个两列动作组、等高且无横向溢出；不存在旧的一通栏加两个小按钮布局。
-- [ ] AC4：移动报销 sticky action bar 默认直接包含“退回修改 / 通过”，两者触控高度至少 44px；转审不进入该主动作组。
-- [ ] AC5：展开退回修改前，意见输入和引用清单不存在；展开后意见必填、异常引用项优先、确认弹窗准确说明回到申请人修改态。
-- [ ] AC6：任一现有 fail-closed 条件成立时，原因紧贴动作组上方，通过、退回修改、转审全部禁用；正常报销的可见动作不被误伤。
-- [ ] AC7：执行退回修改后，服务端响应和持久化仍为 returned/draft；修改后重提创建新 workflow instance 并从重新匹配的首个可执行节点开始。
-- [ ] AC8：历史 rejected 报销仍可读取、显示、编辑和重提；打印/时间线仍正确显示“驳回”，不发生数据迁移或历史改写。
-- [ ] AC9：旧 reject endpoint 的既有兼容测试继续通过；产品 UI 和新 `allowedActions` 不再为报销提供调用路径。
-- [ ] AC10：请假、补卡、采购、差旅分别通过动作集合与确认流程回归；共享 `BusinessDetailActionPanel` 的其他消费者 DOM 顺序不变。
-- [ ] AC11：typecheck、build、相关后端测试、PC/移动 E2E、UI strict/self-test、process contract、Trellis governance 与 `git diff --check` 全部通过。
-- [ ] AC12：面向用户可测试前，需另行批准 push/部署，并通过公网 bundle、PC 1280px、移动端和五类审批回归。
+- [x] AC1：服务端测试逐项证明 reimbursement=`approve,return[,transfer]`、leave/purchase/travel=`approve,reject,return[,transfer]`、attendance_correction=`approve,reject[,transfer]`；无权限或已处理任务仍返回空动作。
+- [x] AC2：报销 PC 和移动 fixture 的 `allowedActions` 及可见 UI 均不含 reject；页面上“驳回”“确认驳回”按钮数为 0。
+- [x] AC3：PC 报销右栏“通过 / 退回修改”同处一个两列动作组、等高且无横向溢出；不存在旧的一通栏加两个小按钮布局。
+- [x] AC4：移动报销 sticky action bar 默认直接包含“退回修改 / 通过”，两者触控高度至少 44px；转审不进入该主动作组。
+- [x] AC5：展开退回修改前，意见输入和引用清单不存在；展开后意见必填、异常引用项优先、确认弹窗准确说明回到申请人修改态。
+- [x] AC6：任一现有 fail-closed 条件成立时，原因紧贴动作组上方，通过、退回修改、转审全部禁用；正常报销的可见动作不被误伤。
+- [x] AC7：执行退回修改后，服务端响应和持久化仍为 returned/draft；修改后重提创建新 workflow instance 并从重新匹配的首个可执行节点开始。
+- [x] AC8：历史 rejected 报销仍可读取、显示、编辑和重提；打印/时间线仍正确显示“驳回”，不发生数据迁移或历史改写。
+- [x] AC9：旧 reject endpoint 的既有兼容测试继续通过；产品 UI 和新 `allowedActions` 不再为报销提供调用路径。
+- [x] AC10：请假、补卡、采购、差旅分别通过动作集合与确认流程回归；共享 `BusinessDetailActionPanel` 的其他消费者 DOM 顺序不变。
+- [x] AC11：typecheck、build、相关后端测试、PC/移动 E2E、UI strict/self-test、process contract、Trellis governance 与 `git diff --check` 全部通过。
+- [x] AC12：面向用户可测试前，需另行批准 push/部署，并通过公网 bundle、PC 1280px、移动端和五类审批回归。
 
 ## Test Plan
 

.trellis/tasks/archive/2026-09/09-04-approval-return-reject-actions/task.json

@@ -3,7 +3,7 @@
   "name": "approval-return-reject-actions",
   "title": "审批退回驳回语义与动作布局",
   "description": "核清五类审批实体的退回与驳回真实后果，并按实体收敛报销动作投影及 PC/移动布局。",
-  "status": "in_progress",
+  "status": "completed",
   "dev_type": null,
   "scope": "trellis,server,client,tests,docs",
   "package": null,
@@ -11,7 +11,7 @@
   "creator": "shunli",
   "assignee": "shunli",
   "createdAt": "2026-09-04",
-  "completedAt": null,
+  "completedAt": "2026-09-04",
   "branch": null,
   "base_branch": "main",
   "worktree_path": null,
@@ -21,6 +21,6 @@
   "children": [],
   "parent": null,
   "relatedFiles": [],
-  "notes": "",
+  "notes": "生产已发布 acada24adc8b，五类动作回归、B2 配置和三张 rejected 状态只读核验通过；真实账号逐页查看历史 rejected 随父任务 AC11 验证。",
   "meta": {}
 }