DOCG7 治理文档事实源口径

docs/product-design-rules.md

@@ -1,6 +1,6 @@
 # 产品设计规则基线
 
-本文件是 R100 之后 PC 网页和企业微信/手机网页统一优化的事实源。目标用户是 10 人以下的国内科技公司：使用频次高、角色重叠、审批链短，系统应当像工作台，不像宣传站，也不应像重型 ERP。
+本文件是 PC 网页和企业微信/手机网页统一优化的当前事实源。目标用户是 10 人以下的国内科技公司：使用频次高、角色重叠、审批链短，系统应当像工作台，不像宣传站，也不应像重型 ERP。
 
 ## 设计目标
 
@@ -153,15 +153,15 @@ MIA7 之后，移动 OA 的信息架构以“一级入口少、任务摘要轻
 
 ## 报销专项规则
 
-报销是下一批 R101 的主流程，不在 R100 直接改数据模型。R101 必须单独处理：
+RI6 之后，报销和票据体验以“员工从报销详情补材料、财务从台账复核、移动端轻任务”为当前事实源：
 
-- 后端生成业务编号，例如 `BX20260506001`，前端不再用 UUID 作为主展示。
-- 草稿允许删除；审批中使用撤回；已通过和已支付不提供删除。
-- 报销明细存在且只有一条时，上传发票默认绑定该明细。
-- 多条明细时优先按金额匹配；无法匹配时自动生成新明细，不向普通用户暴露“绑定整单”。
-- 发票上传支持批量 PDF，OCR 显示明确状态和可重试入口，不长期停留在“上传中/处理中”。
-- PC 端适合完整明细和对账；手机端适合上传 PDF 发票、补充说明、继续编辑草稿和查状态。
-- 报销详情等深层页的底部主操作在 iPhone 11 等小屏上仍保持同行双按钮，不因适配降级为单列。
+- 后端业务编号是用户主展示，例如 `BX20260506001`；UUID 不作为普通用户主编号。
+- 草稿允许编辑和删除；审批中按审批状态提供可解释下一步；已通过、已支付不提供删除。
+- 普通员工发票入口仍在报销详情“添加发票”，不恢复员工侧“票据中心/发票池”主导航。
+- 发票状态文案使用“识别中、识别失败、可添加、已添加、重复票据、已归档/已报销”等用户可理解表达，不暴露 OCR provider、发票池、绑定整单、不绑定明细等内部术语。
+- 报销详情按摘要、明细、发票、附件、审批流、付款状态和下一步动作分区；PC 保持高密度，移动保持轻任务。
+- PC 端适合完整明细、对账和财务复核；手机端适合上传 PDF 发票、补充说明、继续编辑草稿和查状态。
+- 报销详情等深层页使用统一移动详情壳和吸底操作，不把底部 Tab 留在深层事实页。
 
 ## 请假、票据、采购、差旅规则
 
@@ -170,48 +170,26 @@ MIA7 之后，移动 OA 的信息架构以“一级入口少、任务摘要轻
 - 采购和差旅页使用和报销一致的列表、状态、操作区和移动卡片规则。
 - 所有上传控件都使用中文按钮和文件名回显。
 
-## R99 WIP 处置
+LP6 之后，请假和采购体验以“状态清楚、审批历史一致、缺配置不 500”为当前事实源：
 
-当前工作区存在 R99 企业微信移动端整改 WIP，涉及：
+- 请假详情展示日期、天数、假别、原因、当前状态、当前节点、审批历史和退回/驳回说明；从已批准记录返回时不得落到新建表单语境。
+- 采购详情展示业务编号或标题、金额、状态、附件说明、审批历史和预算 warning。缺预算池时使用用户可理解提示，不暴露后端技术结果或返回 500。
+- 报销、请假、采购三类单据的详情页和卡片遵循同一主标识、状态、关键指标、审批流和下一步动作槽位。
+- 差旅仍不进入当前主线扩展；如恢复差旅能力，必须先新建独立 Issue CSV。
 
-- `client/src/pages/MobilePortalPage.tsx`
-- `client/src/pages/MobileMePage.tsx`
-- `client/src/components/mobile/MobileBottomNav.tsx`
-- `client/src/layouts/AppShellLayout.tsx`
-- `client/src/pages/MobileReimbursementsPage.tsx`
-- `client/src/pages/MobileLeavePage.tsx`
-- `client/src/router/index.tsx`
-- `client/src/router/lazy/index.ts`
+## 当前后续批次
 
-这些改动方向与本设计基线基本一致，但仍需要在 R103 中统一吸收或经批准清理。本 R100 批次不把这些 WIP 当作完成项提交，避免和设计规则、报销重构混在一起。
+已完成的当前事实链为：R6、PC6、PA6、FL6、AP6、RI6、LP6、ME6 自动化、QG6、DG7/MRF7、MIA7。`ME6-3` 代表性企业微信真机门禁仍待确认，MIF7 是下一批移动信息架构整改合同。
 
-## 后续批次
+MIF7 移动整改默认包含：
 
-R6 小范围试运行准备：
+- 首页去重：常用入口改成不重复底部 Tab 的快捷动作，待处理摘要压缩为一张轻摘要。
+- 进度页分标签：员工按草稿、审批中、已通过、退回驳回分组；审批人按待我审批、已处理分组。
+- 通知中心事件化：通知不展示审批动作按钮，点击直达目标详情。
+- 详情页统一壳：返回位置、标题、状态、内容顺序和底部动作一致。
+- 返回语义统一：优先回来源页或来源标签；无来源时回业务列表或进度标签。
 
-- 先新建独立 R6 合同，固定 2-3 个内部用户、角色、时间窗口、回滚联系人、问题登记表和每日收口节奏。
-- R6 范围限定为报销、请假、采购、审批、企业微信入口/通知、财务付款/导出。
-- R6 不扩预算、ERP、AI、完整差旅、复杂 BPM；发现需求只登记为新 Issue。
-- 试运行反馈按“阻断、严重、一般、体验建议”分级，不能现场扩大实现范围。
-
-R101 报销主流程重构：
-
-- 后端业务编号、权限和删除规则。
-- 报销列表、明细页、发票绑定和草稿编辑体验。
-- PC 与手机报销流程的自动化回归。
-- 需要 reviewer 检查权限、状态机和回滚策略。
-
-R102 跨页面一致性：
-
-- 票据、请假、采购、差旅页面统一列表、表单、上传和状态文案。
-- 清理路径式标题、原生上传控件和 UUID 主展示。
-- 补齐页面级 Playwright 视觉诊断。
-
-R103 企业微信/手机端统一清理：
-
-- 吸收或清理 R99 WIP。
-- 固定移动首页、我的、报销、请假、审批、票据上传的移动页面。
-- 手机端不再复用桌面表格作为主要体验。
+历史阶段说明：早期文档中的 R99、R100、R101、R102、R103 是移动与页面治理的历史批次代号，不再作为 2026-05-12 之后的当前排期或待办事实源。需要追溯当时决策时，可阅读历史 Issue CSV 和 `docs/文档事实源状态矩阵.md`。
 
 ## 验收规则