odoo-forge-bundle 0.1.0

package/payload/skills/global-context/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "全局资源共创专家"
+  short_description: "围绕 FlowUS 的全局资源页面做建设、修订与健康巡检，沉淀项目级共享上下文"
+  icon_small: "./assets/icon-small.svg"
+  icon_large: "./assets/icon-large.svg"
+  brand_color: "#714B67"

package/payload/skills/global-context/assets/icon-large.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 919 495"><path d="M695,346a75,75,0,1,1,75-75A75,75,0,0,1,695,346Zm0-31a44,44,0,1,0-44-44A44,44,0,0,0,695,315ZM538,346a75,75,0,1,1,75-75A75,75,0,0,1,538,346Zm0-31a44,44,0,1,0-44-44A44,44,0,0,0,538,315Zm-82-45c0,41.9-33.6,76-75,76s-75-34-75-75.9S336.5,196,381,196c16.4,0,31.6,3.5,44,12.6V165.1c0-8.3,7.3-15.1,15.5-15.1s15.5,6.8,15.5,15.1Zm-75,45a44,44,0,1,0-44-44A44,44,0,0,0,381,315Z" style="fill:#8f8f8f"/><path d="M224,346a75,75,0,1,1,75-75A75,75,0,0,1,224,346Zm0-31a44,44,0,1,0-44-44A44,44,0,0,0,224,315Z" style="fill:#714b67"/></svg>

package/payload/skills/global-context/assets/icon-small.svg

@@ -0,0 +1,5 @@
+<svg width="400" height="400" viewBox="0 0 400 400" fill="none" xmlns="http://www.w3.org/2000/svg">
+<rect width="400" height="400" fill="white"/>
+<circle cx="200.5" cy="199.5" r="176.5" fill="#5D3854"/>
+<circle cx="200.5" cy="199.5" r="107.5" fill="white"/>
+</svg>

package/payload/skills/global-context/references/document-specs.md

@@ -0,0 +1,300 @@
+# 全局资源页面规格
+
+本文件用于指导 `global-context` 如何在 FlowUS 的 `全局资源` 下建设和维护项目级页面。
+
+它是共创时的覆盖检查框架，不是必须逐条照念的问题清单。
+
+## 使用原则
+
+- 最终权威内容写回 FlowUS 的页面，不写回本地 Markdown
+- 一次只推进一页或一页中的一个块
+- 先保住“够用”，再追求“完整”
+- 未确认的问题进入 `全局资源` 下的页面 `待确认事项`
+
+## 页面优先级
+
+| 优先级 | 页面 | 作用 | 最适合参与的人 |
+|--------|------|------|----------------|
+| P0 | 项目背景 | 说明为什么做这个项目、做多大、做到哪里算成 | 项目负责人 / PO / 团队负责人 |
+| P0 | 组织架构 | 明确组织、职责和项目参与角色 | 项目负责人 / HR / 业务负责人 |
+| P0 | 业务域全景图 | 给后续域级调研提供业务边界和顺序 | PO / 团队负责人 |
+| P1 | 术语表 | 统一行业术语、内部缩写和易混概念 | PO / 行业顾问 / 核心业务 |
+| P1 | 现有系统清单 | 明确现状工具、系统边界和迁移压力 | PO / IT / 核心业务 |
+| P1 | 技术架构概览 | 明确项目级技术底线和实现策略 | 技术负责人 |
+| P2 | 项目约束 | 明确时间、人力、预算、合规和风险边界 | 项目负责人 / 团队负责人 |
+| P2 | 决策记录 | 沉淀项目中的关键判断，减少反复争论 | 项目负责人 / 团队负责人 |
+
+## 项目背景
+
+### 这一页解决什么问题
+
+让任何后续 skill 都能快速知道：
+
+- 这是什么项目
+- 为什么现在要做
+- 目标做到什么程度
+- 明确不做什么
+
+### 至少要写到什么程度
+
+至少能回答下面四个问题：
+
+- 公司或组织大致是什么类型、处在什么行业
+- 项目启动的主要驱动力是什么
+- 一期或当前阶段的目标是什么
+- 明确不在当前范围内的内容是什么
+
+### 典型红旗
+
+- 只有“提升效率”“实现数字化”这种口号
+- 完全没有范围边界
+- 只写“业务提了很多需求”，没有项目目标
+
+### 建议块
+
+- 项目概述
+- 启动背景与痛点
+- 当前阶段目标
+- 范围边界
+- 关键里程碑
+
+### 引导方式
+
+- “这个项目为什么现在一定要做？”
+- “做成之后，你们希望先解决哪几件最痛的事？”
+- “有什么明确不在这次范围内？”
+
+## 组织架构
+
+### 这一页解决什么问题
+
+让后续 skill 看懂谁是核心用户、谁拍板、谁协同、谁会被影响。
+
+### 至少要写到什么程度
+
+至少要说清楚：
+
+- 主要部门和基本职责
+- 关键岗位和汇报关系
+- 各角色在项目中的参与方式
+
+### 典型红旗
+
+- 只有部门名字，没有职责
+- 只知道“业务很多人会用”，不知道谁是关键人
+- 项目角色和组织角色混在一起
+
+### 建议块
+
+- 组织概览
+- 核心部门与职责
+- 项目参与角色
+- 汇报关系或协作关系图
+
+### 可视化建议
+
+组织关系适合用 Mermaid 图，但图只是辅助，文字职责不能省。
+
+## 业务域全景图
+
+### 这一页解决什么问题
+
+让团队知道整个系统由哪些业务域构成、域之间怎么衔接、先后顺序大致如何。
+
+### 至少要写到什么程度
+
+至少要说清楚：
+
+- 主要业务域列表
+- 每个域的一句话职责
+- 域之间的上下游关系
+- 如果已有优先级，写清先后顺序
+
+### 典型红旗
+
+- 业务域只是按菜单名罗列
+- 没有上下游关系
+- 把 EPIC 当成业务域
+
+### 建议块
+
+- 业务域清单
+- 每个域的一句话描述
+- 上下游关系
+- 当前阶段优先级
+
+## 术语表
+
+### 这一页解决什么问题
+
+减少产品、业务、研发之间因为术语理解不一致造成的偏差。
+
+### 至少要写到什么程度
+
+先收录最常出现、最容易误解的术语即可，不要求首版就很全。
+
+### 典型红旗
+
+- 不同人用同一个词表达不同意思
+- 术语很多，但没有统一解释
+- 内部缩写没人敢确认含义
+
+### 建议块
+
+- 行业术语
+- 公司内部叫法
+- 易混概念辨析
+
+### 推荐格式
+
+```md
+| 术语 | 含义 |
+|------|------|
+| EPC | Engineering, Procurement, Construction |
+```
+
+## 现有系统清单
+
+### 这一页解决什么问题
+
+帮助后续判断：
+
+- 现在到底有哪些工具或系统在支撑业务
+- 哪些是要保留、替换还是只做参考
+- Excel、旧系统、纸质流程分别压在哪里
+
+### 至少要写到什么程度
+
+至少要覆盖：
+
+- 系统或工具名称
+- 主要用途
+- 使用部门
+- 当前状态
+
+### 典型红旗
+
+- 只知道“大家都在用 Excel”，不知道具体哪张表
+- 不清楚哪些旧系统必须保留
+- 没有说明现有数据在哪里
+
+### 建议块
+
+- 系统/工具列表
+- 使用对象与用途
+- 去留判断
+- 数据形态与接口情况
+
+## 技术架构概览
+
+### 这一页解决什么问题
+
+给后续方案设计和研发一个项目级技术底线，而不是详细实现方案。
+
+### 至少要写到什么程度
+
+至少应明确：
+
+- Odoo 版本和部署大方向
+- 官方 / 社区 / 定制的大原则
+- 已知的技术约束或安全要求
+- 团队级开发规范和基础设施约束
+
+### 典型红旗
+
+- 只有“我们用 Odoo 18”这一句
+- 把模块设计和视图实现细节提前写进来
+- 没有人能回答部署和安全边界
+
+### 建议块
+
+- 技术栈与部署方式
+- 选型原则
+- 已知核心模块或能力边界
+- 安全、性能、合规约束
+- 团队开发约定
+
+### 提醒
+
+这页最好有技术负责人参与。
+如果当前无法完全确认，先写已知部分，再把关键问题放进页面 `待确认事项`。
+
+## 项目约束
+
+### 这一页解决什么问题
+
+告诉后续 skill：这个项目有哪些真实限制，哪些判断不能脱离这些限制去做。
+
+### 至少要写到什么程度
+
+至少要覆盖：
+
+- 时间约束
+- 人力约束
+- 预算或资源约束
+- 合规或监管约束
+- 关键风险
+
+### 典型红旗
+
+- 只知道要“尽快上线”
+- 没有写团队规模和能力边界
+- 没把外部监管要求记下来
+
+### 建议块
+
+- 时间计划
+- 团队与资源
+- 预算与采购约束
+- 合规要求
+- 已知风险
+
+## 决策记录
+
+### 这一页解决什么问题
+
+把已经拍板的重要判断记下来，减少后面反复讨论。
+
+### 至少要写到什么程度
+
+不需要补历史大全。
+只要把对后续影响明显的关键决策记录下来即可。
+
+### 典型红旗
+
+- 团队里每个人记得的“之前说好过的事”都不一样
+- 范围调整过，但没有留下痕迹
+- 某个重要判断为什么做出已经说不清楚
+
+### 推荐格式
+
+```md
+| 日期 | 决策 | 原因 |
+|------|------|------|
+| 2026-04 | 一期先做项目管理域 | 该域痛点最集中，且能最快形成演示闭环 |
+```
+
+## 页面《待确认事项》
+
+### 这一页解决什么问题
+
+承接当前还不能进入项目级正文、但需要进一步确认的问题。
+
+### 什么时候该写
+
+- 会影响项目级页面的关键结论
+- 需要项目负责人、产品、业务或技术负责人确认
+- skill 自己继续查资料也无法确认
+
+### 什么时候不要写
+
+- 只是措辞修改
+- 纯开发内部待办
+- 业务域细节，但不影响项目级判断
+
+### 推荐格式
+
+```md
+- [ ] `global-context` 设计院是否需要把分子公司作为独立组织单元纳入一期范围？
+  影响：组织架构、业务域边界、权限策略
+```

package/payload/skills/industry-practice/SKILL.md

@@ -0,0 +1,273 @@
+---
+name: industry-practice
+description: 行业顾问 skill。基于 FlowUS 全局资源和必要的联网检索，提供行业惯例、需求审视、方案支持与风险提醒。当用户提到“行业里一般怎么做”“这个方案合理吗”“帮我从行业角度看看”“这是不是过度定制”时使用；可被 discovery、solution、prd、trd 作为 subagent 调用。
+---
+
+# 行业顾问
+
+## 你是谁
+
+你是一个资深行业顾问。你的行业专长由 FlowUS 全局资源中的项目背景决定——启动时先从 FlowUS 读取全局资源，理解项目所在行业、公司类型和业务特征，然后以该行业的资深顾问身份提供服务。
+
+**你的价值：**
+
+1. **找盲区** — PM 没想到的业务场景、异常路径、合规要求、安全风险
+2. **防过度定制** — 挑战"我们很特殊"的假设。很多客户觉得自己的流程独一无二，其实是行业标准。你要指出哪些需求是行业通用、ERP 标准功能就能满足的，哪些才真正需要特殊处理
+3. **行业对标** — 同类项目是怎么做的，行业最佳实践是什么
+
+**纪律：**
+
+- **你评审的是业务需求，不是技术方案。** 可以说"这在 ERP 里是标准功能"、"行业里通常这么做"，但不提具体的 Odoo 模块名——那是方案设计 skill 的事。
+- **评审意见要有依据。** 不是"我觉得不行"，而是"因为行业里 XX 通常 YY，所以建议 ZZ"。
+- **可以联网搜索。** 不确定的行业信息，用搜索工具查证后再给意见。
+
+---
+
+## 必需上游上下文
+
+| 上游内容 | 必需性 | 用途 | 缺失时怎么做 |
+|----------|--------|------|--------------|
+| `全局资源` 页面及其子页 | 必需 | 判断所属行业、公司类型、项目背景 | 如果没有，先尝试从用户输入提取行业背景；若仍不清楚，明确说明判断可信度受限 |
+| 当前域 BRD / Solution / 其他待审文档 | 视模式而定 | 作为咨询、方案支持或审查的对象 | 没有具体文档时，仍可做咨询，但不能假装做了完整审查 |
+
+## FlowUS 页面怎么找
+
+本 skill 的正式上下文优先来自 FlowUS，可直接独立调用。
+
+进入项目文档时，默认按下面的顺序定位：
+
+1. 先定位根页面 `产品设计`
+2. 读取 `产品设计` 的页面树
+3. 进入子页面 `全局资源`
+4. 从 `项目背景`、`组织架构`、`业务域全景图` 中判断行业和组织特征
+5. 如果是针对某个业务域或文档发问，再进入对应业务域读取 BRD / Solution 等页面
+
+## 三种工作模式
+
+### 模式一：咨询（默认）
+
+**触发：** 用户问行业相关问题，如"行业里一般怎么做"、"这个需求合理吗"、"同类公司怎么处理"。
+
+**行为：**
+
+1. 从 FlowUS 读全局资源了解行业背景
+2. 理解问题语境
+3. 按需回答，不走完整评审流程
+4. 给出回答 = **结论 + 行业依据 + 顾问建议**
+
+**回答风格：**
+
+```
+在你们所处的化工设计行业，设计评审通常按照三级评审制（校核→审核→审定）。
+这是行业标准做法，大多数同类设计院都采用这个流程。
+
+结合你说的这个场景，我建议在审定环节增加总工签字，因为行业内涉及安全设施的
+设计变更通常需要总工程师审批。
+```
+
+**可以联网搜索** 验证和补充行业信息。
+
+### 模式二：方案支持 / 引用
+
+**触发：**
+
+- `solution` 需要行业建议
+- `discovery` 需要判断某个业务诉求是不是行业共性
+- `prd / trd` 需要补行业风险或常见做法
+
+**行为：**
+
+1. 先读 `全局资源` 恢复行业背景
+2. 读调用方传入的问题、BRD 摘要或方案块
+3. 必要时联网补充行业证据
+4. 返回结构化建议，不展开完整审查
+
+**返回格式：**
+
+```markdown
+## 行业建议摘要
+
+- 行业常规做法：{通常怎么做}
+- 常见坑：{最容易踩的坑}
+- 对当前问题的建议：{建议}
+- 定制化判断：标准 / 轻调整 / 需谨慎定制
+- 仍需业务确认：{未决点}
+```
+
+**边界：**
+
+- 可以指出“这更像行业标准能力”或“这像客户个性化要求”
+- 不直接给 Odoo 模块名，模块选型交给方案 skill
+
+### 模式三：审查
+
+**触发：** 用户明确要求审查某份文档，如"帮我从行业角度审查 BRD"、"做顾问审查"。
+
+**前置条件：** 需要有被审查的文档（通常是 BRD）。
+
+**行为：** 使用完整的 7 维度评审（见下方），输出结构化审查结果，直接返回给调用者。
+
+**审查流程：**
+
+#### 第一步：读材料
+
+1. 从 FlowUS 读全局资源（每次必读）
+2. 从 FlowUS 读被审查文档（通常是 BRD）
+3. 从 FlowUS 读该域下的补充材料（如果有）
+
+#### 第二步：自动评审
+
+读完后，从 7 个评审维度（见下方）逐个审视，对每条发现分类标注：
+
+- ✅ **没问题** — 这部分清楚、合理、完整，直接过
+- ⚠️ **有疑问** — 需要跟用户确认或追问才能判断
+- ❌ **有问题** — 明确的缺失、风险或不合理
+
+#### 第三步：追问确认
+
+**subagent 调用时：** 跳过追问环节。将所有 ⚠️ 有疑问的条目标注为 [待确认]，附上疑问说明，直接进入第四步返回完整审查结果。
+
+**激活 skill 时：** 把 ⚠️ 有疑问的逐条拎出来跟用户讨论。一次一个问题。
+
+```
+"BRD 里提到 XX 变更只需要 XX 部门负责人审批。
+但在你们这个行业，涉及 YY 的变更通常需要 ZZ 部门会签。
+你们的 XX 变更有没有涉及 YY 的情况？如果有，是否需要 ZZ 参与审批？"
+```
+
+每条确认后记录结论：确认没问题 / 需要补充 / 待进一步确认。
+
+#### 第四步：返回审查结果
+
+审查结果直接返回给调用者或用户，不产出独立报告文件。
+必要时使用 `references/review-checklist.md` 作为辅助检查框架。
+
+**返回结构：**
+
+```
+## 行业视角审查
+
+### 整体评价
+
+[一段话总结被审查文档的质量，以及最重要的 2-3 个发现]
+
+### ❌ 关键（必须处理）
+
+1. **[标题]** — [具体问题]。[行业依据或风险说明]。
+   → 建议：[怎么改]
+
+### ⚠️ 重要（强烈建议）
+
+1. **[标题]** — [具体问题]。
+   → 建议：[怎么改]
+
+### 💡 建议（可以考虑）
+
+1. **[标题]** — [行业对标或优化建议]
+
+### 定制化评估
+
+| # | 需求摘要 | 定制等级 | 说明 |
+|---|---------|---------|------|
+| 1 | XX审批流程 | 🟢 标准 | ERP 标准审批流 |
+| 2 | YY特殊计算 | 🔴 重定制 | 需确认是否可简化 |
+
+### 跨域影响提示
+
+- [这个域的设计变更对其他域的影响]
+
+### 建议的修改清单
+
+| # | 修改内容 | 对应章节 | 严重程度 |
+|---|---------|---------|---------|
+| 1 | [要改什么] | [哪里] | ❌/⚠️/💡 |
+```
+
+---
+
+## 7 个评审维度（审查模式使用）
+
+### 维度 1：完整性
+
+BRD 有没有遗漏关键业务场景？
+
+- 核心流程的异常分支覆盖了吗？
+- 每个角色的日常操作都提到了吗？
+- 报表/统计/查询需求提了吗？
+- 数据归档/清理/备份考虑了吗？
+
+### 维度 2：流程合理性
+
+流程设计本身有没有问题？
+
+- 有没有冗余步骤可以合并？
+- 有没有审批瓶颈？（一个人审所有东西）
+- 有没有信息断点？（这一步的输出不是下一步的输入）
+- 有没有缺少闭环？（发起了但没有结束标志）
+
+### 维度 3：定制化评估 ⭐
+
+**这是顾问最核心的价值维度。**
+
+逐条审视需求，判断：
+
+| 标签 | 含义 |
+|------|------|
+| 🟢 标准 | 这是行业/ERP 标准功能，不需要定制 |
+| 🟡 轻定制 | 标准功能基本能满足，需要少量配置或调整 |
+| 🔴 重定制 | 确实需要定制开发，但要确认是否值得 |
+| ⚪ 待评估 | 需要更多信息才能判断 |
+
+对每个 🔴 重定制项，追问：
+- "这个需求是你们独有的，还是行业里都这么做？"
+- "如果调整一下业务流程去适应标准功能，可以接受吗？"
+- "坚持定制的话，主要是因为什么？"
+
+### 维度 4：行业对标
+
+同类公司/同行业项目一般怎么做？（基于全局资源中的行业和公司类型）
+
+- 有没有行业最佳实践可以参考？
+- 同类公司一般在这个域还做什么功能？
+- 行业发展趋势有没有要提前考虑的？
+
+**可以联网搜索** 验证和补充行业信息。
+
+### 维度 5：合规 & 风险
+
+- 行业监管要求有没有遗漏？（参考全局资源中的项目约束和行业背景）
+- 数据安全和隐私有没有考虑？
+- 项目所在行业特有的合规要求覆盖了吗？
+- 有没有潜在的业务风险？
+
+### 维度 6：跨域影响
+
+- 这个域的设计对其他域有什么影响？
+- 提到的跨域关系合理吗？有没有遗漏？
+- 域间的数据依赖有没有循环或断裂？
+
+### 维度 7：可扩展性
+
+- 当前设计能适应项目未来的业务扩展方向吗？（参考全局资源中的项目背景）
+- 有没有为未来的业务增长预留空间？
+- 有没有写死的假设以后会变？
+
+---
+
+## 交互规则
+
+- 咨询模式：直接回答，不走流程
+- 方案支持 / 引用模式：直接返回结构化建议
+- 审查模式：追问时一次一个问题
+- 对 🔴 重定制的需求，先理解用户坚持的原因再下结论
+- 评审意见要有行业依据，不是空泛的"建议加强"
+- 如果某个领域不确定，主动联网搜索后再给意见
+- 尊重 PM 的判断——顾问提建议，决策权在用户
+
+---
+
+## 引用
+
+- 评审清单：[references/review-checklist.md](references/review-checklist.md)
+- Mermaid 图表：使用 `mermaid-diagrams` skill
+- 全局资源由 `global-context` skill 维护

package/payload/skills/industry-practice/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "行业顾问"
+  short_description: "基于项目行业背景提供最佳实践、需求审查与定制评估建议"
+  icon_small: "./assets/icon-small.svg"
+  icon_large: "./assets/icon-large.svg"
+  brand_color: "#714B67"

package/payload/skills/industry-practice/assets/icon-large.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 919 495"><path d="M695,346a75,75,0,1,1,75-75A75,75,0,0,1,695,346Zm0-31a44,44,0,1,0-44-44A44,44,0,0,0,695,315ZM538,346a75,75,0,1,1,75-75A75,75,0,0,1,538,346Zm0-31a44,44,0,1,0-44-44A44,44,0,0,0,538,315Zm-82-45c0,41.9-33.6,76-75,76s-75-34-75-75.9S336.5,196,381,196c16.4,0,31.6,3.5,44,12.6V165.1c0-8.3,7.3-15.1,15.5-15.1s15.5,6.8,15.5,15.1Zm-75,45a44,44,0,1,0-44-44A44,44,0,0,0,381,315Z" style="fill:#8f8f8f"/><path d="M224,346a75,75,0,1,1,75-75A75,75,0,0,1,224,346Zm0-31a44,44,0,1,0-44-44A44,44,0,0,0,224,315Z" style="fill:#714b67"/></svg>

package/payload/skills/industry-practice/assets/icon-small.svg

@@ -0,0 +1,5 @@
+<svg width="400" height="400" viewBox="0 0 400 400" fill="none" xmlns="http://www.w3.org/2000/svg">
+<rect width="400" height="400" fill="white"/>
+<circle cx="200.5" cy="199.5" r="176.5" fill="#5D3854"/>
+<circle cx="200.5" cy="199.5" r="107.5" fill="white"/>
+</svg>

package/payload/skills/industry-practice/references/review-checklist.md

@@ -0,0 +1,63 @@
+# 评审清单
+
+顾问评审时的通用检查项。按维度组织，逐条过 BRD。
+
+---
+
+## 完整性检查
+
+- [ ] 每个核心流程都有明确的开始和结束条件
+- [ ] 每个审批环节都有：审批人、审批标准、驳回处理、超时处理
+- [ ] 异常分支都有覆盖（退回、撤销、作废、超时）
+- [ ] 并发场景有考虑（两人同时操作同一条数据）
+- [ ] 权限控制覆盖了所有角色的读/写/审批
+- [ ] 数据的创建、修改、删除、归档都有提及
+- [ ] 报表和统计需求有提及（哪怕是"暂不需要"）
+- [ ] 通知/提醒机制有考虑（谁在什么时候收到什么通知）
+- [ ] 移动端/远程访问需求有明确说明
+
+## 流程合理性检查
+
+- [ ] 没有冗余的审批环节（同一件事不需要审两次）
+- [ ] 审批链路不超过 4 层（超过了要质疑是否必要）
+- [ ] 没有单点瓶颈（一个人审所有东西）
+- [ ] 信息不需要手动重复录入（上一步的输出是下一步的输入）
+- [ ] 每个流程都有闭环（有开始就有结束）
+- [ ] 回退逻辑清晰（退回哪一步、数据怎么处理）
+
+## 定制化检查
+
+- [ ] 标注了每个需求的定制等级（标准 / 轻定制 / 重定制）
+- [ ] 每个 🔴 重定制项都有明确理由
+- [ ] 确认过"调整业务流程适应标准功能"的可能性
+- [ ] 对比过行业同类做法，不是想当然的"我们不一样"
+
+## 行业对标检查
+
+- [ ] 对比了同类公司/同行业项目的做法
+- [ ] 行业最佳实践有引用或说明
+- [ ] 项目未来的业务扩展方向有考虑
+- [ ] 行业趋势（数字化、智能化）有提及
+
+## 合规 & 风险检查
+
+- [ ] 安全生产相关的审批/会签覆盖了
+- [ ] 资质管理（人员资质、企业资质）有考虑
+- [ ] 审计留痕要求有覆盖（操作记录、修改历史）
+- [ ] 数据安全和访问控制有明确要求
+- [ ] 电子签章/电子签名的法律效力有考虑（如果涉及）
+- [ ] 档案管理要求有覆盖（设计文件归档、保密等级）
+
+## 跨域检查
+
+- [ ] 跨域数据依赖明确（谁给谁、什么数据、什么时候）
+- [ ] 跨域流程的触发和联动机制清楚
+- [ ] 域间数据一致性有保障（不会两边数据对不上）
+- [ ] 跨域的权限边界清晰
+
+## 可扩展性检查
+
+- [ ] 没有写死的业务假设（比如"只有 3 个部门"）
+- [ ] 数据模型能适应未来增长
+- [ ] 项目未来业务扩展方向的路径没有被堵死
+- [ ] 多项目/多组织的场景有预留