治理前端设计规则 05-26-oa-seven-day-trial-live-ops

.trellis/spec/frontend/index.md

@@ -5,9 +5,10 @@
 ## Overview
 
 hyb-oa frontend work uses React, TypeScript, Vite and Tailwind under `client/`.
-The project-specific frontend/design rules live in
-`../hyb-oa/frontend-react-vite-design.md`; detailed visual facts remain in
-`docs/产品设计规则.md`.
+The project-specific frontend implementation rules live in
+`../hyb-oa/frontend-react-vite-design.md`; product experience facts remain in
+`docs/产品设计规则.md`. Visual and interaction design authority comes from the
+installed `frontend-design` skill.
 
 ---
 

.trellis/spec/hyb-oa/frontend-react-vite-design.md

@@ -3,9 +3,10 @@
 ## Source Of Truth
 
 Frontend visual and interaction design uses the installed `frontend-design`
-skill as the primary design authority. `docs/产品设计规则.md` remains a product,
-brand and historical fact source, not the final aesthetic tie-breaker. For
-PC/mobile/WeCom pages, add Playwright or visual verification when reasonable.
+skill as the primary design authority. `docs/产品设计规则.md` remains a product
+experience and business-boundary fact source, not a visual, brand or aesthetic
+rulebook. For PC/mobile/WeCom pages, add Playwright or visual verification when
+reasonable.
 
 ## Rules
 
@@ -16,8 +17,9 @@ PC/mobile/WeCom pages, add Playwright or visual verification when reasonable.
   Trellis, deployment and business data boundaries.
 - PC pages should keep dense but orderly OA layouts: clear header, filters,
   table/list, status, details and predictable actions.
-- Mobile pages must use the unified mobile shell, card/list rows, safe-area and
-  sticky action patterns from the design rules.
+- Mobile pages must reuse the existing unified mobile shell, card/list rows,
+  safe-area and sticky action patterns unless the current task intentionally
+  redesigns them with `frontend-design`.
 - Do not add decorative landing-page styling to operational OA pages.
 - Run `cd client && npm run typecheck && npm run build` for frontend changes.
 

.trellis/tasks/05-26-oa-seven-day-trial-live-ops/implement.md

@@ -33,3 +33,10 @@
 - findingCount：0
 - 主报告：`research/day2-oa-real-use-daily/summary.json`
 - 备注：首次运行时企业微信渲染矩阵因测试 mock 未覆盖 `/api/auth/capabilities` 报错；已补 mock 并复跑完整 Day 2 巡检通过。
+
+## 设计规则治理
+
+- 用户确认项目旧有前端设计规则重复且噪音过大后，已将 `docs/产品设计规则.md` 从“设计规则基线”瘦身为“产品体验事实源”。
+- 前端视觉、布局审美、组件观感、字体、颜色、动效、间距和交互细节统一以 `frontend-design` skill 为裁决来源。
+- `docs/产品设计规则.md` 仅保留 hyb-oa 特有的目标用户、PC/移动/企业微信职责、页面分层、信息语义、OA/企微主办边界和验收边界。
+- 已同步 AGENTS、Trellis frontend spec、文档索引、事实源矩阵、Agent 交付实践、试运行手册、测试规约和相关业务规约，避免后续 agent 继续引用旧的竞品/品牌/样板设计规则。

AGENTS.md

@@ -19,14 +19,14 @@
 - 中文沟通；commit message 使用中文并引用 Trellis task 名称或任务 ID。
 - 不泄露密码、token、Secret、真实票据、合同正文、银行资料、完整账号、完整本地路径或原始 payload。
 - 不轻易新建文档；优先更新现有事实源、模块规约、操作手册、证据文档或当前 Trellis task。
-- 页面视觉与交互设计以 `frontend-design` skill 为准；`docs/产品设计规则.md` 仅保留业务事实、品牌识别和验收参考。
+- 页面视觉与交互设计以 `frontend-design` skill 为准；`docs/产品设计规则.md` 仅保留业务体验事实、信息架构和验收边界。
 - 面向用户可测试的改动，只有部署与公网检查通过后才能告知用户可以测试。
 
 ## 当前项目事实源
 
 - 文档入口与状态：`docs/文档索引.md`、`docs/文档事实源状态矩阵.md`
 - Agent/Trellis 交付实践：`docs/Agent开发交付实践.md`
-- 产品/品牌事实与历史视觉规则：`docs/产品设计规则.md`（视觉裁决以 `frontend-design` skill 为准）
+- 产品体验事实源：`docs/产品设计规则.md`（视觉裁决以 `frontend-design` skill 为准）
 - 报销、发票、OCR、附件规则：`docs/报销发票附件规则.md`
 - 试运行与自动化验证：`docs/试运行与自动化验证手册.md`
 - Trellis workflow：`.trellis/workflow.md`
@@ -52,4 +52,4 @@
 - 默认按 Trellis workflow 执行：task/prd -> design/implement notes（按需） -> implement -> check -> spec/docs update -> commit -> finish。
 - 涉及权限模型、状态机、workflow、数据迁移、审批规则时，实施后必须启动只读 review，不让 reviewer 改代码。
 - 公网部署、生产配置、真实数据写入、数据库重置、企业微信写入和真实付款必须另行获得明确批准。
-- 若 Trellis 规则与业务文档冲突：当前 Trellis task PRD/设计 > 当前模块规约 > 业务规约和 `docs/产品设计规则.md` 中的事实源内容 > Trellis spec > 历史证据；前端视觉裁决优先使用 `frontend-design` skill，历史 Issue CSV 只用于追溯。
+- 若 Trellis 规则与业务文档冲突：当前 Trellis task PRD/设计 > 当前模块规约 > 业务规约和 `docs/产品设计规则.md` 中的体验事实 > Trellis spec > 历史证据；前端视觉裁决优先使用 `frontend-design` skill，历史 Issue CSV 只用于追溯。

docs/Agent开发交付实践.md

@@ -25,7 +25,7 @@ Trellis 的定位是“开发执行合同和上下文组织层”，不是业务
 - Trellis task：承载本轮需求 PRD、范围边界、验收、测试计划、上下文和复盘。
 - Trellis spec：沉淀稳定开发规则和高频工程边界。
 - Issue CSV：历史审计材料或特殊外部交付导出格式，不作为新任务前置合同。
-- `docs/`：仍是业务事实源、产品规则、操作手册和证据入口。
+- `docs/`：仍是业务事实源、产品体验事实、操作手册和证据入口。
 - `AGENTS.md`：只保留 Trellis-first 入口和不可违反硬约束。
 
 每个非微小 Trellis task 必须有 `prd.md`；复杂流程、API、迁移、权限、部署或治理变更补 `design.md` 或 `implement.md`；`.trellis/workspace/` 默认作为本地个人日志，不提交。提交前必须运行 `node scripts/qa/check-trellis-governance.mjs`。
@@ -53,7 +53,7 @@ TRELLIS2 后，项目不再维护独立的交付 Skill。每轮固定流程、
 
 - 每轮交付固定流程：优先进入 `.trellis/workflow.md` 或 `.trellis/spec/hyb-oa/project-governance.md`。
 - 试运行和验证顺序：优先进入 `docs/试运行与自动化验证手册.md` 或对应 Trellis task。
-- Playwright 视觉巡检要求：优先进入 `docs/产品设计规则.md` 和相关 QA 脚本。
+- Playwright 视觉巡检要求：优先进入相关 QA 脚本和当前 Trellis task；视觉裁决使用 `frontend-design`。
 - 报销、发票、企业微信等高频业务入口：优先进入对应业务规约和 `.trellis/spec/hyb-oa/` 领域 spec。
 
 详细业务规则放在 `docs/`，稳定开发规则沉淀到 `.trellis/spec/`，当前任务上下文由 `.trellis/tasks/<task>/prd.md`、`implement.jsonl` 和 `check.jsonl` 串联。
@@ -64,7 +64,7 @@ TRELLIS2 后，项目不再维护独立的交付 Skill。每轮固定流程、
 
 - 文档入口：`docs/文档索引.md`
 - 文档状态矩阵：`docs/文档事实源状态矩阵.md`
-- 设计事实源：`docs/产品设计规则.md`
+- 产品体验事实源：`docs/产品设计规则.md`
 - 报销发票规则：`docs/报销发票附件规则.md`
 - 试运行手册：`docs/试运行与自动化验证手册.md`
 - Agent 交付实践：`docs/Agent开发交付实践.md`
@@ -82,43 +82,16 @@ AGENTS.md 只放 Trellis-first 入口和硬约束，不复制长规则。
 
 验证失败时先定位是代码问题、测试桩问题、环境问题还是数据问题。数据库迁移漂移、生产配置、远程服务变更属于高风险操作，必须暂停确认。
 
-### 6. 视觉和业务同时验收
+### 6. 前端体验和业务同时验收
 
-本项目是面向 10 人以下国内科技公司的轻 OA，不只看功能能否跑通，也要看：
+前端页面不只看功能能否跑通，也要同时看视觉、交互、信息语义和真实业务路径。治理口径固定如下：
 
-- PC 和手机能力是否一致。
-- 企业微信入口是否保持登录态和移动布局。
-- 页面是否符合 `www.hyinda.com` 的品牌气质。
-- 文案是否符合国内 OA 习惯。
-- 是否出现 PC 表格误入手机、黑色大块导航、按钮样式不一致、文字截断、弹窗自动弹键盘等明显问题。
-
-DG8 之后，页面视觉和布局治理只有一个主 UI 参考：飞书工作台/飞书审批。外部最佳实践只沉淀原则，不复制竞品交互或文案；参考钉钉、泛微、每刻、合思、企业微信、Ant Design、WeUI 等公开资料时，必须先按 `docs/产品设计规则.md` 的主参考层级抽象为本项目自己的事实源：
-
-- PC 端：以飞书式工作台和审批列表的信息层级为主，保留表格、筛选、详情分区、批量处理和管理配置。
-- 移动端：以飞书式轻任务和审批/进度入口为主，结合企业微信消息驱动、卡片列表、一级底部导航、深层 Push 页和吸底主操作。
-- 审批：待办聚合、明确状态、可追溯、可催办、超时提醒和效率统计。AP6 v1 已提供催办、待办摘要和超时提醒 job；后续审批/通知/催办开发必须先核对统一审批中心规约，复用既有接口、审计和通知语义，不另造平行链路。
-- 企业微信：入口、身份、个人应用消息和 deeplink，不替代 OA 正式审批。
-
-DG9 之后，页面任务必须先按 `docs/产品设计规则.md` 的 A/B/C 页面分层选样板，再开始设计或编码：
-
-- A 类核心流程先对齐审批中心、移动审批/进度、报销详情、首页和通知样板。
-- B 类业务运营按 A 类样板迁移，但不得顺手新增移动采购创建、恢复冻结差旅主线或改变财务/OCR/项目接口。
-- C 类管理配置保持中后台高密度布局；只在授权管理或审计场景展示必要内部编号。
-- PC 页面优先复用 `WorkspaceHeader`、指标条、`FilterBar`、主表格和分页；移动页面优先复用移动槽位、`mobile-list-card`、`mobile-field-row` 和吸底操作。
-
-可自动化的体验检查先自动化，例如 Playwright PC、移动、企业微信 UA 和 DOM 指标；真实企业微信登录、手机应用消息到达、真实通知权限和财务制度决策必须保留人工确认记录。
-
-移动页治理必须收敛到同一套事实源和组件体系：
-
-- 改移动页面前先读 `docs/产品设计规则.md`，确认是否属于底部一级 Tab、首页图标宫格、卡片列表、深层 Push 页、顶部返回、吸底主操作或安全区问题。
-- 新移动页默认纳入统一响应式 token 和跨视口视觉矩阵，覆盖 320、360、375、390、393、414、430px；不得只按某一台手机打补丁。
-- 专用 `/mobile` 路由默认使用统一移动槽位、`mobile-card`、移动列表卡片和吸底操作；不得把桌面 `card-std p-4` 作为手机主容器，也不得为单个页面自造另一套间距、卡片或图标布局。
-- 角色差异采用“同框架、按角色裁剪内容和动作”：员工、审批人、财务、管理员、负责人看到不同入口和动作，但不创建互不一致的角色专属移动 UI。
-- 信息展示必须先去重再上屏：首页只保留一处待办/进度摘要，通知只作为事件流并直达业务详情，底部角标只表达数量；同一卡片或同一行只展示一次业务编号和一次状态标签。
-- 审批入口默认承载“待我审批”和“我发起的进度”两种视角；普通员工不能看到不可点或无权限的审批入口，审批人/财务/负责人只能看到服务端允许的动作。
-- 真机验证暂停时记录为 `PAUSED`；自动化通过不能替代代表性真机确认，也不能关闭仍待人工确认的移动阻断。当前 `ME6-3` 已由三台代表设备反馈关闭，后续新增真机问题必须另建 Issue 跟踪。
-
-截至 R7EP/OPS8 收口，RI6 报销票据体验、LP6 请假采购体验、ME6 自动化/部署收口、QG6 QA 治理、MIF7/MIF7T 移动整改与真机反馈、带凭据 live smoke/OCR 复检、R7/OPS7/DOC7 草案材料、R7EP 自动门禁和 OPS8 远端只读状态检查均已完成；`ME6-3` 已关闭。后续可进入 R7E 人工确认环节，但不得把文档草案或自动门禁通过当成真实 R7 已启动，也不得把未来新增真机问题用自动化伪造成关闭。R7 真实执行必须保持 `R7E-*` 为 TODO，直到用户确认最终人员、角色、窗口、回滚联系人、问题登记负责人、每日收口节奏和暂停/回滚决策人。
+- `frontend-design` 是视觉与交互设计裁决来源；项目文档不再重复维护颜色、字体、圆角、卡片、竞品参考层级或页面美术规则。
+- `docs/产品设计规则.md` 只用于判断业务体验事实：目标用户、PC/移动/企微职责、页面分层、信息语义、OA/企微主办边界和验收边界。
+- 审批、报销、采购、合同、项目、企业微信、OCR、附件等领域问题，先读对应业务规约，不在前端设计规则里重复定义。
+- 可自动化的体验检查先自动化，例如 Playwright PC、移动、企业微信 UA 和 DOM 指标；真实企业微信登录、手机应用消息到达、真实通知权限和财务制度决策必须保留人工确认记录。
+- 真机验证暂缓时记录为 `PAUSED`；自动化通过不能替代代表性真机确认，也不能关闭仍待人工确认的移动阻断。
+- 面向用户可测试的页面改动，必须在部署和公网检查通过后再告知用户可测。
 
 文档治理采用 DCL7 后的中文优先和物理精简策略：
 
@@ -183,7 +156,7 @@ agent 在声明 blocker 前，必须先查项目内已有资产：
 - 开发：按 Issue 实施后端、前端、脚本或文档变更，并执行对应验证。
 - 审查：默认先报风险、行为回归、权限泄漏、状态机问题和漏测项。
 - QA：用接口回归、Playwright、视觉截图、真机/公网 smoke 和人工步骤复核。
-- 设计师：对齐 `docs/产品设计规则.md`、公司官网视觉和国内 OA 操作习惯。
+- 设计师：使用 `frontend-design` 做视觉和交互判断，并对照 `docs/产品设计规则.md` 的业务体验事实。
 - 用户代理：模拟普通员工、审批人、财务、管理员在 PC、手机、企业微信里的真实路径。
 
 不需要用户显式写“请扮演某角色”。agent 应根据语义自动选择角色；若任务跨多个角色，先给执行顺序和交接物。
@@ -211,7 +184,7 @@ agent 在声明 blocker 前，必须先查项目内已有资产：
 - 前端 typecheck、build、关键页面 Playwright 和视觉截图。
 - 公网 `/ready`、企业微信配置、资源版本、核心文案和 live smoke。
 - 业务流程巡检：报销、发票、请假、审批、票据、附件上传、异步任务终态。
-- 设计规则巡检：PC 页面误入移动端、原生英文上传控件、内部码值、UUID 主展示、按钮和底部导航异常。
+- 前端体验巡检：PC 页面误入移动端、原生英文上传控件、内部码值、UUID 主展示、按钮和底部导航异常。
 
 不适合完全自动化的任务要保留人工验收入口，例如真实企业微信登录、真实账号安全操作、生产数据处理、财务制度决策。
 

docs/产品设计规则.md

@@ -1,242 +1,66 @@
-# 产品设计规则基线
+# 产品体验事实源
 
-> 2026-05-26 更新：前端视觉与交互设计的最终裁决迁移到 `frontend-design` skill。本文件继续作为 hyb-oa 的业务事实、品牌识别、历史页面治理和验收参考；当本文旧视觉规则与 `frontend-design` 冲突时，以 `frontend-design` 为准，同时不得覆盖安全、隐私、生产部署和真实数据边界。
+> 2026-05-27 治理口径：前端视觉、布局审美、组件观感、字体、颜色、动效、间距和交互细节的最终裁决统一交给 `frontend-design` skill。本文件不再作为设计规则手册，只保留 hyb-oa 的产品体验事实、业务信息架构、页面职责和验收边界。
 
-本文件是 PC 网页和企业微信/手机网页统一优化的当前事实源。目标用户是 10 人以下的国内科技公司：使用频次高、角色重叠、审批链短，系统应当像工作台，不像宣传站，也不应像重型 ERP。
+## 权威边界
 
-## 设计目标
+- `frontend-design`：决定页面视觉方向、布局表达、审美质量、控件组合、交互动效、响应式呈现和前端设计一致性。
+- 本文件：记录 hyb-oa 特有的用户场景、角色优先级、模块职责、信息展示语义、企微/OA 边界和验证要求。
+- 业务模块规约：报销、审批、采购、合同、项目、资产、企业微信、OCR、附件等领域细则以对应 `docs/需求-*.md`、`docs/报销发票附件规则.md` 和当前 Trellis task 为准。
+- Trellis spec：沉淀稳定工程规则和实现约束；当前任务的范围、验收和测试计划以 `.trellis/tasks/<task>/prd.md` 为准。
+- 历史 Issue CSV 和历史截图只用于追溯，不作为新页面设计裁决。
 
-- 首屏只放今天最该处理的事，避免解释系统功能。
-- PC 端服务批量查看、对账、审批和管理；手机端服务提交、补资料、查状态和处理待办。
-- 页面文案使用国内 OA 常见表达：待处理、草稿、审批中、已通过、已支付、已驳回、提交、保存、删除、撤回。
-- 所有业务对象使用业务编号或摘要展示，不把 UUID 当作主编号展示给用户。
-- 颜色以浅色工作台为主，黑色只用于正文或弱边框，不作为移动主按钮、底部导航、首屏卡片背景。
+不得再把竞品页面、旧批次样板、颜色值、圆角、卡片样式、字体、官网视觉截图或历史视觉规则追加到本文。需要前端设计判断时，直接使用 `frontend-design`。
 
-## 品牌视觉参考
+## 用户与使用事实
 
-OA 页面应参考公司主页 `www.hyinda.com` 的视觉气质，但不能做成营销页。R111 起以 2026-05-08 对官网首页“海音达 Hyinda”的实际视觉抓取作为基线，截图和颜色摘要保存在 `output/playwright/r111-hyinda-design/`：
+- 目标用户是 10 人以下的国内科技公司，角色重叠、审批链短、使用频次高。
+- PC 端主要服务批量查看、对账、审批、财务复核、导出和管理配置。
+- 手机/企业微信端主要服务提交、补材料、查状态、处理待办和从消息直达业务详情。
+- 系统应优先支持真实工作流，不做营销站式介绍页，也不把低频配置入口放到高频员工路径里。
+- 页面可见内容应使用国内 OA 常见表达，例如待处理、草稿、审批中、已通过、已支付、已驳回、提交、保存、删除、撤回。
 
-- 品牌识别：使用“海音达 Hyinda”的稳重科技感，页面干净、留白充足、边界清晰。
-- 主色倾向：官网核心蓝约为 `rgb(0,57,138)`，用于主按钮、选中态、重点链接和关键状态。
-- 中性色：白色、浅灰蓝、浅边框和深 slate 文本为主，避免大面积黑色块。
-- 圆角与卡片：控制在工作台风格，卡片边界清晰，不使用营销式大面积渐变、装饰光斑或夸张大圆角。
-- 字体气质：官网使用偏现代无衬线风格；OA 继续使用系统无衬线字体，但字号、行距和按钮高度要克制。
-- 双端一致：PC 和企业微信/手机端都遵循同一品牌色和控件语义，只根据屏幕密度调整布局。
+## 页面职责分层
 
-## 主 UI/布局参考层级
+页面分层只用于判断优先级、业务信息量和验证范围，不规定具体视觉样式。
 
-DG8 之后，hyb-oa 的唯一主 UI/布局参考是飞书工作台/飞书审批。主参考只用于统一布局密度、信息层级、交互克制度和 PC/移动一致性；Hyinda 官网品牌气质、OA 工作台定位和本文件规则优先于任何竞品。不得复制飞书页面文案、视觉细节、IM、云文档、多维表格、开放平台生态、登录、审批、通知或项目能力。
+- A 类核心流程：登录/找回密码、首页、审批中心、审批/进度移动页、报销列表、报销详情、移动报销详情、通知中心。
+- B 类业务运营：票据池、AP 台账、付款批次、请假、采购、资产、项目、项目详情、合同台账。
+- C 类管理配置：用户、组织、主数据、审批规则、工作流定义、系统设置、Feature Flag、审计日志。
 
-参考层级固定如下：
+A 类页面优先保证真实试运行路径顺畅；B 类页面优先保证台账、复核和导出不误导；C 类页面允许展示更多审计和排障信息，但不得泄露无权限数据。
 
-- 主参考：飞书工作台/飞书审批。PC 工作台、审批列表、审批/进度分组、消息直达详情、催办语义和移动轻任务优先按这一层抽象。
-- 品牌修正：Hyinda 官网的品牌蓝、浅色背景、清晰边界、克制字号和工作台气质是最终视觉裁剪标准。
-- 功能流程参考：钉钉只参考审批场景覆盖和高频申请模板；泛微 e-office 只参考 OA 信息架构和台账结构，不指导视觉风格；每刻/合思只参考报销、票据、OCR、财务复核和付款导出流程，不指导整体 UI。
-- 控件语义参考：Ant Design 只参考 PC 表格、筛选、表单和导航的中后台语义；WeUI/Ant Design Mobile 只参考移动控件、安全区、TabBar、List、Tabs 和动作反馈语义。
-- 实际基础设施：企业微信只做入口、绑定、免登录、个人应用消息和 deeplink，不替代 OA 正式审批页，也不指导 OA 主视觉。
-
-落到 hyb-oa 的统一布局原则：
-
-- PC 工作台是高密度办公面板，首屏优先待处理、我发起的进度、退回待补、财务待复核/待付款和异常提醒；列表保留筛选、批量查看、审批、财务复核、导出和管理配置。
-- 移动端首页是消息驱动的轻入口，服务提交、补材料、查状态、处理待办和从企业微信消息回流；不得把 PC 表格和批量管理能力搬到手机端。
-- 审批/进度入口承载两类视角：审批人处理待我审批，员工查看我发起的进度；通知仍是事件流，点击应直达业务详情或审批详情。
-- 详情页是业务事实源，PC 按摘要、关键字段、附件/发票、审批流和日志分区；移动深层 Push 页隐藏底部 Tab，使用顶部返回、状态和吸底操作。
-- 竞品资料只用于抽象原则；不得复制飞书、钉钉、企业微信、泛微、每刻、合思、WeUI 或 Ant Design 的页面文案、视觉细节和专有交互。
-
-### WFDG 企微/OA 主办界面边界
-
-WFDG 后，涉及企业微信和 OA 双端的页面必须先判断业务主办方，再套用页面样板：
+## OA 与企业微信边界
 
 - `OA 主办`：报销、采购、费用、合同、项目、付款、AP、代账和高敏附件仍在 OA 内提交、审批、查看和导出；企业微信只发送脱敏消息和 OA deeplink。
-- `企微镜像`：HR/考勤员工日常审批、打卡、人事助手和假期余额由企业微信主办；OA 页面只展示同步镜像、规则快照、审计状态和失败重试，不作为企微正常可用时的日常新建入口。
-- `OA 应急接管`：仅管理员人工开启 `oa_hr_emergency_mode_v1` 后，OA 才临时开放请假、补卡、外出、加班提交和审批；页面必须显式展示应急原因、范围、预计结束时间和 `EMERGENCY` 标记。
-- 移动工作台可展示企微镜像状态和 OA 应急入口状态，但不得把采购、合同、财务附件上传到企业微信原生审批或企业微信附件。
-- 企业微信消息卡片只承载标题、类型、编号、状态和入口；点击后通过免登录或账号绑定进入 OA 目标页，附件查看和审批动作仍按 OA 服务端权限执行。
+- `企微镜像`：HR/考勤员工日常审批、打卡、人事助手和假期余额优先由企业微信主办；OA 展示同步镜像、规则快照、审计状态和失败重试。
+- `OA 应急接管`：仅管理员人工开启应急模式后，OA 才临时开放请假、补卡、外出、加班提交和审批；页面必须说明应急原因、范围和预计结束时间。
+- 企业微信消息只承载标题、类型、编号、状态和入口；点击后通过免登录或账号绑定进入 OA 目标页，附件查看和审批动作仍按 OA 服务端权限执行。
 
-## DG9 页面分层与样板
+## 信息语义
 
-DG9 之后，页面整改以“共享样板先行、核心流程优先、低频配置后置”为执行口径。DG9 只承接 UI/布局统一，不替代 WF8 审批通知验收、不替代 UX8 真实反馈池、不替代 BIZ8 财务/OCR/项目业务验收，也不代表已启动部署。
+- 普通用户主展示使用业务编号或业务摘要，不把 UUID、taskId、entityId、内部状态码或调试字段作为主编号。
+- 审计页、管理员排障页和打印留痕页可在权限允许范围内展示必要内部编号。
+- 同一业务对象在同一区域只展示一次主标识；同一状态在同一区域只展示一次。
+- 通知中心是事件收件箱，不是待办列表或进度页副本；通知点击应直达业务详情、审批任务或可解释的失败提示。
+- 首页只做工作台摘要，不重复完整待办列表、通知列表和进度列表。
+- 审批入口同时服务审批人和发起人：审批人处理待我审批，员工查看我发起的进度。
+- 普通员工不应看到不可点或无权限的审批入口；审批、财务、负责人和管理员只能看到服务端允许的动作。
 
-页面分层如下：
+## 业务体验事实
 
-- A 类核心流程：审批中心、审批/进度移动页、报销列表、报销详情、移动报销详情、首页、通知中心。这些页面优先使用 DG9 工作台骨架和移动槽位，是后续页面整改的样板。
-- B 类业务运营：票据池、AP 台账、付款批次、请假、采购、资产、项目、项目详情等。按 A 类样板迁移，但不新增移动采购创建、不恢复冻结差旅主线、不改变 OCR、付款、导出或项目关联接口。
-- C 类管理配置：用户、组织、主数据、审批规则、工作流定义、系统设置、Feature Flag、审计等。保持中后台高密度布局，允许在授权管理场景展示必要内部编号或审计字段，但不改变权限模型、审批规则语义或路由。
+- 报销主展示使用后端业务编号，例如 `BX20260506001`；UUID 不作为普通用户主编号。
+- 报销草稿允许编辑和删除；审批中按审批状态提供可解释下一步；已通过、已支付不提供删除。
+- 普通员工发票入口在报销详情补充材料，不恢复员工侧“票据中心/发票池”主导航。
+- 发票状态文案面向用户表达，例如识别中、识别失败、可添加、已添加、重复票据、已归档/已报销；不暴露 OCR provider、绑定整单、不绑定明细等内部术语。
+- 请假、补卡、外出、加班的员工日常主路径优先走企业微信；OA 负责镜像、审计、异常和应急接管。
+- 采购、合同、项目、财务附件和高敏资料不迁移到企业微信原生审批或企业微信附件。
+- 差旅仍不进入当前主线扩展；如恢复差旅能力，必须先新建独立 Trellis task。
 
-DG9 样板规则：
+## 验收边界
 
-- PC 列表页使用统一工作台骨架：`WorkspaceHeader`、指标条、`FilterBar`、主表格、分页和批量/导出操作区。
-- PC 详情页使用统一事实源骨架：顶部摘要、关键字段、材料/附件/发票、审批流、日志和主操作区；同一状态或业务编号不得在同一区域重复展示。
-- 移动页使用统一移动槽位：`mobile-card`、`mobile-list-card`、固定状态槽、`mobile-field-row`、安全区和吸底操作，不把桌面 `card-std p-4/p-5/p-6` 主容器回流到专用 `/mobile` 页面。
-- 通知仍是事件流，首页只保留一处待办或进度摘要；企业微信继续只承担入口、免登录、个人应用消息和 deeplink。
-- 后续页面任务必须先判断页面属于 A/B/C 哪一层，再选择 DG9 样板，不再临时混用多个竞品视觉风格。
-
-参考资料：
-
-- 钉钉审批：https://page.dingtalk.com/wow/dingtalk/act/approval-web
-- 飞书审批：https://www.feishu.cn/content/article/7584390246654037188
-- 飞书审批催办：https://www.feishu.cn/content/134344362384
-- 企业微信应用消息：https://s.apifox.cn/apidoc/docs-site/406014/api-10061693
-- Ant Design 表单页：https://4x.ant.design/docs/spec/research-form-cn
-- Ant Design 表格：https://012x.ant.design/docs/pattern/table
-- Ant Design 导航：https://ant.design/docs/spec/navigation/
-- Ant Design Mobile/Mini TabBar：https://0x-mini.ant.design/components/tab-bar
-- Ant Design Mobile/Mini SafeArea：https://0x-mini.ant.design/components/safe-area
-- WeUI：https://github.com/Tencent/weui
-
-## 文案规则
-
-禁止：
-
-- 口语化标题，例如“先处理这几件事”。
-- 内部评价词，例如“清爽”。
-- 对用户解释设计意图，例如“低频模块放在这里，避免干扰移动首页”。
-- 路由式标题，例如直接显示 `/invoice-pool`。
-- 长段功能说明占据表单、弹窗、列表首屏。
-
-推荐：
-
-- 首页模块标题用“待处理”“常用”“我的申请”“通知”。
-- 操作按钮用“新建报销”“继续编辑”“提交审批”“删除草稿”“上传发票”。
-- 空状态只说明现状和下一步，例如“暂无草稿”“暂无待处理审批”。
-- 表单说明放在字段错误、帮助文本或 hover/折叠信息里，不放在首屏大段文案。
-
-## 信息层级与去重规则
-
-- 首页只做工作台摘要：同一页面最多出现一处待办或进度列表；底部 Tab 红点只表达全局数量，通知列表只表达事件，不作为待办列表副本。
-- 审批入口承载两类视角：审批人看“待我审批/已处理”，员工看“我发起的/审批进度”；普通员工不能看到不可点或无权限的审批入口。
-- 通知卡片表达“发生了什么”，点击应直达审批任务或业务详情；目标不存在、已删除或无权限时显示可理解提示，不跳回首页。
-- 同一卡片或同一表格行只展示一次主标识。标题为“报销单 BX20260512001”时，正文不再出现“业务单号：BX20260512001”。
-- 状态只展示一次，优先使用右侧状态标签；不要在标题、副标题和正文里重复写“已通过/业务状态：已通过/状态：已通过”。
-- 卡片固定槽位：第一行左侧为业务类型加业务编号或摘要，第一行右侧为状态；第二行放申请人、金额/天数、日期；第三行可选当前节点或更新时间。
-- PC 高密度表格允许保留独立“单号/编号”列，但同一行的标题或摘要不得再拼接同一编号；确需复制编号时放在单号列或详情页摘要区。
-- UUID、taskId、entityId、内部状态码和调试字段不进入用户主展示；审计页、管理员排障页和打印留痕页按权限例外处理。
-- 发票号码、采购测试编号、资产分类标识等长编号在列表和摘要区默认使用短形态展示；完整值只通过 hover/title、详情编辑字段或“复制”动作提供，避免长数字压缩 PC 表格扫读。
-
-### MIA7 移动工作台、进度、通知和详情标准
-
-MIA7 之后，移动 OA 的信息架构以“一级入口少、任务摘要轻、详情事实源清楚”为基线。后续移动页面整改必须先判断内容属于哪一层，再决定展示位置：
-
-- `底部导航` 只承载一级模块，不承载具体动作。默认语义为首页、审批/进度、报销、我的；底部红点只表达数量，不展示待办内容。
-- `首页常用` 只能放快捷动作，不重复底部 Tab。推荐动作是新建报销、上传票据、请假、资产扫码、发起采购等；报销、审批/进度、我的这类一级入口不应再次出现在常用宫格。
-- `首页待处理` 只保留一张轻摘要。审批人可以看到待批数量和 1 条最紧急待办，员工可以看到我发起的进度摘要；不得同时出现总数、三宫格指标、待办列表、卡片状态和进入按钮五层重复。
-- `审批/进度页` 按角色分流：员工使用草稿、审批中、已通过、退回驳回等状态标签查看我发起的事项；审批人使用待我审批、已处理标签查看任务；两者不得混成同一个无分组流水列表。
-- `通知中心` 是事件收件箱，不是待办列表或进度页副本。通知卡片优先展示事件类型、标题、时间和已读状态，点击先标记已读再直达业务详情；通知页不展示审批动作按钮。
-- `详情页` 是业务事实源。所有移动深层详情统一使用同一详情壳：左侧返回，标题和副标题居中或左侧主内容区，右侧状态；隐藏底部 Tab；内容顺序为摘要、关键字段、材料/附件/发票、审批流、下一步动作。
-- `返回语义` 优先回到来源页或来源标签；没有来源时回到对应业务列表或进度标签。不得从已批准记录详情返回到新建表单顶部，也不得把采购详情无条件返回审批首页。
-- `角色首页` 必须体现角色优先级。员工优先我的申请和快捷动作，审批人优先待批，财务优先待复核、待付款、台账和导出；不同角色可共用框架，但摘要、入口和动作必须裁剪。
-- `真机差异` 不按单机型写补丁。iPhone 12/iOS 14 企业微信等真实 WebView 间距问题应先纳入截图样本和移动 token 复核，再通过统一槽位、间距 token 或安全区规则修正。
-
-## 色彩规则
-
-- 主色：品牌蓝/青色系，用于主按钮、选中态、链接和轻量提示。
-- 中性色：白色、浅灰、浅蓝灰用于背景、卡片和分隔。
-- 状态色：红色表示危险或失败，橙色表示待处理，绿色表示完成。
-- 禁止移动端主卡、底部导航选中态和核心 CTA 使用黑色大块背景。
-- 卡片圆角保持 8px 左右；移动端可使用 12px 到 16px，但不做营销式大圆角堆叠。
-
-## PC 页面模式
-
-列表页：
-
-- 顶部只保留标题、核心筛选、主操作。
-- 表格列优先显示业务编号、申请人、金额/天数、状态、更新时间、操作。
-- 筛选区默认收敛为关键字段：状态、申请人、时间、业务编号或关键词；高级筛选折叠，不压缩列表首屏。
-- 分页、空状态、批量操作和导出入口必须清楚区分；员工页少配置，财务和管理员页可更高密度。
-- 操作列至少区分“查看/编辑”和状态允许时的“删除草稿”。
-- 长 ID、调试字段、路径字段默认不进入主列。
-
-明细页：
-
-- 标题显示业务编号或摘要，例如“报销单 BX20260506001”。
-- 状态、金额、申请人、更新时间作为摘要条。
-- 主流程操作固定在页头或底部操作区，高风险动作必须二次确认；审批动作按钮保持“通过 / 驳回 / 退回”短文案，具体后果放在确认弹窗中说明。
-- 高风险动作包括提交审批、通过、驳回、退回、转审、撤回、删除、归档、启用/停用、批量处理、财务复核/付款、重复票据例外、功能开关批量执行、敏感数据导出、通知测试或重发；普通保存草稿、筛选、分页、查看、预览、取消编辑和非敏感导航不强制确认。
-- 审批流、附件、发票和日志分区展示，避免混在一个长表单里。
-- 审批、财务和管理员视角可以展示更多审计信息，但普通员工主视角只展示与下一步动作有关的信息。
-
-表单和弹窗：
-
-- 表单先收集必要字段，非必要字段折叠或后置。
-- 发票、附件上传使用自定义中文控件，不暴露浏览器原生 `Choose File` 文案。
-- 弹窗只承担单一任务，不在弹窗里解释整个业务流程；确认弹窗统一使用 OA 内组件，不使用浏览器原生 `window.confirm` 或类似原生阻塞弹窗。
-
-## 移动统一页面范式
-
-- 所有 `/mobile` 页面默认复用同一套移动 Shell、响应式 token、底部导航、安全区和视觉矩阵；不允许单页自造布局体系解决局部拥挤。
-- 专用 `/mobile` 页面包括移动首页、审批、报销列表、报销详情、我的、个人设置、通知、票据上传、请假和资产扫码；这些页面必须先使用统一移动组件和样式，再按业务差异裁剪内容。
-- 手机端默认隐藏 PC 侧边栏和顶栏，使用移动首页、底部导航和轻量卡片。
-- 菜单不应占用大量空间；常用入口放底部导航，更多入口放“我的”。
-- 移动底部导航固定为“首页、审批、报销、我的”；票据上传作为首页快捷入口和报销页内操作，不作为底部一级 Tab。
-- 移动“审批”是审批与进度入口，不只服务审批人；员工进入后查看我发起的报销、请假、采购进度，审批人进入后处理待我审批。
-- 移动端必须按响应式规则自动适配，不按单个机型写补丁；验收至少覆盖 320、360、375、390、393、414、430px 宽度。
-- 移动首页一级快捷入口使用图标宫格：图标在上、短标题在下，4 项等宽，辅助说明不在小屏常驻展示，避免图标和文字挤压；标题单行省略，不允许逐字换行。
-- 移动端页面边距、卡片间距、底部导航高度和吸底操作高度使用统一 token；不通过 viewport 缩放字体解决拥挤问题。
-- 次级入口和信息字段可按最小宽度自动从两列变一列；核心操作按钮必须保持明确可点，不得被内容、安全区或底部栏遮挡。
-- 报销详情、审批详情等深层 Push 页隐藏底部导航，使用顶部返回和上下文吸底操作，避免底部 Tab 在深层页面假选中；审批详情的通过、驳回、退回等主操作放在底部操作区并先确认。PC 端保持工作台和详情页高密度布局，不强制把所有操作移到底部，但高风险动作同样必须先确认。
-- 企业微信个人应用消息 deeplink 应直达移动待办或业务详情；首次进入如需点击进入工作台，应保持后续可直接回到目标页。
-- 首页最近通知只展示事件消息，不能重复完整待办卡片；如果某条待办已在首页待处理摘要出现，通知区域不再重复显示同一待办内容。
-- 移动列表使用卡片和状态标签，首屏优先展示“谁提交、什么事项、金额/天数、当前状态和下一步”。
-- 列表使用卡片，不直接显示桌面表格。
-- 详情页按摘要、业务字段、发票/附件、审批流、日志分区展示；普通员工移动端不默认展示后台审计细节。
-- 表单单列优先，字段纵向排列，按钮宽度稳定，首屏优先完成“新建/继续编辑/提交”。
-- toast、dialog、actionsheet、tabbar、cell、button 等语义参考微信生态习惯；样式必须回到 hyb-oa 自身品牌和组件规则。
-- 企业微信入口应尽量免登录；绑定失败或权限不足时显示明确下一步，而不是让用户反复登录。
-- 头像 fallback 遵循国内中文习惯：中文/CJK 姓名默认取首个可见字符，英文或拼音姓名保留两段首字母。
-- “我的”页和更多入口使用组件级自适应槽位：头像/图标槽固定，文字槽使用 `minmax(0, 1fr)` 可收缩，间距使用移动 token 或 `clamp()`；不按具体 iPhone/Android 机型写补丁，不通过放大字号、放大卡片或改成单列来规避图文拥挤。
-- 所有专用 `/mobile` 页面统一使用移动槽位和移动卡片：图标/头像/状态槽固定，文字槽可收缩，列表项使用移动列表卡片，提示、空状态和表单分组使用移动 token；不得把桌面 `card-std p-4` 当作移动主容器重新引入。
-- 移动卡片保持白底、浅边框、轻阴影，不显示 PC 端 `SectionPanel` 的蓝青色顶边装饰线。
-- 移动角色差异采用“同框架、按角色裁剪内容和动作”：员工、审批人、财务、管理员、负责人看到不同入口、摘要、动作和敏感信息，但不做多套角色专属移动 UI。
-- 移动验收必须包含跨视口自动化和代表性真机确认；若真机验证暂缓，只能记为 `PAUSED`，不能把相关移动阻断标为完成。
-
-## 报销专项规则
-
-RI6 之后，报销和票据体验以“员工从报销详情补材料、财务从台账复核、移动端轻任务”为当前事实源：
-
-- 后端业务编号是用户主展示，例如 `BX20260506001`；UUID 不作为普通用户主编号。
-- 草稿允许编辑和删除；审批中按审批状态提供可解释下一步；已通过、已支付不提供删除。
-- 普通员工发票入口仍在报销详情“添加发票”，不恢复员工侧“票据中心/发票池”主导航。
-- 发票状态文案使用“识别中、识别失败、可添加、已添加、重复票据、已归档/已报销”等用户可理解表达，不暴露 OCR provider、发票池、绑定整单、不绑定明细等内部术语。
-- 报销详情按摘要、明细、发票、附件、审批流、付款状态和下一步动作分区；PC 保持高密度，移动保持轻任务。
-- PC 端适合完整明细、对账和财务复核；手机端适合上传 PDF 发票、补充说明、继续编辑草稿和查状态。
-- 报销详情等深层页使用统一移动详情壳和吸底操作，不把底部 Tab 留在深层事实页。
-
-## 请假、票据、采购、差旅规则
-
-- 请假手机端应提供新建、编辑草稿、提交和查看记录，不显示桌面表格。
-- 票据中心应显示票据号码、销售方、金额、OCR 状态和绑定状态，不把内部 ID 放在主位置。
-- 采购和差旅页使用和报销一致的列表、状态、操作区和移动卡片规则。
-- 所有上传控件都使用中文按钮和文件名回显。
-
-LP6 之后，请假和采购体验以“状态清楚、审批历史一致、缺配置不 500”为当前事实源：
-
-- 请假详情展示日期、天数、假别、原因、当前状态、当前节点、审批历史和退回/驳回说明；从已批准记录返回时不得落到新建表单语境。
-- 采购详情展示业务编号或标题、金额、状态、附件说明、审批历史和预算 warning。缺预算池时使用用户可理解提示，不暴露后端技术结果或返回 500。
-- 报销、请假、采购三类单据的详情页和卡片遵循同一主标识、状态、关键指标、审批流和下一步动作槽位。
-- 差旅仍不进入当前主线扩展；如恢复差旅能力，必须先新建独立 Issue CSV。
-
-## 当前移动批次状态
-
-已完成的当前事实链为：R6、PC6、PA6、FL6、AP6、RI6、LP6、ME6 自动化与真机门禁、QG6、DG7/MRF7、MIA7、MIF7、MIF7T 和 MIF7TD。`ME6-3` 已关闭；后续移动体验问题进入 UX8 或单独 Issue，不重新打开 MIF7/MIF7T。
-
-MIF7/MIF7T 已落地的移动规则包括：
-
-- 首页去重：常用入口改成不重复底部 Tab 的快捷动作，待处理摘要压缩为一张轻摘要。
-- 进度页分标签：员工按草稿、审批中、已通过、退回驳回分组；审批人按待我审批、已处理分组。
-- 通知中心事件化：通知不展示审批动作按钮，点击直达目标详情。
-- 详情页统一壳：返回位置、标题、状态、内容顺序和底部动作一致。
-- 返回语义统一：优先回来源页或来源标签；无来源时回业务列表或进度标签。
-- 角色首页裁剪：普通员工、审批人和财务保留同一移动框架，但入口、摘要和动作按角色区分。
-- 采购移动列表：移动端可查看采购列表和详情；移动发起采购属于后续需求，不默认纳入 R7。
-
-历史阶段说明：早期文档中的 R99、R100、R101、R102、R103 是移动与页面治理的历史批次代号，不再作为 2026-05-12 之后的当前排期或待办事实源。需要追溯当时决策时，可阅读历史 Issue CSV 和 `docs/文档事实源状态矩阵.md`。
-
-## 验收规则
-
-每个后续批次至少满足：
-
-- Issue CSV 中明确业务流程级 `Test_Method`。
-- `node scripts/qa/check-ui-design-rules.mjs` 可运行并记录问题。
-- 前端改动执行 `cd client && npm run typecheck` 和 `cd client && npm run build`。
-- 涉及移动端或视觉问题时，补充 Playwright 截图或视觉诊断。
-- 涉及状态机、权限、数据迁移时，单独 reviewer 审查并写清回滚路径。
+- 前端页面改动必须先使用 `frontend-design` 做设计判断，再按影响范围执行 `cd client && npm run typecheck`、`cd client && npm run build` 和必要 Playwright/视觉验证。
+- 涉及移动或企业微信 WebView 的改动，应覆盖代表性视口；真机验证暂缓时只能记为 `PAUSED`，不能用自动化通过替代人工确认。
+- 涉及权限、状态机、审批规则、数据迁移、生产配置、企业微信写入或真实数据写入时，必须按当前 Trellis task 和对应业务规约补充验证与回滚说明。
+- 面向用户可测试的页面改动，只有部署和公网检查通过后，才可告知用户可以测试。
+- 本文件自身不代表页面已经整改、不代表已经部署、不替代真实试运行 Go/No-Go。

docs/报销发票附件规则.md

@@ -119,7 +119,7 @@ PC 端：
 
 - 适合明细编辑、批量查看、财务复核和台账导出。
 - 报销详情分区展示：摘要、明细、发票、附件、审批流、预算与审核提示。
-- PC 报销列表和详情遵循 [产品设计规则基线](./产品设计规则.md)：业务编号、状态、申请人、金额和更新时间优先，不把 UUID 或内部状态码作为主展示。
+- PC 报销列表和详情遵循 [产品体验事实源](./产品设计规则.md)：业务编号、状态、申请人、金额和更新时间优先，不把 UUID 或内部状态码作为主展示；视觉与交互裁决以 `frontend-design` 为准。
 
 手机/企业微信端：
 

docs/文档事实源状态矩阵.md

@@ -10,7 +10,7 @@
 
 ## 冲突优先级
 
-当前 Trellis task PRD/设计 > 当前 PRD/模块规约 > 产品和设计规则 > 当前操作手册 > 技术参考 > 历史证据 > git 历史。
+当前 Trellis task PRD/设计 > 当前 PRD/模块规约 > 产品体验事实和业务规约 > 当前操作手册 > 技术参考 > 历史证据 > git 历史。前端视觉与交互裁决优先使用 `frontend-design`。
 
 ## 台账状态值
 
@@ -28,8 +28,8 @@
 | Stream | Contract | Status | 用途 |
 | --- | --- | --- | --- |
 | `GOV8` | `issues/2026-05-13_16-31-09-gov8-system-governance.csv` | `EVIDENCE` | 连续型 Issue 治理、文档台账、流程模板和审计脚本，已收口 |
-| `DG8` | `issues/2026-05-13_22-56-49-design-ui-governance.csv` | `EVIDENCE` | 设计治理主参考系统收口；飞书工作台/飞书审批为唯一主 UI/布局参考，不代表页面已整改 |
-| `DG9` | `issues/2026-05-13_23-30-00-dg9-ui-layout-rollout.csv` | `EVIDENCE` | 全站 UI/布局样板迁移已收口；最新代码已作为 R7E 基线部署到公网，不替代 WF8/UX8/BIZ8 |
+| `DG8` | `issues/2026-05-13_22-56-49-design-ui-governance.csv` | `EVIDENCE` | 历史设计治理证据；前端视觉与交互裁决已由 `frontend-design` 接管 |
+| `DG9` | `issues/2026-05-13_23-30-00-dg9-ui-layout-rollout.csv` | `EVIDENCE` | 历史页面整改证据；A/B/C 分层仍可追溯，后续页面设计不再复制 DG9 视觉样板 |
 | `R7E` | `issues/2026-05-13_17-11-44-r7e-human-trialrun.csv` | `EVIDENCE` | 真实扩大试运行阶段验收、P2 排序和 R7E 收口已完成，P0/P1 阻断为 0 |
 | `ORG8` | `issues/2026-05-13_18-23-51-org8-master-data-permission.csv` | `EVIDENCE` | 组织账号和权限主数据治理已阶段收口；本地代表性角色验收通过，不替代 R7E 真实人工试运行 |
 | `WF8` | `issues/2026-05-13_18-23-52-wf8-approval-notification.csv` | `EVIDENCE` | 审批与通知增强已阶段收口；deeplink 过期修复已部署并经代表设备真机点击回 OA 验证 |
@@ -132,7 +132,7 @@
 | `REG` | `docs/文档事实源状态矩阵.md` | 文档台账 | 文档分类和状态事实源 | `CURRENT` | product/dev | `GOV8,QAOPS9,P2D,P2-ORG,P2-FIN-DECISION,P2-FIN-V1,P2-OCR-SAMPLE,P2Q,P2AUTO,P2AF,P2-FIN-LIVE-DECISION,P2-FIN-LIVE,PRELAUNCH,CASHIER-VOUCHER-V1,LAUNCH-DEPLOY-FINANCE,FIN-PROD-ENABLE,ACCOUNTING-HANDOFF-V1,SYSTEM-COMPLETE-GATE,LAUNCH-OPS-V1,REQ-COMPLETE-AUDIT,ATTV1,LAUNCH-AUTO-OPS-V1,AUTO-REMAINING-CLOSEOUT,HR-WECOM-DIRECTORY-V1,WFOC,DBWFOC,WFDG,WDRG,WCP1,WCPC,WHMS,WHMSLIVE,WOUA,WAPI,WRRA,WOUAFIX,WRV1,WRA1,WMSG1,WAPC1,WAPC2,WPROC1,WPROC2,WAPC2F,WAPC2FLIVE,WCBK1,WEGOV1,WARCH1,WARCH2,WROAD2,WARCH3,WCHECK1,WEXT1,WOPS1,WROAD2C,WROAD2B,WAPPR1,WRULE1,WAUTO1,WEXT1LD,WFULLSMOKE1,WTCLOSE2,WREAL1P,OAOPS1,ASSET1,OSMOKE1,OALAUNCH1,OMAT1,OPOLICY1,OAFLOW1,OAFRONT6,OAKISS1,PCDESIGN1,TRELLIS2` | `audit-docs` | none | 2026-05-26 | `audit-docs --check-registry` | medium | 判断文档权威性；登记 TRELLIS2 官方 task-first 口径，以及当前 OALAUNCH1、OMAT1、OPOLICY1、OAFLOW1、OAFRONT6、OAKISS1、PCDESIGN1、OAOPS1、ASSET1、OSMOKE1、每日巡检、阻断即修和冻结项事实 |
 | `PRD-MVP` | `docs/海音达OA-MVP需求规格说明书.md` | 需求事实源 | PRD 主事实源 | `CURRENT` | product | `REQ8,P2T,GOV8,HR-WECOM-DIRECTORY-V1,WFOC,DBWFOC,WFDG,WDRG,WCP1,WCPC,WHMS,WHMSLIVE,WOUA,WAPI,WRRA,WAPC1,WAPC2,WAPC2FLIVE,WCBK1,WEGOV1,WACP3,WACP3R,WARCH1,WARCH2,WROAD2,WARCH3,WCHECK1,WEXT1` | Trellis task / 历史 Issue CSV | `docs/requirements-specification.md` | 2026-05-26 | `rg` | high | WARCH3/WCHECK1/WEXT1/WOPS1 后定义 HR/考勤企微主办、OA 自建留存、受控测试域、只读历史查询、自动巡检、打卡摘要、外出/加班 dry-run、WEXT1-FORMAL、WREAL1 前置和深度镜像边界；ERP 未来不接入 OA |
 | `PRODUCT-SCOPE` | `docs/产品口径.md` | 需求事实源 | 产品边界事实源 | `CURRENT` | product | `REQ8,P2T,WFDG,WDRG,WCP1,WCPC,WHMS,WHMSLIVE,WOUA,WAPI,WRRA,WAPC1,WAPC2FLIVE,WCBK1,WEGOV1` | `rg` | none | 2026-05-19 | `rg` | high | 记录已拍板产品边界、企微/OA 设计门禁、开发路线图、WCBK1 真实回调事件证据、WEGOV1 混合主办边界和 OA 自建留存策略 |
-| `DESIGN-UI` | `docs/产品设计规则.md` | 设计事实源 | PC/移动/企业微信设计事实源 | `CURRENT` | design/frontend | `MIA7,MIF7,GOV8,DG8,DG9,WFDG` | Playwright/视觉审查/DG8/DG9/WFDG | none | 2026-05-18 | `rg` | high | 页面改动必须读取；DG8 后飞书为主 UI/布局参考；DG9 后按页面分层和样板选型；WFDG 后区分 OA 主办、企微镜像和 OA 应急接管 |
+| `DESIGN-UI` | `docs/产品设计规则.md` | 产品体验事实源 | PC/移动/企业微信职责、页面分层、信息语义和验收边界 | `CURRENT` | product/frontend | `MIA7,MIF7,GOV8,DG8,DG9,WFDG` | Playwright/视觉审查/DG8/DG9/WFDG | none | 2026-05-27 | `rg` | high | 视觉与交互裁决以 `frontend-design` 为准；本文只保留业务体验事实、OA/企微主办边界、A/B/C 页面职责和验收边界 |
 | `ROADMAP-WECOM` | `docs/企微优先开发路线图.md` | 开发治理 | 企微优先开发路线图事实源 | `CURRENT` | product/dev | `WDRG,WCP1,WCPC,WHMS,WHMSLIVE,WOUA,WAPI,WRRA,WOUAFIX,WRV1,WRA1,WMSG1,WAPC1,WAPC2,WPROC1,WPROC2,WAPC2F,WAPC2FLIVE,WCBK1,WEGOV1,WACP3,WACP3R,WREAD1,WREAD1F,WADM1,WARCH1,WARCH2,WROAD2,WARCH3,WCHECK1,WEXT1,WOPS1,WROAD2C,WROAD2B,WAPPR1,WRULE1,WAUTO1,WEXT1LD,WFULLSMOKE1,WROUTE2,WTCLOSE1,WTCLOSE2,WREAL1P` | Trellis task / 历史 Issue CSV | none | 2026-05-26 | `rg` | high | WAUTO1/WEXT1LD/WFULLSMOKE1/WTCLOSE1/WTCLOSE2 后固定最小审批历史留存、正式只读历史查询、受控上线自动巡检、三天业务冒烟、审批规则规范化、审批链校验、自动证据汇总、全域最终目标测试、小团队一层审批 + 管理员兜底、测试号最终收口、告警降噪、打卡摘要、外出/加班 dry-run、live 前 dry-run gate、WEXT1-FORMAL 前置和真实试用准备；仍禁止直接进入深度镜像 |
 | `WECOM-API-CATALOG` | `docs/企微API能力目录.md` | 集成事实源 | 企微 API 能力目录和 Secret 矩阵事实源 | `CURRENT` | product/backend/qa | `WAPI,WRRA,WAPC1,WAPC2,WPROC1,WPROC2,WAPC2F,WAPC2FLIVE,WCBK1,WEGOV1,WACP3,WACP3R,WREAD1,WADM1,WARCH1,WARCH2,WROAD2,WARCH3,WCHECK1,WEXT1,WAPPR1,WTCLOSE1,WRULE1,WTCLOSE2` | 官方企业微信开发者中心链接 / Trellis task / 历史 Issue CSV | none | 2026-05-26 | `rg` | high | 企微开发先读；只保存摘要、链接和项目决策，不保存 Secret、token、完整 userid、手机号、邮箱或原始 payload；记录审批补偿、打卡摘要、巡检只写 OA 留存、不写企业微信、企微原生审批规则不可只读 API 化、需人工门禁，以及 WRULE1/WTCLOSE2 只读审批链校验和最终收口边界 |
 | `DELIVERY` | `docs/开发交付与变更管理规约.md` | 开发治理 | 开发交付事实源 | `CURRENT` | dev/qa | `GOV8,WDRG,WRRA,WAPC1,WPROC1,WPROC2,WCBK1,WEGOV1,WOPS1,WROAD2C,WROAD2B,WAPPR1,WAUTO1,WEXT1LD,WFULLSMOKE1,TRELLIS2` | `rg` | none | 2026-05-26 | `rg` | high | Trellis task、review、commit、交付规则；WFULLSMOKE1 后固定 WAUTO1、WEXT1LD、全域最终目标测试和 WEXT1-FORMAL/WREAL1 前置门禁 |
@@ -163,7 +163,7 @@
 | `docs/文档索引.md` | 当前事实源 | 唯一文档入口 |
 | `docs/文档事实源状态矩阵.md` | 当前事实源 | 文档分类和恢复规则 |
 | `docs/海音达OA-MVP需求规格说明书.md` | 当前事实源 | PRD 主事实源 |
-| `docs/产品设计规则.md` | 当前事实源 | PC、移动、企业微信设计规则；DG8 主 UI/布局参考层级 |
+| `docs/产品设计规则.md` | 当前事实源 | 产品体验事实源；PC、移动、企业微信职责、页面分层、信息语义和验收边界 |
 | `docs/企微优先开发路线图.md` | 当前事实源 | WROAD2 后企微优先 HR/考勤改造阶段顺序、四域边界、API/Secret 口径、运行优先、审批只读 POC、自动样件、回调、补偿拉取、WREAD1 可读性、WARCH1/WARCH2 自建留存查询、受控上线巡检和禁止跳阶段 |
 | `docs/企微API能力目录.md` | 当前事实源 | WROAD2 后企微官方 API、Secret 矩阵、权限/可信 IP/回调模板、读写边界、无完整 sandbox 假设、运行优先、审批只读 POC、回调/补偿证据入库、只读查询和每日巡检写 OA 留存边界 |
 | `docs/产品口径.md` | 当前事实源 | 产品边界和业务规则 |

docs/文档索引.md

@@ -26,8 +26,7 @@ R6 -> PC6 -> PA6 -> FL6 -> AP6 -> RI6 -> LP6 -> ME6/QG6 -> DG7/MRF7 -> MIA7 -> M
 - ME6 自动化、公网视觉矩阵和 `ME6-3` 代表性企业微信真机门禁已完成。
 - QG6 已完成 QA 治理升级。
 - MIA7 已完成移动信息架构、视觉和流程审查；MIF7-1..7 与 MIF7T 已完成本地整改、公网部署、公网匿名复检和带凭据 live smoke/OCR 复检。
-- DG8 已完成设计治理主参考系统收口：飞书工作台/飞书审批是唯一主 UI/布局参考；本结论只更新设计事实源，不代表已做页面整改。
-- DG9 承接 DG8 后的页面整改：按 A/B/C 页面分层和 DG9 样板统一 PC、移动和企业微信入口布局；最新代码已作为 R7E 试运行基线部署到公网，不替代 WF8、UX8 或 BIZ8 业务验收。
+- DG8/DG9 是历史设计治理证据；2026-05-27 后前端视觉与交互裁决以 `frontend-design` 为准，`docs/产品设计规则.md` 只保留产品体验事实。
 - R7E 阶段验收、P2 排序和 QAOPS8 上线硬化阶段收口已完成，当前 P0/P1 阻断为 0；后续 P2 功能开发必须另建或延续对应连续合同。
 - FBA 是 R7E 后全端功能边界审计，只提供证据和后续候选草案，不启动 P2 功能开发。
 - QAOPS9 是 R7E 后上线硬化连续合同，优先处理公网业务流测试数据、live smoke 账号链路、恢复演练 dry-run 和 SLO/Go-No-Go 自动化增强；隔离本地业务流可使用临时库和测试开关，公网证据必须保持 flag-off 或 SKIP 可解释；不部署、不执行生产恢复、不重置数据库、不打印远端 env。
@@ -89,8 +88,8 @@ R6 -> PC6 -> PA6 -> FL6 -> AP6 -> RI6 -> LP6 -> ME6/QG6 -> DG7/MRF7 -> MIA7 -> M
 | 治理流 | 当前合同 | 当前状态 | 范围 | 不做 |
 | --- | --- | --- | --- | --- |
 | `GOV8` | `issues/2026-05-13_16-31-09-gov8-system-governance.csv` | 已收口 | 文档分类、台账、流程模板、审计脚本、需求冻结、变更控制 | 不改业务代码、不部署 |
-| `DG8` | `issues/2026-05-13_22-56-49-design-ui-governance.csv` | 已收口：设计事实源主参考系统更新 | 主 UI/布局参考层级、外部参考降级、Agent/Skill 设计入口、设计检查门禁 | 不改业务页面、不部署、不接入飞书 |
-| `DG9` | `issues/2026-05-13_23-30-00-dg9-ui-layout-rollout.csv` | 已收口；最新代码已随 R7E 部署到试运行环境 | A/B/C 页面分层、共享工作台骨架、移动槽位、审批/报销/首页/通知样板、设计门禁 | 不替代 WF8、UX8 或 BIZ8 业务验收 |
+| `DG8` | `issues/2026-05-13_22-56-49-design-ui-governance.csv` | 历史设计治理证据 | 旧主参考系统、外部参考降级和设计检查门禁；视觉裁决已由 `frontend-design` 接管 | 不改业务页面、不部署、不接入飞书 |
+| `DG9` | `issues/2026-05-13_23-30-00-dg9-ui-layout-rollout.csv` | 历史页面整改证据；最新代码已随 R7E 部署到试运行环境 | A/B/C 页面分层和共享组件迁移证据；后续页面设计不再复制 DG9 视觉样板 | 不替代 WF8、UX8 或 BIZ8 业务验收 |
 | `R7E` | `issues/2026-05-13_17-11-44-r7e-human-trialrun.csv` | 已收口：阶段验收通过，P2 排序与 R7E 收口完成 | 人工确认、真实试运行、每日问题收口、验收结论 | 不新增 P2 能力；付款批次延期到 P2 |
 | `ORG8` | `issues/2026-05-13_18-23-51-org8-master-data-permission.csv` | 已收口：本地代表性角色验收通过 | 组织、账号、直属主管、停用、角色、企业微信绑定、权限边界 | 不做审批流程增强；不替代 R7E 真实人工试运行 |
 | `WF8` | `issues/2026-05-13_18-23-52-wf8-approval-notification.csv` | 已收口：deeplink 修复已部署并经代表设备真机点击回 OA 验证 | 转审、通知、催办、邮件通道决策、三渠道验收 | 不做复杂 BPM 或审批设计器；通知模板和偏好设置延期到 P2 |
@@ -175,7 +174,7 @@ R6 -> PC6 -> PA6 -> FL6 -> AP6 -> RI6 -> LP6 -> ME6/QG6 -> DG7/MRF7 -> MIA7 -> M
 | `OALAUNCH1` | `issues/2026-05-23_16-49-39-oa-final-launch-readiness-v1.csv` | 当前最终启用前收口与 Go/No-Go 门禁：在 OAOPS1/ASSET1D 之上增加业务闭环、权限、备份恢复、数据治理、培训和 Day 7 决策 | 新增 `scripts/qa/run-oa-final-launch-readiness.sh`，默认只读聚合 OAOPS1、ASSET1D、权限矩阵、备份恢复演练和人工 Go/No-Go 证据，输出 `PASS_OA_LAUNCH_READY` / `PASS_WITH_FINDINGS` / `PAUSED_MANUAL_CONFIRMATION` / `SKIP/BLOCKED_BY_EXTERNAL_CONFIG` | 不创建业务数据、不执行付款、不写企业微信、不恢复数据库；未达到 `PASS_OA_LAUNCH_READY` 前不得宣布最终正式启用完成 |
 | `OMAT1` | `issues/2026-05-23_17-20-00-oa-maturity-gap-review-v1.csv` | 当前成熟度缺口审查台账：按 MAGI 审视/执行/提升轮次，对标国内主流 OA、协同、低代码、财务和资产系统，记录每个问题或建议供用户逐项采纳、暂缓或否决 | 已登记最终启用、真实业务闭环、权限、备份恢复、运营支持、流程配置、报表、财务月结、合同、采购、资产、HR 镜像、移动体验、数据治理、SLO、集成、知识档案、主数据、UX、AI 边界、国内对标来源、小团队取舍原则、用户决策回填、成熟度证据视图和最低非功能基线等候选项 | 本台账只做审查和决策，不直接触发业务代码实现；采纳项必须另建或延续对应 Trellis task，并满足 OALAUNCH1 门禁 |
 | `OPOLICY1` | `issues/2026-05-24_01-20-52-oa-policy-system-alignment-v1.csv` | 当前制度与 OA 对齐合同：先把外部制度包裁剪为小团队 V1，再回写 OA 事实源和启用门禁 | 已固化制度参数、资料留存、用印台账、审批异常 SOP、制度签收和 P2 冻结边界；预算硬控、复杂招采、电子签章、完整电子档案系统、ERP/银行深集成和 AI 自动改规则不作为正式启用前置条件 | 本合同优先制度和事实源调整；现有合同台账/资产台账/公告能力可承载 V1，不立即做 schema 或业务代码改造 |
-| `OAFRONT6` | `issues/2026-05-25_12-29-03-oa-frontend-maturity-small-step-v1.csv` | 当前前端成熟化小步收口：承接 OAFRONT5 部署后 PC 硬问题清零和设计审计；审批规则路由标题、资产台账详情分区、移动视觉矩阵稳定等待、合同台账表单分组和长编号压缩均已实施部署，公网 PC 只读视觉矩阵复测 `PASS_PC_READONLY_VISUAL_READY` 且 `findingCount=0`；Portal 继续后置观察 | 页面改动继续读取 `docs/产品设计规则.md` 和 OALAUNCH1 启用门禁；后续 Portal 仍需按真实使用反馈推进 | 不写公网业务数据；不替代真实业务闭环、备份恢复、7 天稳定化或 Day 7 Go/No-Go |
+| `OAFRONT6` | `issues/2026-05-25_12-29-03-oa-frontend-maturity-small-step-v1.csv` | 当前前端成熟化小步收口：承接 OAFRONT5 部署后 PC 硬问题清零和设计审计；审批规则路由标题、资产台账详情分区、移动视觉矩阵稳定等待、合同台账表单分组和长编号压缩均已实施部署，公网 PC 只读视觉矩阵复测 `PASS_PC_READONLY_VISUAL_READY` 且 `findingCount=0`；Portal 继续后置观察 | 页面改动使用 `frontend-design` 做视觉裁决，并读取 `docs/产品设计规则.md` 的产品体验事实和 OALAUNCH1 启用门禁；后续 Portal 仍需按真实使用反馈推进 | 不写公网业务数据；不替代真实业务闭环、备份恢复、7 天稳定化或 Day 7 Go/No-Go |
 | `OAKISS1` | `issues/2026-05-25_20-53-34-oa-business-flow-kiss-review-v1.csv` | 当前全业务流程 KISS 审查台账：按 MAGI 审视/执行/提升轮次，对报销/OCR、审批、采购/费用、合同/项目、付款/AP、票据池、资产、权限、移动/企微入口逐项做自动化和人工步骤审查 | 已形成 OAOPS1、OALAUNCH1、权限矩阵、PC 视觉、负责人审批链、资产试录和 OCR 辅助证据；建议保留 P0 主流程、简化 TEST/SMOKE 噪声和高密度后台页、后置 P2 复杂能力 | 本台账只做审查和建议，不直接改业务代码；真实业务闭环、备份恢复和 Day 7 Go/No-Go 仍按 OALAUNCH1 人工门禁执行 |
 | `PCDESIGN1` | `issues/2026-05-25_21-27-56-oa-pc-page-design-review-v1.csv` | 当前 PC 全页面设计审查台账：以项目经理和设计总监视角按 MAGI 审视/执行/提升轮次盘点 PC 路由、页面分层、交互、内容和 KISS 建议 | 已复跑关键 PC 视觉矩阵 `PASS_PC_READONLY_VISUAL_READY`，并补全 45 条静态 PC 路由扫描 `PASS_PC_STATIC_ROUTE_SCAN_READY`；建议优先收敛 HR/考勤边界、冻结模块入口、高密度 B/C 页默认视图和动态详情页证据 | 本台账只做审查和建议，不直接改业务代码；采纳后必须另建前端实施 Trellis task |
 | `TRELLIS1` | `issues/2026-05-26_09-02-34-trellis-primary-development-workflow-v1.csv` | 历史迁移合同：完成 Trellis-first 初始接入 | Trellis task/spec/workflow 成为开发入口的第一步，旧口径仍保留 Issue CSV 绑定 | 历史审计；已由 TRELLIS2 官方 task 合同口径替代 |
@@ -189,7 +188,7 @@ R6 -> PC6 -> PA6 -> FL6 -> AP6 -> RI6 -> LP6 -> ME6/QG6 -> DG7/MRF7 -> MIA7 -> M
 | 阶段 | 必读入口 | 目的 |
 | --- | --- | --- |
 | 需求阶段 | 当前 Trellis task、[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)、对应 `需求-*.md`、[产品口径](./产品口径.md) | 判断做什么、不做什么、验收什么 |
-| 设计阶段 | 最新设计治理合同、[产品设计规则](./产品设计规则.md)、[架构概览](./架构概览.md)、[集成边界](./集成边界.md)、`docs/ops/*.md`、必要 ADR | 判断页面、权限、状态流、集成和非功能边界 |
+| 设计阶段 | `frontend-design`、当前 Trellis task、[产品设计规则](./产品设计规则.md)、[架构概览](./架构概览.md)、[集成边界](./集成边界.md)、`docs/ops/*.md`、必要 ADR | 用 `frontend-design` 判断视觉和交互；用项目事实源判断页面职责、权限、状态流、集成和非功能边界 |
 | 开发阶段 | 当前 Trellis task、[开发交付与变更管理规约](./开发交付与变更管理规约.md)、`AGENTS.md` | 判断文件范围、依赖、方案批准和交接物 |
 | 测试阶段 | [测试规约与回归门禁](./测试规约与回归门禁.md)、[试运行与自动化验证手册](./试运行与自动化验证手册.md)、当前 Trellis task 的 Test Plan | 判断怎么测、何时可收口 |
 | 发布阶段 | [发布试运行准备清单](./trialrun/发布试运行准备清单.md)、[公网 Live Smoke 准备清单](./trialrun/公网LiveSmoke准备清单.md)、[OPS7 运维交接 Runbook](./trialrun/OPS7运维交接Runbook.md) | 判断公网、企业微信、真实 OCR 和回滚条件 |
@@ -202,7 +201,7 @@ R6 -> PC6 -> PA6 -> FL6 -> AP6 -> RI6 -> LP6 -> ME6/QG6 -> DG7/MRF7 -> MIA7 -> M
 | --- | --- |
 | [海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md) | PRD 主事实源；WARCH3/WCHECK1/WEXT1 后包含企微审批配置、只读 POC、工程化前置、process gate、请假/补卡样例、自建留存、受控上线巡检、打卡摘要、外出/加班 dry-run 和深度镜像前置口径 |
 | [文档事实源状态矩阵](./文档事实源状态矩阵.md) | 文档分类、删除恢复和冲突规则 |
-| [产品设计规则](./产品设计规则.md) | PC、移动、企业微信 WebView 设计事实源；DG8 后飞书工作台/飞书审批为唯一主 UI/布局参考；DG9 后按页面分层和样板选型 |
+| [产品设计规则](./产品设计规则.md) | 产品体验事实源；记录 PC、移动、企业微信职责、页面分层、信息语义和验收边界；视觉与交互裁决以 `frontend-design` 为准 |
 | [企微优先开发路线图](./企微优先开发路线图.md) | WDRG/WCP1/WCPC/WHMS/WHMSLIVE/WOUA/WAPI/WRRA/WOUA-FIX/WRV1/WRA1/WMSG1/WAPC1/WAPC2/WPROC1/WPROC2/WAPC2F/WAPC2FLIVE/WCBK1/WEGOV1/WACP3/WACP3R/WREAD1/WREAD1F/WARCH1/WARCH2/WROAD2/WARCH3/WCHECK1/WEXT1/WOPS1/WROAD2-CLOSEOUT/WROAD2-BIZ1/WAPPR1/WRULE1/WAUTO1/WEXT1LD/WFULLSMOKE1/WTCLOSE1/WTCLOSE2/WREAL1-PREP 后企微优先 HR/考勤改造的阶段顺序、准入/退出门禁、并行规则、禁止跳阶段、API/Secret 口径、运行优先、自建留存、受控上线巡检、三天业务冒烟、审批规则规范化、审批链校验、自动证据汇总、全域最终目标测试、测试号最终收口、告警降噪、打卡摘要、外出/加班 dry-run、WEXT1-FORMAL 和后续 WREAL1/镜像前置事实源 |
 | [企微 API 能力目录](./企微API能力目录.md) | WAPI/WAPC1/WAPC2/WPROC1/WPROC2/WAPC2F/WAPC2FLIVE/WCBK1/WEGOV1/WACP3/WACP3R/WARCH1/WARCH2/WROAD2/WARCH3/WCHECK1/WEXT1 后企微官方 API、Secret 矩阵、权限/可信 IP/回调模板、读写边界、运行优先、审批配置、只读 POC、回调/补偿入库、打卡摘要留存、外出/加班 dry-run 和巡检写 OA 留存边界事实源 |
 | [产品口径](./产品口径.md) | 已拍板产品边界和业务规则；WEGOV1 后包含混合主办、自建留存、受控测试域、后续阶段顺序和深度镜像前置口径 |
@@ -291,7 +290,7 @@ R6 -> PC6 -> PA6 -> FL6 -> AP6 -> RI6 -> LP6 -> ME6/QG6 -> DG7/MRF7 -> MIA7 -> M
 ## 阅读顺序
 
 1. 新需求：当前 Trellis task PRD + 对应模块规约。
-2. 页面体验：产品设计规则；DG8 后先按主 UI/布局参考层级判断。
+2. 页面体验：视觉与交互先使用 `frontend-design`；业务体验事实参考产品设计规则。
 3. 报销/发票：报销发票附件规则 + 报销 OCR 规约。
 4. 试运行/部署/真机：试运行手册 + 发布清单 + 真机清单。
 5. 历史追溯：历史功能状态矩阵 + git 历史 + 相关 Issue CSV。

docs/测试规约与回归门禁.md

@@ -112,7 +112,7 @@ R7E 前和后续非微小改动至少从以下组合中按风险选择；进入
 | --- | --- | --- |
 | 历史 CSV 兼容 | `python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py <issue.csv>` | 仅当当前任务包含 legacy/export CSV 时校验通过 |
 | 前端基础 | `cd client && npm run typecheck`、`cd client && npm run build` | 类型和构建通过，Vite chunk warning 不单独阻断 |
-| 设计规则 | `node scripts/qa/check-ui-design-rules.mjs --strict` | 当前 UI 设计规则 0 findings |
+| UI 规则脚本 | `node scripts/qa/check-ui-design-rules.mjs --strict` | 当前 UI 静态规则 0 findings；视觉与交互裁决以 `frontend-design` 为准 |
 | MIF7 移动矩阵 | `cd client && npx playwright test tests/e2e/dg7-mobile-information-dedupe.spec.ts --workers=1 --reporter=list` | 首页、进度/审批、通知、三类详情和财务首页通过；公网时设置 `E2E_BASE_URL=https://oa.hyinda.com` |
 | R6/MUD6/WCM6 移动回归 | `r6-mobile-responsive-system-hotfix`、`r6-mobile-unified-design-rollout`、`r6-wecom-mobile-rendering-hardening` | 旧移动矩阵用于防止信息架构整改破坏基础移动体验 |
 | 公网匿名 | `/ready`、`check-public-bundle-copy.mjs` | `/ready` 成功且 public bundle findings=0 |

docs/试运行与自动化验证手册.md

@@ -13,7 +13,7 @@
 1. 读取 `AGENTS.md`。
 2. 读取最新 `issues/*.csv`。
 3. 按任务读取事实源：
-   - 设计：`docs/产品设计规则.md`
+   - 页面体验事实：`docs/产品设计规则.md`；视觉与交互裁决使用 `frontend-design`
    - 报销发票：`docs/报销发票附件规则.md`
    - Agent 交付：`docs/Agent开发交付实践.md`
 4. 检查 `git status --short`，保护用户已有改动。

docs/需求-合同附件归档规约.md

@@ -6,9 +6,9 @@
 **补充口径**：OPOLICY1 后，合同/用印先按小团队 V1 执行；V1 通过合同台账、归档位置、离线档案号、非涉密证明和审计承载，不立即上电子签章或完整法务系统。
 **上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
 **审批总依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)
-**体验总依据**：[产品设计规则基线](./产品设计规则.md)
+**体验事实依据**：[产品体验事实源](./产品设计规则.md)；视觉与交互裁决以 `frontend-design` 为准。
 
-本规约细化合同台账、合同编号、非涉密附件、归档位置、权限审计和业务关联要求。合同审批、合同变更审批和归档动作仍回到 OA 统一审批中心留痕；PC 和移动页面模式以产品设计规则基线为体验依据；本规约不替代公司法务制度。
+本规约细化合同台账、合同编号、非涉密附件、归档位置、权限审计和业务关联要求。合同审批、合同变更审批和归档动作仍回到 OA 统一审批中心留痕；PC 和移动页面职责以产品体验事实源为依据；本规约不替代公司法务制度。
 
 ---
 

docs/需求-请假考勤修正规约.md

@@ -5,9 +5,9 @@
 **状态**：模块级开发规约
 **上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
 **相关事实源**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)、[需求 - 企业微信基础设施规约](./需求-企业微信基础设施规约.md)
-**体验总依据**：[产品设计规则基线](./产品设计规则.md)
+**体验事实依据**：[产品体验事实源](./产品设计规则.md)；视觉与交互裁决以 `frontend-design` 为准。
 
-本规约细化请假、补卡、外出、加班与考勤修正的产品要求。WFOC 起，企业微信作为 HR/考勤员工日常审批和打卡规则主操作端；OA 负责按域镜像、应急接管、恢复回写、查询导出和审计。WEGOV1 后进一步明确：企微成熟 HR/考勤功能优先上线，OA 不重造企业微信完整打卡/考勤/HR 产品，但必须做自建历史留存、审计、入口、消息和应急兜底。WAPC2 后，请假和补卡先通过 QA-only runner 只读验证模板详情与低风险 `sp_no` 审批详情；WAPC2FLIVE 已生成 OA-POC 样件并复跑通过；WCBK1 已完成真实回调 URL 验证和一条测试审批事件确认；WACP3R 已自动发现模板并证明补偿拉取和详情读取可用。WREAD1F 后，用户真机确认请假/补卡在企业微信消息卡片、列表和详情页均可看清，远端报告 `/app/artifacts/qa-flow/wecom-approval-readability-gate-20260519T133628Z/summary.json` 为 `PASS_READABLE`；驳回有二次确认，同意单击即通过。WARCH1 已实现请假/补卡最小审批历史留存、回调事件入库、补偿拉取入库和离线读取证明；WARCH2 已提供正式只读历史查询。WROAD2 后进入测试账号受控上线；WARCH3 已新增 07:30 systemd 自动巡检和脱敏企微告警；WCHECK1 已新增打卡规范化明细、日/月摘要和规则快照留存；WEXT1 已支持外出/加班 dry-run，但未 live 创建模板或审批单。WOPS1 后告警默认发给 `HYD000006`（`wangshunli` 的员工号）且只报新增异常；WROAD2-BIZ1 在三天内补充测试账号打卡、请假、补卡和 OA 离线查看人工业务冒烟；WAPPR1 把“申请人不得任意选择审批人、必须自动带出审批人、禁止自审”列为真实试用前门禁。WROAD2-CLOSEOUT/WROAD2-BIZ1/WAPPR1/WRULE1/WTCLOSE2/WREMOTE1 完成前不启用真实员工；外出/加班下一步改为 WEXT1-FORMAL 正式模板人工提交 + 系统只读校验，不再自动创建 OA-POC 外出/加班模板；四类测试号证据与审批规则门禁通过后才问真实小范围试用。当前仍不代表完整审批镜像、外出/加班正式模板证据、应急接管或恢复回写已实现。PC 和移动页面体验以产品设计规则基线为依据，不重复定义通用审批链和移动导航规则。
+本规约细化请假、补卡、外出、加班与考勤修正的产品要求。WFOC 起，企业微信作为 HR/考勤员工日常审批和打卡规则主操作端；OA 负责按域镜像、应急接管、恢复回写、查询导出和审计。WEGOV1 后进一步明确：企微成熟 HR/考勤功能优先上线，OA 不重造企业微信完整打卡/考勤/HR 产品，但必须做自建历史留存、审计、入口、消息和应急兜底。WAPC2 后，请假和补卡先通过 QA-only runner 只读验证模板详情与低风险 `sp_no` 审批详情；WAPC2FLIVE 已生成 OA-POC 样件并复跑通过；WCBK1 已完成真实回调 URL 验证和一条测试审批事件确认；WACP3R 已自动发现模板并证明补偿拉取和详情读取可用。WREAD1F 后，用户真机确认请假/补卡在企业微信消息卡片、列表和详情页均可看清，远端报告 `/app/artifacts/qa-flow/wecom-approval-readability-gate-20260519T133628Z/summary.json` 为 `PASS_READABLE`；驳回有二次确认，同意单击即通过。WARCH1 已实现请假/补卡最小审批历史留存、回调事件入库、补偿拉取入库和离线读取证明；WARCH2 已提供正式只读历史查询。WROAD2 后进入测试账号受控上线；WARCH3 已新增 07:30 systemd 自动巡检和脱敏企微告警；WCHECK1 已新增打卡规范化明细、日/月摘要和规则快照留存；WEXT1 已支持外出/加班 dry-run，但未 live 创建模板或审批单。WOPS1 后告警默认发给 `HYD000006`（`wangshunli` 的员工号）且只报新增异常；WROAD2-BIZ1 在三天内补充测试账号打卡、请假、补卡和 OA 离线查看人工业务冒烟；WAPPR1 把“申请人不得任意选择审批人、必须自动带出审批人、禁止自审”列为真实试用前门禁。WROAD2-CLOSEOUT/WROAD2-BIZ1/WAPPR1/WRULE1/WTCLOSE2/WREMOTE1 完成前不启用真实员工；外出/加班下一步改为 WEXT1-FORMAL 正式模板人工提交 + 系统只读校验，不再自动创建 OA-POC 外出/加班模板；四类测试号证据与审批规则门禁通过后才问真实小范围试用。当前仍不代表完整审批镜像、外出/加班正式模板证据、应急接管或恢复回写已实现。PC 和移动页面职责以产品体验事实源为依据，不重复定义通用审批链和移动导航规则。
 
 ---
 

docs/需求-采购费用审批规约.md

@@ -6,9 +6,9 @@
 **补充口径**：OPOLICY1 后，小团队 V1 将预算硬控、复杂招采和供应商生命周期管理后置；正式启用前以资金安排说明、预算外原因、管理层审批留痕和 OA 审计为主。
 **上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
 **审批总依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)
-**体验总依据**：[产品设计规则基线](./产品设计规则.md)
+**体验事实依据**：[产品体验事实源](./产品设计规则.md)；视觉与交互裁决以 `frontend-design` 为准。
 
-本规约细化采购申请和费用申请的业务边界、字段、状态、权限、异常、验收场景和后续开发拆分建议。审批动作、状态机、审批规则矩阵、权限数据范围和留痕要求，以统一审批中心规约为总依据；PC 和移动页面模式以产品设计规则基线为体验依据；本规约只补充采购和费用业务自身规则。
+本规约细化采购申请和费用申请的业务边界、字段、状态、权限、异常、验收场景和后续开发拆分建议。审批动作、状态机、审批规则矩阵、权限数据范围和留痕要求，以统一审批中心规约为总依据；PC 和移动页面职责以产品体验事实源为依据；本规约只补充采购和费用业务自身规则。
 
 ---
 

docs/需求-项目轻管理规约.md

@@ -4,9 +4,9 @@
 **日期**：2026-05-09
 **状态**：模块级开发规约
 **上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
-**审批与体验依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)、[产品设计规则基线](./产品设计规则.md)
+**审批与体验事实依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)、[产品体验事实源](./产品设计规则.md)；视觉与交互裁决以 `frontend-design` 为准。
 
-本规约细化项目轻管理的业务边界、字段、状态、角色、业务关联、异常、验收场景和后续开发拆分建议。项目页目标是汇总关键事项和业务关联，帮助 10 人以下科技公司看清项目交付、风险和费用，不替代专业项目管理工具。项目相关审批和待办回到统一审批中心，PC 和移动页面模式以产品设计规则基线为依据。
+本规约细化项目轻管理的业务边界、字段、状态、角色、业务关联、异常、验收场景和后续开发拆分建议。项目页目标是汇总关键事项和业务关联，帮助 10 人以下科技公司看清项目交付、风险和费用，不替代专业项目管理工具。项目相关审批和待办回到统一审批中心，PC 和移动页面职责以产品体验事实源为依据。
 
 ---