"ID","Title","Description","Acceptance","Test_Method","Tools","Dev_Status","Review1_Status","Regression_Status","Files","Dependencies","Notes"
"OAFRONT2-0","建立前端设计细化审计合同","按 MAGI 审视、执行、提升轮次，在 OAFRONT1 基础上继续做页面级、组件级、视觉层级和交互体验审计；本合同只记录建议和后续采纳门禁，不直接修改 UI 代码、不部署、不写公网业务数据。","本 CSV 校验通过；每条建议有明确页面范围、验收方式和是否需要人工采纳；自动截图通过不等于设计成熟闭环的边界被写清。","受影响流程：设计事实源 -> OAFRONT1 证据 -> 截图/代码抽样 -> OAFRONT2 建议台账 -> 用户采纳决策；验证步骤：validate_issues_csv.py 本 CSV；check-process-contract general；git diff --check。","python3|node|git|manual","DONE","DONE","DONE","issues/2026-05-24_23-28-05-oa-frontend-design-detailed-audit-v1.csv","[]","已通过 validate_issues_csv.py、check-process-contract general 和 git diff --check；本轮已复核 docs/产品设计规则.md、OAFRONT1 CSV、移动视觉矩阵截图、PC 历史截图和页面结构统计；不改业务代码。回滚/清理：如不采纳本审计，只删除本 CSV 或在后续合同标记 superseded。"
"OAFRONT2-1","修正视觉矩阵截图时机，避免动效中间态误判","当前移动矩阵截图中首页、我的、采购、请假多处内容整体偏淡，结合代码可见 .page-scaffold 有 420ms page-reveal opacity 动画，而 r6-mobile-unified-design-rollout 进入页面后立即截图；截图可能截到动效中间态，导致把最终态页面误判为低对比或 disabled。","视觉矩阵在截图前等待目标 marker 可见后，再等待 page-scaffold opacity=1 或统一禁用动画；新截图中移动首页、我的、采购、请假不再出现整页内容半透明；报告明确记录截图稳定等待。","受影响流程：视觉矩阵 -> 移动页面截图 -> 设计审计判断；验证步骤：VISUAL_MATRIX_SCOPE=mobile bash scripts/qa/run-visual-matrix.sh live；人工比对 output/playwright/<issue>/mobile-matrix/w320-* 首页、我的、采购、请假截图；必要时新增 opacity metric。","playwright|node|manual","TODO","TODO","TODO","client/tests/e2e/r6-mobile-unified-design-rollout.spec.ts;scripts/qa/run-visual-matrix.sh;client/src/index.css","[""OAFRONT2-0""]","优先级 P0/P1，先修证据工具再判断真实低对比问题。建议实现口径：测试环境截图前等待动画结束，或在视觉测试上下文注入 prefers-reduced-motion/disable-animation，不改真实用户动效。"
"OAFRONT2-2","移动首页工作台层级需要最终态复核","移动首页应是消息驱动轻入口，但当前截图中的标题、待处理卡、财务卡、常用和考勤内容在 320 宽下显得过浅；若排除截图动效后仍存在，则会影响员工在企业微信内快速判断今天该做什么。","最终态截图中 首页标题、待处理数量、主待办、常用入口、财务/考勤卡标题达到清晰可读；待办摘要只保留一处，快捷入口不重复底部 Tab；不引入黑色大块背景。","受影响流程：企业微信进入 OA -> 首页查看待处理/常用/财务/考勤 -> 点击进入业务；验证步骤：先完成 OAFRONT2-1 稳定截图；复跑移动视觉矩阵；人工比对 w320/w390 首页；真机或 Codex Desktop 复核首页 5 秒内能看清主动作。","playwright|manual","TODO","TODO","TODO","client/src/pages/MobilePortalPage.tsx;client/src/styles/mobile-touch.css;client/src/index.css","[""OAFRONT2-1""]","优先级 P1。设计建议：以报销详情页的强标题和金额层级为参考，调移动标题、卡片标题、状态和按钮 token；不要重排整个首页信息架构。"
"OAFRONT2-3","移动我的页个人信息与入口可点性偏弱","移动我的页截图中个人信息、账号与绑定、更多入口接近 disabled 观感；页面还使用 SectionPanel 承载移动内容，虽然装饰顶线已隐藏，但视觉强度和移动卡片语义不如 mobile-card/mobile-action-link 统一。","最终态我的页中姓名、部门、员工号、个人设置、账号资料、通知/请假/报销/审批入口都清楚可读并像可点击项；管理员入口不误导普通员工；企业微信提醒开关说明不过度占首屏。","受影响流程：员工进入 我的 -> 查看账号 -> 修改通知偏好 -> 进入更多业务；验证步骤：稳定截图后比对 w320/w390 我的；检查移动入口 hit target >=44px；无横向溢出；普通员工不看到无权限管理入口。","playwright|manual","TODO","TODO","TODO","client/src/pages/MobileMePage.tsx;client/src/styles/mobile-touch.css;client/src/components/patterns/SectionPanel.tsx","[""OAFRONT2-1""]","优先级 P1。建议小步：移动我的页优先改 token/卡片层级和入口文案，不立刻重做个人中心信息架构。"
"OAFRONT2-4","移动采购和请假页面 CTA 与状态层级需复核","采购、请假在 320 截图中标题、统计、标签和新建按钮均偏淡，像不可用状态；请假还显示浏览器默认日期占位 mm/dd/yyyy，和国内 OA 语境不一致。","稳定截图后采购和请假页面主标题、状态标签、新建按钮、表单字段、日期控件都清楚可用；日期展示使用中文用户可理解语义；冻结或不可用控件有明确原因，不让用户误判为系统不可操作。","受影响流程：手机查看采购申请 -> 查看状态；手机请假 -> 新建请假 -> 选择假期类型和日期；验证步骤：移动矩阵 w320/w390 采购、请假截图；表单字段可点击；无桌面表格；无英文日期占位作为主要提示。","playwright|manual","TODO","TODO","TODO","client/src/pages/MobilePurchaseRequestsPage.tsx;client/src/pages/MobileLeavePage.tsx;client/src/styles/mobile-touch.css","[""OAFRONT2-1""]","优先级 P1。企微 HR/考勤主办已冻结，OA 请假移动页如仅作镜像/应急入口，需要在页面口径上避免误导为常规主办。"
"OAFRONT2-5","移动审批列表已可用但筛选与批量入口偏重","移动审批页相比其他移动页更清楚，待我审批、在线状态、搜索、筛选与批量、审批卡片层级基本成立；但 320 宽首屏中过早展示搜索和筛选与批量，会挤压真正待办内容。","审批人首屏优先看到待批数量和第一条待办；搜索、筛选和批量保持可用但不抢占主待办；员工视角仍清楚区分我发起的进度和待我审批，不混成一个流水列表。","受影响流程：审批人企业微信进入审批 -> 看详情 -> 处理；员工进入审批进度 -> 查看自己提交的事项；验证步骤：移动矩阵审批页；角色化登录截图；待办卡片状态、申请人、金额/天数、当前节点不重复。","playwright|manual","TODO","TODO","TODO","client/src/pages/MobileApprovalsPage.tsx","[""OAFRONT2-0""]","优先级 P2。当前不作为 launch blocker；若真实审批人反馈找不到待办，再提升优先级。"
"OAFRONT2-6","移动报销详情可作为移动深层页正向样板","移动报销详情截图层级清楚：返回、业务编号、状态、金额、明细、吸底操作都明确，是当前移动端最接近设计规则的页面；应作为后续采购详情、请假详情、资产扫码结果、审批详情的参考样板。","形成移动深层详情页统一验收口径：顶部返回和状态、摘要卡、关键字段、材料/附件/审批流、吸底操作；采购详情、请假详情、资产扫码结果后续迁移时对齐该样板。","受影响流程：移动详情打开 -> 扫读事实 -> 补材料/提交/审批；验证步骤：以 w320 报销详情为基准，比对采购详情、请假详情、审批详情；深层页隐藏底部 Tab；主操作高度 >=44px。","playwright|manual","TODO","TODO","TODO","client/src/pages/MobileReimbursementDetailPage.tsx;client/src/pages/MobilePurchaseRequestDetailPage.tsx;client/src/pages/MobileLeavePage.tsx;client/src/pages/MobileApprovalsPage.tsx","[""OAFRONT2-0""]","优先级 P1/P2。建议先写入设计事实源或后续实现合同，不在本审计里直接重构。"
"OAFRONT2-7","PC Portal 更像柔和展示页而非高密度工作台","PC Portal 历史截图中 hero 面积较大、装饰圆纹明显、卡片圆角偏大、英文测试姓名可见，并存在较大空白区；对 10 人小团队日常使用，首屏应更直接呈现待办、草稿、退回、财务待处理、合同/资产提醒和最近动作。","采纳后 PC Portal 首屏减少营销式 hero 和装饰，强化工作台密度；测试账号显示中文职能名或中文姓名；空白区被真实工作摘要、可行动入口或清晰空状态替代。","受影响流程：PC 登录 -> 今日工作台 -> 进入报销/审批/财务/合同/资产；验证步骤：PC 1440 截图对比 Hyinda 官网基线和 DG9 工作台规则；无 English smoke name 作为主展示；首屏可见 P0/P1 关键入口。","playwright|manual","TODO","TODO","TODO","client/src/pages/PortalHomePage.tsx;client/src/index.css;client/src/components/patterns/WorkbenchHero.tsx","[""OAFRONT2-0""]","优先级 P2，建议等 7 天真实反馈后决定是否动 Portal 布局；可先做 smoke 账号中文展示和 hero 小步收敛。"
"OAFRONT2-8","PC 报销列表密度合格但空态和动作权重可再收敛","报销列表已使用 ListWorkspace，密度和状态分组较好；但空数据时统计卡、筛选区和表格之间留白较大，删除/导出/新建等动作权重需要跟真实状态绑定，避免员工首屏看起来像空系统。","报销列表在有数据和无数据时都能清楚表达下一步；草稿可编辑/删除，审批中不可删除，已支付不提供危险动作；空态引导新建报销或上传发票，不让表格空白成为主体。","受影响流程：员工打开报销列表 -> 继续草稿/新建/查看状态 -> 财务导出；验证步骤：PC 和移动报销截图；权限角色切换；check-ui-design-rules；相关回归不出现原生英文或内部术语。","playwright|manual","TODO","TODO","TODO","client/src/pages/ReimbursementsPage.tsx;client/src/components/patterns/ListWorkspace.tsx","[""OAFRONT2-0""]","优先级 P2。当前不阻塞上线；若真实员工反馈找不到新建/继续编辑，再升级。"
"OAFRONT2-9","合同台账和资产台账表单布局需要面向真实录入优化","合同台账截图中新增表单占据大量左列，列表在右列，日期输入仍显示 mm/dd/yyyy，状态值 active 偏码值；资产台账截图中分类管理和资产列表并列，但缺少明显的新建资产主动作，容易让管理员先被分类表单吸走注意力。","合同台账和资产台账真实录入路径清楚：新建/列表/筛选/详情/归档位置分层；日期和状态使用中文业务文案；资产主动作明显；敏感字段仍只登记摘要或线下归档位置。","受影响流程：管理员录入合同台账 -> 筛选合同 -> 记录归档位置；管理员录入资产 -> 分类 -> 建卡 -> 查看/筛选；验证步骤：PC 1440 截图；创建 1 条测试合同/资产的人工或自动流程；普通员工权限负例。","playwright|manual","TODO","TODO","TODO","client/src/pages/ContractsRegistryPage.tsx;client/src/pages/AssetRegistryPage.tsx","[""OAFRONT2-0""]","优先级 P1/P2。ASSET1D 已进入真实试录，资产页如真实使用卡顿应优先；合同页可随 OALAUNCH1 真实合同台账验收同步收敛。"
"OAFRONT2-10","C 类管理配置页需要统一高密度但不追求员工化","多处 C 类页面仍使用 PageHeader + card-std，例如人员、组织、Feature Flag、通知通道、审计、薪资、绩效等；这些页面可以保留中后台密度，但页头、筛选、空态、危险动作确认和内部字段展示例外需要统一规则。","C 类页面形成统一后台样板：标题、短说明、筛选/列表、详情/配置区、审计字段；只有管理员排障页允许展示必要内部 ID；危险动作都有确认；普通员工不可见管理入口。","受影响流程：管理员维护用户/组织/配置/审计 -> 保存/启停/导出；验证步骤：权限矩阵负例；PC 截图；danger action confirm；无普通员工越权入口。","playwright|manual","TODO","TODO","TODO","client/src/pages/PeoplePage.tsx;client/src/pages/DepartmentsPage.tsx;client/src/pages/FeatureFlagsPage.tsx;client/src/pages/NotificationChannelsPage.tsx;client/src/pages/AuditLogsPage.tsx","[""OAFRONT2-0""]","优先级 P2。不要在 launch 前大面积重构后台配置页，只记录样板并在后续单页修复时套用。"
"OAFRONT2-11","全局 PC 视觉 token 偏装饰化，需要小步收敛","index.css 中 body、workbench-hero、metric-card、section-panel、portal-action-tile 等使用多处 radial/linear gradient、装饰圆纹、较大 panel 圆角和阴影；这和产品设计规则中的工作台定位存在轻微张力。","采纳后 PC A/B 类业务页减少装饰性渐变和圆纹，卡片圆角和阴影更克制；移动端继续保留 12px 左右卡片；Hyinda 品牌蓝仍用于主按钮、选中态和重点链接。","受影响流程：PC 工作台、报销、合同、资产、财务页面扫读；验证步骤：PC 1440 截图对比；不破坏现有移动矩阵；不引入黑色大块背景或单一蓝色主题。","playwright|manual","TODO","TODO","TODO","client/src/index.css;client/src/design/tokens.ts;client/src/design/theme.css;client/src/components/patterns","[""OAFRONT2-0""]","优先级 P2。建议以视觉 token 小步收敛，不逐页手改样式。"
"OAFRONT2-12","大页面拆分应服务设计一致性而非纯代码洁癖","页面统计显示 ReimbursementDetail 1894 行、PurchaseRequests 1793 行、MobileApprovals 1664 行、ApOperations 1636 行、EmployeeProfile 1552 行、MobileReimbursementDetail 1507 行、AssetRegistry 1400 行、PortalHome 1219 行；这些页面承载过多状态、表单、列表和弹窗，后续设计修复容易牵连。","采纳后按真实高频路径逐页拆成 section/card/dialog/action 组件；每次只拆一个页面，不改 API、权限、状态机或路由；拆分后页面视觉截图和功能回归通过。","受影响流程：核心页面维护 -> 设计一致性修复 -> 回归；验证步骤：client typecheck/build；相关 Playwright；页面文件降低复杂度但业务行为不变。","typescript|playwright","TODO","TODO","TODO","client/src/pages/ReimbursementDetailPage.tsx;client/src/pages/PurchaseRequestsPage.tsx;client/src/pages/MobileApprovalsPage.tsx;client/src/pages/ApOperationsPage.tsx;client/src/pages/EmployeeProfilePage.tsx;client/src/pages/MobileReimbursementDetailPage.tsx;client/src/pages/AssetRegistryPage.tsx;client/src/pages/PortalHomePage.tsx","[""OAFRONT2-0""]","优先级 P2。建议 launch 前不做大拆分；上线稳定后从真实反馈最多的 1 个页面开始。"
"OAFRONT2-13","高频页说明文案仍应继续压缩","产品设计规则要求首屏少解释，多给下一步动作；抽样可见 Portal、Profile、Leave、ApprovalRules、Dashboard 等页面有较多 subtitle/description，小团队真实使用后容易变成阅读负担。","A/B 类页面首屏标题短、动作明确、空态说明现状和下一步；C 类页面保留必要配置说明；文案不讲设计意图、不解释系统边界过长、不出现竞品或内部治理话术。","受影响流程：员工/审批人/财务打开高频页 -> 识别下一步动作；验证步骤：rg subtitle/description 清单；截图首屏可见主动作；check-ui-design-rules 可扩展文案规则。","rg|manual|playwright","TODO","TODO","TODO","client/src/pages;docs/产品设计规则.md","[""OAFRONT2-0""]","优先级 P1/P2。建议优先清理移动首页、我的、报销、审批、合同台账、资产台账，不在后台配置页一刀切。"
"OAFRONT2-14","设计 QA 需要从结构检查升级到视觉质量指标","OAFRONT1 中 check-ui-design-rules 0 未抑制 finding，说明当前规则能查禁词、黑色块、内部术语等硬错误，但不能量化动效截图时机、低对比文本、DG9 覆盖率、PC 装饰密度、页面复杂度和真实首屏可读性。","新增或扩展 QA-only 设计审计报告：输出移动截图稳定性、低对比风险、DG9 样板覆盖率、PageHeader/ListWorkspace 分布、大页面清单、PC 渐变/圆角密度；报告脱敏且只读。","受影响流程：设计审查 -> 自动证据 -> 采纳决策 -> 后续 UI 修复；验证步骤：node scripts/qa/check-ui-design-rules.mjs --json；新增报告不含密码、token、真实票据、合同正文、完整账号或完整本地路径。","node|playwright","TODO","TODO","TODO","scripts/qa/check-ui-design-rules.mjs;scripts/qa/run-visual-matrix.sh;client/tests/e2e/project-wide-visual.spec.ts","[""OAFRONT2-0""]","优先级 P1，推荐优先采纳。先把证据工具做扎实，再决定哪些页面真改。"
"OAFRONT2-15","用户采纳问答门禁","本轮建议涉及 QA 工具、小步可读性、PC 视觉收敛、大页面拆分和真实反馈池；进入开发前需要用户明确采纳范围，避免因主观审美重排影响 OALAUNCH1 启用节奏。","用户对 4 组给出 A/B/C 决策：1) 先修视觉矩阵截图稳定性和低对比证据；2) 先做移动首页/我的/采购/请假小步可读性；3) PC Portal/合同/资产视觉收敛是否等 7 天反馈；4) 大页面拆分是否后置。未采纳项不得进入开发。","受影响流程：审计建议 -> 用户 A/B/C 决策 -> 新实施合同 -> 开发/暂缓/否决；验证步骤：人工回填用户选择并 validate CSV。","manual|python3","TODO","TODO","TODO","issues/2026-05-24_23-28-05-oa-frontend-design-detailed-audit-v1.csv","[""OAFRONT2-0""]","默认推荐：组1=A，组2=A 但先等 OAFRONT2-1 稳定截图后小步修，组3=B 等 7 天反馈，组4=B 后置到 launch 后。"