hyb-oa/.trellis/tasks/08-30-reimbursement-assets-prior-approval-correction/prd.md

取消报销资产事前批准强制

Goal

纠正 B1 把不存在的公司制度做成系统强制的问题：公司当前不要求办公家具、通用设备或办公电子设备采购事前审批，报销系统不得要求员工填写“事前批准依据”才能保存或提交。保留已上线的兼容字段与历史数据，不做 migration；把 assets 类型的员工说明改为资产登记导向，要求在明细说明中写清物品、使用人或责任人、存放位置。

Background and Confirmed Facts

• 当前生产候选 0f9f403 已上线 B1/B2。B1 在 PC、移动端和服务端把所有 category=assets 明细一律要求填写事前批准依据，但公司没有对应的事前审批制度。
• 继续保留必填或教员工填写固定话术都会制造虚假合规痕迹；改成大额门槛仍然是在实现一条不存在的规则，因此本轮直接取消强制，不设置金额触发条件。
• ReimbursementItem.asset_prior_approval_basis 已是可空列；生产现有明细没有已填写值，但仍按兼容原则保留列、API 字段和任何历史值，不删除、不回填、不迁移。
• BX-20260828-0016 是外部技术服务费用，不含 assets 明细，可在本任务并行规划/实施期间由真实财务作为真人 canary 退回。BX-20260828-0017 的实物是办公家具，必须等待本纠偏上线后再退回。

Scope

• 报销 assets 明细创建、编辑、提交的批准依据校验。
• PC/移动端 assets 明细编辑、保存和展示，以及办公用品 2,000 元选类提示。
• 三个启用 assets 费用类型的 seed description。
• 产品口径、报销规约、聚焦后端与端到端测试，以及无 migration 的受控部署验收。

Requirements

R1 取消所有 assets 批准依据阻断

• 服务端删除三个强制点：明细创建 server/src/routes/reimbursements.js:3670、明细编辑 :3835、提交时 missingAssetApprovalItemIds 检查 :4061-4077。
• assets 明细未提供 assetPriorApprovalBasis 时允许创建、编辑和提交；票据—明细关联、票面金额、正金额、费用类型启用状态及其他既有门禁保持不变。
• 创建 assets 明细时，批准依据缺失或空白保存为 null。编辑时字段未传必须保留历史值，显式传 null/空白才清空；切换为非 assets 类型继续清空该字段。不得因页面隐藏字段而在编辑日期、金额、类型或说明时静默丢失历史值。
• 删除必填校验后必须同步消除其下游的非空假设：创建路径 server/src/routes/reimbursements.js:3686-3687 使用 body.assetPriorApprovalBasis?.trim() || null；编辑路径 :3854-3856 使用 targetApprovalBasis?.trim() || null。字段 omitted、数据库现值为 null 或显式 null 均不得触发 .trim() TypeError/500。

R2 移除无用途的前端输入与展示

• PC ReimbursementItemEditor.tsx 和移动端 MobileReimbursementDetailPage.tsx 不再渲染“事前批准依据”输入框，也不再因其为空禁用保存按钮。
• PC ReimbursementDetailPage.tsx 和移动端明细卡不再展示“事前批准依据”行。API 类型与详情响应字段保留以兼容旧客户端和历史数据，但当前 UI 不再发送该字段。
• 清理 PC/移动端编辑状态、初始值和保存 payload 中只为该输入框服务的数据流，确保普通编辑不显式发送 null 清空历史值。

R3 把资产类型说明改为资产登记导向

• assets_equipment、assets_furniture、assets_office_electronics 三个启用类型不再出现“事前批准”“批准人”“批准时间”或“批准依据”。
• 类型说明要求员工在明细“说明”中写清物品名称、实际使用人或责任人、存放位置，供管理员后续人工建卡和资产登记使用。
• assets_office_electronics 保留单条明细 2,000 元选类提示以及“不等同于会计固定资产确认标准”的声明。

R4 统一 2,000 元提示文案

• 以下四处提示统一为“该金额通常应选择办公电子设备。”，删除“并填写事前批准依据”：PC 编辑态 ReimbursementItemEditor.tsx:188、PC 展示态 ReimbursementDetailPage.tsx:1282、移动编辑态 MobileReimbursementDetailPage.tsx:1112、移动展示态 MobileReimbursementDetailPage.tsx:1143。
• 提示仍只在 office_supplies 且单条明细金额大于等于 2,000 元时显示，保持提示级、不阻断、不自动改类。

R5 文档、规约与测试同步

• 更新 docs/产品口径.md:194，明确公司当前无 assets 事前审批要求，资产信息通过明细说明支持人工登记。
• 更新 .trellis/spec/hyb-oa/reimbursement-invoice-ocr.md:984/988/1031/1032，删除强制批准合同和对应错误矩阵，保留 nullable/API 兼容与非 assets 清理语义。
• 反转 server/tests/unit/routes/reimbursements.expense-standards.test.js:337-348 的断言：缺批准依据的 assets 明细不得再返回 400，并补创建/编辑兼容测试。至少覆盖：创建 assets 且字段 omitted 返回成功并落库 null；编辑数据库现值为 null 的 assets 且字段 omitted 返回成功并保持 null；编辑有历史值的 assets 且字段 omitted 保留原值；显式 null/空白清空；切换非 assets 清空。
• server/tests/unit/scripts/reimbursement-expense-policy-migration.test.js:17 继续证明列为 nullable 且 migration 无破坏性操作；本轮不得新建或修改生产 migration。
• 更新 client/tests/e2e/r111-invoice-reimbursement-guard.spec.ts:747-804：PC/移动端不显示批准输入或展示，保存不被阻断，四处 2,000 元提示使用新文案；票据明确关联和免票补助合同继续通过。
• 在 reimbursement spec 沉淀通用防回归规则：取消或放宽必填校验时，必须审计后续代码是否依赖该校验提供的非空、类型或状态保证，并为真实空值路径补回归测试；不得只删除前置错误分支。

Acceptance Criteria

• PC 和移动端选择三个 assets 类型时均不出现“事前批准依据”输入框，未填写该字段也能保存明细并提交。
• 服务端创建、编辑、提交均不再返回 required_for_assets 或 asset_prior_approval_basis_required，其他 B2 票据门禁不回退。
• 创建 assets 字段 omitted、编辑 assets 现值为 null 且字段 omitted 均成功并保持 null，不出现 TypeError/500；有值 omitted、显式清空和切换非 assets 的兼容语义均有测试锁定。
• 当前 UI 编辑 assets 明细不会发送该兼容字段；服务端遗漏字段保留历史值，显式清空有效，切换非 assets 仍清空。
• PC/移动编辑态和展示态四处 2,000 元提示一致，仍为提示级且不自动改类型。
• 三个启用 assets 类型 description 均转为资产登记导向；办公电子设备仍保留 2,000 元及非会计固定资产门槛声明。
• 数据库列、Prisma schema、API 字段及历史数据保留，无 migration、无批量更新、无数据清理。
• 聚焦后端测试、前端 typecheck/build、r111 E2E、Trellis/process/docs 治理和 git diff --check 全部通过。
• 新候选完成独立只读复核、push、无 migration 部署和公网 PC/移动验证后，才允许真实财务退回 0017。

Out of Scope

• 新增采购申请、审批流、金额批准门槛、数量/单价模型或自动资产建卡。
• 改造票据直接重关联、明细删除联动、B3 财务一页式或恢复行内费用标准提示。
• 修复 deploy-existing.sh --no-deps、PGDATA 容器内检查、admin smoke 治理等运维债。
• 清空 asset_prior_approval_basis 历史值、删除数据库列或修改既有 migration。
• 代替真实财务退回、审批或付款；0016 canary 和 0017 退回继续按生产写入门禁单独执行。

Test Plan

• 服务端：Prisma validate；聚焦 reimbursement expense-standards、创建/编辑路由、seed defaults 与既有 migration 测试，确认无批准依据可通过且 B2 金额/关联门禁不回退。
• 前端：typecheck、build、r111 聚焦 Playwright；同时覆盖 PC/移动编辑态和展示态的字段消失、保存可用与新提示文案。
• 数据与部署：确认无新增 migration、pre/post pending=none、init/seed exit 0、三个 description 正确、B2 仍 global on、合成 assets 草稿通过且 0017 未被当作 smoke。
• 治理：task validate、Trellis governance、process contract、docs registry、敏感信息扫描和 git diff --check。