odoo-forge-bundle 0.1.9 → 0.1.10

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.10",
   "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.10",
   "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 读该域下的补充材料（如果有）
 
 #### 第二步：自动评审
 

package/payload/skills/module-report/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: module-report
-description: Odoo 模块报告 skill。用于对已选定的模块、仓库或本地路径做深入阅读，生成完整模块报告，并写入 FlowUS 的“项目Wiki / 模块报告”。当用户需要“精读模块”“沉淀模块知识库”“生成模块报告”时使用；如果还在大范围找候选，则先用 module-research。
+description: Odoo 模块报告 skill。用于对已选定的模块、仓库或本地路径做深入阅读，生成完整模块报告，并写入 Notion 的“项目Wiki / 模块报告”。当用户需要“精读模块”“沉淀模块知识库”“生成模块报告”时使用；如果还在大范围找候选，则先用 module-research。
 ---
 
 # 模块报告
@@ -13,7 +13,7 @@ description: Odoo 模块报告 skill。用于对已选定的模块、仓库或
 
 1. 深入阅读已选定的模块或仓库
 2. 生成完整模块报告正文
-3. 将模块报告沉淀到 FlowUS 的模块知识库
+3. 将模块报告沉淀到 Notion 的模块知识库
 
 它**不负责做大范围候选搜索**。如果用户还没确定要看哪个模块，先交给 `module-research`。
 
@@ -23,12 +23,12 @@ description: Odoo 模块报告 skill。用于对已选定的模块、仓库或
 |----------|--------|------|--------------|
 | `全局资源` 页面及其子页 | 必需 | 判断模块对你们项目的推荐度、简介口径和使用场景 | 如果没有，仍可写报告，但要明确推荐度可信度下降 |
 | 目标仓库 / 模块 / 本地路径 | 必需 | 决定要精读什么 | 没有目标就停止，先让调用方回到 `module-research` |
-| `项目Wiki / 模块报告` 页面 | 建议 | 写入 FlowUS 模块知识库 | 如果没有，则先创建 |
+| `项目Wiki / 模块报告` 页面 | 建议 | 写入 Notion 模块知识库 | 如果没有，则先创建 |
 | 相关业务域的 `BRD / Solution` | 推荐 | 结合当前业务域判断该模块在你们项目中的实际使用场景 | 如果没有，则至少基于 `全局资源` 做判断，并说明适用范围仍较宽 |
 
 ## 开始前先读什么
 
-在进入模块源码之前，先用 FlowUS MCP 读取与你们项目有关的上下文，不要直接脱离项目背景写“推荐度 / 使用场景 / 简介”。
+在进入模块源码之前，先用 Notion MCP 读取与你们项目有关的上下文，不要直接脱离项目背景写“推荐度 / 使用场景 / 简介”。
 
 默认先读：
 
@@ -45,28 +45,33 @@ description: Odoo 模块报告 skill。用于对已选定的模块、仓库或
 - `使用场景`：写清楚在你们项目的哪类业务域、流程、角色或需求下可以考虑
 - `推荐度`：结合你们项目背景判断是 `推荐 / 备选 / 谨慎`
 
-## FlowUS 页面怎么找
+## Notion 页面怎么找
 
 写入时默认按下面的顺序定位：
 
 1. 先定位根页面 `项目Wiki`
-2. 读取 `项目Wiki` 的页面树
+2. 读取 `项目Wiki` 的页面结构
 3. 在 `项目Wiki` 下进入或创建页面 `模块报告`
-4. 在 `模块报告` 下按仓库名定位或创建多维表，多维表名字就是仓库名字
-5. 在对应多维表内按 `标题` 查找记录；有则更新，没有则新建
+4. 在 `模块报告` 下按仓库名定位或创建数据库，数据库名字就是仓库名字
+5. 先 `fetch` 数据库，拿到真实 schema 和 `data_source_id`
+6. 再在对应 `data_source_id` 下按 `标题` 查找记录；有则更新，没有则新建
 
-如果对象不存在，按下面的 FlowUS MCP 模板创建，不要自由发挥。
+这里要按 Notion MCP 的真实工作方式来写，不要再沿用旧的“多维表 + create_page/update_page”心智。
 
-### 页面与多维表创建模板
+### 页面与数据库创建模板
 
 1. 创建 `项目Wiki` 页面：
 
 ```json
 {
-  "properties": {
-    "title": "项目Wiki"
-  },
-  "icon": "📚"
+  "pages": [
+    {
+      "properties": {
+        "title": "项目Wiki"
+      },
+      "icon": "📚"
+    }
+  ]
 }
 ```
 
@@ -77,137 +82,131 @@ description: Odoo 模块报告 skill。用于对已选定的模块、仓库或
   "parent": {
     "page_id": "{项目Wiki_page_id}"
   },
-  "properties": {
-    "title": "模块报告"
-  },
-  "icon": "📦"
+  "pages": [
+    {
+      "properties": {
+        "title": "模块报告"
+      },
+      "icon": "📦"
+    }
+  ]
 }
 ```
 
-3. 在 `模块报告` 页面下创建仓库级多维表。
-这里必须创建成页面内可见的内嵌多维表，也就是 `is_inline: true`：
+3. 在 `模块报告` 页面下创建仓库级数据库。
+推荐 schema 固定为：
+
+```sql
+CREATE TABLE (
+  "标题" TITLE,
+  "简介" RICH_TEXT,
+  "使用场景" RICH_TEXT,
+  "推荐度" SELECT('推荐':green, '备选':yellow, '谨慎':red)
+)
+```
+
+对应调用形态：
 
 ```json
 {
   "parent": {
     "page_id": "{模块报告_page_id}"
   },
-  "title": [
-    {
-      "type": "text",
-      "text": {
-        "content": "server-tools"
-      }
-    }
-  ],
-  "icon": {
-    "emoji": "🗃️"
-  },
-  "is_inline": true,
-  "properties": {
-    "标题": { "title": {} },
-    "简介": { "rich_text": {} },
-    "使用场景": { "rich_text": {} },
-    "推荐度": {
-      "select": {
-        "options": [
-          { "name": "推荐" },
-          { "name": "备选" },
-          { "name": "谨慎" }
-        ]
-      }
-    }
-  }
+  "title": "server-tools",
+  "schema": "CREATE TABLE (\"标题\" TITLE, \"简介\" RICH_TEXT, \"使用场景\" RICH_TEXT, \"推荐度\" SELECT('推荐':green, '备选':yellow, '谨慎':red))"
 }
 ```
 
-4. 在仓库级多维表里创建模块记录页：
+4. 创建完数据库后，立刻 `fetch` 该数据库。
+不要跳过这一步，因为后续写记录必须用返回结果里的 `data_source_id` 和真实属性名。
+
+5. 在仓库级数据库里创建模块记录页：
 
 ```json
 {
   "parent": {
-    "database_id": "{仓库级多维表_database_id}"
+    "data_source_id": "{仓库级数据库_data_source_id}"
   },
-  "properties": {
-    "title": "sale_order_tag",
-    "简介": "为销售订单提供标签分类与筛选能力",
-    "使用场景": "适合在你们项目中需要按业务主题、项目来源或专项任务给销售订单分类时考虑",
-    "推荐度": "备选"
-  },
-  "icon": "🧩"
+  "pages": [
+    {
+      "properties": {
+        "标题": "sale_order_tag",
+        "简介": "为销售订单提供标签分类与筛选能力",
+        "使用场景": "适合在你们项目中需要按业务主题、项目来源或专项任务给销售订单分类时考虑",
+        "推荐度": "备选"
+      },
+      "icon": "🧩"
+    }
+  ]
 }
 ```
 
 ### 创建后的验证步骤
 
-每次创建仓库级多维表后，都要立刻验证它是不是“页面内可见”：
+每次创建仓库级数据库后，都要立刻做这两步验证：
 
-1. 对 `模块报告_page_id` 执行一次 `get_block_children`
-2. 确认返回结果里出现刚创建的仓库级多维表
-3. 如果页面里看不见，但数据库确实建出来了，优先怀疑创建成了 standalone database
-4. 此时不要继续写记录，先删掉错误数据库，再按 `is_inline: true` 重建
+1. `fetch` 父页面，确认数据库已经出现在 `模块报告` 页面下
+2. `fetch` 新数据库，确认返回结果中能看到真实 schema 和 `data_source_id`
 
-不要只以“create_database 调用了成功”作为结束条件，要以“父页面能看到这个内嵌多维表”作为成功标准。
+不要只以“create_database 调用了成功”作为结束条件，
+要以“父页面可见 + schema 可识别 + 可拿到 data_source_id”作为成功标准。
 
-## FlowUS 多维表约定
+## Notion 数据库约定
 
-每个仓库一个多维表，表名直接使用仓库名字，例如：
+每个仓库一个数据库，数据库标题直接使用仓库名字，例如：
 
 - `server-tools`
 - `project`
 - `hr`
 
-每个多维表至少要有下面 4 个核心列，不能漏：
+每个数据库应具备 4 个核心属性：
 
 - `标题`
 - `简介`
 - `使用场景`
 - `推荐度`
 
-其中：
+推荐类型如下：
 
-- `标题` 使用标题列
-- `简介` 使用文本字段
-- `使用场景` 使用文本字段
-- `推荐度` 使用 `select` 单选字段，选项固定为 `推荐 / 备选 / 谨慎`
+- `标题`：`TITLE`
+- `简介`：`RICH_TEXT`
+- `使用场景`：`RICH_TEXT`
+- `推荐度`：`SELECT('推荐':green, '备选':yellow, '谨慎':red)`
 
-如果多维表不存在，创建时就把 4 个字段一次建齐，而且必须是 `is_inline: true` 的内嵌多维表。目标 schema 参考：
+如果数据库已经存在，则：
 
-```json
-{
-  "标题": { "title": {} },
-  "简介": { "rich_text": {} },
-  "使用场景": { "rich_text": {} },
-  "推荐度": {
-    "select": {
-      "options": [
-        { "name": "推荐" },
-        { "name": "备选" },
-        { "name": "谨慎" }
-      ]
-    }
-  }
-}
-```
+- 先 `fetch` 数据库，读取真实 schema
+- 如果缺少属性，用 `update_data_source` 补齐
+- 如果属性名与预期不一致，先统一命名，再继续写记录
+- 不要在没有拿到 `data_source_id` 的情况下直接写记录
 
-如果多维表已经存在，但缺少 `简介 / 使用场景 / 推荐度` 任一列：
+### 模块记录写入要求
 
-- 先补齐缺失列
-- 再创建或更新模块记录
+目标上，模块记录应包含：
 
-创建或更新模块记录时，`标题 / 简介 / 使用场景 / 推荐度` 这 4 个属性必须同时写，不允许只写 `标题`。
+- `标题`
+- `简介`
+- `使用场景`
+- `推荐度`
 
-记录属性写入口径参考：
+摘要字段口径按下面的标准准备：
 
 ```json
 {
-  "title": "sale_order_tag",
+  "标题": "sale_order_tag",
   "简介": "为销售订单提供标签分类与筛选能力",
   "使用场景": "适合在你们项目中需要按业务主题、项目来源或专项任务给销售订单分类时考虑",
   "推荐度": "备选"
 }
 ```
 
+写入时要按这个顺序：
+
+1. 如果是新记录，用 `create_pages` 在数据库的 `data_source_id` 下创建
+2. 如果是已有记录，先 `fetch` 该页面，再用 `update_page` 更新属性和正文
+3. 写完后重新 `fetch` 页面或数据库，确认属性和值已经落进去
+4. 只有在属性和正文都成功写入后，才可以把本次 Notion 更新当作完成状态
+
 点开每一行的页面后，再写入完整模块报告正文。
 
 ## 什么时候使用
@@ -241,15 +240,16 @@ description: Odoo 模块报告 skill。用于对已选定的模块、仓库或
    - 依赖模块
    - 安装前置条件
    - 维护和兼容性信号
-5. 再回到 FlowUS 上下文判断：
+5. 再回到 Notion 上下文判断：
    - 对你们项目的推荐度
    - 在你们项目中的使用场景
-   - 适合写进多维表的简介口径
+   - 适合写进数据库属性的简介口径
 6. 生成完整模块报告正文，固定按 5 段结构写
-7. 写入 FlowUS：
-   - 定位仓库名对应的多维表
-   - 先确认多维表 4 个核心列齐全
-   - 更新或创建对应模块这一行，并同时回填 `标题 / 简介 / 使用场景 / 推荐度`
+7. 写入 Notion：
+   - 定位仓库名对应的数据库
+   - 先 `fetch` 数据库，确认 schema 和 `data_source_id`
+   - 如果 schema 有问题，先修 schema 再继续
+   - 创建或更新模块记录，并验证 4 个属性已写入
    - 将完整报告写入该行页面正文
 8. 返回简短摘要给调用方
 
@@ -332,13 +332,13 @@ description: Odoo 模块报告 skill。用于对已选定的模块、仓库或
 
 如果是多模块批量精读：
 
-- 同仓库模块写入同一个多维表
-- 不同仓库分别写入各自仓库名的多维表
+- 同仓库模块写入同一个数据库
+- 不同仓库分别写入各自仓库名的数据库
 - 每个模块独立占一行并拥有自己的正文页面
 
-## FlowUS 写入结果
+## Notion 写入结果
 
-写入多维表时，摘要字段按下面的口径回填：
+写入数据库时，摘要字段按下面的口径回填：
 
 - `标题`：模块技术名或最常用名称
 - `简介`：一句话说明模块做什么，语气与术语要尽量贴近你们项目
@@ -347,7 +347,7 @@ description: Odoo 模块报告 skill。用于对已选定的模块、仓库或
 
 如果同一模块已经存在：
 
-- 更新该模块对应行的 4 个字段
+- 优先读取现有记录和数据库 schema，再判断如何更新 4 个属性
 - 更新该行页面正文
 - 不重复新建
 
@@ -356,7 +356,8 @@ description: Odoo 模块报告 skill。用于对已选定的模块、仓库或
 - 不只重复 README，要补代码层判断
 - 不只说“有这个功能”，要说清楚模块的实际使用方式
 - `简介 / 使用场景 / 推荐度` 必须结合 `全局资源`，有业务域上下文时还要结合对应 `BRD / Solution`
-- 创建或更新模块记录时，不能漏掉 `简介 / 使用场景 / 推荐度`
+- 不要跳过 `fetch`，要以 Notion 当前真实 schema 和 `data_source_id` 为准
+- 创建或更新模块记录时，目标上不应漏掉 `简介 / 使用场景 / 推荐度`
 - `依赖与安装` 必须细到跟着就能装好
 - `操作指南` 里的配置指南必须细到跟着就能配好
 - `操作指南` 必须包含至少 1 个闭环演示场景，让用户能实际走通一遍
@@ -364,7 +365,7 @@ description: Odoo 模块报告 skill。用于对已选定的模块、仓库或
 
 ## 返回给调用方的摘要格式
 
-写完 FlowUS 后，给调用方返回一段短摘要即可，例如：
+写完 Notion 后，给调用方返回一段短摘要即可，例如：
 
 ```markdown
 ## 模块报告已更新

package/payload/skills/module-report/agents/openai.yaml

@@ -1,6 +1,6 @@
 interface:
   display_name: "模块报告"
-  short_description: "精读已选定模块并把完整模块报告写入 FlowUS 的项目Wiki/模块报告"
+  short_description: "精读已选定模块并把完整模块报告写入 Notion 的项目Wiki/模块报告"
   icon_small: "./assets/icon-small.svg"
   icon_large: "./assets/icon-large.svg"
   brand_color: "#714B67"

package/payload/skills/module-research/SKILL.md

@@ -14,7 +14,7 @@ description: Odoo 模块搜索 skill。用于按业务需求搜索 OCA、第三
 1. 按需求搜索 OCA、第三方 GitHub 仓库和本地模块
 2. 返回适合方案阶段快速判断的候选简表
 
-它**不负责深度精读，也不写 FlowUS 报告库**。一旦用户已经选中模块、仓库或候选集合，需要转交给 `module-report`。
+它**不负责深度精读，也不写 Notion 报告库**。一旦用户已经选中模块、仓库或候选集合，需要转交给 `module-report`。
 
 ## 必需上游上下文
 
@@ -23,9 +23,9 @@ description: Odoo 模块搜索 skill。用于按业务需求搜索 OCA、第三
 | `全局资源` 页面及其子页 | 必需 | 了解项目背景，判断“推荐级别” | 如果读不到，明确说明推荐级别可信度下降 |
 | 当前需求描述 / 方案块 / 业务问题 | 必需 | 决定搜索关键词和筛选方向 | 先要求调用方把需求说清楚，不要盲搜 |
 
-## FlowUS 页面怎么找
+## Notion 页面怎么找
 
-如果调用方没有显式传入项目背景，默认从 FlowUS 恢复：
+如果调用方没有显式传入项目背景，默认从 Notion 恢复：
 
 1. 先定位根页面 `产品设计`
 2. 读取 `产品设计` 的页面树
@@ -46,7 +46,7 @@ description: Odoo 模块搜索 skill。用于按业务需求搜索 OCA、第三
 
 - 需要确认官方标准模块是否已经覆盖，用 `odoo18-docs`
 - 需要深入精读某个已选模块，用 `module-report`
-- 需要把模块报告沉淀进 FlowUS，用 `module-report`
+- 需要把模块报告沉淀进 Notion，用 `module-report`
 
 ## 默认假设
 
@@ -110,7 +110,7 @@ description: Odoo 模块搜索 skill。用于按业务需求搜索 OCA、第三
   - 模块定位是否顺 Odoo 心智模型
   - 模块是否贴合你们当前项目场景
 
-`推荐级别` 的判断必须结合 FlowUS 中的 `全局资源`，不能脱离项目背景空评。
+`推荐级别` 的判断必须结合 Notion 中的 `全局资源`，不能脱离项目背景空评。
 
 ## 输出格式
 
@@ -145,7 +145,7 @@ description: Odoo 模块搜索 skill。用于按业务需求搜索 OCA、第三
 ## Guardrails
 
 - 不要把“搜到了相关关键词”当成“可用”
-- 不要写 FlowUS 报告页或多维表
+- 不要写 Notion 报告页或数据库
 - 不要替代 `odoo18-docs` 做官方能力查证
 - 不要替代 `module-report` 做正式模块报告
 - 不要在没读 manifest 和 README 的情况下下推荐结论

package/payload/skills/prd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: prd
-description: EPIC 级产品需求共创 skill。用于基于 FlowUS 中的全局资源、域级 BRD、域级 Solution、当前 EPIC 页面和页面《待确认事项》，逐步收敛出可交付 PRD。当用户提到“写 PRD”“整理这个 epic 的功能规格”“补规则/状态/权限/视图”“把这个 EPIC 说清楚”“改现有 PRD”时必须使用。
+description: EPIC 级产品需求共创 skill。用于基于 Notion 中的全局资源、域级 BRD、域级 Solution、当前 EPIC 页面和页面《待确认事项》，逐步收敛出可交付 PRD。当用户提到“写 PRD”“整理这个 epic 的功能规格”“补规则/状态/权限/视图”“把这个 EPIC 说清楚”“改现有 PRD”时必须使用。
 ---
 
 # EPIC 级产品需求共创
@@ -9,14 +9,14 @@ description: EPIC 级产品需求共创 skill。用于基于 FlowUS 中的全局
 
 你是 Odoo Forge 的 EPIC 级产品需求共创专家。
 
-你的职责不是一次性“把 PRD 写完”，而是把某个 EPIC 的业务边界、用户故事、规则、状态、页面和权限逐步讨论清楚，再把确认过的内容沉淀成 FlowUS 中的 `PRD` 页面。
+你的职责不是一次性“把 PRD 写完”，而是把某个 EPIC 的业务边界、用户故事、规则、状态、页面和权限逐步讨论清楚，再把确认过的内容沉淀成 Notion 中的 `PRD` 页面。
 
 你的核心价值：
 
 - 把域级 `BRD` 和 `Solution` 翻译成可交付的 EPIC 级产品规格
 - 保留业务语言，但用 Odoo 术语帮助表达更精确
 - 让 `trd` 和 `uat` 读完后基本不需要再猜业务逻辑
-- 只把已经讨论并确认的结论写回 FlowUS
+- 只把已经讨论并确认的结论写回 Notion
 
 ## 什么时候使用
 
@@ -46,9 +46,9 @@ description: EPIC 级产品需求共创 skill。用于基于 FlowUS 中的全局
 | 当前业务域根页面下的页面 `待确认事项` | 推荐 | 恢复当前未决问题，避免把伪共识写进 `PRD` | 若没有，则先在当前业务域根页面下创建页面 `待确认事项` |
 | 当前 EPIC 下已有的 `PRD` | 推荐 | 判断是新建还是增量修订，并避免重复写 | 若没有，则进入新建模式 |
 
-## FlowUS 页面怎么找
+## Notion 页面怎么找
 
-本 skill 的正式文档读取和落地都依赖 FlowUS，不依赖本地文件。
+本 skill 的正式文档读取和落地都依赖 Notion，不依赖本地文件。
 
 进入项目文档时，固定按下面的顺序定位：
 
@@ -237,7 +237,7 @@ description: EPIC 级产品需求共创 skill。用于基于 FlowUS 中的全局
 
 ## 页面《待确认事项》处理
 
-所有 `PRD` 阶段的未决问题都统一写进 FlowUS 中“当前业务域根页面”下、标题固定为 `待确认事项` 的页面。
+所有 `PRD` 阶段的未决问题都统一写进 Notion 中“当前业务域根页面”下、标题固定为 `待确认事项` 的页面。
 
 统一格式：
 
@@ -266,7 +266,7 @@ description: EPIC 级产品需求共创 skill。用于基于 FlowUS 中的全局
 
 ### 2. 写回位置必须正确
 
-最终权威内容都写回 FlowUS：
+最终权威内容都写回 Notion：
 
 - EPIC 级规格写入当前 EPIC 页面下的 `PRD`
 - 未决问题写入当前业务域根页面下的页面 `待确认事项`

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

@@ -1,6 +1,6 @@
 # PRD 输出模板
 
-使用本模板组织并写入 FlowUS 中当前 EPIC 页面下的 `PRD` 页面。
+使用本模板组织并写入 Notion 中当前 EPIC 页面下的 `PRD` 页面。
 
 这份模板是仓库内的写作辅助，不是最终落地文档。
 最终权威内容必须写回当前 EPIC 页面下的 `PRD` 页面。

package/payload/skills/review/SKILL.md

@@ -54,9 +54,9 @@ description: Odoo Forge 通用文档审查 skill。用于审查 BRD、Solution
 | 当前业务域根页面下的页面 `待确认事项` | 推荐 | 判断当前未决问题和重复问题 | 没有则先创建 |
 | 必要的上下游文档 | 视文档类型而定 | 判断一致性和可交付性 | 缺失时在报告中明确指出 |
 
-## FlowUS 页面怎么找
+## Notion 页面怎么找
 
-本 skill 的正式上下文只来自 FlowUS。
+本 skill 的正式上下文只来自 Notion。
 
 进入项目文档时，默认按下面的顺序定位：
 
@@ -136,7 +136,7 @@ description: Odoo Forge 通用文档审查 skill。用于审查 BRD、Solution
 
 1. **识别审查对象**
    确认当前文档类型、所在业务域、当前工作模式。
-2. **读取 FlowUS 上下文**
+2. **读取 Notion 上下文**
    先读 `全局资源`，再读当前文档、必要上下游文档和页面 `待确认事项`。
 3. **加载对应清单**
    按文档类型读取对应 checklist，不混用检查点。

package/payload/skills/solution/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: solution
-description: 域级 Odoo 方案共创 skill。用于基于 FlowUS 中的全局资源、域级 BRD 和待确认事项，研究官方能力、补充 OCA/社区模块、调用顾问 subagent，逐步收敛业务域的 Solution 页面。当用户提到“做方案设计”“模块选型”“GAP 分析”“写 Solution”“看看 Odoo 怎么落地”“评估官方和 OCA 方案”时必须使用。
+description: 域级 Odoo 方案共创 skill。用于基于 Notion 中的全局资源、域级 BRD 和待确认事项，研究官方能力、补充 OCA/社区模块、调用顾问 subagent，逐步收敛业务域的 Solution 页面。当用户提到“做方案设计”“模块选型”“GAP 分析”“写 Solution”“看看 Odoo 怎么落地”“评估官方和 OCA 方案”时必须使用。
 ---
 
 # 域级 Odoo 方案共创
@@ -16,7 +16,7 @@ description: 域级 Odoo 方案共创 skill。用于基于 FlowUS 中的全局
 - 把业务真相翻译成顺着 Odoo 心智模型的落地方案
 - 先查官方能力，再补社区模块，最后才考虑必要定制
 - 善用 subagent 补证据和专业判断，而不是凭印象拍方案
-- 只把已经讨论并确认的方案结论写回 FlowUS
+- 只把已经讨论并确认的方案结论写回 Notion
 
 ## 什么时候使用
 
@@ -44,9 +44,9 @@ description: 域级 Odoo 方案共创 skill。用于基于 FlowUS 中的全局
 | 当前域 `Solution` | 推荐 | 判断是首次方案还是增量修订，并避免重复研究 | 若没有，则进入新建模式 |
 | 相关会议纪要 / 调研记录 / 外部资料 | 可选 | 缩短研究路径，提高判断质量 | 没有也可继续，但要明确哪些结论尚未验证 |
 
-## FlowUS 页面怎么找
+## Notion 页面怎么找
 
-本 skill 的正式文档读取和落地都依赖 FlowUS，不依赖本地文件。
+本 skill 的正式文档读取和落地都依赖 Notion，不依赖本地文件。
 
 进入项目文档时，固定按下面的顺序定位：
 
@@ -195,7 +195,7 @@ description: 域级 Odoo 方案共创 skill。用于基于 FlowUS 中的全局
 2. **OCA / 社区补充按需查**
    当官方能力不能完整覆盖，或明显存在社区补位可能时，再用 `module-research` 搜索候选模块，先拿回“模块名 / 简介 / 推荐级别 / 适用场景”的简表。
 3. **候选模块精读按需查**
-   当已经找到候选模块，需要沉淀正式模块报告时，再用 `module-report` 精读，并把结果写入 FlowUS 的 `项目Wiki / 模块报告`。
+   当已经找到候选模块，需要沉淀正式模块报告时，再用 `module-report` 精读，并把结果写入 Notion 的 `项目Wiki / 模块报告`。
 4. **顾问建议按需查**
    当涉及行业常规做法、公司制度约束、交付规范或方案取舍时，调用 `industry-practice`、`company-rules`。
 
@@ -267,7 +267,7 @@ description: 域级 Odoo 方案共创 skill。用于基于 FlowUS 中的全局
   - 触发：官方能力不足，或明显存在社区补位可能时
 
 - `module-report`
-  - 用途：精读候选模块，生成正式模块报告，并写入 FlowUS 的 `项目Wiki / 模块报告`
+  - 用途：精读候选模块，生成正式模块报告，并写入 Notion 的 `项目Wiki / 模块报告`
   - 触发：已经找到候选模块，准备沉淀模块知识库或进入正式推荐时
 
 - `industry-practice`
@@ -286,7 +286,7 @@ description: 域级 Odoo 方案共创 skill。用于基于 FlowUS 中的全局
 
 ## 页面《待确认事项》处理
 
-所有方案未决问题统一写进 FlowUS 中“当前业务域根页面”下、标题固定为 `待确认事项` 的页面，不在本 skill 内维护额外状态，也不落到本地文件。
+所有方案未决问题统一写进 Notion 中“当前业务域根页面”下、标题固定为 `待确认事项` 的页面，不在本 skill 内维护额外状态，也不落到本地文件。
 
 统一格式：
 
@@ -315,7 +315,7 @@ description: 域级 Odoo 方案共创 skill。用于基于 FlowUS 中的全局
 
 ### 2. 写回位置必须正确
 
-最终权威内容都写回 FlowUS：
+最终权威内容都写回 Notion：
 
 - 域级方案写入当前业务域根页面下的页面 `Solution`
 - 方案未决问题写入当前业务域根页面下的页面 `待确认事项`

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

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

package/payload/skills/trd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: trd
-description: EPIC 级技术设计共创 skill。用于基于 FlowUS 中的全局资源、域级 Solution、当前 EPIC 的 PRD 和页面《待确认事项》，逐步收敛出可直接开发的 TRD。当用户提到“写 TRD”“做技术设计”“把这个 PRD 翻成 Odoo 技术实现”“补模型/方法/权限/视图实现”“改现有 TRD”时必须使用。
+description: EPIC 级技术设计共创 skill。用于基于 Notion 中的全局资源、域级 Solution、当前 EPIC 的 PRD 和页面《待确认事项》，逐步收敛出可直接开发的 TRD。当用户提到“写 TRD”“做技术设计”“把这个 PRD 翻成 Odoo 技术实现”“补模型/方法/权限/视图实现”“改现有 TRD”时必须使用。
 ---
 
 # EPIC 级技术设计共创
@@ -9,14 +9,14 @@ description: EPIC 级技术设计共创 skill。用于基于 FlowUS 中的全局
 
 你是 Odoo Forge 的 EPIC 级技术设计专家。
 
-你的职责不是一次性“把技术文档写满”，而是把某个 EPIC 的模块拆分、模型设计、规则实现、权限、视图和数据文件逐步讨论清楚，再把确认过的结论沉淀成 FlowUS 中的 `TRD` 页面。
+你的职责不是一次性“把技术文档写满”，而是把某个 EPIC 的模块拆分、模型设计、规则实现、权限、视图和数据文件逐步讨论清楚，再把确认过的结论沉淀成 Notion 中的 `TRD` 页面。
 
 你的核心价值：
 
 - 把 `PRD` 翻译成可直接开发的 Odoo 技术规格
 - 明确模块边界、模型来源、方法职责和文件组织
 - 让研发或 AI 读完后基本不需要再猜 `PRD`
-- 只把已经讨论并确认的技术结论写回 FlowUS
+- 只把已经讨论并确认的技术结论写回 Notion
 
 ## 什么时候使用
 
@@ -45,9 +45,9 @@ description: EPIC 级技术设计共创 skill。用于基于 FlowUS 中的全局
 | 当前业务域根页面下的页面 `待确认事项` | 推荐 | 恢复当前未决问题，避免把伪共识写进 `TRD` | 若没有，则先在当前业务域根页面下创建页面 `待确认事项` |
 | 当前 EPIC 下已有的 `TRD` | 推荐 | 判断是新建还是增量修订，并避免重复写 | 若没有，则进入新建模式 |
 
-## FlowUS 页面怎么找
+## Notion 页面怎么找
 
-本 skill 的正式文档读取和落地都依赖 FlowUS，不依赖本地文件。
+本 skill 的正式文档读取和落地都依赖 Notion，不依赖本地文件。
 
 进入项目文档时，固定按下面的顺序定位：
 
@@ -241,7 +241,7 @@ description: EPIC 级技术设计共创 skill。用于基于 FlowUS 中的全局
 
 ## 页面《待确认事项》处理
 
-所有 `TRD` 阶段的未决问题都统一写进 FlowUS 中“当前业务域根页面”下、标题固定为 `待确认事项` 的页面。
+所有 `TRD` 阶段的未决问题都统一写进 Notion 中“当前业务域根页面”下、标题固定为 `待确认事项` 的页面。
 
 统一格式：
 
@@ -270,7 +270,7 @@ description: EPIC 级技术设计共创 skill。用于基于 FlowUS 中的全局
 
 ### 2. 写回位置必须正确
 
-最终权威内容都写回 FlowUS：
+最终权威内容都写回 Notion：
 
 - EPIC 级技术设计写入当前 EPIC 页面下的 `TRD`
 - 未决问题写入当前业务域根页面下的页面 `待确认事项`

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

@@ -1,6 +1,6 @@
 # TRD 输出模板
 
-使用本模板组织并写入 FlowUS 中当前 EPIC 页面下的 `TRD` 页面。
+使用本模板组织并写入 Notion 中当前 EPIC 页面下的 `TRD` 页面。
 
 这份模板是仓库内的写作辅助，不是最终落地文档。
 最终权威内容必须写回当前 EPIC 页面下的 `TRD` 页面。

package/payload/skills/uat/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: uat
-description: EPIC 级验收文档共创 skill。用于基于 FlowUS 中的全局资源、当前 EPIC 的 PRD、TRD 和页面《待确认事项》，逐步收敛出人工可执行的 UAT。当用户提到“写 UAT”“生成验收手册”“这个 EPIC 怎么验收”“补测试场景/回归指引/签字页”“改现有 UAT”时必须使用。
+description: EPIC 级验收文档共创 skill。用于基于 Notion 中的全局资源、当前 EPIC 的 PRD、TRD 和页面《待确认事项》，逐步收敛出人工可执行的 UAT。当用户提到“写 UAT”“生成验收手册”“这个 EPIC 怎么验收”“补测试场景/回归指引/签字页”“改现有 UAT”时必须使用。
 ---
 
 # EPIC 级验收文档共创
@@ -9,14 +9,14 @@ description: EPIC 级验收文档共创 skill。用于基于 FlowUS 中的全局
 
 你是 Odoo Forge 的 EPIC 级验收文档专家。
 
-你的职责不是写“测试理论”，而是把某个 EPIC 的验收步骤、前置数据、角色操作和预期结果逐步讨论清楚，再把确认过的结论沉淀成 FlowUS 中的 `UAT` 页面。
+你的职责不是写“测试理论”，而是把某个 EPIC 的验收步骤、前置数据、角色操作和预期结果逐步讨论清楚，再把确认过的结论沉淀成 Notion 中的 `UAT` 页面。
 
 你的核心价值：
 
 - 把 `PRD` 和 `TRD` 翻译成任何人都能照着执行的验收手册
 - 先覆盖主路径，再覆盖边界、权限、自动化和回归
 - 让测试、PM、客户、开发都能直接用
-- 只把已经讨论并确认的验收结论写回 FlowUS
+- 只把已经讨论并确认的验收结论写回 Notion
 
 ## 什么时候使用
 
@@ -45,9 +45,9 @@ description: EPIC 级验收文档共创 skill。用于基于 FlowUS 中的全局
 | 当前业务域根页面下的页面 `待确认事项` | 推荐 | 恢复当前未决问题，避免把伪共识写进 `UAT` | 若没有，则先在当前业务域根页面下创建页面 `待确认事项` |
 | 当前 EPIC 下已有的 `UAT` | 推荐 | 判断是新建还是增量修订，并避免重复写 | 若没有，则进入新建模式 |
 
-## FlowUS 页面怎么找
+## Notion 页面怎么找
 
-本 skill 的正式文档读取和落地都依赖 FlowUS，不依赖本地文件。
+本 skill 的正式文档读取和落地都依赖 Notion，不依赖本地文件。
 
 进入项目文档时，固定按下面的顺序定位：
 
@@ -224,7 +224,7 @@ description: EPIC 级验收文档共创 skill。用于基于 FlowUS 中的全局
 
 被调用时：
 
-- 直接读取 FlowUS 上下文
+- 直接读取 Notion 上下文
 - 优先完成产出
 - 如果发现不明确项，继续完成主体内容，再把问题写入页面 `待确认事项`
 
@@ -241,7 +241,7 @@ description: EPIC 级验收文档共创 skill。用于基于 FlowUS 中的全局
 
 ## 页面《待确认事项》处理
 
-所有 `UAT` 阶段的未决问题都统一写进 FlowUS 中“当前业务域根页面”下、标题固定为 `待确认事项` 的页面。
+所有 `UAT` 阶段的未决问题都统一写进 Notion 中“当前业务域根页面”下、标题固定为 `待确认事项` 的页面。
 
 统一格式：
 
@@ -270,7 +270,7 @@ description: EPIC 级验收文档共创 skill。用于基于 FlowUS 中的全局
 
 ### 2. 写回位置必须正确
 
-最终权威内容都写回 FlowUS：
+最终权威内容都写回 Notion：
 
 - EPIC 级验收文档写入当前 EPIC 页面下的 `UAT`
 - 未决问题写入当前业务域根页面下的页面 `待确认事项`

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

@@ -1,6 +1,6 @@
 # UAT 输出模板
 
-使用本模板组织并写入 FlowUS 中当前 EPIC 页面下的 `UAT` 页面。
+使用本模板组织并写入 Notion 中当前 EPIC 页面下的 `UAT` 页面。
 
 这份模板是仓库内的写作辅助，不是最终落地文档。
 最终权威内容必须写回当前 EPIC 页面下的 `UAT` 页面。

package/payload/platforms/claude/hooks.template.json

@@ -1,15 +0,0 @@
-{
-  "hooks": {
-    "PreToolUse": [
-      {
-        "matcher": "mcp__flowus__delete_block",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "echo '⚠️  即将删除 FlowUS block，此操作不可撤销。'"
-          }
-        ]
-      }
-    ]
-  }
-}

package/payload/platforms/claude/mcp.template.json

@@ -1,9 +0,0 @@
-{
-  "mcpServers": {
-    "flowus": {
-      "type": "stdio",
-      "command": "odoo-forge",
-      "args": ["mcp", "flowus"]
-    }
-  }
-}

package/payload/platforms/claude/plugin.template.json

@@ -1,8 +0,0 @@
-{
-  "name": "odoo-forge",
-  "version": "0.1.9",
-  "description": "Internal Odoo Forge plugin for Claude Code.",
-  "author": {
-    "name": "Internal Team"
-  }
-}

package/payload/platforms/claude/settings.template.json

@@ -1,3 +0,0 @@
-{
-  "agent": "navigator"
-}

package/payload/platforms/codex/mcp.template.json

@@ -1,12 +0,0 @@
-{
-  "mcpServers": {
-    "flowus": {
-      "type": "stdio",
-      "command": "odoo-forge",
-      "args": [
-        "mcp",
-        "flowus"
-      ]
-    }
-  }
-}

package/payload/platforms/codex/plugin.template.json

@@ -1,19 +0,0 @@
-{
-  "name": "odoo-forge",
-  "version": "0.1.9",
-  "description": "Odoo skill suite for Codex and Claude Code.",
-  "skills": "./skills",
-  "mcpServers": "./.mcp.json",
-  "interface": {
-    "displayName": "Odoo Forge",
-    "shortDescription": "Odoo delivery skills",
-    "longDescription": "Unified Odoo delivery skills and platform wiring for Codex and Claude Code.",
-    "developerName": "Internal Team",
-    "category": "Productivity",
-    "capabilities": [
-      "Skills",
-      "MCP"
-    ],
-    "websiteURL": "https://example.internal/odoo-forge"
-  }
-}