4.0 KiB
最小待办交接投影
2026-09-11 复核接续：取消旧身份门户读取
原批准的双端身份隔离仍未完整成立：迟到 401 会按当前会话刷新并重放旧请求，乙结果可进入甲 key；双端甲→乙→甲已在冻结树 dcde0d44 的合成浏览器复现。此次沿原目标修复，不改全局认证、角色或生产。只为 fetchPortalHome 增加可选 AbortSignal，两个 queryFn 消费并传递它，使旧页面卸载时 Query 层取消、传输层终止，不让旧结果缓存。
新增双端迟到 401 的真实请求取消断言及往返登录验证，并检查同身份正常 401 刷新仍可用。不把“请求成功返回”当作全部晚到场景。原 postpush-identity 包与 NO_GO 回执保留；新构建、专项/联合及真实隔离结果另存 postpush-cancellation，独立复核仍单列。
2026-09-11 复核后追加：门户查询按身份隔离（已批准本地实施）
- 修复前 PC ["portal-home"] 和手机 ["mobile", "portal", "home"] 跨账号共享 QueryClient 数据；staleTime: 0 只触发后台刷新，不禁止先展示已有缓存。双端合成浏览器均已在未修构建上复现乙登录后等待网络期间显示甲待办，失败证据保留在 postpush-identity/red.log。
- 在这两个现有 queryKey 后追加已确认员工 id，并以身份存在性控制查询；不以 canUseFinance 控制整个请求。保持原前缀，使既有 invalidateQueries 前缀调用仍命中；不使用保留上一 key 数据的 placeholderData/keepPreviousData。
- 不修改全局认证或通过给角色加权限解决；按身份分区使旧身份请求晚返回也不能覆盖当前门户。既有认证/PWA 清理不等于 React Query 清理，其他模块的全局缓存生命周期风险不能由本修复推断已全部解决。
- 验收须在同一页面文档切换两个合成员工：新身份已生效但门户响应未返回、响应失败及旧请求晚到时均零旧身份待办；正确响应只显示新身份事项。覆盖 PC/手机、现有角色与失效刷新。不用真实员工手测或强刷“修复”缓存。
服务端服务 loadReimbursementPaymentHandoffs 从业务记录只读构造 { total, items }，挂在现有 portal home DTO。项目为小团队，四类活动对象按稳定 key 去重，total 从返回 items 计算；不新建队列数据库或通用任务系统。资料未齐不是忽略该报销的理由，点击进入原业务页由权威 readiness/写事务决定能否组批。
只选择必要字段。退回检查最新流程最后的 return/reject 事实，禁止把历史曾退回但当前主动撤回的草稿重新标成待修改。付款查询限 reimbursement，exclude deleted/paid，排除非取消批次占用；部门 gate 在本次加载内缓存，不解密银行资料。批次复核使用原 manager/ceo+review 资格及非制单人条件；付款处理仅 manage。
门户行动行复用现有组件，旧 finance pending/failed 聚合行只作为旧服务端 DTO 兼容，收到新投影时不重复列入行动计数；独立风险提醒不冒充付款复核。移动端复用同一 items，报销使用 mobile 深链，付款沿既有移动边界。只读查询错误使用页面已有错误反馈，不回落成零待办。
09-11 提交后复核发现：手机 portalHomeQuery 仍以 canUseFinance 启用，旧财务聚合的展示资格意外限制了新增业务待办的数据加载。修复仅移除整个已认证门户查询上的财务开关，保持财务卡片的 canUseFinance 判断和服务端角色/归属/部门/非本人制单过滤；不通过给员工增加财务权限绕过缺陷。补 employee 与 ceo 独立浏览器上下文的手机直接进入测试，不能只测 finance 手机或 employee PC。
无 schema/迁移/seed/业务写入/消息发送；已有通知机制不变，通知丢失不丢业务事实。每次渲染不是批准执行，写接口仍独立授权。代码回退恢复旧门户，不改业务记录。独立 reviewer 受 inline 限制时明确 pending。