MIA7 固化移动信息架构审查与整改合同

2026-05-12 21:59:40 +08:00
@@ -76,6 +76,20 @@ R6 之后的 PC、移动和审批体验参考国内主流协同/OA 产品的共
 - PC 高密度表格允许保留独立“单号/编号”列，但同一行的标题或摘要不得再拼接同一编号；确需复制编号时放在单号列或详情页摘要区。
 - UUID、taskId、entityId、内部状态码和调试字段不进入用户主展示；审计页、管理员排障页和打印留痕页按权限例外处理。

+### MIA7 移动工作台、进度、通知和详情标准
+
+MIA7 之后，移动 OA 的信息架构以“一级入口少、任务摘要轻、详情事实源清楚”为基线。后续移动页面整改必须先判断内容属于哪一层，再决定展示位置：
+
+- `底部导航` 只承载一级模块，不承载具体动作。默认语义为首页、审批/进度、报销、我的；底部红点只表达数量，不展示待办内容。
+- `首页常用` 只能放快捷动作，不重复底部 Tab。推荐动作是新建报销、上传票据、请假、资产扫码、发起采购等；报销、审批/进度、我的这类一级入口不应再次出现在常用宫格。
+- `首页待处理` 只保留一张轻摘要。审批人可以看到待批数量和 1 条最紧急待办，员工可以看到我发起的进度摘要；不得同时出现总数、三宫格指标、待办列表、卡片状态和进入按钮五层重复。
+- `审批/进度页` 按角色分流：员工使用草稿、审批中、已通过、退回驳回等状态标签查看我发起的事项；审批人使用待我审批、已处理标签查看任务；两者不得混成同一个无分组流水列表。
+- `通知中心` 是事件收件箱，不是待办列表或进度页副本。通知卡片优先展示事件类型、标题、时间和已读状态，点击先标记已读再直达业务详情；通知页不展示审批动作按钮。
+- `详情页` 是业务事实源。所有移动深层详情统一使用同一详情壳：左侧返回，标题和副标题居中或左侧主内容区，右侧状态；隐藏底部 Tab；内容顺序为摘要、关键字段、材料/附件/发票、审批流、下一步动作。
+- `返回语义` 优先回到来源页或来源标签；没有来源时回到对应业务列表或进度标签。不得从已批准记录详情返回到新建表单顶部，也不得把采购详情无条件返回审批首页。
+- `角色首页` 必须体现角色优先级。员工优先我的申请和快捷动作，审批人优先待批，财务优先待复核、待付款、台账和导出；不同角色可共用框架，但摘要、入口和动作必须裁剪。
+- `真机差异` 不按单机型写补丁。iPhone 12/iOS 14 企业微信等真实 WebView 间距问题应先纳入截图样本和移动 token 复核，再通过统一槽位、间距 token 或安全区规则修正。
+
 ## 色彩规则

 - 主色：品牌蓝/青色系，用于主按钮、选中态、链接和轻量提示。
@@ -106,6 +106,8 @@ R7/OPS7/DOC7 非真机准备（2026-05-12）：已创建 `issues/2026-05-12_17-4

 DG7/MRF7 移动信息架构与展示去重治理收口（2026-05-12）：已根据 iPhone 12、iPhone 14 和 Redmi K60 企业微信真机反馈建立首页/审批/通知/业务卡片去重规约，并完成移动端实现与部署。员工底部“审批”入口改为“进度”视角，展示我发起的报销、请假、采购进度且不显示审批动作；审批人仍使用“审批”视角。首页只保留一处待处理摘要，首页通知不再重复完整待办；底部审批角标移到图标右上外侧，不覆盖图标或文字。审批详情改为 `/mobile/approvals/:taskId` Push 页并隐藏底部 Tab；通知中心卡片整体可点，先标记已读再直达报销、请假、采购或审批移动详情；采购和请假通知不再回首页或新建表单。PC/移动卡片展示引入共享业务主标识工具，同一卡片不重复业务编号或状态；`check-ui-design-rules.mjs` 已增加重复业务编号扫描规则。验证结果：`client typecheck/build`、`check-ui-design-rules --self-test/--strict`、DG7 专项 3 passed、WCM6 11 passed、R124/R6 响应式/MUD6 15 passed。已执行 `bash deploy/trialrun/deploy.sh`，公网 `/ready` 正常，public bundle `findings=0`，live smoke readiness PASS，报告 `artifacts/qa-flow/live-smoke-readiness-20260512-205559`；公网移动视觉矩阵 7 passed，报告 `artifacts/qa-flow/dg7-mobile-information-dedupe-governance-visual-matrix-20260512-205634`。因当前无法做完整三机复测，`ME6-3` 继续保持 TODO，不用本轮自动化替代真机门禁。

+MIA7 移动信息架构、视觉与流程审查（2026-05-12）：用户完成一轮 iPhone12/iPhone14/Redmi 企业微信真机抽查后，确认上一轮硬问题基本关闭，但发现首页、常用入口、待处理摘要、进度、通知、详情返回和角色首页仍存在信息架构层面的重复与不一致。已基于 `9da0ca9`、现有移动截图、页面源码和公开同类产品原则创建 `issues/2026-05-12_21-48-39-mobile-ia-visual-flow-review.csv`，并输出审查报告 `docs/trialrun/mobile-ia-visual-flow-review.md`。本轮只做标准和问题登记：已把 MIA7 移动工作台、进度、通知、详情壳和返回语义写入 `docs/product-design-rules.md`，并新建后续整改合同 `issues/2026-05-12_21-48-40-mobile-ia-flow-remediation.csv`。MIA7 结论不代表问题已修复；MIF7 仍为 TODO，`ME6-3` 真机门禁仍保持待确认。
+
 ## 结论

 R70 初次试运行暂停项已在 2026-04-28 的 R71 定向修复后关闭。基于本地环境复测，经理团队日历与员工报销缺票提示/发票上传绑定提交链路均已通过，可恢复下一轮本地人工试运行。
@@ -0,0 +1,122 @@
+# MIA7 移动 OA 信息架构、视觉与流程审查
+
+审查日期：2026-05-12
+代码基线：`9da0ca9`
+审查范围：专用 `/mobile` 路由的首页、审批/进度、通知、报销详情、请假详情、采购详情、财务/审批人首页角色差异。
+本轮性质：审查、规约和整改合同，不改业务代码，不部署，不关闭 `ME6-3` 真机门禁。
+
+## 参考原则
+
+公开资料只能抽象为本项目原则，不复制竞品页面：
+
+- 钉钉审批强调假勤、财务等高频审批场景和手机端处理能力，适合作为“移动端服务高频轻任务”的方向参考：https://page.dingtalk.com/wow/dingtalk/act/approval-web
+- 飞书审批强调统一入口聚合人事、财务、采购等流程、消息主动触达和移动端处理，适合作为“一个审批/进度入口 + 通知直达”的方向参考：https://www.feishu.cn/content/article/7584390246654037188
+- 飞书催办说明发起人从“我发起的”任务详情发起催办，处理人收到消息通知，适合作为 AP6 催办语义的产品参考：https://www.feishu.cn/content/134344362384
+- Ant Design Mini 的 TabBar、List、Tabs、SafeArea 分别对应底部主导航、列表槽位、分组切换和安全区语义：https://0x-mini.ant.design/components/tab-bar/ ，https://0x-mini.ant.design/components/list/ ，https://0x-mini.ant.design/components/tabs/ ，https://0x-mini.ant.design/components/safe-area/
+- 企业微信应用消息适合作为 OA deeplink 通知通道，正式审批和业务状态仍以 OA 内部权限和状态机为准：https://s.apifox.cn/apidoc/docs-site/406014/api-10061693
+
+落到 hyb-oa 的设计基线：移动端是消息驱动的轻工作台；首页只回答今天最该处理什么；审批/进度承载待我审批和我发起的进度；通知是事件收件箱；详情页是业务事实源。
+
+## 当前标准
+
+后续 MIF7 整改按 `docs/product-design-rules.md` 的 MIA7 标准执行：
+
+- 底部导航只承载一级模块，首页常用只放快捷动作，不重复底部 Tab。
+- 首页待处理最多一张轻摘要，不同时堆总数、三宫格、列表、状态标签和入口按钮。
+- 员工进度使用草稿、审批中、已通过、退回驳回分组；审批人使用待我审批、已处理分组。
+- 通知中心是事件收件箱，卡片展示事件、时间和已读状态，点击直达业务详情，不展示审批动作。
+- 移动深层详情统一详情壳：左侧返回、标题/副标题、右侧状态、隐藏底部 Tab，内容按摘要、关键字段、材料、审批流、下一步动作排列。
+- 返回优先回来源；无来源时回对应业务列表或进度标签，不回新建表单顶部。
+
+## 视觉与源码证据
+
+已核对的自动化截图：
+
+- `output/playwright/r6-wecom-mobile-rendering-hardening/w390-iphone12-wecom-mobile-home.png`：390 x 844。
+- `output/playwright/r6-wecom-mobile-rendering-hardening/w414-iphone-wecom-mobile-home.png`：414 x 896。
+- `output/playwright/mobile-oa-information-dedupe-governance/employee-progress-w390.png`：390 x 844。
+- `output/playwright/mobile-oa-information-dedupe-governance/employee-progress-w414.png`：414 x 844。
+- `output/playwright/mobile-oa-information-dedupe-governance/manager-approval-push-detail.png`。
+- `output/playwright/mobile-oa-information-dedupe-governance/notification-direct-leave-detail.png`。
+
+关键源码证据：
+
+- 首页常用入口与底部导航重复：`client/src/pages/MobilePortalPage.tsx:223`，`client/src/features/mobile/navigation.ts:30`。
+- 审批人首页待处理摘要重复层级：`client/src/pages/MobilePortalPage.tsx:276`。
+- 员工进度页未按状态分标签：`client/src/pages/MobileApprovalsPage.tsx:915`。
+- 通知中心仍使用业务列表卡片语义：`client/src/pages/MobileNotificationsPage.tsx:126`。
+- 报销详情自定义左返回：`client/src/pages/MobileReimbursementDetailPage.tsx:798`。
+- 请假详情使用右侧返回且回到新建表单页：`client/src/pages/MobileLeavePage.tsx:279`、`client/src/pages/MobileLeavePage.tsx:308`。
+- 采购详情使用右侧返回且固定回审批/进度：`client/src/pages/MobilePurchaseRequestDetailPage.tsx:53`。
+- 通用 `PageHeader` 把 actions 放右侧，不适合作为移动深层详情返回壳：`client/src/components/common/PageHeader.tsx:14`。
+- 首页图标宫格和 iPhone 12 间距相关 CSS：`client/src/styles/mobile-touch.css:55`，390px 宽度不会触发 `max-width: 359px` 的小屏特化。
+
+## 问题分级
+
+### 严重
+
+1. 首页常用入口重复底部导航。员工常用里仍可能出现报销、进度、我的；审批人也会看到审批/报销/我的重复。问题根因是 `primaryActions` 直接复用了底部一级入口语义。建议常用只保留新建报销、传票据、请假、资产扫码、发起采购等动作。
+
+2. 审批人首页待处理摘要过度重复。当前同一张卡内同时有 `1 待批`、待办/超时/类型三项数字、待办摘要卡、摘要卡 `待处理` 和 `进入审批`。这会让用户觉得首页有多块相同信息。建议压缩为一张轻摘要：标题、一个主数字、最紧急一条、一个“查看全部待办”入口。
+
+3. 移动详情壳不统一。报销详情、请假详情、采购详情的返回位置、标题大小、状态位置和内容顺序不同；请假/采购返回按钮在右侧，报销返回在左侧。建议抽出统一 `MobileDetailShell` 或同等组件，所有深层详情复用。
+
+4. 返回语义不稳定。报销回报销列表，请假回 `/mobile/leave` 但首屏是新建表单，采购固定回 `/mobile/approvals`。用户从通知或进度进入详情后，返回应优先回来源；无来源时回对应业务列表或进度标签。
+
+### 一般
+
+5. 员工进度缺少状态标签。草稿、审批中、已通过、退回驳回混在“我发起的”列表，和通知中心的事件列表观感接近。建议用标签或分段，默认显示“审批中”，草稿和已通过可切换。
+
+6. 通知中心和进度页视觉语义过近。通知卡片仍像业务卡片，缺少事件流特征。建议通知卡片增加事件类型图标、未读主导、时间和来源，弱化金额/节点等业务详情字段，不展示审批动作。
+
+7. 请假移动页把新建表单和记录列表放在同一长页。用户从已批准请假返回时容易落到新建请假语境。建议拆成“新建请假”和“请假记录”两个入口或在同页使用分段标签，详情返回记录标签。
+
+8. 采购缺少清晰移动列表入口。已有详情页，但没有明确“我的采购”移动列表承接返回和历史查看，导致采购详情只能回审批/进度。建议在进度页保留来源参数，或补轻量我的采购列表入口。
+
+9. 财务和经理首页差异不够。当前移动首页主要围绕审批能力判断，财务角色缺少待复核、待付款、台账/导出优先摘要。建议财务首页独立摘要卡显示待复核、待付款、风险/异常、进入台账。
+
+10. `进入审批` 文案不精确。点击待办摘要进详情，点击按钮进列表，这个行为可以保留，但按钮应改成“查看全部待办”或“进入待办列表”，避免误解。
+
+11. iPhone 12 图文间距仍需用用户真机截图复核。现有 Chromium 截图没有完整复现真实 iOS 14 企业微信差异；CSS 在 390px 宽度下使用默认图标宫格间距，可能受 iOS 14 WebView 字体渲染或企业微信内核影响。建议后续把用户 iPhone12 和 iPhone14 截图作为 MIF7 视觉样本，不按机型硬编码。
+
+### 体验建议
+
+12. 首页中“待办、超时、类型”三项指标适合审批效率页或管理统计，不适合移动首页首屏。移动首页应优先行动，不优先统计。
+
+13. 通知中心的作用需要在产品模型中固定为“事件收件箱”：看发生了什么、快速进入详情、批量已读。审批进度才负责看状态，不要两边都承担状态追踪。
+
+14. 深层详情内容应统一信息顺序，但字段按业务差异裁剪：报销突出金额、发票、附件、审批、付款；请假突出日期、天数、假别、原因、审批；采购突出金额、供应商、明细、附件、审批。
+
+## 角色流程审查
+
+| 角色 | 当前可用 | 主要问题 | 建议目标 |
+| --- | --- | --- | --- |
+| 普通员工 | 底部进入“进度”；通知可直达报销/请假/采购详情；采购和请假不再跳首页 | 常用入口重复底部 Tab；进度未分状态；请假返回落到新建表单；通知与进度视觉接近 | 首页只放快捷动作和进度摘要；进度按状态标签；详情返回记录或来源标签 |
+| 审批人/经理 | 首页有待处理摘要；底部审批角标正常；待办摘要可进入详情，按钮进入列表 | 首页待处理重复层级过多；按钮文案不精确；详情壳和返回不统一 | 首页只保留一个待办摘要；按钮改“查看全部待办”；审批详情统一 Push 壳 |
+| 财务 | 底部红色角标可接受；财务可使用已实现台账和付款能力 | 财务首页和经理首页差异不明显，缺少待复核/待付款/导出摘要 | 财务首页优先财务待办、付款、风险异常、台账/导出入口 |
+
+## 自动化规则建议
+
+后续 MIF7 或 QG7 可以落地以下断言：
+
+1. 首页常用入口与底部导航重复数不得超过 0；如保留一级入口，必须有明确白名单和理由。
+2. 首页待处理摘要同一卡片内数量表达层级不得超过 2 个，例如主数字加一条待办，不再出现三宫格统计。
+3. 普通员工 `/mobile/approvals` 必须存在状态标签或分段：草稿、审批中、已通过、退回驳回。
+4. 通知中心卡片不得包含审批动作按钮；点击有目标的通知必须进入业务详情或审批详情。
+5. 所有 `/mobile/*/:id` 深层详情必须隐藏底部 Tab，并存在统一左侧返回控件。
+6. 请假详情返回不得落到新建表单顶部；采购详情不得无条件返回审批首页。
+7. 财务账号移动首页必须出现财务摘要或财务入口，且不与经理首页完全同构。
+8. 移动视觉矩阵继续覆盖 320、360、375、390、393、414、430px；真实 iPhone12/iOS14 企业微信截图作为单独人工样本，不用自动化替代。
+
+## 后续整改顺序
+
+建议后续执行 MIF7，而不是继续逐个按钮修：
+
+1. 首页去重和常用动作重排。
+2. 进度/审批分标签。
+3. 通知中心事件化。
+4. 统一移动详情壳和返回语义。
+5. 财务首页角色化摘要。
+6. 自动化断言和真机截图复核入口。
+
+本报告只登记问题和标准，不代表上述问题已修复。