@jspg-ai/coding-bb 0.0.3-beta.4 → 0.0.3-beta.7

package/cbb/dev-standards/rules/cbb-ai-behavior.md

@@ -1,117 +1,119 @@
----
-trigger: always_on
----
-
-# AI 行为准则
-
-七条行为准则，减少 AI 编码常见错误。源自 [Andrej Karpathy 对 LLM 编码缺陷的观察](https://x.com/karpathy/status/2015883857489522876)。
-
-**权衡：** 这些准则倾向于谨慎而非速度。对于简单任务（如修 typo、改文案），按常识判断即可。
-
-## 1. 先想后写
-
-**不假设，不隐藏困惑，主动呈现权衡。**
-
-实现前：
-- 明确声明假设，不确定时主动询问
-- 若存在多种解释，呈现出来而非自己默默选一种
-- 若有更简单的方案，说出来，必要时 push back
-- 若有不明确的地方，停下来，说出困惑，请求澄清
-
-## 2. 简洁至上
-
-**用最少代码解决问题，不加推测性内容。**
-
-- 不实现用户未要求的功能
-- 不为单次使用的代码创建抽象
-- 不添加用户未要求的"灵活性"或"可配置性"
-- 不为不可能发生的场景写错误处理
-- 写了 200 行却发现 50 行就能搞定 → 重写
-
-自问："资深工程师会说过度设计吗？"如果会，简化。
-
-## 3. 外科手术式修改
-
-**只改必须改的，只清理自己造成的烂摊子。**
-
-编辑已有代码时：
-- 不顺手"改进"相邻代码、注释或格式
-- 不重构没坏的东西
-- 匹配现有风格，即使你更习惯另一种写法
-- 发现无关的死代码，口头提及即可，不要删除
-
-当你的改动产生孤儿代码时：
-- 删除因你的改动而不再使用的 import / 变量 / 函数
-- 不删除已有的死代码，除非用户要求
-
-**检验标准：** 每一行改动都应该能追溯到用户的需求。
-
-## 4. 目标驱动执行
-
-**定义成功标准，循环直到验证通过。**
-
-将命令式任务转换为可验证的目标：
-
-| 而非… | 转换为… |
-|--------|---------|
-| "加个校验" | "先写无效输入的测试，再让测试通过" |
-| "修这个 bug" | "先写能复现的测试，再修到测试通过" |
-| "重构 X" | "确保重构前后测试全部通过" |
-
-多步任务先给简短计划：
-```
-1. [步骤] → 验证: [检查项]
-2. [步骤] → 验证: [检查项]
-3. [步骤] → 验证: [检查项]
-```
-
-清晰的成功标准让 AI 可以独立循环验证，模糊的标准（"搞一下"）需要反复澄清。
-
-## 5. 失败要大声说出来
-
-**悄悄绕过失败比直接失败更糟糕。**
-
-- 有步骤被跳过，"完成"就是错的——说出来
-- 有测试被跳过，"测试通过"就是错的——说出来
-- 不确定就直接说不确定，不假装确认
-- 默认暴露不确定性，不掩盖
-
-**检验标准：** 任何跳过的步骤、不确定的结论、未验证的结果，都以标记形式呈现，不悄悄带过。
-
-## 6. 不认同也要说出来
-
-当项目现有约定明显有问题时：
-
-- 照样遵循，保持一致——不悄悄另起炉灶
-- 明确提出来——指出风险，给出替代方案
-- 让用户做决策，不要替用户做选择
-
-**检验标准：** 你的代码放进现有代码中，读不出"换了一个人写的"。发现的问题以建议形式呈现，而非悄悄用另一种方式实现。
-
-## 7. 先批准，后动工
-
-**任何实现动作前，先陈述方案并获得用户批准。**
-
-- 动手前说出打算怎么做（方案、涉及文件、验证方式），等用户确认
-- 仪式随任务缩放：小改动两三句话说清即可；大改动走 openspec 工作流（propose → specs → design）
-- "太简单不需要方案"是最危险的念头——简单意味着方案短，而不是没有方案
-- 中途发现复杂度超出预期：停下来重新说明，不要闷头扩大改动范围
-
-**检验标准：** 用户从未因"AI 直接改了代码没打招呼"而感到意外。
-
-## 8. 业务空间目录纪律
-
-**仅当工作目录是业务空间根（存在 `workspace-config.json`）时生效：写操作命令必须落在需求工作树内。**
-
-业务空间根（主分支）只负责组织与调度，不做需求开发。接到需求先建工作树（`/cbb:worktree-init` 或 `/cbb-worktree-init`），之后：
-
-- 一切产生写操作的命令（git commit / openspec / 构建 / 测试 / 文件修改）必须以 `.worktrees/worktree-<需求名>/`（或其应用子目录）为工作目录：显式 `cd` 或绝对路径
-- 禁止在空间根执行写操作：不在主分支提交代码、不在空间根创建 openspec 变更产物、不改 `.codespace/` 基准代码
-- 只读命令（git status / log、查看文件）在空间根执行无妨
-- 会话开始时确认本次需求对应的工作树路径；存在多个未完成工作树时，先与用户确认目标，不要猜
-
-**检验标准：** 空间根主分支的 `git status` 永远干净（除工具维护的配置文件外），openspec 变更产物只出现在需求工作树内。
-
----
-
+---
+trigger: always_on
+---
+
+# AI 行为准则
+
+七条行为准则，减少 AI 编码常见错误。源自 [Andrej Karpathy 对 LLM 编码缺陷的观察](https://x.com/karpathy/status/2015883857489522876)。
+
+**权衡：** 这些准则倾向于谨慎而非速度。对于简单任务（如修 typo、改文案），按常识判断即可。
+
+## 1. 先想后写
+
+**不假设，不隐藏困惑，主动呈现权衡。**
+
+实现前：
+- 明确声明假设，不确定时主动询问
+- 若存在多种解释，呈现出来而非自己默默选一种
+- 若有更简单的方案，说出来，必要时 push back
+- 若有不明确的地方，停下来，说出困惑，请求澄清
+
+## 2. 简洁至上
+
+**用最少代码解决问题，不加推测性内容。**
+
+- 不实现用户未要求的功能
+- 不为单次使用的代码创建抽象
+- 不添加用户未要求的"灵活性"或"可配置性"
+- 不为不可能发生的场景写错误处理
+- 写了 200 行却发现 50 行就能搞定 → 重写
+
+自问："资深工程师会说过度设计吗？"如果会，简化。
+
+## 3. 外科手术式修改
+
+**只改必须改的，只清理自己造成的烂摊子。**
+
+编辑已有代码时：
+- 不顺手"改进"相邻代码、注释或格式
+- 不重构没坏的东西
+- 匹配现有风格，即使你更习惯另一种写法
+- 发现无关的死代码，口头提及即可，不要删除
+
+当你的改动产生孤儿代码时：
+- 删除因你的改动而不再使用的 import / 变量 / 函数
+- 不删除已有的死代码，除非用户要求
+
+**检验标准：** 每一行改动都应该能追溯到用户的需求。
+
+## 4. 目标驱动执行
+
+**定义成功标准，循环直到验证通过。**
+
+将命令式任务转换为可验证的目标：
+
+| 而非… | 转换为… |
+|--------|---------|
+| "加个校验" | "先写无效输入的测试，再让测试通过" |
+| "修这个 bug" | "先写能复现的测试，再修到测试通过" |
+| "重构 X" | "确保重构前后测试全部通过" |
+
+多步任务先给简短计划：
+```
+1. [步骤] → 验证: [检查项]
+2. [步骤] → 验证: [检查项]
+3. [步骤] → 验证: [检查项]
+```
+
+清晰的成功标准让 AI 可以独立循环验证，模糊的标准（"搞一下"）需要反复澄清。
+
+## 5. 失败要大声说出来
+
+**悄悄绕过失败比直接失败更糟糕。**
+
+- 有步骤被跳过，"完成"就是错的——说出来
+- 有测试被跳过，"测试通过"就是错的——说出来
+- 不确定就直接说不确定，不假装确认
+- 默认暴露不确定性，不掩盖
+
+**检验标准：** 任何跳过的步骤、不确定的结论、未验证的结果，都以标记形式呈现，不悄悄带过。
+
+## 6. 不认同也要说出来
+
+当项目现有约定明显有问题时：
+
+- 照样遵循，保持一致——不悄悄另起炉灶
+- 明确提出来——指出风险，给出替代方案
+- 让用户做决策，不要替用户做选择
+
+**检验标准：** 你的代码放进现有代码中，读不出"换了一个人写的"。发现的问题以建议形式呈现，而非悄悄用另一种方式实现。
+
+## 7. 先批准，后动工
+
+**任何实现动作前，先陈述方案并获得用户批准。**
+
+- 动手前说出打算怎么做（方案、涉及文件、验证方式），等用户确认
+- 仪式随任务缩放：小改动两三句话说清即可；大改动走 openspec 工作流（propose → specs → design）
+- "太简单不需要方案"是最危险的念头——简单意味着方案短，而不是没有方案
+- 中途发现复杂度超出预期：停下来重新说明，不要闷头扩大改动范围
+
+**检验标准：** 用户从未因"AI 直接改了代码没打招呼"而感到意外。
+
+## 8. 业务空间目录纪律
+
+**仅当工作目录是业务空间根（存在 `workspace-config.json`）时生效：写操作命令必须落在需求工作树内。**
+
+业务空间根（主分支）只负责组织与调度，不做需求开发。接到需求先建工作树（`/cbb:worktree-init` 或 `/cbb-worktree-init`），之后：
+
+- 一切产生写操作的命令（git commit / openspec / 构建 / 测试 / 文件修改）必须以 `.worktrees/worktree-<需求名>/`（或其应用子目录）为工作目录：显式 `cd` 或绝对路径
+- 禁止在空间根执行写操作：不在主分支提交代码、不在空间根创建 openspec 变更产物、不改 `.codespace/` 基准代码
+- 只读命令（git status / log、查看文件）在空间根执行无妨
+- 会话开始时确认本次需求对应的工作树路径；存在多个未完成工作树时，先与用户确认目标，不要猜
+
+**会话与工作目录是两回事：** AI 会话窗口始终停在**空间根**（worktree 内不装 AI 配置，无工作流命令），`/opsx:*` 等命令仍在空间根会话发起；只是**产生写操作的工作目录**指向需求工作树（显式 `cd` 或绝对路径）。不要把会话切到 worktree 内，也不要因「在 worktree 内开发」就在空间根直接动手。
+
+**检验标准：** 空间根主分支的 `git status` 永远干净（除工具维护的配置文件外），openspec 变更产物只出现在需求工作树内。
+
+---
+
 **这些准则生效的标志：** diff 中不必要的改动减少、不会因过度设计而重写、澄清问题在实现前而非出错后提出。

package/cbb/lib/install/codebuddy.js

@@ -0,0 +1,32 @@
+/**
+ * WorkBuddy / CodeBuddy 适配器
+ *
+ * 腾讯 WorkBuddy 桌面工作台与 CodeBuddy IDE / CLI 共用项目级配置目录 `.codebuddy/`，
+ * 故一个适配器同时覆盖两者。
+ *
+ * 与 Claude Code / Qoder 的映射差异：
+ * - rules：`.codebuddy/rules/*.md`（扁平文件、递归加载），frontmatter 用
+ *   `alwaysApply: true`（Qoder 的 `trigger: always_on` 需改写，见 ruleRewrites）
+ * - skills：`.codebuddy/skills/<name>/SKILL.md`，结构与 Claude 同构
+ * - commands：`.codebuddy/commands/`，支持目录嵌套（`/group:command`），与 Claude 同风格
+ * - hooks：完全兼容 Claude Code Hooks 规范，settings 结构一致，直接复用 settingsManager
+ */
+
+const path = require('path');
+const os = require('os');
+
+module.exports = {
+  name: 'codebuddy',
+  displayName: 'WorkBuddy（CodeBuddy）',
+  rulesDir: '.codebuddy/rules',
+  skillsDir: '.codebuddy/skills',
+  commandsDir: '.codebuddy/commands/opsx',
+  // worktree 管理命令（非 openspec 上游）：独立命名空间 /cbb:worktree-*
+  worktreeCommandsDir: '.codebuddy/commands/cbb',
+  // 规则 frontmatter 改写：Qoder 风格 → CodeBuddy 风格
+  ruleRewrites: [['trigger: always_on', 'alwaysApply: true']],
+  // 用户级 settings，写入全局生效，不污染项目目录
+  settingsFile: path.join(os.homedir(), '.codebuddy', 'settings.json'),
+  settingsFileIsUserLevel: true,
+  hookEvents: ['UserPromptSubmit'],
+};

package/cbb/lib/install/init.js

@@ -4,7 +4,8 @@
  * OpenSpec Shared Standards 安装脚本
  *
  * 将AI 编码规范与工作流套件安装到目标项目中。
- * 支持工具：Claude Code (.claude/rules/)、Qoder (.qoder/rules/)、opencode (.opencode/rules/)
+ * 支持工具：Claude Code (.claude/rules/)、Qoder (.qoder/rules/)、opencode (.opencode/rules/)、
+ *          WorkBuddy/CodeBuddy (.codebuddy/rules/)、TraeWork/TraeCode (.trae/rules/)
  *
  * 使用方式：
  *   npm install -g @jspg-ai/coding-bb  # 首次使用
@@ -51,14 +52,17 @@ const MANIFEST_FILE = path.join(MANIFEST_DIR, '.managed-by-cbb');
 const LAST_TOOLS_FILE = path.join(MANIFEST_DIR, '.last-tools');
 
 // 适配器
+// 适配器（数组顺序 = 工具选择面板的显示顺序）
 const adapters = [
-  require('./claude-code'),
-  require('./qoder'),
   require('./opencode'),
+  require('./codebuddy'),
+  require('./trae'),
+  require('./qoder'),
+  require('./claude-code'),
 ];
 
-// superpowers 部署白名单：仅装 openspec 工作流硬依赖 + 方法论基底（源仓库仍保留全量 14 个，
-// 供 cbb update --upstream-superpowers 维护；砍掉的与 openspec 工作流重叠或属低频场景）
+// superpowers 部署白名单：仅装 openspec 工作流硬依赖 + 方法论基底（源仓库仍保留全量 15 个，
+// 供 cbbm update --upstream-superpowers 维护；砍掉的与 openspec 工作流重叠或属低频场景）
 const SUPERPOWERS_WHITELIST = [
   'writing-plans',                  // openspec apply：生成 plan.md（schema.yaml 引用）
   'subagent-driven-development',    // openspec apply：执行 plan.md（schema.yaml 引用）
@@ -83,9 +87,17 @@ const OPENSPEC_COMMANDS_EXCLUDE = ['onboard.md'];
 // settings.json hook 工具
 const settingsManager = require('../utils/settings');
 
+/** 适配器的 hook 方言参数（Trae 需顶层 version 字段等差异） */
+function hookOpts(adapter) {
+  return adapter.hookDialect ? { dialect: adapter.hookDialect } : {};
+}
+
 // 清单驱动的文件清理决策（保护用户文档 CLAUDE.md / AGENTS.md 等）
 const { pathsToDelete, protectedKeptPaths } = require('./cleanup');
 
+// 规则 frontmatter 改写（Trae/CodeBuddy 需 alwaysApply: true）
+const { applyRuleRewrites } = require('./rule-rewrite');
+
 // .gitignore 条目决策（纯函数：检测/写入/卸载移除）
 const gitignore = require('../utils/gitignore');
 
@@ -306,7 +318,8 @@ function deployCoreRules(adapter, isUpgrade, managedPaths) {
       // 同名文件存在时直接覆盖
       removePath(destPath);
 
-      fs.writeFileSync(destPath, fs.readFileSync(srcPath, 'utf-8'));
+      const content = applyRuleRewrites(adapter, fs.readFileSync(srcPath, 'utf-8'));
+      fs.writeFileSync(destPath, content);
     }
   });
 
@@ -1128,9 +1141,9 @@ async function init(targetDir, options = {}) {
       const settingsPath = adapter.settingsFileIsUserLevel
         ? adapter.settingsFile
         : path.join(TARGET_DIR, adapter.settingsFile);
-      settingsManager.addHooks(settingsPath, command, adapter.hookEvents);
+      settingsManager.addHooks(settingsPath, command, adapter.hookEvents, hookOpts(adapter));
       // 清理旧版本遗留的 SessionStart hook（现已仅安装 UserPromptSubmit）
-      if (settingsManager.removeLegacyHooks(settingsPath)) {
+      if (settingsManager.removeLegacyHooks(settingsPath, hookOpts(adapter))) {
         log(`清理 ${adapter.displayName} 遗留的 SessionStart hook`, 'success');
       }
       if (!adapter.settingsFileIsUserLevel) newPaths.add(adapter.settingsFile);
@@ -1739,8 +1752,8 @@ async function setupUserLevelComponents(targetAdapters = adapters) {
   if (hookAdapters.length > 0) {
     const command = settingsManager.getCheckUpdateCommand();
     hookAdapters.forEach(adapter => {
-      settingsManager.addHooks(adapter.settingsFile, command, adapter.hookEvents);
-      settingsManager.removeLegacyHooks(adapter.settingsFile);
+      settingsManager.addHooks(adapter.settingsFile, command, adapter.hookEvents, hookOpts(adapter));
+      settingsManager.removeLegacyHooks(adapter.settingsFile, hookOpts(adapter));
     });
     summaryParts.push(`版本检查 hook → ${hookAdapters.map(a => a.displayName).join('、')}`);
   }
@@ -1856,7 +1869,7 @@ async function uninstallUserLevelComponents() {
   // 移除版本检查 hook（保留用户其余配置）
   adapters.forEach(adapter => {
     if (!adapter.settingsFile || !adapter.hookEvents) return;
-    if (settingsManager.removeHooks(adapter.settingsFile, adapter.hookEvents)) {
+    if (settingsManager.removeHooks(adapter.settingsFile, adapter.hookEvents, hookOpts(adapter))) {
       log(`${adapter.settingsFile}: 移除版本检查 hook，保留用户配置`, 'success');
     }
   });
@@ -1887,7 +1900,7 @@ async function uninstall() {
   // 是否同时卸载用户级组件（工具 skills + 版本检查 hook，作用于 ~/.claude 等用户目录）
   let removeUserLevel = false;
   if (fs.existsSync(USER_MANIFEST_FILE)) {
-    const answerUser = await ask('是否同时卸载用户级组件（~/.claude、~/.qoder 的版本检查 hook）？(y/N): ');
+    const answerUser = await ask('是否同时卸载用户级组件（~/.claude、~/.qoder、~/.codebuddy、~/.trae-cn 的版本检查 hook）？(y/N): ');
     removeUserLevel = answerUser.toLowerCase() === 'y' || answerUser.toLowerCase() === 'yes';
   }
 
@@ -1906,11 +1919,11 @@ async function uninstall() {
       : path.join(TARGET_DIR, adapter.settingsFile);
     // 项目级：需在清单中才处理
     if (!adapter.settingsFileIsUserLevel && !managedPaths.has(adapter.settingsFile)) return;
-    if (removeUserLevel && settingsManager.removeHooks(settingsPath, adapter.hookEvents)) {
+    if (removeUserLevel && settingsManager.removeHooks(settingsPath, adapter.hookEvents, hookOpts(adapter))) {
       log(`${adapter.settingsFile}: 移除版本检查 hook，保留用户配置`, 'success');
     }
     // 清理旧版本遗留的 SessionStart hook（无版本差异，无条件清理）
-    if (settingsManager.removeLegacyHooks(settingsPath)) {
+    if (settingsManager.removeLegacyHooks(settingsPath, hookOpts(adapter))) {
       log(`${adapter.settingsFile}: 清理遗留 SessionStart hook`, 'success');
     }
     skippedPaths.add(adapter.settingsFile);
@@ -1968,11 +1981,50 @@ async function uninstall() {
   console.log(`\n✅ 卸载完成！共移除 ${removed} 个文件/目录\n`);
 }
 
+// ── 上游版本检查 ──────────────────────────────────────────────
+
+/**
+ * 检查 openspec / superpowers 是否有上游新版本（只读，不改动任何文件）。
+ * 供 cbbm check-upstream 调用。
+ */
+async function checkUpstream() {
+  const results = await Promise.allSettled([
+    openspec.checkUpstream().then(r => ({ name: 'openspec', ...r })),
+    superpowers.checkUpstream().then(r => ({ name: 'superpowers', ...r })),
+  ]);
+
+  let outdated = false;
+  for (const r of results) {
+    if (r.status === 'rejected') {
+      log(`检查失败: ${r.reason.message}`, 'error');
+      continue;
+    }
+    const { name, current, latest, outdated: isOutdated } = r.value;
+    if (!latest) {
+      log(`${name}: 无法获取上游版本`, 'warn');
+      continue;
+    }
+    if (!current) {
+      log(`${name}: 本地无 pin（上游最新 ${latest}）`, 'warn');
+      outdated = true;
+    } else if (isOutdated) {
+      log(`${name}: ${current} → ${latest}（有新版本）`, 'warn');
+      outdated = true;
+    } else {
+      log(`${name}: ${current} 已是最新`, 'success');
+    }
+  }
+
+  if (outdated) {
+    log('升级方式：修改对应 .version 的 pin 后，执行 cbbm update --upstream-openspec / --upstream-superpowers', 'info');
+  }
+}
+
 // ── CLI 入口 ──────────────────────────────────────────────
 
 // 入口身份：cbb（用户命令） / cbbm（内部命令，由流程、hook、Agent 技能调用）
 const ENTRY = process.env.CBB_ENTRY === 'cbbm' ? 'cbbm' : 'cbb';
-const INTERNAL_COMMANDS = ['check-update', 'wiki', 'wp'];
+const INTERNAL_COMMANDS = ['check-update', 'check-upstream', 'wiki', 'wp'];
 const UPSTREAM_FLAGS = ['--upstream-superpowers', '--upstream-openspec'];
 
 const args = process.argv.slice(2);
@@ -2011,11 +2063,11 @@ switch (command) {
     const upstreamSuperpowers = restArgs.includes('--upstream-superpowers');
     const upstreamOpenspec = restArgs.includes('--upstream-openspec');
     if (upstreamSuperpowers || upstreamOpenspec) {
-      // 维护者选项：从 GitHub 拉取上游原生内容到本包源仓库（发布流程用）
+      // 维护者选项：按 .version 的 pin 重新拉取上游原生内容到本包源仓库（发布流程用）
       if (upstreamSuperpowers) {
         superpowers.fetchLatestSkills().then(result => {
           if (result.skipped) {
-            log(`superpowers skills 已是最新 (${result.sha.slice(0, 8)})`, 'success');
+            log(`superpowers skills 已是最新 (${result.tag})`, 'success');
           }
           const validation = superpowers.validateSkills();
           if (!validation.valid) {
@@ -2031,22 +2083,13 @@ switch (command) {
       }
       if (upstreamOpenspec) {
         openspec.fetchLatestOpenSpec().then(result => {
-          if (!result.skipped) {
-            const validation = openspec.validateDeployed();
-            if (!validation.valid) {
-              log(`部署不完整,缺失: ${validation.missing.join(', ')}`, 'error');
-              process.exit(1);
-            }
-            log(`openspec 工作流完整性校验通过`, 'success');
-          } else {
-            const validation = openspec.validateDeployed();
-            if (!validation.valid) {
-              log(`本地 openspec 工作流不完整,请重新运行 cbb update --upstream-openspec:`, 'error');
-              for (const m of validation.missing) log(`  - 缺失 ${m}`, 'error');
-              process.exit(1);
-            }
-            log(`openspec 工作流完整性校验通过`, 'success');
+          const validation = openspec.validateDeployed();
+          if (!validation.valid) {
+            log(`部署不完整,缺失: ${validation.missing.join(', ')}`, 'error');
+            for (const m of validation.missing) log(`  - 缺失 ${m}`, 'error');
+            process.exit(1);
           }
+          log(`openspec 工作流完整性校验通过`, 'success');
         }).catch(err => {
           log(`更新失败: ${err.message}`, 'error');
           process.exit(1);
@@ -2069,6 +2112,12 @@ switch (command) {
   case 'check-update':
     require('../utils/check-update.js');
     break;
+  case 'check-upstream':
+    checkUpstream().catch(err => {
+      log(err.message, 'error');
+      process.exit(1);
+    });
+    break;
   case 'wp':
     require('../wiki/index.js').publish(restArgs);
     break;
@@ -2100,11 +2149,12 @@ function showHelp() {
 @jspg-ai/coding-bb v${pkg.version} — cbbm：内部命令（由流程 / hook / Agent 技能调用）
 
   cbbm check-update          版本检查（用户级 hook 每日自动触发）
+  cbbm check-upstream        检查 openspec / superpowers 是否有上游新版本
   cbbm wiki / cbbm wp        Wiki 查询与发布（AI 通过技能调用）
 
-维护者选项（拉取上游原生内容到本包源仓库）：
-  cbbm update --upstream-superpowers    从 GitHub 拉取最新 superpowers skills
-  cbbm update --upstream-openspec       从 GitHub 拉取最新 OpenSpec 工作流
+维护者选项（按 .version 的 pin 重新拉取上游原生内容到本包源仓库）：
+  cbbm update --upstream-superpowers    按 pin tag 拉取 superpowers skills（走镜像）
+  cbbm update --upstream-openspec       按 pin 版本从 npmmirror 渲染 OpenSpec 工作流
 `);
     return;
   }

package/cbb/lib/install/rule-rewrite.js

@@ -0,0 +1,27 @@
+'use strict';
+
+/**
+ * 规则 frontmatter 改写（纯函数，无副作用，便于单测）。
+ *
+ * 源规则（cbb/dev-standards/rules/*.md）用 Qoder 的 frontmatter 约定
+ * `trigger: always_on`。各工具对"始终生效"的字段名不同：
+ *  - Qoder：trigger: always_on（源格式）
+ *  - Claude Code / opencode：无该字段，靠各自机制加载
+ *  - WorkBuddy/CodeBuddy、Trae：alwaysApply: true
+ *
+ * 适配器通过 ruleRewrites（[[from, to], ...]）声明改写规则，部署时套用；
+ * 无 ruleRewrites 的适配器原样返回。
+ */
+
+/**
+ * 按适配器的 ruleRewrites 改写规则文本。
+ * @param {object} adapter 适配器配置
+ * @param {string} text 规则文件原文
+ * @returns {string} 改写后的文本（无 ruleRewrites 时原样返回）
+ */
+function applyRuleRewrites(adapter, text) {
+  if (!adapter || !adapter.ruleRewrites) return text;
+  return adapter.ruleRewrites.reduce((t, [from, to]) => t.split(from).join(to), text);
+}
+
+module.exports = { applyRuleRewrites };

package/cbb/lib/install/trae.js

@@ -0,0 +1,35 @@
+/**
+ * TraeWork / TraeCode 适配器
+ *
+ * 字节 TraeWork 桌面工作台与 TraeCode IDE 共用项目级配置目录 `.trae/`，
+ * 故一个适配器同时覆盖两者。
+ *
+ * 与 Claude Code / Qoder 的映射差异：
+ * - rules：`.trae/rules/*.md`（扁平文件、支持子目录，最多 3 层），frontmatter 用
+ *   `alwaysApply: true`（Qoder 的 `trigger: always_on` 需改写，见 ruleRewrites）
+ * - skills：`.trae/skills/<name>/SKILL.md`，结构与 Claude 同构
+ * - commands：`.trae/commands/`，支持目录嵌套（最多 3 层），与 Claude 同风格
+ * - hooks：`~/.trae-cn/hooks.json`，格式与 Claude 相近但需顶层 `version: 1`
+ *   （由 settingsManager 的 hookDialect 处理），事件名/输出字段一致
+ */
+
+const path = require('path');
+const os = require('os');
+
+module.exports = {
+  name: 'trae',
+  displayName: 'TraeWork（TraeCode）',
+  rulesDir: '.trae/rules',
+  skillsDir: '.trae/skills',
+  commandsDir: '.trae/commands/opsx',
+  // worktree 管理命令（非 openspec 上游）：独立命名空间 /cbb:worktree-*
+  worktreeCommandsDir: '.trae/commands/cbb',
+  // 规则 frontmatter 改写：Qoder 风格 → Trae 风格
+  ruleRewrites: [['trigger: always_on', 'alwaysApply: true']],
+  // 用户级 hooks 配置（Trae 用 hooks.json，国内版目录为 ~/.trae-cn/）
+  settingsFile: path.join(os.homedir(), '.trae-cn', 'hooks.json'),
+  settingsFileIsUserLevel: true,
+  hookEvents: ['UserPromptSubmit'],
+  // Trae 的 hooks.json 需顶层 version: 1（Claude 风格 settings.json 无此字段）
+  hookDialect: 'trae',
+};