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

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 主展示、按钮和底部导航异常。
 
 不适合完全自动化的任务要保留人工验收入口，例如真实企业微信登录、真实账号安全操作、生产数据处理、财务制度决策。