wangsli/hyb-oa
1
0
派生 0
代码 工单 合并请求 工作流 5 软件包 项目 发布 百科 活动

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

浏览代码
这个提交包含在：
wangsli
2026-05-11 10:16:05 +08:00
父节点 bc6b222224
当前提交 c8b67498fb
共修改 12 个文件，包含 111 行新增和 19 行删除
下载 Patch 文件 下载 Diff 文件 展开所有文件 折叠所有文件
docs/agent-development-practices.md
+9
查看文件
@@ -73,6 +73,15 @@ AGENTS.md 只放硬约束和入口，不复制长规则。
- 文案是否符合国内 OA 习惯。
- 是否出现 PC 表格误入手机、黑色大块导航、按钮样式不一致、文字截断、弹窗自动弹键盘等明显问题。
外部最佳实践只沉淀原则，不复制竞品交互或文案。参考钉钉、飞书、企业微信、Ant Design、WeUI 等公开资料时，必须先抽象为本项目自己的事实源：
- PC 端：工作台、表格、筛选、详情分区、批量处理和管理配置。
- 移动端：企业微信消息驱动、卡片列表、一级底部导航、深层 Push 页和吸底主操作。
- 审批：待办聚合、明确状态、可追溯、可催办、超时提醒和效率统计。
- 企业微信：入口、身份、个人应用消息和 deeplink，不替代 OA 正式审批。
可自动化的体验检查先自动化，例如 Playwright PC、移动、企业微信 UA 和 DOM 指标；真实企业微信登录、手机应用消息到达、真实通知权限和财务制度决策必须保留人工确认记录。
### 7. 提交要小批次、中文、可回滚
一次需求可以有多个 commit，但每个 commit 应该能说明一个清晰主题：
docs/product-design-rules.md
+34
查看文件
@@ -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 报销主流程重构：
- 后端业务编号、权限和删除规则。
docs/reimbursement-invoice-rules.md
+5
查看文件
@@ -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 等小屏上仍保持同行双按钮，不降级为单列。
docs/trialrun/real-device-public-checklist.md
+4 -4
查看文件
@@ -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_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` | `SMOKE002` | 移动首页、报销页、详情页、PDF 发票入口可用 | 公网自动视觉通过；真机核心链路通过 | `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，吸底双按钮不遮挡 | 公网自动视觉通过；R6 继续真机观察不同设备体验 | `output/playwright/r5-live-mobile-wecom-visual/` |
| 通知与 deeplink | `oa_smoke_01` / `oa_smoke_02` | `SMOKE002` / `SMOKE101` | 通知能回到移动待办或详情页 | 真机通过：收到个人应用消息，点击后首次需点进入工作台，后续可直达移动审批 | `output/playwright/r5-wecom-app-message-live/` |
自动化补充证据（用于审批链业务验收）：
docs/trialrun/release-readiness-checklist.md
+17 -6
查看文件
@@ -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。
- 当前最大缺口：R5 公网自动化和真实 OCR 已通过；企业微信真机人工验收尚未执行，因此 R5 尚未完成，R6 仍不能开始。
- 当前状态：本地门禁已闭环；R4 部署预检、D3 受控同步、D4 只读复检、R5 公网 live smoke、真实 PDF OCR、PC/自动化审批链、企业微信真机入口、个人应用消息和 deeplink 均已完成。
- 当前最大缺口：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 通过解释为“自动进入正式试运行”。
建议首批角色：
docs/需求-合同附件归档规约.md
+2 -1
查看文件
@@ -5,8 +5,9 @@
**状态**：模块级开发规约
**上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
**审批总依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)
**体验总依据**：[产品设计规则基线](./product-design-rules.md)
本规约细化合同台账、合同编号、非涉密附件、归档位置、权限审计和业务关联要求。合同审批、合同变更审批和归档动作仍回到 OA 统一审批中心留痕；本规约不替代公司法务制度。
本规约细化合同台账、合同编号、非涉密附件、归档位置、权限审计和业务关联要求。合同审批、合同变更审批和归档动作仍回到 OA 统一审批中心留痕；PC 和移动页面模式以产品设计规则基线为体验依据；本规约不替代公司法务制度。
---
docs/需求-统一审批中心规约.md
+14 -2
查看文件
@@ -1,7 +1,7 @@
# 需求 - 统一审批中心规约
**版本**：1.1
**日期**：2026-05-10
**版本**：1.2
**日期**：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，必须在技术方案中写明回滚策略和回归范围。
docs/需求-请假考勤修正规约.md
+2 -1
查看文件
@@ -5,8 +5,9 @@
**状态**：模块级开发规约
**上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
**相关事实源**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)、[需求 - 企业微信基础设施规约](./需求-企业微信基础设施规约.md)
**体验总依据**：[产品设计规则基线](./product-design-rules.md)
本规约细化请假、补卡、外出、加班与考勤修正的产品要求。正式审批记录以 OA 为准；企业微信打卡只作为原始采集来源，不直接决定最终考勤结论。
本规约细化请假、补卡、外出、加班与考勤修正的产品要求。正式审批记录以 OA 为准；企业微信打卡只作为原始采集来源，不直接决定最终考勤结论。PC 和移动页面体验以产品设计规则基线为依据，不重复定义通用审批链和移动导航规则。
---
docs/需求-采购费用审批规约.md
+2 -1
查看文件
@@ -5,8 +5,9 @@
**状态**：模块级开发规约
**上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
**审批总依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)
**体验总依据**：[产品设计规则基线](./product-design-rules.md)
本规约细化采购申请和费用申请的业务边界、字段、状态、权限、异常、验收场景和后续开发拆分建议。审批动作、状态机、审批规则矩阵、权限数据范围和留痕要求，以统一审批中心规约为总依据；本规约只补充采购和费用业务自身规则。
本规约细化采购申请和费用申请的业务边界、字段、状态、权限、异常、验收场景和后续开发拆分建议。审批动作、状态机、审批规则矩阵、权限数据范围和留痕要求，以统一审批中心规约为总依据；PC 和移动页面模式以产品设计规则基线为体验依据；本规约只补充采购和费用业务自身规则。
---
docs/需求-项目轻管理规约.md
+2 -1
查看文件
@@ -4,8 +4,9 @@
**日期**：2026-05-09
**状态**：模块级开发规约
**上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)
**审批与体验依据**：[需求 - 统一审批中心规约](./需求-统一审批中心规约.md)、[产品设计规则基线](./product-design-rules.md)
本规约细化项目轻管理的业务边界、字段、状态、角色、业务关联、异常、验收场景和后续开发拆分建议。项目页目标是汇总关键事项和业务关联，帮助 10 人以下科技公司看清项目交付、风险和费用，不替代专业项目管理工具。
本规约细化项目轻管理的业务边界、字段、状态、角色、业务关联、异常、验收场景和后续开发拆分建议。项目页目标是汇总关键事项和业务关联，帮助 10 人以下科技公司看清项目交付、风险和费用，不替代专业项目管理工具。项目相关审批和待办回到统一审批中心，PC 和移动页面模式以产品设计规则基线为依据。
---