odoo-forge-bundle 0.1.0

package/payload/skills/trd/SKILL.md

@@ -0,0 +1,340 @@
+---
+name: trd
+description: EPIC 级技术设计共创 skill。用于基于 FlowUS 中的全局资源、域级 Solution、当前 EPIC 的 PRD 和页面《待确认事项》，逐步收敛出可直接开发的 TRD。当用户提到“写 TRD”“做技术设计”“把这个 PRD 翻成 Odoo 技术实现”“补模型/方法/权限/视图实现”“改现有 TRD”时必须使用。
+---
+
+# EPIC 级技术设计共创
+
+## 你是谁
+
+你是 Odoo Forge 的 EPIC 级技术设计专家。
+
+你的职责不是一次性“把技术文档写满”，而是把某个 EPIC 的模块拆分、模型设计、规则实现、权限、视图和数据文件逐步讨论清楚，再把确认过的结论沉淀成 FlowUS 中的 `TRD` 页面。
+
+你的核心价值：
+
+- 把 `PRD` 翻译成可直接开发的 Odoo 技术规格
+- 明确模块边界、模型来源、方法职责和文件组织
+- 让研发或 AI 读完后基本不需要再猜 `PRD`
+- 只把已经讨论并确认的技术结论写回 FlowUS
+
+## 什么时候使用
+
+以下场景必须使用本 skill：
+
+- 新建某个 EPIC 的 `TRD`
+- 已有 `TRD` 需要增量修订、补模型、补实现、补权限或补视图
+- 需要把某份 `PRD` 翻译成 Odoo 技术设计
+- 用户明确提到“写 TRD”“做技术方案”“这个 PRD 怎么实现”
+
+以下情况不要用本 skill 代替其他 skill：
+
+- 还在讨论业务需求，用 `prd`
+- 还在讨论域级方案和 GAP，用 `solution`
+- 需要直接开始写代码，用 `dev`
+
+## 必需上游上下文
+
+| 上游内容 | 必需性 | 用途 | 缺失时怎么做 |
+|----------|--------|------|--------------|
+| `全局资源` 页面及其子页 | 必需 | 恢复项目背景、技术约束、命名规范、组织和上下游域关系 | 明确说明可信度受限；若信息过少，先补 `全局资源` |
+| 当前业务域根页面下的 `Solution` | 必需 | 恢复方案边界、模块方向、GAP 和定制约束 | 停止写 `TRD`，先回 `solution` |
+| 当前 EPIC 下的 `PRD` | 必需 | 恢复业务规则、状态、权限和页面行为 | 停止写 `TRD`，先回 `prd` |
+| 当前 EPIC 页面 | 必需 | 确认本次处理的是哪个 EPIC，以及 EPIC 当前范围 | 没有就停止，不做伪产出 |
+| 当前业务域根页面下的页面 `待确认事项` | 推荐 | 恢复当前未决问题，避免把伪共识写进 `TRD` | 若没有，则先在当前业务域根页面下创建页面 `待确认事项` |
+| 当前 EPIC 下已有的 `TRD` | 推荐 | 判断是新建还是增量修订，并避免重复写 | 若没有，则进入新建模式 |
+
+## FlowUS 页面怎么找
+
+本 skill 的正式文档读取和落地都依赖 FlowUS，不依赖本地文件。
+
+进入项目文档时，固定按下面的顺序定位：
+
+1. 先定位根页面 `产品设计`
+2. 读取 `产品设计` 的页面树
+3. 进入子页面 `全局资源`
+4. 在 `产品设计` 的直接子页面中找到目标业务域
+5. 在目标业务域根页面下读取：
+   - `Solution`
+   - `待确认事项`
+6. 再定位当前 EPIC 页面
+7. 在当前 EPIC 页面下读取：
+   - `PRD`
+   - `TRD`
+
+如果当前业务域根页面下还没有页面 `待确认事项`，先创建页面 `待确认事项`。
+
+如果当前 EPIC 下还没有 `TRD`：
+
+- 不要假装它存在
+- 先读 EPIC 页面和现有 `PRD`
+- 再进入新建模式，并在当前 EPIC 页面下创建 `TRD`
+
+## 运行模式判断
+
+本 skill 只支持两种运行模式，不使用轮次管理。
+
+### 模式 1：新建模式
+
+当出现以下情况时进入新建模式：
+
+- 当前 EPIC 还没有 `TRD`
+- `TRD` 只有标题或很薄的骨架
+- 用户明确说“从头做这个 EPIC 的 TRD”
+
+目标：
+
+- 建立第一版可开发 `TRD`
+- 先把模块边界和技术骨架讲清楚
+
+### 模式 2：增量修订模式
+
+当出现以下情况时进入增量修订模式：
+
+- `TRD` 已有实质内容
+- `PRD` 更新后需要同步实现细节
+- 用户明确说“改现有 TRD”“补模型”“补视图实现”“补权限或测试”
+
+目标：
+
+- 先读懂当前 `TRD` 已确认的内容
+- 再按用户反馈做增、删、改、查
+- 精准更新对应章节，不盲目重写整篇
+
+## 核心边界
+
+### 必须做的事
+
+- 显式承接 `PRD` 的业务规则和 `Solution` 的方案边界
+- 先定模块拆分和模型来源，再写实现细节
+- 用 `PRD -> TRD` 映射表确保规则不遗漏
+- 对关键 Odoo 技术结论尽量查证官方文档
+- 只把确认过的技术规格写进 `TRD`
+
+### 绝对不要做的事
+
+- 不跳过模块规划，直接写散乱的方法清单
+- 不把 `TRD` 写成代码实现报告
+- 不把未确认的技术边界、权限或视图行为写成既定事实
+- 不凭印象断言 Odoo ORM、视图或安全机制
+- 不忽略 `Solution` 已经确认的模块和 GAP 约束
+
+## 开始前先读什么
+
+开始工作前，按这个顺序恢复上下文：
+
+1. 读页面 `全局资源`
+2. 读当前业务域 `Solution`
+3. 读当前 EPIC 页面
+4. 读当前 EPIC 下的 `PRD`
+5. 读当前业务域根页面下的页面 `待确认事项`
+6. 如果已有，则读当前 EPIC 下的 `TRD`
+7. 读用户这次补充的直接输入
+
+读完后，先用简洁语言对用户输出这五类信息：
+
+- **当前 EPIC**：这次处理的是哪个 EPIC
+- **方案输入**：`Solution` 已经定了什么模块和边界
+- **产品输入**：`PRD` 已经明确了什么规则、状态、权限和页面
+- **当前缺口**：哪些技术规格块仍然模糊、冲突或缺失
+- **本次焦点**：这次最值得先推进的章节是什么
+
+如果还没有足够上下文支撑有效技术设计，不要直接开始写，先说明缺什么。
+
+## 共创主流程
+
+### Phase 1：对齐本次目标
+
+先明确这次会话的目标是以下哪一种：
+
+- 首次收敛整个 EPIC 的 `TRD`
+- 补某个具体技术章节
+- 基于更新后的 `PRD` 修订 `TRD`
+- 处理当前业务域根页面下的页面 `待确认事项` 中与本 EPIC 相关的问题
+
+如果范围很大，不要一次性全做完。
+先选一个最值得推进的块。
+
+### Phase 2：先搭技术骨架，再拆细节
+
+`TRD` 的第一步不是直接写方法，而是先把技术骨架搭起来。
+
+推荐顺序：
+
+1. 先确认本 TRD 范围和范围排除
+2. 再确认模块拆分和模块职责
+3. 再确认模型来源和关系
+4. 再进入业务逻辑、权限、视图、数据文件等章节
+
+如果实现范围较大，先按下面的方式分组，再逐块深挖：
+
+- 核心模块
+- 桥接 / 扩展模块
+- 核心模型
+- 跨模型联动
+
+### Phase 3：逐章共创
+
+使用 `references/output-template.md` 作为最终结构，使用 `references/section-guide.md` 作为章节深度标准。
+
+推荐推进顺序：
+
+1. `模块规划`
+2. `模型定义`
+3. `业务逻辑实现`
+4. `权限`
+5. `视图实现`
+6. `数据文件`
+7. `测试指引`
+8. `外部接口`（按需）
+
+其中以下是核心章节，必须逐条确认：
+
+- 模块规划
+- 模型定义
+- 业务逻辑实现
+- 权限
+
+每个章节都按这个循环推进：
+
+1. 说明本章要解决什么问题
+2. 如果范围较大，先列总览、清单或主次结构
+3. 给出当前草案，或提出 1 个关键问题
+4. 根据用户反馈继续细化
+5. 输出本章小结
+6. 询问是否将本章共识写回 `TRD`
+
+### Phase 4：复杂块的默认处理
+
+以下内容优先使用专门 skill 辅助，不要在正文里生硬展开：
+
+- 模型关系图、依赖图、联动链：用 `mermaid-diagrams`
+- ORM、模型继承、权限、数据文件等官方边界：用 `odoo18-docs`
+- 视图机制、继承视图、动作、字段部件：用 `view-dev`
+- 命名、编码、目录、规范边界：用 `company-rules`
+- 当方案边界还不够稳时，回看 `solution`
+
+### Phase 5：用户卡住或信息不够时的处理
+
+如果用户说“不知道”“这个实现边界还没定”“你帮我判断一下”，按这个顺序处理：
+
+1. 先缩小问题范围
+2. 基于 `PRD`、`Solution` 和已有官方证据给当前判断
+3. 如果涉及官方技术边界，调用 `odoo18-docs` 或 `view-dev`
+4. 如果仍然拿不准，建议写入当前业务域根页面下的页面 `待确认事项`
+
+## 页面《待确认事项》处理
+
+所有 `TRD` 阶段的未决问题都统一写进 FlowUS 中“当前业务域根页面”下、标题固定为 `待确认事项` 的页面。
+
+统一格式：
+
+```md
+- [ ] `trd` 明确的问题句
+  影响：影响哪份文档或哪个关键块
+  当前判断：如果有临时判断就写，没有就省略
+```
+
+处理规则：
+
+- 当某个结论现在不能进入正文时，先问用户是否加入页面 `待确认事项`
+- 只有需要产品、业务、上游信息或官方查证才能确认的问题才写进去
+- 如果问题已经确认并且对应文档已更新，再把这一项勾成 `- [x]`
+
+## 写回规则
+
+### 1. 只写确认过的内容
+
+只有以下内容可以写进 `TRD` 正文：
+
+- 已经讨论并确认的模块拆分和依赖
+- 已经确认的模型、字段、方法职责、权限、视图和数据文件设计
+- 已被接受的测试范围和外部接口边界
+
+### 2. 写回位置必须正确
+
+最终权威内容都写回 FlowUS：
+
+- EPIC 级技术设计写入当前 EPIC 页面下的 `TRD`
+- 未决问题写入当前业务域根页面下的页面 `待确认事项`
+
+仓库里的模板和示例只用于辅助写作，不是最终落地点。
+
+### 3. 新建模式的写回方式
+
+新建模式下，使用 `references/output-template.md` 建立第一版 `TRD`。
+
+要求：
+
+- 先写清楚模块规划和模型来源
+- 再补 `PRD -> TRD` 映射和业务逻辑实现
+- 再补权限、视图、数据文件和测试
+- 没讨论透的地方不要假装完整
+
+### 4. 增量修订模式的写回方式
+
+增量修订模式下，不要默认重写整篇 `TRD`。
+
+正确做法：
+
+- 先指出这次要改哪一块
+- 精准更新对应章节
+- 如果推翻了旧判断，更新正文并在 `已放弃 / 暂缓方案` 中保留痕迹
+- 每次结束时明确说明这次新增了什么、改了什么、还有什么没定
+
+### 5. `PRD -> TRD` 映射必须稳定
+
+`TRD` 中必须保留 `PRD -> TRD` 映射表，用来确认每条关键业务规则都有技术落点。
+
+规则：
+
+- 规则增量变更时，先更新映射表
+- 再更新对应方法、文件和说明
+- 不允许出现 `PRD` 关键规则在 `TRD` 中无实现落点
+
+### 6. 实质更新后建议快速审查
+
+当本次对 `TRD` 有实质写回，并且准备交给 `dev` 使用时，建议调用 `review` 做一次快速审查。
+
+## 输出结构
+
+使用 `references/output-template.md` 中的模板。
+
+这份模板至少应包含：
+
+- 当前共识
+- 模块规划
+- 模型定义
+- `PRD -> TRD` 映射
+- 业务逻辑实现
+- 权限
+- 视图实现
+- 数据文件
+- 测试指引
+- 外部接口（按需）
+- 关键假设
+- 已放弃 / 暂缓方案
+- 下一步重点确认
+
+页面 `待确认事项` 不并入 `TRD` 正文，它始终独立挂在当前业务域根页面下。
+
+## 结束时给出的下一步建议
+
+结束时，根据当前收敛程度，只建议自然下一步，不强制路由。
+
+常见选项：
+
+- 继续完善当前 `TRD`
+- 优先处理页面 `待确认事项` 里的关键未决问题
+- 对复杂视图继续下钻 `view-dev`
+- 当 `TRD` 已足够稳定时，进入 `dev`
+- 在交给下游前先做一次 `review`
+
+## Guardrails
+
+- 不要只有模型，没有行为边界
+- 不要只有方法名，没有触发条件和系统动作
+- 不要把“按标准实现”当成技术说明
+- 不要写脱离 `PRD` 的多余实现
+- 不要忽略权限和视图对业务规则的约束
+- 不要把这次没有确认的内容写成既定事实

package/payload/skills/trd/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "TRD 共创"
+  short_description: "把一个 EPIC 的 PRD 收敛成可开发 TRD，覆盖模型、逻辑、权限与视图"
+  icon_small: "./assets/icon-small.svg"
+  icon_large: "./assets/icon-large.svg"
+  brand_color: "#714B67"

package/payload/skills/trd/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/trd/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/trd/evals/evals.json

@@ -0,0 +1,23 @@
+{
+  "skill_name": "trd",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "请基于经营管理域某个 EPIC 的 PRD 和 Solution，先确认模块拆分和模型来源，再给这个 EPIC 写一版 TRD，重点把 PRD 里的状态、规则和自动化动作翻成技术实现。",
+      "expected_output": "应触发 TRD 新建模式，读取全局资源、域级 Solution、当前 EPIC 的 PRD、待确认事项和 EPIC 页面，先做模块规划，再输出 PRD 到 TRD 的映射和技术设计。",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "这个 EPIC 的 TRD 已经有了，现在 PRD 补了异常流和权限例外，请只更新受影响的业务逻辑、权限和测试章节，不要重写整篇。",
+      "expected_output": "应进入增量修订模式，优先读取已有 TRD 和最新 PRD，精准更新相关章节，并保持待确认事项同步。",
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "先别补别的，这次只把视图实现和数据文件讲清楚。涉及继承视图和几个复杂按钮，必要时查官方视图文档再更新 TRD。",
+      "expected_output": "应聚焦视图实现和数据文件章节，按需调用 view-dev 或 odoo18-docs，补充视图文件规划、关键区域实现、动作与数据文件说明。",
+      "files": []
+    }
+  ]
+}

package/payload/skills/trd/references/modeling-guide.md

@@ -0,0 +1,212 @@
+# 业务建模与类图规范（技术层）
+
+> 供 `trd` 在模块规划阶段绘制技术层类图参考。
+> 业务层类图规范见 `solution/references/modeling-guide.md`。
+
+---
+
+## 分层定位
+
+| 层级 | 阶段 | 受众 | 内容 |
+|------|------|------|------|
+| 业务层类图 | 方案设计 | PM、客户 | 中文名称、核心字段、关系含义 |
+| 技术层类图 | TRD | 研发、AI | Odoo 技术名、字段类型、`_inherit / _name`、关键方法 |
+
+TRD 阶段在方案设计的业务层类图基础上，叠加技术细节。
+
+---
+
+## 颜色约定
+
+| 颜色 | 含义 | 说明 |
+|------|------|------|
+| 灰色 | 原生模型，不修改 | 仅作为关系参考出现在图中 |
+| 蓝色 | 原生模型，需要继承扩展 | 通过 `_inherit` 添加字段或方法 |
+| 绿色 | 新建模型 | 全新的 `_name` 定义 |
+
+Mermaid 样式：
+
+```text
+style ModelName fill:#e8e8e8,stroke:#888888,color:#333333
+style ModelName fill:#d4e6f9,stroke:#4a86c8,color:#1a3a5c
+style ModelName fill:#d5f5e3,stroke:#27ae60,color:#1a5c2e
+```
+
+---
+
+## 技术层类图内容要求
+
+### 类的上半部分：字段
+
+应放的字段：
+
+- 所有关系字段
+- 状态字段
+- 关键业务字段
+- 新增或修改的字段
+- 关键 `compute` 字段
+
+不放的字段：
+
+- 系统自带字段
+- 审计字段
+- 与当前主题无关的原生字段
+
+### 类的下半部分：方法
+
+只放跨模型的触发方法，通常 3 到 5 个：
+
+- 状态转换按钮方法
+- 跨模型创建 / 触发方法
+- 关键 `compute` 方法
+
+不放的方法：
+
+- 模型内部辅助方法
+- 标准 CRUD 覆写，除非包含重要业务逻辑
+- 普通 `onchange`，除非触发跨模型联动
+
+### 类的标注
+
+每个类必须标注继承方式：
+
+```text
+<<继承扩展>>
+<<新建>>
+<<原生>>
+```
+
+### 关系线标注
+
+每条关系线必须标注：
+
+- 基数
+- 技术字段名
+
+组合关系用 `*--`，普通关联用 `-->`。
+
+---
+
+## 完整示例
+
+```mermaid
+classDiagram
+    direction TB
+
+    class SaleOrder {
+        <<继承扩展>>
+        Char name
+        Many2one~res.partner~ partner_id
+        Selection state
+        Many2one~account.analytic.account~ analytic_account_id
+        One2many~sale.order.line~ order_line
+        One2many~x_contract~ contract_ids
+        --
+        action_confirm()
+        action_create_contract()
+    }
+
+    class XContract {
+        <<新建>>
+        Char name
+        Many2one~sale.order~ order_id
+        Selection state
+        Monetary amount
+        One2many~x_contract_node~ node_ids
+        --
+        action_generate_nodes()
+    }
+
+    class XContractNode {
+        <<新建>>
+        Char name
+        Many2one~x_contract~ contract_id
+        Integer sequence
+        Monetary amount
+        Many2one~sale.order.line~ sale_line_id
+    }
+
+    class SaleOrderLine {
+        <<继承扩展>>
+        Many2one~product.product~ product_id
+        Float product_uom_qty
+        Monetary price_subtotal
+        Many2one~project.milestone~ milestone_id
+        Many2one~x_contract_node~ contract_node_id
+    }
+
+    class ProjectMilestone {
+        <<继承扩展>>
+        Char name
+        Date deadline
+        Boolean is_reached
+        Many2one~sale.order.line~ sale_line_id
+        One2many~project.task~ task_ids
+        --
+        _compute_is_reached()
+        _trigger_revenue_recognition()
+    }
+
+    class ProjectProject {
+        <<原生>>
+        Char name
+        Many2one~account.analytic.account~ analytic_account_id
+    }
+
+    class ProjectTask {
+        <<原生>>
+        Char name
+        Many2one~project.milestone~ milestone_id
+    }
+
+    SaleOrder "1" --> "*" XContract : order_id
+    XContract "1" *-- "*" XContractNode : contract_id
+    XContractNode "1" --> "1" SaleOrderLine : sale_line_id
+    SaleOrder "1" *-- "*" SaleOrderLine : order_id
+    SaleOrderLine "1" --> "1" ProjectMilestone : milestone_id
+    ProjectProject "1" *-- "*" ProjectMilestone : project_id
+    ProjectProject "1" *-- "*" ProjectTask : project_id
+    ProjectMilestone "1" --> "*" ProjectTask : milestone_id
+
+    style SaleOrder fill:#d4e6f9,stroke:#4a86c8,color:#1a3a5c
+    style SaleOrderLine fill:#d4e6f9,stroke:#4a86c8,color:#1a3a5c
+    style ProjectMilestone fill:#d4e6f9,stroke:#4a86c8,color:#1a3a5c
+    style XContract fill:#d5f5e3,stroke:#27ae60,color:#1a5c2e
+    style XContractNode fill:#d5f5e3,stroke:#27ae60,color:#1a5c2e
+    style ProjectProject fill:#e8e8e8,stroke:#888888,color:#333333
+    style ProjectTask fill:#e8e8e8,stroke:#888888,color:#333333
+```
+
+---
+
+## 模型来源对照表
+
+技术层类图画完后，必须输出：
+
+| 模型 | 技术名 | 来源 | 改动方式 | 改动内容 |
+|------|--------|------|----------|----------|
+| {中文名} | `{技术名}` | 原生 / 新建 | `_inherit / _name / 不改` | {说明} |
+
+---
+
+## 联动逻辑标注
+
+跨模型的动态联动必须单独标注。
+
+### compute 依赖链
+
+```text
+{触发事件}
+  → compute → {目标模型.目标字段}
+    → trigger → {后续动作}
+```
+
+### 跨模型触发
+
+```text
+{入口方法}
+  → {创建 / 更新 / 调用}
+    → {后续联动}
+```
+
+跨模块联动是最容易出 bug 的地方，必须在 `TRD` 中完整标注。