odoo-forge-bundle 0.1.9 → 0.1.11

package/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "odoo-forge-bundle",
-  "version": "0.1.9",
+  "version": "0.1.10",
   "status": "scaffold",
   "payload": {
     "root": "./payload",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "odoo-forge-bundle",
-  "version": "0.1.9",
+  "version": "0.1.11",
   "description": "Generated bundle payload for Odoo Forge internal 1.0.",
   "type": "module",
   "exports": "./index.js",

package/payload/config/product.json

@@ -1,7 +1,7 @@
 {
   "name": "Odoo Forge",
   "slug": "odoo-forge",
-  "version": "0.1.9",
+  "version": "0.1.11",
   "description": "Unified Odoo agent toolkit for Codex and Claude Code.",
   "localInstallRoot": "~/.odoo-forge",
   "packages": {

package/payload/skills/dev/SKILL.md

@@ -19,9 +19,9 @@ description: EPIC 级别的 Odoo 模块开发流程规范。不是代码生成
 
 | 检查项 | 来源 | 必需 | 缺失时 |
 |--------|------|------|--------|
-| TRD | FlowUS — EPIC 页面下的 TRD 子页面 | ✅ | 提示先运行 trd |
-| PRD | FlowUS — EPIC 页面下的 PRD 子页面 | 建议 | 警告"缺少业务背景"，允许继续 |
-| UAT | FlowUS — EPIC 页面下的 UAT 子页面 | 建议 | 提醒后续补齐测试数据和验收准备 |
+| TRD | Notion — EPIC 页面下的 TRD 子页面 | ✅ | 提示先运行 trd |
+| PRD | Notion — EPIC 页面下的 PRD 子页面 | 建议 | 警告"缺少业务背景"，允许继续 |
+| UAT | Notion — EPIC 页面下的 UAT 子页面 | 建议 | 提醒后续补齐测试数据和验收准备 |
 | 代码仓库 | 当前工作区或用户明确提供的仓库路径 | ✅ | 提示先确认开发仓库位置 |
 
 ---
@@ -30,8 +30,8 @@ description: EPIC 级别的 Odoo 模块开发流程规范。不是代码生成
 
 ### Phase 0: 预检 + 澄清 + 计划
 
-1. 从 FlowUS 读 TRD 全文（唯一技术输入）
-2. 从 FlowUS 读 PRD（理解业务背景，写代码时不偏离业务意图）
+1. 从 Notion 读 TRD 全文（唯一技术输入）
+2. 从 Notion 读 PRD（理解业务背景，写代码时不偏离业务意图）
 3. 确认代码仓库当前状态（分支、当前工作区或 worktree）
 4. **如有需要，再创建独立 worktree：**
    ```bash
@@ -44,7 +44,7 @@ description: EPIC 级别的 Odoo 模块开发流程规范。不是代码生成
    - 💡 建议：可以做得更好的地方
    - 没有疑问就说"没有疑问"，不硬凑
 6. **等用户回答澄清**
-7. **在 FlowUS 创建 DEV-PLAN 页面：** EPIC 子页面下
+7. **在 Notion 创建 DEV-PLAN 页面：** EPIC 子页面下
    - 环境信息（worktree、分支、模块名）
    - 澄清记录（问答）
    - 空进度表（Phase 0~8）
@@ -205,7 +205,7 @@ UAT 准备：
 用户确认后可以 commit + push。"
 ```
 
-**终检通过后：** 在 FlowUS 的 DEV-PLAN 页面记录该 EPIC 的开发完成状态和交付摘要。
+**终检通过后：** 在 Notion 的 DEV-PLAN 页面记录该 EPIC 的开发完成状态和交付摘要。
 
 ---
 
@@ -215,7 +215,7 @@ UAT 准备：
 
 1. **暂停开发**，不要自己决定
 2. 明确指出问题：哪条 TRD 规格有问题、为什么
-3. 记录到 FlowUS DEV-PLAN 页面的"发现"表
+3. 记录到 Notion DEV-PLAN 页面的"发现"表
 4. 建议用户回去改 TRD（调 trd）
 5. TRD 修改完成后再继续
 
@@ -225,7 +225,7 @@ UAT 准备：
 
 ## DEV-PLAN 页面规格
 
-位置：FlowUS — EPIC 页面下的 DEV-PLAN 子页面
+位置：Notion — EPIC 页面下的 DEV-PLAN 子页面
 
 ### 内容结构
 
@@ -277,7 +277,7 @@ UAT 准备：
 
 ### 更新时机
 
-- 每完成一个 Phase → 更新 FlowUS DEV-PLAN 页面进度表状态
+- 每完成一个 Phase → 更新 Notion DEV-PLAN 页面进度表状态
 - 发现问题 → 追加到"发现"表
 - 用户确认 → 追加到"确认记录"
 - 更新"最后更新"时间戳

package/payload/skills/discovery/SKILL.md

@@ -47,9 +47,9 @@ description: 域级业务需求共创 skill。用于围绕单个业务域做深
 | 当前业务域根页面下的页面 `待确认事项` | 推荐 | 恢复当前未决问题，避免反复讨论同一问题 | 若没有，则在当前业务域根页面下创建页面 `待确认事项` |
 | 相关会议纪要 / 调研记录 | 可选 | 补充上下文，缩短追问路径 | 没有也可以继续，但要明确哪些结论尚未验证 |
 
-## FlowUS 页面怎么找
+## Notion 页面怎么找
 
-本 skill 的正式文档读取和落地都依赖 FlowUS，不依赖本地文件。
+本 skill 的正式文档读取和落地都依赖 Notion，不依赖本地文件。
 
 进入项目文档时，固定按下面的顺序定位：
 
@@ -268,7 +268,7 @@ description: 域级业务需求共创 skill。用于围绕单个业务域做深
 
 ## 页面《待确认事项》处理
 
-所有未决问题统一写进 FlowUS 中“当前业务域根页面”下、标题固定为 `待确认事项` 的页面，不在本 skill 内维护额外状态，也不落到本地文件。
+所有未决问题统一写进 Notion 中“当前业务域根页面”下、标题固定为 `待确认事项` 的页面，不在本 skill 内维护额外状态，也不落到本地文件。
 
 统一格式：
 

package/payload/skills/discovery/references/output-template.md

@@ -1,6 +1,6 @@
 # Discovery V2 BRD 输出模板
 
-使用本模板组织并写入 FlowUS 中的域级 BRD 页面。
+使用本模板组织并写入 Notion 中的域级 BRD 页面。
 
 这份模板是仓库内的写作辅助，不是最终落地文档。
 最终权威内容必须写回当前业务域根页面下的 BRD 页面。
@@ -260,5 +260,5 @@ flowchart LR
 
 - {下一轮最值得继续确认的块}
 
-> `待确认事项` 不放在 BRD 正文内，而是作为 FlowUS 中挂在当前业务域根页面下的独立页面维护。
+> `待确认事项` 不放在 BRD 正文内，而是作为 Notion 中挂在当前业务域根页面下的独立页面维护。
 ```

package/payload/skills/epic-planning/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: epic-planning
-description: EPIC 拆分规划 skill。用于基于 FlowUS 中的全局资源、域级 BRD、域级 Solution 和页面《待确认事项》，把业务域方案拆成可交付 EPIC 清单，在业务域下建立 `Epics` 页面，并为每个 EPIC 建立标准命名和简介骨架。当用户提到“拆 EPIC”“做交付拆分”“规划 Epic 清单”“把域级方案拆成开发批次”“建立 Epics 页面”“调整 Epic 边界/命名/依赖”时必须使用。
+description: EPIC 拆分规划 skill。用于基于 Notion 中的全局资源、域级 BRD、域级 Solution 和页面《待确认事项》，把业务域方案拆成可交付 EPIC 清单，在业务域下建立 `Epics` 页面，并为每个 EPIC 建立标准命名和简介骨架。当用户提到“拆 EPIC”“做交付拆分”“规划 Epic 清单”“把域级方案拆成开发批次”“建立 Epics 页面”“调整 Epic 边界/命名/依赖”时必须使用。
 ---
 
 # EPIC 拆分规划
@@ -9,14 +9,14 @@ description: EPIC 拆分规划 skill。用于基于 FlowUS 中的全局资源、
 
 你是 Odoo Forge 的 EPIC 拆分规划专家。
 
-你的职责不是直接写 `PRD`，而是把域级 `BRD` 和 `Solution` 翻译成可交付的 EPIC 清单、边界和顺序，再把确认后的拆分结果沉淀成 FlowUS 中的页面 `Epics` 和各个 EPIC 页面。
+你的职责不是直接写 `PRD`，而是把域级 `BRD` 和 `Solution` 翻译成可交付的 EPIC 清单、边界和顺序，再把确认后的拆分结果沉淀成 Notion 中的页面 `Epics` 和各个 EPIC 页面。
 
 你的核心价值：
 
 - 把域级方案拆成真正可开发、可验收、可分批交付的业务能力块
 - 让后续 `prd / trd / uat` 都有稳定的 EPIC 入口和边界
 - 避免 EPIC 拆得过大、过碎，或按技术层错误切分
-- 只把已经确认的拆分结论写回 FlowUS
+- 只把已经确认的拆分结论写回 Notion
 
 ## 什么时候使用
 
@@ -46,9 +46,9 @@ description: EPIC 拆分规划 skill。用于基于 FlowUS 中的全局资源、
 | 当前业务域根页面下的页面 `Epics` | 推荐 | 判断是首次拆分还是增量修订，并读取已有 EPIC 清单 | 若没有，则进入新建模式 |
 | 相关会议纪要 / 里程碑 / 上线计划 | 可选 | 帮助判断优先级、批次和依赖 | 没有也可继续，但要明确哪些排序仍待确认 |
 
-## FlowUS 页面怎么找
+## Notion 页面怎么找
 
-本 skill 的正式文档读取和落地都依赖 FlowUS，不依赖本地文件。
+本 skill 的正式文档读取和落地都依赖 Notion，不依赖本地文件。
 
 进入项目文档时，固定按下面的顺序定位：
 
@@ -119,7 +119,7 @@ description: EPIC 拆分规划 skill。用于基于 FlowUS 中的全局资源、
 - 优先按业务闭环、业务目标和验收边界拆分
 - 明确每个 EPIC 的目标、范围、不在范围、依赖和建议优先级
 - 把不能确认的拆分问题统一写进页面 `待确认事项`
-- 只把确认过的拆分结果写回 FlowUS
+- 只把确认过的拆分结果写回 Notion
 
 ### 绝对不要做的事
 
@@ -271,7 +271,7 @@ description: EPIC 拆分规划 skill。用于基于 FlowUS 中的全局资源、
 
 ## 页面《待确认事项》处理
 
-所有 EPIC 拆分阶段的未决问题都统一写进 FlowUS 中“当前业务域根页面”下、标题固定为 `待确认事项` 的页面。
+所有 EPIC 拆分阶段的未决问题都统一写进 Notion 中“当前业务域根页面”下、标题固定为 `待确认事项` 的页面。
 
 统一格式：
 
@@ -332,7 +332,7 @@ description: EPIC 拆分规划 skill。用于基于 FlowUS 中的全局资源、
 - 单个 EPIC 页面的标准简介结构
 
 仓库模板只是写作辅助，不是最终落地位置。
-最终权威内容必须写回 FlowUS 页面中。
+最终权威内容必须写回 Notion 页面中。
 
 ## 结束时给出的下一步建议
 

package/payload/skills/epic-planning/references/output-template.md

@@ -1,9 +1,9 @@
 # EPIC 拆分输出模板
 
-使用本模板组织并写入 FlowUS 中当前业务域根页面下的 `Epics` 页面，以及各个 EPIC 页面。
+使用本模板组织并写入 Notion 中当前业务域根页面下的 `Epics` 页面，以及各个 EPIC 页面。
 
 这份模板是仓库内的写作辅助，不是最终落地文档。
-最终权威内容必须写回 FlowUS 页面中。
+最终权威内容必须写回 Notion 页面中。
 
 原则：
 

package/payload/skills/global-context/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: global-context
-description: 项目级全局资源共创 skill。用于在 FlowUS 的“产品设计 -> 全局资源”下新建、补齐或巡检项目背景、组织架构、业务域全景图、术语表、现有系统清单等共享上下文页面。当用户提到“建设全局资源”“补项目背景”“看看全局文档缺什么”“更新组织架构”“维护项目基础文档”时必须使用。
+description: 项目级全局资源共创 skill。用于在 Notion 的“产品设计 -> 全局资源”下新建、补齐或巡检项目背景、组织架构、业务域全景图、术语表、现有系统清单等共享上下文页面。当用户提到“建设全局资源”“补项目背景”“看看全局文档缺什么”“更新组织架构”“维护项目基础文档”时必须使用。
 ---
 
 # 项目级全局资源共创
@@ -9,14 +9,14 @@ description: 项目级全局资源共创 skill。用于在 FlowUS 的“产品
 
 你是项目级上下文架构师，也是全局资源文档的共创主持人。
 
-你的职责不是一次性“把 8 份文档写满”，而是帮助团队把项目级共识持续沉淀到 FlowUS 的 `全局资源` 页面体系里，给后续 `discovery`、`solution`、`prd`、`trd`、`uat` 提供统一认知基线。
+你的职责不是一次性“把 8 份文档写满”，而是帮助团队把项目级共识持续沉淀到 Notion 的 `全局资源` 页面体系里，给后续 `discovery`、`solution`、`prd`、`trd`、`uat` 提供统一认知基线。
 
 你的核心价值：
 
 - 把零散的项目背景整理成可复用的共享上下文
 - 区分“项目级共识”和“业务域细节”，避免文档串层
 - 一次只推进一份页面或一个块，不把用户压垮
-- 只把确认过的内容写回 FlowUS
+- 只把确认过的内容写回 Notion
 
 ## 什么时候使用
 
@@ -43,9 +43,9 @@ description: 项目级全局资源共创 skill。用于在 FlowUS 的“产品
 | `全局资源` 下的页面 `待确认事项` | 推荐 | 恢复当前未决的项目级问题 | 如果没有，先在 `全局资源` 下创建页面 `待确认事项` |
 | 项目材料、会议纪要、现有表格、制度文档 | 可选 | 缩短追问路径，提高首版质量 | 没有也可继续，但要明确哪些结论还未验证 |
 
-## FlowUS 页面怎么找
+## Notion 页面怎么找
 
-本 skill 的正式读取和落地都依赖 FlowUS，不依赖本地文件。
+本 skill 的正式读取和落地都依赖 Notion，不依赖本地文件。
 
 进入项目文档时，固定按下面的顺序定位：
 
@@ -56,7 +56,7 @@ description: 项目级全局资源共创 skill。用于在 FlowUS 的“产品
 5. 检查是否存在页面 `待确认事项`
 6. 再判断应该进入初始建设、增量完善还是健康巡检模式
 
-推荐的 FlowUS 结构如下：
+推荐的 Notion 结构如下：
 
 ```text
 产品设计
@@ -247,11 +247,11 @@ description: 项目级全局资源共创 skill。用于在 FlowUS 的“产品
 - 这一页到底要帮助下游理解什么
 - 到什么程度才算“够用”
 - 哪些回答说明还停留在口号或印象层
-- 最终应写成什么结构，落到 FlowUS 的哪一页
+- 最终应写成什么结构，落到 Notion 的哪一页
 
 ## 页面《待确认事项》处理
 
-所有项目级未决问题统一写进 FlowUS 中页面 `全局资源` 下、标题固定为 `待确认事项` 的页面，不在本 skill 内维护额外状态，也不落到本地文件。
+所有项目级未决问题统一写进 Notion 中页面 `全局资源` 下、标题固定为 `待确认事项` 的页面，不在本 skill 内维护额外状态，也不落到本地文件。
 
 统一格式：
 
@@ -281,7 +281,7 @@ description: 项目级全局资源共创 skill。用于在 FlowUS 的“产品
 
 ### 2. 写回位置必须正确
 
-最终权威内容都写回 FlowUS：
+最终权威内容都写回 Notion：
 
 - `项目背景`、`组织架构`、`业务域全景图` 等作为 `全局资源` 的子页面
 - 项目级未决问题写入 `全局资源` 下的页面 `待确认事项`
@@ -312,7 +312,7 @@ description: 项目级全局资源共创 skill。用于在 FlowUS 的“产品
 
 ## 输出结构
 
-本 skill 的正式输出不是本地文件，而是 FlowUS `全局资源` 页面体系。
+本 skill 的正式输出不是本地文件，而是 Notion `全局资源` 页面体系。
 
 推荐维护的页面如下：
 
@@ -346,4 +346,4 @@ description: 项目级全局资源共创 skill。用于在 FlowUS 的“产品
 - 不要把“技术架构概览”写成模块级实现细节
 - 不要因为用户给的信息零散，就自行杜撰组织关系或项目边界
 - 不要把仓库里的模板当成最终交付物
-- 不要在没有读 FlowUS 页面树的情况下猜测页面结构
+- 不要在没有读 Notion 页面树的情况下猜测页面结构

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

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

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

@@ -1,12 +1,12 @@
 # 全局资源页面规格
 
-本文件用于指导 `global-context` 如何在 FlowUS 的 `全局资源` 下建设和维护项目级页面。
+本文件用于指导 `global-context` 如何在 Notion 的 `全局资源` 下建设和维护项目级页面。
 
 它是共创时的覆盖检查框架，不是必须逐条照念的问题清单。
 
 ## 使用原则
 
-- 最终权威内容写回 FlowUS 的页面，不写回本地 Markdown
+- 最终权威内容写回 Notion 的页面，不写回本地 Markdown
 - 一次只推进一页或一页中的一个块
 - 先保住“够用”，再追求“完整”
 - 未确认的问题进入 `全局资源` 下的页面 `待确认事项`

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

@@ -1,13 +1,13 @@
 ---
 name: industry-practice
-description: 行业顾问 skill。基于 FlowUS 全局资源和必要的联网检索，提供行业惯例、需求审视、方案支持与风险提醒。当用户提到“行业里一般怎么做”“这个方案合理吗”“帮我从行业角度看看”“这是不是过度定制”时使用；可被 discovery、solution、prd、trd 作为 subagent 调用。
+description: 行业顾问 skill。基于 Notion 全局资源和必要的联网检索，提供行业惯例、需求审视、方案支持与风险提醒。当用户提到“行业里一般怎么做”“这个方案合理吗”“帮我从行业角度看看”“这是不是过度定制”时使用；可被 discovery、solution、prd、trd 作为 subagent 调用。
 ---
 
 # 行业顾问
 
 ## 你是谁
 
-你是一个资深行业顾问。你的行业专长由 FlowUS 全局资源中的项目背景决定——启动时先从 FlowUS 读取全局资源，理解项目所在行业、公司类型和业务特征，然后以该行业的资深顾问身份提供服务。
+你是一个资深行业顾问。你的行业专长由 Notion 全局资源中的项目背景决定——启动时先从 Notion 读取全局资源，理解项目所在行业、公司类型和业务特征，然后以该行业的资深顾问身份提供服务。
 
 **你的价值：**
 
@@ -30,9 +30,9 @@ description: 行业顾问 skill。基于 FlowUS 全局资源和必要的联网
 | `全局资源` 页面及其子页 | 必需 | 判断所属行业、公司类型、项目背景 | 如果没有，先尝试从用户输入提取行业背景；若仍不清楚，明确说明判断可信度受限 |
 | 当前域 BRD / Solution / 其他待审文档 | 视模式而定 | 作为咨询、方案支持或审查的对象 | 没有具体文档时，仍可做咨询，但不能假装做了完整审查 |
 
-## FlowUS 页面怎么找
+## Notion 页面怎么找
 
-本 skill 的正式上下文优先来自 FlowUS，可直接独立调用。
+本 skill 的正式上下文优先来自 Notion，可直接独立调用。
 
 进入项目文档时，默认按下面的顺序定位：
 
@@ -50,7 +50,7 @@ description: 行业顾问 skill。基于 FlowUS 全局资源和必要的联网
 
 **行为：**
 
-1. 从 FlowUS 读全局资源了解行业背景
+1. 从 Notion 读全局资源了解行业背景
 2. 理解问题语境
 3. 按需回答，不走完整评审流程
 4. 给出回答 = **结论 + 行业依据 + 顾问建议**
@@ -111,9 +111,9 @@ description: 行业顾问 skill。基于 FlowUS 全局资源和必要的联网
 
 #### 第一步：读材料
 
-1. 从 FlowUS 读全局资源（每次必读）
-2. 从 FlowUS 读被审查文档（通常是 BRD）
-3. 从 FlowUS 读该域下的补充材料（如果有）
+1. 从 Notion 读全局资源（每次必读）
+2. 从 Notion 读被审查文档（通常是 BRD）
+3. 从 Notion 读该域下的补充材料（如果有）
 
 #### 第二步：自动评审