G1-G6 同步 R6 前置规约与最佳实践

2026-05-11 10:16:05 +08:00
@@ -12,7 +12,9 @@ Use this skill when working in `/home/shunli/Projects/hyb-oa` or when the user a
 Read only what is relevant:
 - Always read `AGENTS.md` and the newest relevant `issues/*.csv`.
- For UI/page work, read `docs/product-design-rules.md` and `references/visual-qa.md`.
+- After R5, first check the main R5/R6 contract status before planning trial-run or follow-up work; R5 must remain the completed gate and R6 must have its own Issue CSV before expanding scope.
 - For UI/page work, PC/mobile/WeCom experience, approval UX, or domestic OA benchmarking, read `docs/product-design-rules.md` and `references/visual-qa.md`.
 - For approval workflow, roles, self-approval, notification, deeplink, reminder, or escalation work, read `docs/需求-统一审批中心规约.md`.
 - For reimbursement, invoice, OCR, duplicate invoice, or attachment work, read `docs/reimbursement-invoice-rules.md` and `references/reimbursement.md`.
 - For local/WeCom/public trial-run, OCR runtime, Caddy, or DB drift work, read `docs/trialrun-runbook.md` and `references/trialrun.md`.
 - For how this skill should evolve, read `docs/agent-development-practices.md`.
@@ -32,10 +34,10 @@ Default behavior:
 ## Delivery Loop
 1. Check `git status --short`; do not revert unrelated user changes.
-2. Identify or create the current Issue CSV before non-trivial work.
+2. Identify or create the current Issue CSV before non-trivial work; after R5, distinguish R6 preparation from actual trial-run execution.
 3. State the implementation approach before editing code; if already approved, proceed.
 4. Keep changes scoped to the current Issue.
-5. Prefer existing project patterns and official SDKs.
+5. Prefer existing project patterns, official SDKs, and principles from documented domestic OA/approval/mobile references; do not copy competitor flows or text directly.
 6. Verify with the narrowest relevant automated tests, then expand by risk.
 7. Use Playwright screenshots or visual metrics for PC/mobile/WeCom UI changes.
 8. Update Issue CSV statuses only after the stated `Test_Method` passes.
@@ -92,3 +94,11 @@ Final responses should include:
 - 面向用户可测改动的部署状态：commit hash、公网 URL、`/ready`、公网前端资源/文案检查，以及用户现在是否可以测试。
 - What remains blocked and why.
 - Commit hashes when commits were made.
 ## R6 and Trial-Run Defaults
 - R6 can start only from a new Issue CSV that fixes users, roles, time window, rollback contact, issue log, and daily closeout rhythm.
 - R6 scope defaults to reimbursement, leave, procurement, approval, Enterprise WeChat entry/notification, finance payment/export.
 - Do not expand to budget, ERP, AI, full travel, or complex BPM during R6; record those as follow-up Issues.
 - Enterprise WeChat personal app message is the formal approval notification channel after R5; mock and group bots are not acceptance evidence for R6 business notification.
 - Approval-chain correctness can be proven by PC or automation, while Enterprise WeChat validates entry, binding,免登录, notification, deeplink, and mobile layout.
@@ -73,6 +73,15 @@ AGENTS.md 只放硬约束和入口，不复制长规则。
 - 文案是否符合国内 OA 习惯。
 - 是否出现 PC 表格误入手机、黑色大块导航、按钮样式不一致、文字截断、弹窗自动弹键盘等明显问题。
 外部最佳实践只沉淀原则，不复制竞品交互或文案。参考钉钉、飞书、企业微信、Ant Design、WeUI 等公开资料时，必须先抽象为本项目自己的事实源：
 - PC 端：工作台、表格、筛选、详情分区、批量处理和管理配置。
 - 移动端：企业微信消息驱动、卡片列表、一级底部导航、深层 Push 页和吸底主操作。
 - 审批：待办聚合、明确状态、可追溯、可催办、超时提醒和效率统计。
 - 企业微信：入口、身份、个人应用消息和 deeplink，不替代 OA 正式审批。
 可自动化的体验检查先自动化，例如 Playwright PC、移动、企业微信 UA 和 DOM 指标；真实企业微信登录、手机应用消息到达、真实通知权限和财务制度决策必须保留人工确认记录。
 ### 7. 提交要小批次、中文、可回滚
 一次需求可以有多个 commit，但每个 commit 应该能说明一个清晰主题：
@@ -21,6 +21,28 @@ OA 页面应参考公司主页 `www.hyinda.com` 的视觉气质，但不能做
 - 字体气质：官网使用偏现代无衬线风格；OA 继续使用系统无衬线字体，但字号、行距和按钮高度要克制。
 - 双端一致：PC 和企业微信/手机端都遵循同一品牌色和控件语义，只根据屏幕密度调整布局。
 ## 国内同类系统体验基线
 R6 之后的 PC、移动和审批体验参考国内主流协同/OA 产品的共性，而不是复制任何单一产品。公开资料显示，钉钉审批强调模板化审批、假勤/财务场景和移动处理，飞书审批强调一站式入口、即时消息通知、移动端处理、流程配置和催办，企业微信自建应用适合作为工作台入口、身份和个人消息 deeplink。PC 端的工作台、表格、表单和导航可参考 Ant Design 的信息密度和后台系统模式，移动端参考微信生态常见的 WeUI/Ant Design Mobile 控件语义。
 落到 hyb-oa 的原则：
 - PC 是高密度工作台，服务筛选、批量查看、审批、财务复核、导出和管理配置。
 - 移动端是消息驱动的轻入口，服务提交、补材料、查状态、处理待办和从企业微信消息回流。
 - 企业微信只做入口、绑定、免登录、个人应用消息和 deeplink，不替代 OA 正式审批页。
 - 审批体验以“待办聚合、清晰状态、明确下一步、可催办和可追溯”为目标；催办、超时提醒和效率统计属于 R6 后续优化，不混入 R6 首轮试运行门禁。
 参考资料：
 - 钉钉审批：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/
 - WeUI：https://www.npmjs.com/package/weui
 ## 文案规则
 禁止：
@@ -52,6 +74,8 @@ OA 页面应参考公司主页 `www.hyinda.com` 的视觉气质，但不能做
 - 顶部只保留标题、核心筛选、主操作。
 - 表格列优先显示业务编号、申请人、金额/天数、状态、更新时间、操作。
 - 筛选区默认收敛为关键字段：状态、申请人、时间、业务编号或关键词；高级筛选折叠，不压缩列表首屏。
 - 分页、空状态、批量操作和导出入口必须清楚区分；员工页少配置，财务和管理员页可更高密度。
 - 操作列至少区分“查看/编辑”和状态允许时的“删除草稿”。
 - 长 ID、调试字段、路径字段默认不进入主列。
@@ -61,6 +85,7 @@ OA 页面应参考公司主页 `www.hyinda.com` 的视觉气质，但不能做
 - 状态、金额、申请人、更新时间作为摘要条。
 - 主流程操作固定在页头或底部操作区，危险操作靠右或二次确认。
 - 审批流、附件、发票和日志分区展示，避免混在一个长表单里。
 - 审批、财务和管理员视角可以展示更多审计信息，但普通员工主视角只展示与下一步动作有关的信息。
 表单和弹窗：
@@ -74,6 +99,8 @@ OA 页面应参考公司主页 `www.hyinda.com` 的视觉气质，但不能做
 - 菜单不应占用大量空间；常用入口放底部导航，更多入口放“我的”。
 - 移动底部导航固定为“首页、审批、报销、我的”；票据上传作为首页快捷入口和报销页内操作，不作为底部一级 Tab。
 - 报销详情、审批详情等深层 Push 页隐藏底部导航，使用顶部返回和上下文吸底操作，避免底部 Tab 在深层页面假选中。
 - 企业微信个人应用消息 deeplink 应直达移动待办或业务详情；首次进入如需点击进入工作台，应保持后续可直接回到目标页。
 - 移动列表使用卡片和状态标签，首屏优先展示“谁提交、什么事项、金额/天数、当前状态和下一步”。
 - 列表使用卡片，不直接显示桌面表格。
 - 表单字段纵向排列，按钮宽度稳定，首屏优先完成“新建/继续编辑/提交”。
 - 企业微信入口应尽量免登录；绑定失败或权限不足时显示明确下一步，而不是让用户反复登录。
@@ -115,6 +142,13 @@ OA 页面应参考公司主页 `www.hyinda.com` 的视觉气质，但不能做
 ## 后续批次
 R6 小范围试运行准备：
 - 先新建独立 R6 合同，固定 2-3 个内部用户、角色、时间窗口、回滚联系人、问题登记表和每日收口节奏。
 - R6 范围限定为报销、请假、采购、审批、企业微信入口/通知、财务付款/导出。
 - R6 不扩预算、ERP、AI、完整差旅、复杂 BPM；发现需求只登记为新 Issue。
 - 试运行反馈按“阻断、严重、一般、体验建议”分级，不能现场扩大实现范围。
 R101 报销主流程重构：
 - 后端业务编号、权限和删除规则。
@@ -4,6 +4,8 @@
 当前报销、发票、OCR、附件、付款和导出开发以 [需求 - 报销发票 OCR 规约](./需求-报销发票OCR规约.md) 为模块级开发规约；本文保留为报销细则来源。如两者有重复，以新规约整合后的口径为准。首批发票合规以 OCR、查重和财务人工复核为主，自动验真作为后续评估项。
 R5 公网验收后确认：正式发票/OCR 上传入口只接受 PDF 发票文件；图片和拍照直传不作为发票入口。附件材料仍可上传图片或 PDF，但必须与发票分离。重复票据、已使用票据和 OCR 失败必须进入可解释终态，不能长期停留在处理中。
 ## 总原则
 - PC 与手机功能一致，只允许布局和控件形态不同。
@@ -34,6 +36,7 @@
 ## 上传与 OCR
 - 发票/OCR 上传只允许 PDF 发票文件；图片、拍照直传和 HTML `capture` 入口不作为正式发票上传方式。
 - PC 票据中心、PC 报销详情、移动报销详情和企业微信 WebView 内的发票入口都必须执行 PDF-only 口径。
 - 上传后页面必须显示明确状态，不应长期停留在“上传中”。
 - OCR 完成后，添加发票弹窗应自动刷新并尝试添加可用发票。
 - OCR 失败、重复、已使用、他人已使用都要显示可理解原因。
@@ -100,11 +103,13 @@ PC 端：
 - 适合明细编辑、批量查看、财务复核和台账导出。
 - 报销详情分区展示：摘要、明细、发票、附件、审批流、预算与审核提示。
 - PC 报销列表和详情遵循 [产品设计规则基线](./product-design-rules.md)：业务编号、状态、申请人、金额和更新时间优先，不把 UUID 或内部状态码作为主展示。
 手机/企业微信端：
 - 适合新建、继续编辑草稿、上传 PDF 发票、补充附件、提交审批、查状态。
 - 不显示桌面表格。
 - 报销详情深层页隐藏底部 Tab，顶部返回清晰，底部主操作不遮挡内容；iPhone 11 等小屏下核心双按钮仍同行展示。
 - 添加发票不默认聚焦搜索框，不自动弹键盘。
 - 底部操作区紧凑，选中态使用品牌实心色；核心操作在 iPhone 11 等小屏上仍保持同行双按钮，不降级为单列。
@@ -77,16 +77,16 @@
 | 主管本人申请 | PC/自动化 | `SMOKE101` / 测试主管 | `SMOKE101` 提交本人申请 | 待办分配给 `SMOKE201` | 通过 | S4 自动化证据 |
 | 公司负责人本人申请 | PC/自动化 | `SMOKE201` / 测试负责人 | `SMOKE201` 提交本人申请 | 不允许自审；无非本人兜底时阻断 | 通过 | S4 自动化证据 |
 | 系统管理员无业务审批权 | PC/自动化 | `SMOKE001` / 测试管理员 | 尝试审批测试单据 | 不允许仅凭 `admin` 审批 | 通过 | S4 自动化证据 |
-| 财务复核与付款/导出 | PC/自动化 | `SMOKE301` / `SMOKE302` | 处理已批准测试单据 | 按财务与财务主管权限处理 | 自动化已覆盖财务节点，PC 页面证据按 R5 收口补充 | S4 自动化证据 / 后续 PC 记录 |
+| 财务复核与付款/导出 | PC/自动化 | `SMOKE301` / `SMOKE302` | 处理已批准测试单据 | 按财务与财务主管权限处理 | 自动化已覆盖财务节点；PC 页面体验后续 R6 继续观察 | S4 自动化证据 |
 ### 企业微信/移动体验验收矩阵
 | 验收项 | 企业微信测试成员 | OA 账号 | 期望结果 | 当前结果 | 截图或录屏位置 |
 | --- | --- | --- | --- | --- | --- |
 | 工作台入口与免登录 | `oa_smoke_01` | `SMOKE002` | 从企业微信工作台进入 OA，已绑定后免登录 | 通过 | 用户确认；截图/录屏不提交仓库 |
-| 提交人移动报销体验 | `oa_smoke_01` | `SMOKE002` | 移动首页、报销页、详情页、PDF 发票入口可用 | 公网自动视觉通过；企业微信真机待补 | `output/playwright/r5-live-mobile-wecom-visual/` |
+| 提交人移动报销体验 | `oa_smoke_01` | `SMOKE002` | 移动首页、报销页、详情页、PDF 发票入口可用 | 公网自动视觉通过；真机核心链路通过 | `output/playwright/r5-live-mobile-wecom-visual/` |
-| 审批人移动待办体验 | `oa_smoke_02` | `SMOKE101` | 移动审批待办、审批详情、结果反馈可用 | 公网自动视觉通过；企业微信真机待补 | `output/playwright/r5-live-mobile-wecom-visual/` |
+| 审批人移动待办体验 | `oa_smoke_02` | `SMOKE101` | 移动审批待办、审批详情、结果反馈可用 | 公网自动视觉通过；真机审批与消息回流通过 | `output/playwright/r5-live-mobile-wecom-visual/` |
-| 移动底部导航与深层页 | `oa_smoke_01` / `oa_smoke_02` | `SMOKE002` / `SMOKE101` | 首页、审批、报销、我的固定可见；报销详情隐藏底部 Tab，吸底双按钮不遮挡 | 公网自动视觉通过；企业微信真机待补 | `output/playwright/r5-live-mobile-wecom-visual/` |
+| 移动底部导航与深层页 | `oa_smoke_01` / `oa_smoke_02` | `SMOKE002` / `SMOKE101` | 首页、审批、报销、我的固定可见；报销详情隐藏底部 Tab，吸底双按钮不遮挡 | 公网自动视觉通过；R6 继续真机观察不同设备体验 | `output/playwright/r5-live-mobile-wecom-visual/` |
 | 通知与 deeplink | `oa_smoke_01` / `oa_smoke_02` | `SMOKE002` / `SMOKE101` | 通知能回到移动待办或详情页 | 真机通过：收到个人应用消息，点击后首次需点进入工作台，后续可直达移动审批 | `output/playwright/r5-wecom-app-message-live/` |
 自动化补充证据（用于审批链业务验收）：
@@ -7,11 +7,12 @@
 ## 1. 当前结论
- Release candidate：`537e608 A8 完成首轮主线总回归门禁`。
+- 首轮本地 release candidate：`537e608 A8 完成首轮主线总回归门禁`。
 - 当前公网 R5 运行代码：`b1ae41f W1-W3 实现企业微信个人应用消息通知`。
 - 主开发合同：`issues/2026-05-09_20-57-19-mvp-mainline-dev-kickoff.csv`，A1-A8 已全部 `DONE/DONE/DONE`。
 - 剩余主线批次合同：`issues/2026-05-10_10-48-03-mvp-remaining-mainline-closeout.csv`，B1-B5 已全部 `DONE/DONE/DONE`。
- 当前状态：本地门禁已闭环；R4 部署预检、D3 受控同步和 D4 只读复检已完成；公网已部署本轮 release candidate。
+- 当前状态：本地门禁已闭环；R4 部署预检、D3 受控同步、D4 只读复检、R5 公网 live smoke、真实 PDF OCR、PC/自动化审批链、企业微信真机入口、个人应用消息和 deeplink 均已完成。
- 当前最大缺口：R5 公网自动化和真实 OCR 已通过；企业微信真机人工验收尚未执行，因此 R5 尚未完成，R6 仍不能开始。
+- 当前最大缺口：R6 尚未单独规划。R6 只能在独立 Issue CSV 中固定试运行名单、时间窗口、回滚联系人和问题登记规则后启动。
 首轮路线保持不变：OA 是唯一业务主系统和正式审批中心；企业微信只做入口、身份、通知、deeplink 和打卡原始采集边界；不接飞书，不接企业微信原生审批。
@@ -81,7 +82,7 @@ R3 审计执行记录见 [`permission-direct-access-audit.md`](permission-direct
 部署前只做只读确认，不直接改生产：
-2026-05-10 R4/D3/D4 结论：`DONE`。已创建部署前 DB/storage 备份，执行 `bash deploy/trialrun/deploy.sh` 同步远端文件树并完成脚本内置 smoke；部署后只读复检显示关键运行时文件哈希对齐、Prisma migration up to date、`/ready` 200、Caddy 正常、企业微信 config 不返回 secret、公网资源文案扫描 0 findings。R5 公网自动化和真实 OCR 已在后续 smoke 密码重置后通过，仍需企业微信真机人工验收后才能关闭。
+2026-05-10 R4/D3/D4 结论：`DONE`。已创建部署前 DB/storage 备份，执行 `bash deploy/trialrun/deploy.sh` 同步远端文件树并完成脚本内置 smoke；部署后只读复检显示关键运行时文件哈希对齐、Prisma migration up to date、`/ready` 200、Caddy 正常、企业微信 config 不返回 secret、公网资源文案扫描 0 findings。后续 R5 已完成公网自动化、真实 PDF OCR、企业微信真机和个人应用消息验收。
 - 当前生产 commit、部署目录和本地 release candidate 是否一致。
 - 生产 `.env` 必需项是否完整；检查时不得打印 secret。
@@ -151,7 +152,17 @@ LIVE_SMOKE_BASE_URL=https://oa.hyinda.com bash scripts/qa/run-live-smoke-readine
 - 证据目录：`artifacts/qa-flow/live-smoke-readiness-20260510-172421/`。
 - pending OCR 辅助扫描仍因缺 `DATABASE_URL` 记录 `SKIP`，不作为 R5 硬阻断。
 - K4 副作用只读审计：`authSessions=555 -> 572`，`auditLogs=258 -> 263`；`reimbursements=1`、`invoices=5`、`ocrResultsLinkedFromInvoices=1` 保持不变；未清理数据。
- 结论：公网自动化和真实 OCR 已通过；企业微信真机人工验收尚未执行，所以主 R5 仍不能置为 `DONE/DONE/DONE`，R6 仍不能开始。
+- 阶段结论：公网自动化和真实 OCR 已通过；当时企业微信真机人工验收尚未执行，所以主 R5 仍不能置为 `DONE/DONE/DONE`。
 2026-05-11 R5 最终收口：
 - 当前公网已部署 `b1ae41f`，R4 复检通过；企业微信通知渠道切换为 `R5-WECOM-APP-PERSONAL / wecom_app_message`，旧 mock 渠道已停用。
 - `node scripts/qa/check-live-smoke-env.mjs --strict` 通过；`LIVE_SMOKE_BASE_URL=https://oa.hyinda.com bash scripts/qa/run-live-smoke-readiness.sh` 通过；证据目录 `artifacts/qa-flow/live-smoke-readiness-20260511-092236/`。
 - 真实 PDF OCR 不再 `SKIP`，重复样票进入“已用于报销，不能重复添加”的可解释终态。
 - 测试组织审批链、admin-only 无业务审批权、自审阻断、财务/财务主管节点已由 PC/自动化证明。
 - 企业微信真机已确认：`oa_smoke_01 -> SMOKE002`、`oa_smoke_02 -> SMOKE101` 绑定、工作台入口、免登录、提交、审批和移动回流通过。
 - 个人应用消息已确认：`SMOKE002` 触发 `SMOKE101` 待办 `936362d8-c4e0-454f-a589-9c9653bcbfda`，delivery 为 `wecom_app_sent`、`errcode=0`、无 `invaliduser`；用户确认手机企业微信收到“海音达工作台”消息，标题正确，点击后可进入移动审批。
 - 结论：主 R5 已 `DONE/DONE/DONE`。R6 仍需单独规划和批准，不能自动扩大试运行。
 判定：
@@ -161,7 +172,7 @@ LIVE_SMOKE_BASE_URL=https://oa.hyinda.com bash scripts/qa/run-live-smoke-readine
 ## 7. 小范围试运行
-只有 R3-R5 无阻断后，才开放 2-3 个内部用户试运行。
+R5 已完成。下一步只能通过独立 R6 Issue CSV 开放 2-3 个内部用户试运行，不能直接把 R5 通过解释为“自动进入正式试运行”。
 建议首批角色：
@@ -5,8 +5,9 @@
 **状态**：模块级开发规约
 **上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
 **审批总依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)
 **体验总依据**：[产品设计规则基线](./product-design-rules.md)
-本规约细化合同台账、合同编号、非涉密附件、归档位置、权限审计和业务关联要求。合同审批、合同变更审批和归档动作仍回到 OA 统一审批中心留痕；本规约不替代公司法务制度。
+本规约细化合同台账、合同编号、非涉密附件、归档位置、权限审计和业务关联要求。合同审批、合同变更审批和归档动作仍回到 OA 统一审批中心留痕；PC 和移动页面模式以产品设计规则基线为体验依据；本规约不替代公司法务制度。
 ---
@@ -1,7 +1,7 @@
 # 需求 - 统一审批中心规约
-**版本**：1.1
+**版本**：1.2
-**日期**：2026-05-10
+**日期**：2026-05-11
 **状态**：模块级开发规约
 **上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
@@ -17,6 +17,7 @@
 - 所有正式审批在 OA 内提交、审批、留痕、归档。
 - PC、移动端和企业微信入口看到的是同一批审批任务和同一套审批记录。
 - 企业微信只做入口、身份、通知和 deeplink；审批动作必须回到 OA 页面完成。
 - R5 已在公网验证企业微信工作台入口、免登录、个人应用消息通知和移动审批回流；R6 之后继续沿用“OA 内审批、企业微信提醒回流”的正式口径。
 ### 1.2 适用对象
@@ -260,10 +261,13 @@
 ## 9. 企业微信边界
 - 企业微信自建应用只作为 `海音达工作台` 手机入口。
 - 企业微信个人应用消息是正式审批待办提醒的首选 IM 通道；群机器人和 mock 只允许作为运维或自动化补充证据。
 - 企业微信消息只发送脱敏提醒：标题、业务编号、状态、处理入口。
 - 企业微信 deeplink 必须指向 OA 审批页或业务详情页。
 - 用户点击消息后，在 OA 内查看详情并执行审批动作。
 - 企业微信原生审批不参与正式审批流，不生成公司认可的正式审批记录。
 - 若企业微信返回 `invaliduser`、`unlicenseduser`、不可见范围或权限类错误，业务提交和审批动作不应回滚，但通知记录必须可审计、可重试，并提示管理员修正企业微信应用可见范围或账号绑定。
 - 真机验收以企业微信手机端收到应用消息并可点击回流为准；系统级弹窗是否出现受客户端通知权限影响，不作为 OA 通知链路硬门槛。
 ---
@@ -274,6 +278,7 @@
 | 正常审批通过 | 申请人提交报销或请假；审批人在 PC 通过；查看业务详情 | 单据从草稿到审批中再到已通过；历史、当前状态、通知记录一致 |
 | 移动端审批 | 申请人提交单据；审批人从 `/mobile/approvals` 打开待办并通过 | 移动端可完成审批；PC 待办同步消失或进入已办 |
 | 企业微信通知回 OA | 待办产生后发送企业微信提醒；审批人点击 deeplink | 打开 OA 对应审批页；不能在企业微信原生审批完成动作 |
 | 企业微信个人应用消息 | 触发待办后向绑定企业微信成员发送个人应用消息 | delivery 为成功且无 `invaliduser`；手机端可收到消息并点击回到 OA 移动审批 |
 | 驳回重提 | 审批人填写原因驳回；申请人查看原因后复制或重建申请 | 原流程留痕完整；新流程有新的提交记录 |
 | 退回修改 | 审批人退回；申请人修改后重提 | 保留同一业务单号和退回历史；重新进入审批中 |
 | 撤回 | 申请人在未完成前撤回 | 流程终止或回到草稿；审批人待办失效 |
@@ -303,4 +308,11 @@
 - A8：审批规则配置矩阵落地，覆盖金额阈值、天数阈值、兜底审批人、转审和撤回。
 - A9：权限与数据范围矩阵落地，覆盖附件下载、导出、例外处理和系统管理员最小授权。
 R6 首轮试运行只验证已有审批主链路稳定性，不新增复杂审批能力。R6 后续优化可单独拆分：
 - 待办聚合：PC 和移动统一展示待办、已办、抄送和通知入口。
 - 催办与超时提醒：按业务类型、金额或天数配置提醒策略，催办动作必须留痕。
 - 审批效率统计：按节点、角色和业务类型统计平均处理时长、超时数量和积压数量。
 - 流程配置治理：把金额阈值、兜底审批人、转审规则和通知路由纳入管理员可理解的配置页。
 涉及状态机、权限模型、数据库迁移或审批规则调整的 Issue，必须在技术方案中写明回滚策略和回归范围。
@@ -5,8 +5,9 @@
 **状态**：模块级开发规约
 **上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
 **相关事实源**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)、[需求 - 企业微信基础设施规约](./需求-企业微信基础设施规约.md)
 **体验总依据**：[产品设计规则基线](./product-design-rules.md)
-本规约细化请假、补卡、外出、加班与考勤修正的产品要求。正式审批记录以 OA 为准；企业微信打卡只作为原始采集来源，不直接决定最终考勤结论。
+本规约细化请假、补卡、外出、加班与考勤修正的产品要求。正式审批记录以 OA 为准；企业微信打卡只作为原始采集来源，不直接决定最终考勤结论。PC 和移动页面体验以产品设计规则基线为依据，不重复定义通用审批链和移动导航规则。
 ---
@@ -5,8 +5,9 @@
 **状态**：模块级开发规约
 **上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
 **审批总依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)
 **体验总依据**：[产品设计规则基线](./product-design-rules.md)
-本规约细化采购申请和费用申请的业务边界、字段、状态、权限、异常、验收场景和后续开发拆分建议。审批动作、状态机、审批规则矩阵、权限数据范围和留痕要求，以统一审批中心规约为总依据；本规约只补充采购和费用业务自身规则。
+本规约细化采购申请和费用申请的业务边界、字段、状态、权限、异常、验收场景和后续开发拆分建议。审批动作、状态机、审批规则矩阵、权限数据范围和留痕要求，以统一审批中心规约为总依据；PC 和移动页面模式以产品设计规则基线为体验依据；本规约只补充采购和费用业务自身规则。
 ---
@@ -4,8 +4,9 @@
 **日期**：2026-05-09
 **状态**：模块级开发规约
 **上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
 **审批与体验依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)、[产品设计规则基线](./product-design-rules.md)
-本规约细化项目轻管理的业务边界、字段、状态、角色、业务关联、异常、验收场景和后续开发拆分建议。项目页目标是汇总关键事项和业务关联，帮助 10 人以下科技公司看清项目交付、风险和费用，不替代专业项目管理工具。
+本规约细化项目轻管理的业务边界、字段、状态、角色、业务关联、异常、验收场景和后续开发拆分建议。项目页目标是汇总关键事项和业务关联，帮助 10 人以下科技公司看清项目交付、风险和费用，不替代专业项目管理工具。项目相关审批和待办回到统一审批中心，PC 和移动页面模式以产品设计规则基线为依据。
 ---
@@ -0,0 +1,7 @@
 ID,Title,Description,Acceptance,Test_Method,Tools,Dev_Status,Review1_Status,Regression_Status,Files,Dependencies,Notes
 G1,基线确认与合同建档,确认 R5 已完成且 R6 未启动，为 R6 前置规约和最佳实践沉淀建立执行合同。,"1) 新 CSV 存在且校验通过；2) 主 R5 为 DONE/DONE/DONE；3) R6 保持 TODO；4) 本轮不改业务代码 不部署 不改远端数据。",流程级验证：git status --short；git log --oneline -5；python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py issues/2026-05-11_10-06-44-r6-governance-benchmark-roadmap.csv。,git|python3|manual,DONE,DONE,DONE,issues/2026-05-11_10-06-44-r6-governance-benchmark-roadmap.csv,[],R5 基线为 bc6b222；本合同只做文档治理和后续工作规划。
 G2,国内同类系统最佳实践摘要,将钉钉审批 飞书审批 企业微信应用消息 Ant Design 和 WeUI 的公开一手资料抽象为 PC 移动 审批 通知的产品原则。,"1) 文档只沉淀原则不复制竞品交互；2) 明确 PC 是高密度工作台和批量处理；3) 明确移动是消息驱动 卡片列表 深层 Push 和吸底主操作；4) 明确企业微信只做入口 通知和 deeplink。",流程级验证：rg -n '国内同类系统|钉钉|飞书|企业微信个人应用消息|Ant Design|WeUI|deeplink' docs/product-design-rules.md docs/需求-统一审批中心规约.md docs/agent-development-practices.md。,rg|manual,DONE,DONE,DONE,docs/product-design-rules.md|docs/需求-统一审批中心规约.md|docs/agent-development-practices.md,"[""G1""]",外部资料仅作为体验原则参考；hyb-oa 仍是唯一正式审批中心。
 G3,规约同步 R5 后事实源,更新产品设计规则 统一审批中心 报销发票和业务规约引用，固定 R5 后正式通知和移动体验口径。,"1) 统一审批中心版本升为 1.2；2) 记录企业微信个人应用消息正式通知口径；3) 报销规则补 PDF-only 和重复票据可解释终态；4) 请假 采购 合同 项目规约引用统一审批和设计规则。",流程级验证：rg -n '版本..1.2|企业微信个人应用消息|PDF-only|重复票据|统一审批中心|产品设计规则' docs/需求-统一审批中心规约.md docs/reimbursement-invoice-rules.md docs/需求-采购费用审批规约.md docs/需求-请假考勤修正规约.md docs/需求-合同附件归档规约.md docs/需求-项目轻管理规约.md。,rg|manual,DONE,DONE,DONE,docs/product-design-rules.md|docs/需求-统一审批中心规约.md|docs/reimbursement-invoice-rules.md|docs/需求-采购费用审批规约.md|docs/需求-请假考勤修正规约.md|docs/需求-合同附件归档规约.md|docs/需求-项目轻管理规约.md,"[""G2""]",不新增 API schema migration 或远端配置。
 G4,Skill 与交付实践更新,更新项目交付 Skill 和 agent 交付实践，要求 R5 后默认检查 R5/R6 状态 规约和外部参考原则。,"1) Skill Required Reading 覆盖 R6 后续和 PC 移动 审批体验；2) Delivery Loop 提醒先查 R5/R6 状态；3) 交付实践写明外部最佳实践只沉淀原则；4) Skill quick_validate 通过。",流程级验证：python3 /home/shunli/.codex/skills/.system/skill-creator/scripts/quick_validate.py .agents/skills/hyb-oa-delivery；rg -n 'R5/R6|国内同类系统|外部最佳实践|真机|真实通知' .agents/skills/hyb-oa-delivery/SKILL.md docs/agent-development-practices.md。,python3|rg,DONE,DONE,DONE,.agents/skills/hyb-oa-delivery/SKILL.md|docs/agent-development-practices.md,"[""G3""]",不更新 AGENTS.md；若后续多次违反硬约束再单独处理。
 G5,R6 小范围试运行后续工作草案,在规约中沉淀 R6 后续工作顺序，明确 R6 只做准备合同 不直接扩大试运行。,"1) R6 后续工作包含名单 窗口 回滚联系人 问题登记 每日收口；2) 范围限定报销 请假 采购 审批 企业微信入口通知 财务付款导出；3) 不扩预算 ERP AI 完整差旅 复杂 BPM；4) 后续体验优化分批实施。",流程级验证：rg -n 'R6|小范围试运行|2-3|问题登记|预算|ERP|AI|复杂 BPM|视觉巡检' docs/product-design-rules.md docs/trialrun/release-readiness-checklist.md docs/trialrun/real-device-public-checklist.md issues/2026-05-10_12-39-37-release-readiness-live-smoke.csv issues/2026-05-11_10-06-44-r6-governance-benchmark-roadmap.csv。,rg|manual,DONE,DONE,DONE,docs/product-design-rules.md|docs/trialrun/release-readiness-checklist.md|docs/trialrun/real-device-public-checklist.md|issues/2026-05-11_10-06-44-r6-governance-benchmark-roadmap.csv,"[""G4""]",R6 真实名单和时间窗口尚未固定；实施阶段不得直接开放真实用户。
 G6,校验与提交,完成 CSV Skill 和文档格式校验后提交本轮治理变更。,"1) 新合同 CSV 校验通过；2) Skill quick_validate 通过；3) 关键术语检索通过；4) git diff --check 通过；5) 中文提交。",流程级验证：python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py issues/2026-05-11_10-06-44-r6-governance-benchmark-roadmap.csv；python3 /home/shunli/.codex/skills/.system/skill-creator/scripts/quick_validate.py .agents/skills/hyb-oa-delivery；rg -n 'R5|R6|企业微信个人应用消息|催办|底部 Tab|PDF-only|统一审批中心|国内同类系统|钉钉|飞书|WeUI|Ant Design' docs .agents/skills/hyb-oa-delivery issues/2026-05-11_10-06-44-r6-governance-benchmark-roadmap.csv；git diff --check。,python3|rg|git,DONE,DONE,DONE,issues/2026-05-11_10-06-44-r6-governance-benchmark-roadmap.csv|docs/*|.agents/skills/hyb-oa-delivery/SKILL.md,"[""G5""]",提交信息建议：G1-G6 同步 R6 前置规约与最佳实践。