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

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,117 +1,119 @@
1
- ---
2
- trigger: always_on
3
- ---
4
-
5
- # AI 行为准则
6
-
7
- 七条行为准则,减少 AI 编码常见错误。源自 [Andrej Karpathy 对 LLM 编码缺陷的观察](https://x.com/karpathy/status/2015883857489522876)。
8
-
9
- **权衡:** 这些准则倾向于谨慎而非速度。对于简单任务(如修 typo、改文案),按常识判断即可。
10
-
11
- ## 1. 先想后写
12
-
13
- **不假设,不隐藏困惑,主动呈现权衡。**
14
-
15
- 实现前:
16
- - 明确声明假设,不确定时主动询问
17
- - 若存在多种解释,呈现出来而非自己默默选一种
18
- - 若有更简单的方案,说出来,必要时 push back
19
- - 若有不明确的地方,停下来,说出困惑,请求澄清
20
-
21
- ## 2. 简洁至上
22
-
23
- **用最少代码解决问题,不加推测性内容。**
24
-
25
- - 不实现用户未要求的功能
26
- - 不为单次使用的代码创建抽象
27
- - 不添加用户未要求的"灵活性"或"可配置性"
28
- - 不为不可能发生的场景写错误处理
29
- - 写了 200 行却发现 50 行就能搞定 → 重写
30
-
31
- 自问:"资深工程师会说过度设计吗?"如果会,简化。
32
-
33
- ## 3. 外科手术式修改
34
-
35
- **只改必须改的,只清理自己造成的烂摊子。**
36
-
37
- 编辑已有代码时:
38
- - 不顺手"改进"相邻代码、注释或格式
39
- - 不重构没坏的东西
40
- - 匹配现有风格,即使你更习惯另一种写法
41
- - 发现无关的死代码,口头提及即可,不要删除
42
-
43
- 当你的改动产生孤儿代码时:
44
- - 删除因你的改动而不再使用的 import / 变量 / 函数
45
- - 不删除已有的死代码,除非用户要求
46
-
47
- **检验标准:** 每一行改动都应该能追溯到用户的需求。
48
-
49
- ## 4. 目标驱动执行
50
-
51
- **定义成功标准,循环直到验证通过。**
52
-
53
- 将命令式任务转换为可验证的目标:
54
-
55
- | 而非… | 转换为… |
56
- |--------|---------|
57
- | "加个校验" | "先写无效输入的测试,再让测试通过" |
58
- | "修这个 bug" | "先写能复现的测试,再修到测试通过" |
59
- | "重构 X" | "确保重构前后测试全部通过" |
60
-
61
- 多步任务先给简短计划:
62
- ```
63
- 1. [步骤] → 验证: [检查项]
64
- 2. [步骤] → 验证: [检查项]
65
- 3. [步骤] → 验证: [检查项]
66
- ```
67
-
68
- 清晰的成功标准让 AI 可以独立循环验证,模糊的标准("搞一下")需要反复澄清。
69
-
70
- ## 5. 失败要大声说出来
71
-
72
- **悄悄绕过失败比直接失败更糟糕。**
73
-
74
- - 有步骤被跳过,"完成"就是错的——说出来
75
- - 有测试被跳过,"测试通过"就是错的——说出来
76
- - 不确定就直接说不确定,不假装确认
77
- - 默认暴露不确定性,不掩盖
78
-
79
- **检验标准:** 任何跳过的步骤、不确定的结论、未验证的结果,都以标记形式呈现,不悄悄带过。
80
-
81
- ## 6. 不认同也要说出来
82
-
83
- 当项目现有约定明显有问题时:
84
-
85
- - 照样遵循,保持一致——不悄悄另起炉灶
86
- - 明确提出来——指出风险,给出替代方案
87
- - 让用户做决策,不要替用户做选择
88
-
89
- **检验标准:** 你的代码放进现有代码中,读不出"换了一个人写的"。发现的问题以建议形式呈现,而非悄悄用另一种方式实现。
90
-
91
- ## 7. 先批准,后动工
92
-
93
- **任何实现动作前,先陈述方案并获得用户批准。**
94
-
95
- - 动手前说出打算怎么做(方案、涉及文件、验证方式),等用户确认
96
- - 仪式随任务缩放:小改动两三句话说清即可;大改动走 openspec 工作流(propose → specs → design)
97
- - "太简单不需要方案"是最危险的念头——简单意味着方案短,而不是没有方案
98
- - 中途发现复杂度超出预期:停下来重新说明,不要闷头扩大改动范围
99
-
100
- **检验标准:** 用户从未因"AI 直接改了代码没打招呼"而感到意外。
101
-
102
- ## 8. 业务空间目录纪律
103
-
104
- **仅当工作目录是业务空间根(存在 `workspace-config.json`)时生效:写操作命令必须落在需求工作树内。**
105
-
106
- 业务空间根(主分支)只负责组织与调度,不做需求开发。接到需求先建工作树(`/cbb:worktree-init` 或 `/cbb-worktree-init`),之后:
107
-
108
- - 一切产生写操作的命令(git commit / openspec / 构建 / 测试 / 文件修改)必须以 `.worktrees/worktree-<需求名>/`(或其应用子目录)为工作目录:显式 `cd` 或绝对路径
109
- - 禁止在空间根执行写操作:不在主分支提交代码、不在空间根创建 openspec 变更产物、不改 `.codespace/` 基准代码
110
- - 只读命令(git status / log、查看文件)在空间根执行无妨
111
- - 会话开始时确认本次需求对应的工作树路径;存在多个未完成工作树时,先与用户确认目标,不要猜
112
-
113
- **检验标准:** 空间根主分支的 `git status` 永远干净(除工具维护的配置文件外),openspec 变更产物只出现在需求工作树内。
114
-
115
- ---
116
-
1
+ ---
2
+ trigger: always_on
3
+ ---
4
+
5
+ # AI 行为准则
6
+
7
+ 七条行为准则,减少 AI 编码常见错误。源自 [Andrej Karpathy 对 LLM 编码缺陷的观察](https://x.com/karpathy/status/2015883857489522876)。
8
+
9
+ **权衡:** 这些准则倾向于谨慎而非速度。对于简单任务(如修 typo、改文案),按常识判断即可。
10
+
11
+ ## 1. 先想后写
12
+
13
+ **不假设,不隐藏困惑,主动呈现权衡。**
14
+
15
+ 实现前:
16
+ - 明确声明假设,不确定时主动询问
17
+ - 若存在多种解释,呈现出来而非自己默默选一种
18
+ - 若有更简单的方案,说出来,必要时 push back
19
+ - 若有不明确的地方,停下来,说出困惑,请求澄清
20
+
21
+ ## 2. 简洁至上
22
+
23
+ **用最少代码解决问题,不加推测性内容。**
24
+
25
+ - 不实现用户未要求的功能
26
+ - 不为单次使用的代码创建抽象
27
+ - 不添加用户未要求的"灵活性"或"可配置性"
28
+ - 不为不可能发生的场景写错误处理
29
+ - 写了 200 行却发现 50 行就能搞定 → 重写
30
+
31
+ 自问:"资深工程师会说过度设计吗?"如果会,简化。
32
+
33
+ ## 3. 外科手术式修改
34
+
35
+ **只改必须改的,只清理自己造成的烂摊子。**
36
+
37
+ 编辑已有代码时:
38
+ - 不顺手"改进"相邻代码、注释或格式
39
+ - 不重构没坏的东西
40
+ - 匹配现有风格,即使你更习惯另一种写法
41
+ - 发现无关的死代码,口头提及即可,不要删除
42
+
43
+ 当你的改动产生孤儿代码时:
44
+ - 删除因你的改动而不再使用的 import / 变量 / 函数
45
+ - 不删除已有的死代码,除非用户要求
46
+
47
+ **检验标准:** 每一行改动都应该能追溯到用户的需求。
48
+
49
+ ## 4. 目标驱动执行
50
+
51
+ **定义成功标准,循环直到验证通过。**
52
+
53
+ 将命令式任务转换为可验证的目标:
54
+
55
+ | 而非… | 转换为… |
56
+ |--------|---------|
57
+ | "加个校验" | "先写无效输入的测试,再让测试通过" |
58
+ | "修这个 bug" | "先写能复现的测试,再修到测试通过" |
59
+ | "重构 X" | "确保重构前后测试全部通过" |
60
+
61
+ 多步任务先给简短计划:
62
+ ```
63
+ 1. [步骤] → 验证: [检查项]
64
+ 2. [步骤] → 验证: [检查项]
65
+ 3. [步骤] → 验证: [检查项]
66
+ ```
67
+
68
+ 清晰的成功标准让 AI 可以独立循环验证,模糊的标准("搞一下")需要反复澄清。
69
+
70
+ ## 5. 失败要大声说出来
71
+
72
+ **悄悄绕过失败比直接失败更糟糕。**
73
+
74
+ - 有步骤被跳过,"完成"就是错的——说出来
75
+ - 有测试被跳过,"测试通过"就是错的——说出来
76
+ - 不确定就直接说不确定,不假装确认
77
+ - 默认暴露不确定性,不掩盖
78
+
79
+ **检验标准:** 任何跳过的步骤、不确定的结论、未验证的结果,都以标记形式呈现,不悄悄带过。
80
+
81
+ ## 6. 不认同也要说出来
82
+
83
+ 当项目现有约定明显有问题时:
84
+
85
+ - 照样遵循,保持一致——不悄悄另起炉灶
86
+ - 明确提出来——指出风险,给出替代方案
87
+ - 让用户做决策,不要替用户做选择
88
+
89
+ **检验标准:** 你的代码放进现有代码中,读不出"换了一个人写的"。发现的问题以建议形式呈现,而非悄悄用另一种方式实现。
90
+
91
+ ## 7. 先批准,后动工
92
+
93
+ **任何实现动作前,先陈述方案并获得用户批准。**
94
+
95
+ - 动手前说出打算怎么做(方案、涉及文件、验证方式),等用户确认
96
+ - 仪式随任务缩放:小改动两三句话说清即可;大改动走 openspec 工作流(propose → specs → design)
97
+ - "太简单不需要方案"是最危险的念头——简单意味着方案短,而不是没有方案
98
+ - 中途发现复杂度超出预期:停下来重新说明,不要闷头扩大改动范围
99
+
100
+ **检验标准:** 用户从未因"AI 直接改了代码没打招呼"而感到意外。
101
+
102
+ ## 8. 业务空间目录纪律
103
+
104
+ **仅当工作目录是业务空间根(存在 `workspace-config.json`)时生效:写操作命令必须落在需求工作树内。**
105
+
106
+ 业务空间根(主分支)只负责组织与调度,不做需求开发。接到需求先建工作树(`/cbb:worktree-init` 或 `/cbb-worktree-init`),之后:
107
+
108
+ - 一切产生写操作的命令(git commit / openspec / 构建 / 测试 / 文件修改)必须以 `.worktrees/worktree-<需求名>/`(或其应用子目录)为工作目录:显式 `cd` 或绝对路径
109
+ - 禁止在空间根执行写操作:不在主分支提交代码、不在空间根创建 openspec 变更产物、不改 `.codespace/` 基准代码
110
+ - 只读命令(git status / log、查看文件)在空间根执行无妨
111
+ - 会话开始时确认本次需求对应的工作树路径;存在多个未完成工作树时,先与用户确认目标,不要猜
112
+
113
+ **会话与工作目录是两回事:** AI 会话窗口始终停在**空间根**(worktree 内不装 AI 配置,无工作流命令),`/opsx:*` 等命令仍在空间根会话发起;只是**产生写操作的工作目录**指向需求工作树(显式 `cd` 或绝对路径)。不要把会话切到 worktree 内,也不要因「在 worktree 内开发」就在空间根直接动手。
114
+
115
+ **检验标准:** 空间根主分支的 `git status` 永远干净(除工具维护的配置文件外),openspec 变更产物只出现在需求工作树内。
116
+
117
+ ---
118
+
117
119
  **这些准则生效的标志:** diff 中不必要的改动减少、不会因过度设计而重写、澄清问题在实现前而非出错后提出。
@@ -0,0 +1,32 @@
1
+ /**
2
+ * WorkBuddy / CodeBuddy 适配器
3
+ *
4
+ * 腾讯 WorkBuddy 桌面工作台与 CodeBuddy IDE / CLI 共用项目级配置目录 `.codebuddy/`,
5
+ * 故一个适配器同时覆盖两者。
6
+ *
7
+ * 与 Claude Code / Qoder 的映射差异:
8
+ * - rules:`.codebuddy/rules/*.md`(扁平文件、递归加载),frontmatter 用
9
+ * `alwaysApply: true`(Qoder 的 `trigger: always_on` 需改写,见 ruleRewrites)
10
+ * - skills:`.codebuddy/skills/<name>/SKILL.md`,结构与 Claude 同构
11
+ * - commands:`.codebuddy/commands/`,支持目录嵌套(`/group:command`),与 Claude 同风格
12
+ * - hooks:完全兼容 Claude Code Hooks 规范,settings 结构一致,直接复用 settingsManager
13
+ */
14
+
15
+ const path = require('path');
16
+ const os = require('os');
17
+
18
+ module.exports = {
19
+ name: 'codebuddy',
20
+ displayName: 'WorkBuddy(CodeBuddy)',
21
+ rulesDir: '.codebuddy/rules',
22
+ skillsDir: '.codebuddy/skills',
23
+ commandsDir: '.codebuddy/commands/opsx',
24
+ // worktree 管理命令(非 openspec 上游):独立命名空间 /cbb:worktree-*
25
+ worktreeCommandsDir: '.codebuddy/commands/cbb',
26
+ // 规则 frontmatter 改写:Qoder 风格 → CodeBuddy 风格
27
+ ruleRewrites: [['trigger: always_on', 'alwaysApply: true']],
28
+ // 用户级 settings,写入全局生效,不污染项目目录
29
+ settingsFile: path.join(os.homedir(), '.codebuddy', 'settings.json'),
30
+ settingsFileIsUserLevel: true,
31
+ hookEvents: ['UserPromptSubmit'],
32
+ };
@@ -4,7 +4,8 @@
4
4
  * OpenSpec Shared Standards 安装脚本
5
5
  *
6
6
  * 将AI 编码规范与工作流套件安装到目标项目中。
7
- * 支持工具:Claude Code (.claude/rules/)、Qoder (.qoder/rules/)、opencode (.opencode/rules/)
7
+ * 支持工具:Claude Code (.claude/rules/)、Qoder (.qoder/rules/)、opencode (.opencode/rules/)
8
+ * WorkBuddy/CodeBuddy (.codebuddy/rules/)、TraeWork/TraeCode (.trae/rules/)
8
9
  *
9
10
  * 使用方式:
10
11
  * npm install -g @jspg-ai/coding-bb # 首次使用
@@ -51,10 +52,13 @@ const MANIFEST_FILE = path.join(MANIFEST_DIR, '.managed-by-cbb');
51
52
  const LAST_TOOLS_FILE = path.join(MANIFEST_DIR, '.last-tools');
52
53
 
53
54
  // 适配器
55
+ // 适配器(数组顺序 = 工具选择面板的显示顺序)
54
56
  const adapters = [
55
- require('./claude-code'),
56
- require('./qoder'),
57
57
  require('./opencode'),
58
+ require('./codebuddy'),
59
+ require('./trae'),
60
+ require('./qoder'),
61
+ require('./claude-code'),
58
62
  ];
59
63
 
60
64
  // superpowers 部署白名单:仅装 openspec 工作流硬依赖 + 方法论基底(源仓库仍保留全量 14 个,
@@ -83,9 +87,17 @@ const OPENSPEC_COMMANDS_EXCLUDE = ['onboard.md'];
83
87
  // settings.json hook 工具
84
88
  const settingsManager = require('../utils/settings');
85
89
 
90
+ /** 适配器的 hook 方言参数(Trae 需顶层 version 字段等差异) */
91
+ function hookOpts(adapter) {
92
+ return adapter.hookDialect ? { dialect: adapter.hookDialect } : {};
93
+ }
94
+
86
95
  // 清单驱动的文件清理决策(保护用户文档 CLAUDE.md / AGENTS.md 等)
87
96
  const { pathsToDelete, protectedKeptPaths } = require('./cleanup');
88
97
 
98
+ // 规则 frontmatter 改写(Trae/CodeBuddy 需 alwaysApply: true)
99
+ const { applyRuleRewrites } = require('./rule-rewrite');
100
+
89
101
  // .gitignore 条目决策(纯函数:检测/写入/卸载移除)
90
102
  const gitignore = require('../utils/gitignore');
91
103
 
@@ -306,7 +318,8 @@ function deployCoreRules(adapter, isUpgrade, managedPaths) {
306
318
  // 同名文件存在时直接覆盖
307
319
  removePath(destPath);
308
320
 
309
- fs.writeFileSync(destPath, fs.readFileSync(srcPath, 'utf-8'));
321
+ const content = applyRuleRewrites(adapter, fs.readFileSync(srcPath, 'utf-8'));
322
+ fs.writeFileSync(destPath, content);
310
323
  }
311
324
  });
312
325
 
@@ -1128,9 +1141,9 @@ async function init(targetDir, options = {}) {
1128
1141
  const settingsPath = adapter.settingsFileIsUserLevel
1129
1142
  ? adapter.settingsFile
1130
1143
  : path.join(TARGET_DIR, adapter.settingsFile);
1131
- settingsManager.addHooks(settingsPath, command, adapter.hookEvents);
1144
+ settingsManager.addHooks(settingsPath, command, adapter.hookEvents, hookOpts(adapter));
1132
1145
  // 清理旧版本遗留的 SessionStart hook(现已仅安装 UserPromptSubmit)
1133
- if (settingsManager.removeLegacyHooks(settingsPath)) {
1146
+ if (settingsManager.removeLegacyHooks(settingsPath, hookOpts(adapter))) {
1134
1147
  log(`清理 ${adapter.displayName} 遗留的 SessionStart hook`, 'success');
1135
1148
  }
1136
1149
  if (!adapter.settingsFileIsUserLevel) newPaths.add(adapter.settingsFile);
@@ -1739,8 +1752,8 @@ async function setupUserLevelComponents(targetAdapters = adapters) {
1739
1752
  if (hookAdapters.length > 0) {
1740
1753
  const command = settingsManager.getCheckUpdateCommand();
1741
1754
  hookAdapters.forEach(adapter => {
1742
- settingsManager.addHooks(adapter.settingsFile, command, adapter.hookEvents);
1743
- settingsManager.removeLegacyHooks(adapter.settingsFile);
1755
+ settingsManager.addHooks(adapter.settingsFile, command, adapter.hookEvents, hookOpts(adapter));
1756
+ settingsManager.removeLegacyHooks(adapter.settingsFile, hookOpts(adapter));
1744
1757
  });
1745
1758
  summaryParts.push(`版本检查 hook → ${hookAdapters.map(a => a.displayName).join('、')}`);
1746
1759
  }
@@ -1856,7 +1869,7 @@ async function uninstallUserLevelComponents() {
1856
1869
  // 移除版本检查 hook(保留用户其余配置)
1857
1870
  adapters.forEach(adapter => {
1858
1871
  if (!adapter.settingsFile || !adapter.hookEvents) return;
1859
- if (settingsManager.removeHooks(adapter.settingsFile, adapter.hookEvents)) {
1872
+ if (settingsManager.removeHooks(adapter.settingsFile, adapter.hookEvents, hookOpts(adapter))) {
1860
1873
  log(`${adapter.settingsFile}: 移除版本检查 hook,保留用户配置`, 'success');
1861
1874
  }
1862
1875
  });
@@ -1887,7 +1900,7 @@ async function uninstall() {
1887
1900
  // 是否同时卸载用户级组件(工具 skills + 版本检查 hook,作用于 ~/.claude 等用户目录)
1888
1901
  let removeUserLevel = false;
1889
1902
  if (fs.existsSync(USER_MANIFEST_FILE)) {
1890
- const answerUser = await ask('是否同时卸载用户级组件(~/.claude、~/.qoder 的版本检查 hook)?(y/N): ');
1903
+ const answerUser = await ask('是否同时卸载用户级组件(~/.claude、~/.qoder、~/.codebuddy、~/.trae-cn 的版本检查 hook)?(y/N): ');
1891
1904
  removeUserLevel = answerUser.toLowerCase() === 'y' || answerUser.toLowerCase() === 'yes';
1892
1905
  }
1893
1906
 
@@ -1906,11 +1919,11 @@ async function uninstall() {
1906
1919
  : path.join(TARGET_DIR, adapter.settingsFile);
1907
1920
  // 项目级:需在清单中才处理
1908
1921
  if (!adapter.settingsFileIsUserLevel && !managedPaths.has(adapter.settingsFile)) return;
1909
- if (removeUserLevel && settingsManager.removeHooks(settingsPath, adapter.hookEvents)) {
1922
+ if (removeUserLevel && settingsManager.removeHooks(settingsPath, adapter.hookEvents, hookOpts(adapter))) {
1910
1923
  log(`${adapter.settingsFile}: 移除版本检查 hook,保留用户配置`, 'success');
1911
1924
  }
1912
1925
  // 清理旧版本遗留的 SessionStart hook(无版本差异,无条件清理)
1913
- if (settingsManager.removeLegacyHooks(settingsPath)) {
1926
+ if (settingsManager.removeLegacyHooks(settingsPath, hookOpts(adapter))) {
1914
1927
  log(`${adapter.settingsFile}: 清理遗留 SessionStart hook`, 'success');
1915
1928
  }
1916
1929
  skippedPaths.add(adapter.settingsFile);
@@ -0,0 +1,27 @@
1
+ 'use strict';
2
+
3
+ /**
4
+ * 规则 frontmatter 改写(纯函数,无副作用,便于单测)。
5
+ *
6
+ * 源规则(cbb/dev-standards/rules/*.md)用 Qoder 的 frontmatter 约定
7
+ * `trigger: always_on`。各工具对"始终生效"的字段名不同:
8
+ * - Qoder:trigger: always_on(源格式)
9
+ * - Claude Code / opencode:无该字段,靠各自机制加载
10
+ * - WorkBuddy/CodeBuddy、Trae:alwaysApply: true
11
+ *
12
+ * 适配器通过 ruleRewrites([[from, to], ...])声明改写规则,部署时套用;
13
+ * 无 ruleRewrites 的适配器原样返回。
14
+ */
15
+
16
+ /**
17
+ * 按适配器的 ruleRewrites 改写规则文本。
18
+ * @param {object} adapter 适配器配置
19
+ * @param {string} text 规则文件原文
20
+ * @returns {string} 改写后的文本(无 ruleRewrites 时原样返回)
21
+ */
22
+ function applyRuleRewrites(adapter, text) {
23
+ if (!adapter || !adapter.ruleRewrites) return text;
24
+ return adapter.ruleRewrites.reduce((t, [from, to]) => t.split(from).join(to), text);
25
+ }
26
+
27
+ module.exports = { applyRuleRewrites };
@@ -0,0 +1,35 @@
1
+ /**
2
+ * TraeWork / TraeCode 适配器
3
+ *
4
+ * 字节 TraeWork 桌面工作台与 TraeCode IDE 共用项目级配置目录 `.trae/`,
5
+ * 故一个适配器同时覆盖两者。
6
+ *
7
+ * 与 Claude Code / Qoder 的映射差异:
8
+ * - rules:`.trae/rules/*.md`(扁平文件、支持子目录,最多 3 层),frontmatter 用
9
+ * `alwaysApply: true`(Qoder 的 `trigger: always_on` 需改写,见 ruleRewrites)
10
+ * - skills:`.trae/skills/<name>/SKILL.md`,结构与 Claude 同构
11
+ * - commands:`.trae/commands/`,支持目录嵌套(最多 3 层),与 Claude 同风格
12
+ * - hooks:`~/.trae-cn/hooks.json`,格式与 Claude 相近但需顶层 `version: 1`
13
+ * (由 settingsManager 的 hookDialect 处理),事件名/输出字段一致
14
+ */
15
+
16
+ const path = require('path');
17
+ const os = require('os');
18
+
19
+ module.exports = {
20
+ name: 'trae',
21
+ displayName: 'TraeWork(TraeCode)',
22
+ rulesDir: '.trae/rules',
23
+ skillsDir: '.trae/skills',
24
+ commandsDir: '.trae/commands/opsx',
25
+ // worktree 管理命令(非 openspec 上游):独立命名空间 /cbb:worktree-*
26
+ worktreeCommandsDir: '.trae/commands/cbb',
27
+ // 规则 frontmatter 改写:Qoder 风格 → Trae 风格
28
+ ruleRewrites: [['trigger: always_on', 'alwaysApply: true']],
29
+ // 用户级 hooks 配置(Trae 用 hooks.json,国内版目录为 ~/.trae-cn/)
30
+ settingsFile: path.join(os.homedir(), '.trae-cn', 'hooks.json'),
31
+ settingsFileIsUserLevel: true,
32
+ hookEvents: ['UserPromptSubmit'],
33
+ // Trae 的 hooks.json 需顶层 version: 1(Claude 风格 settings.json 无此字段)
34
+ hookDialect: 'trae',
35
+ };
@@ -23,11 +23,18 @@ const CACHE_FILE = path.join(os.homedir(), '.cbb', '.update-check-cache.json');
23
23
  const CACHE_TTL = 24 * 60 * 60 * 1000;
24
24
 
25
25
  function getProjectDir() {
26
- return process.env.QODER_PROJECT_DIR || process.env.CLAUDE_PROJECT_DIR || process.cwd();
26
+ return process.env.CODEBUDDY_PROJECT_DIR
27
+ || process.env.TRAE_PROJECT_DIR
28
+ || process.env.QODER_PROJECT_DIR
29
+ || process.env.CLAUDE_PROJECT_DIR
30
+ || process.cwd();
27
31
  }
28
32
 
29
33
  /** 通过环境变量检测当前调用方对应的适配器名称 */
30
34
  function detectAdapterName() {
35
+ // 兼容变量(CLAUDE_PROJECT_DIR)由 Trae / CodeBuddy 一并注入,故优先判定各自专属变量
36
+ if (process.env.CODEBUDDY_PROJECT_DIR) return 'codebuddy';
37
+ if (process.env.TRAE_PROJECT_DIR) return 'trae';
31
38
  if (process.env.QODER_PROJECT_DIR) return 'qoder';
32
39
  if (process.env.CLAUDE_PROJECT_DIR) return 'claude-code';
33
40
  return null;
@@ -19,6 +19,8 @@ const GITIGNORE_RULES = [
19
19
  { add: '.cbb/', accept: ['.cbb/'] },
20
20
  { add: '.codespace/', accept: ['.codespace/', '.codespace'] },
21
21
  { add: '.opencode', accept: ['.opencode', '.opencode/'] },
22
+ { add: '.codebuddy', accept: ['.codebuddy', '.codebuddy/'] },
23
+ { add: '.trae', accept: ['.trae', '.trae/'] },
22
24
  ];
23
25
 
24
26
  /** 将 .gitignore 文本拆为行数组。 */
@@ -11,6 +11,9 @@
11
11
  * removeLegacyHooks 负责清理旧版本曾写入、现已弃用的 SessionStart hook:
12
12
  * 当前仅安装 UserPromptSubmit,但升级自旧版本的用户 settings.json 中可能仍残留
13
13
  * SessionStart 条目,升级 / 卸载时需主动移除,否则会永久残留。
14
+ *
15
+ * 方言:Trae 的 hooks.json 需顶层 `version: 1` 且非 Claude 的 settings.json,
16
+ * 由 opts.dialect === 'trae' 处理(写入时补 version,清理干净后移除)。
14
17
  */
15
18
 
16
19
  const fs = require('fs');
@@ -53,12 +56,16 @@ function stripManaged(arr) {
53
56
  * @param {string} settingsPath settings.json 路径
54
57
  * @param {string} command 要执行的命令
55
58
  * @param {string[]} events 要写入的事件名数组,如 ['UserPromptSubmit']
59
+ * @param {{dialect?: string}} [opts] 方言:'trae' 时补顶层 version: 1(Trae hooks.json 要求)
56
60
  * 已存在本包标记的条目会先移除再添加(保证命令为最新路径),不重复。
57
61
  */
58
- function addHooks(settingsPath, command, events) {
62
+ function addHooks(settingsPath, command, events, opts = {}) {
59
63
  const settings = readSettings(settingsPath);
60
64
  if (!settings.hooks || typeof settings.hooks !== 'object') settings.hooks = {};
61
65
 
66
+ // Trae hooks.json 需要顶层 version 字段(当前仅支持 1)
67
+ if (opts.dialect === 'trae' && settings.version === undefined) settings.version = 1;
68
+
62
69
  events.forEach(event => {
63
70
  settings.hooks[event] = stripManaged(settings.hooks[event]);
64
71
  const entry = { _managedBy: MANAGED_BY, hooks: [{ type: 'command', command }] };
@@ -74,9 +81,10 @@ function addHooks(settingsPath, command, events) {
74
81
  * 清理变空的事件数组 / hooks。
75
82
  * @param {string} settingsPath settings.json 路径
76
83
  * @param {string[]} events 要清理的事件名数组
84
+ * @param {{dialect?: string}} [opts] 方言:'trae' 时把 version 一并视为可清理字段
77
85
  * 返回 true 表示有改动。
78
86
  */
79
- function removeHooks(settingsPath, events) {
87
+ function removeHooks(settingsPath, events, opts = {}) {
80
88
  if (!fs.existsSync(settingsPath)) return false;
81
89
  const settings = readSettings(settingsPath);
82
90
  if (!settings.hooks || typeof settings.hooks !== 'object') return false;
@@ -94,6 +102,11 @@ function removeHooks(settingsPath, events) {
94
102
 
95
103
  if (Object.keys(settings.hooks).length === 0) delete settings.hooks;
96
104
 
105
+ // Trae:hooks 清空后 version 只是本包写入的脚手架,一并移除
106
+ if (opts.dialect === 'trae' && settings.version !== undefined && !settings.hooks) {
107
+ delete settings.version;
108
+ }
109
+
97
110
  // 文件变成空对象则删除,否则写回
98
111
  if (Object.keys(settings).length === 0) {
99
112
  fs.unlinkSync(settingsPath);
@@ -107,8 +120,8 @@ function removeHooks(settingsPath, events) {
107
120
  * 清理遗留事件下本包标记的 hook 条目(旧版本写入的 SessionStart 等)。
108
121
  * 复用 removeHooks 的清理逻辑;返回 true 表示有改动。
109
122
  */
110
- function removeLegacyHooks(settingsPath) {
111
- return removeHooks(settingsPath, LEGACY_HOOK_EVENTS);
123
+ function removeLegacyHooks(settingsPath, opts = {}) {
124
+ return removeHooks(settingsPath, LEGACY_HOOK_EVENTS, opts);
112
125
  }
113
126
 
114
127
  module.exports = {
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: "CBB: Worktree Close"
3
- description: 关闭/清理由 init-worktree 创建的多仓库联动 worktree 工作空间,移除 worktree 并按用户选择处理特性分支
3
+ description: 关闭/清理由 worktree-init 创建的多仓库联动 worktree 工作空间,移除 worktree 并按用户选择处理特性分支
4
4
  category: Workflow
5
5
  tags: [worktree, cleanup, worktree, git-worktree]
6
6
  ---
@@ -1,39 +1,41 @@
1
- # 业务空间使用说明(AI Agent 导航)
2
-
3
- 本目录是由 `@jspg-ai/coding-bb` 初始化的**多仓库联动开发业务空间**。
4
- 进入本目录工作时,请先按本文件理解目录职责与协作约定,再动手。
5
-
6
- ## 核心约定
7
-
8
- 1. **本目录不做需求开发**。本目录(业务空间主分支)只负责组织与调度;所有需求开发都在 `.worktrees/worktree-<需求名>/` 隔离目录内进行。
9
- 2. **AI 配置安装在空间根**:编码规范、OpenSpec 命令、worktree 管理技能都装在本目录(`cbb setup` / `cbb update` 安装);worktree 内**不安装** AI 配置,AI 会话始终以空间根为基础。
10
- 3. **接到新需求先建 worktree**:在本目录执行 `/cbb:worktree-init <需求名>`(opencode 写法:`/cbb-worktree-init`)。它会为 `workspace-config.json` 中的全量关联应用同步创建同名 worktree。
11
- 4. **开发命令在本会话执行,写操作指向 worktree**:需求提案 / 实现 / 验证 / 归档(`/opsx:propose` → `/opsx:apply` → `/opsx:verify` → `/opsx:archive`)在空间根会话执行;但所有产生写操作的命令(git commit / openspec / 构建 / 测试 / 文件修改)必须以 `.worktrees/worktree-<需求名>/`(或其应用子目录)为工作目录(显式 `cd` 或绝对路径);**禁止在空间根(主分支)执行写操作**。
12
- 5. **关联应用增减只改配置**:编辑 `workspace-config.json` 的 `apps` 数组(`name` / `repo` / `side` / `desc`),然后用同一需求名重跑 worktree 初始化即幂等补齐;不要手工 `git clone` 应用仓库。
13
- 6. **不要绕过 worktree 直接修改 `.codespace/` 或本目录的代码**。`.codespace/` 是工具维护的基准代码,不是开发区。
14
-
15
- ## 目录结构与职责
16
-
17
- | 路径 | 职责 | 维护方式 |
18
- |------|----------|----------|
19
- | `workspace-config.json` | 关联应用清单,所有应用联动的唯一数据源 | 人工编辑 |
20
- | `.codespace/` | 各关联应用的基准代码(每个应用一个子目录) | `cbb setup` 与 worktree 流程自动 clone / fetch;**勿手动编辑**;已 gitignore,不提交 |
21
- | `.worktrees/` | 需求隔离开发区(每个需求一个 `worktree-<需求名>/` 目录) | worktree 命令自动创建 / 清理;不提交(首次执行 worktree 流程时自动加入 .gitignore) |
22
- | `openspec/` | OpenSpec 工作流配置(`config.yaml` + `schemas/`) | 由 cbb 安装;需求变更产物(`openspec/changes/` 等)在**需求工作树内**生成,随需求分支提交 |
23
- | `.claude/` `.qoder/` `.opencode/` | AI 工具适配目录:编码规范规则、OpenSpec 命令、worktree 管理命令 | 由 cbb 按 setup 时选择的工具安装;已 gitignore,不提交,勿手动改 |
24
- | `.cbb/` | cbb 安装清单 + worktree 运行时(`.cbb/skills/`:流程文档与脚本,各工具命令共用) | 由 cbb 管理;**勿手动编辑** |
25
-
26
- ## 典型流程
27
-
28
- ```
29
- 本目录:/cbb:worktree-init <需求名>
30
- → 继续在当前会话开发:写操作命令以 .worktrees/worktree-<需求名>/ 为工作目录
31
- (/opsx:propose → /opsx:apply → /opsx:verify → /opsx:archive)
32
- → /cbb:worktree-push 推送 → 合并后 /cbb:worktree-close 关闭
33
- ```
34
-
35
- > 命令写法因 AI 工具而异:Claude Code / Qoder 为 `/cbb:worktree-init`,opencode `/cbb-worktree-init`;`/opsx:*` 同理(opencode 为 `/opsx-*`)。
36
-
37
- ---
38
-
39
- 本文件由 `@jspg-ai/coding-bb` 生成(仅缺失时写入,之后不会覆盖或删除,可自由增补团队约定)。
1
+ # 业务空间使用说明(AI Agent 导航)
2
+
3
+ 本目录是由 `@jspg-ai/coding-bb` 初始化的**多仓库联动开发业务空间**。
4
+ 进入本目录工作时,请先按本文件理解目录职责与协作约定,再动手。
5
+
6
+ ## 核心约定
7
+
8
+ 1. **本目录不做需求开发**。本目录(业务空间主分支)只负责组织与调度;需求开发的**写操作**都在 `.worktrees/worktree-<需求名>/` 隔离目录内进行,**AI 会话仍停在空间根**(worktree 内不装 AI 配置)。
9
+ 2. **AI 配置安装在空间根**:编码规范、OpenSpec 命令、worktree 管理技能都装在本目录(`cbb setup` / `cbb update` 安装);worktree 内**不安装** AI 配置,AI 会话始终以空间根为基础。
10
+ 3. **接到新需求先建 worktree**:在本目录执行 `/cbb:worktree-init <需求名>`(opencode 写法:`/cbb-worktree-init`)。它会为 `workspace-config.json` 中的全量关联应用同步创建同名 worktree。
11
+ 4. **开发命令在本会话执行,写操作指向 worktree**:需求提案 / 实现 / 验证 / 归档(`/opsx:propose` → `/opsx:apply` → `/opsx:verify` → `/opsx:archive`)在空间根会话执行;但所有产生写操作的命令(git commit / openspec / 构建 / 测试 / 文件修改)必须以 `.worktrees/worktree-<需求名>/`(或其应用子目录)为工作目录(显式 `cd` 或绝对路径);**禁止在空间根(主分支)执行写操作**。
12
+ 5. **关联应用增减只改配置**:编辑 `workspace-config.json` 的 `apps` 数组(`name` / `repo` / `side` / `desc`),然后用同一需求名重跑 worktree 初始化即幂等补齐;不要手工 `git clone` 应用仓库。
13
+ 6. **不要绕过 worktree 直接修改 `.codespace/` 或本目录的代码**。`.codespace/` 是工具维护的基准代码,不是开发区。
14
+
15
+ ## 目录结构与职责
16
+
17
+ | 路径 | 职责 | 维护方式 |
18
+ |------|----------|----------|
19
+ | `workspace-config.json` | 关联应用清单,所有应用联动的唯一数据源 | 人工编辑 |
20
+ | `.codespace/` | 各关联应用的基准代码(每个应用一个子目录) | `cbb setup` 与 worktree 流程自动 clone / fetch;**勿手动编辑**;已 gitignore,不提交 |
21
+ | `.worktrees/` | 需求隔离开发区(每个需求一个 `worktree-<需求名>/` 目录) | worktree 命令自动创建 / 清理;不提交(首次执行 worktree 流程时自动加入 .gitignore) |
22
+ | `openspec/` | OpenSpec 工作流配置(`config.yaml` + `schemas/`) | 由 cbb 安装;需求变更产物(`openspec/changes/` 等)在**需求工作树内**生成,随需求分支提交 |
23
+ | `.claude/` `.qoder/` `.opencode/` `.codebuddy/` `.trae/` | AI 工具适配目录:编码规范规则、OpenSpec 命令、worktree 管理命令 | 由 cbb 按 setup 时选择的工具安装;已 gitignore,不提交,勿手动改 |
24
+ | `.cbb/` | cbb 安装清单 + worktree 运行时(`.cbb/skills/`:流程文档与脚本,各工具命令共用) | 由 cbb 管理;**勿手动编辑** |
25
+
26
+ ## 典型流程
27
+
28
+ ```
29
+ 本目录:/cbb:worktree-init <需求名>
30
+ → 继续在当前会话开发:写操作命令以 .worktrees/worktree-<需求名>/ 为工作目录
31
+ (/opsx:propose → /opsx:apply → /opsx:verify → /opsx:archive)
32
+ → /cbb:worktree-push 推送 → 合并后 /cbb:worktree-close 关闭
33
+ ```
34
+
35
+ > 命令写法因 AI 工具而异:Claude Code / Qoder / WorkBuddy / Trae 为 `/cbb:worktree-init`、`/opsx:propose`;opencode 因「文件名即命令名」且 Windows 文件名不允许 `:`,扁平化为 `/cbb-worktree-init`、`/opsx-propose`。
36
+
37
+ ---
38
+
39
+ 本文件由 `@jspg-ai/coding-bb` 生成(仅缺失时写入,之后不会覆盖或删除,可自由增补团队约定)。
40
+
41
+ > ⓘ 本文件仅供导航;目录纪律以 cbb 安装的编码规范规则(`cbb-ai-behavior.md` 第 8 条)为准,该规则随 `cbb update` 更新。
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@jspg-ai/coding-bb",
3
- "version": "0.0.3-beta.4",
3
+ "version": "0.0.3-beta.6",
4
4
  "description": "整合业界热门且高价值的工具、框架与技能,为 AI CODING AGENT 提供统一的行为准则与工作流,辅助开发者将需求高效落地为符合规范的代码",
5
5
  "main": "cbb/lib/install/init.js",
6
6
  "bin": {
@@ -19,7 +19,7 @@
19
19
  "scripts": {
20
20
  "sync:shared": "node scripts/sync-shared.js",
21
21
  "pretest": "node scripts/sync-shared.js --check",
22
- "test": "node test/lib/install/cleanup.test.js && node test/lib/utils/settings.test.js && node test/lib/utils/gitignore.test.js && node test/lib/utils/version.test.js && node test/lib/install/workspaces.test.js && node test/lib/utils/checkbox.test.js && node test/lib/utils/output.test.js && node test/lib/install/cli-help.test.js && node test/lib/wiki/wiki-publish.test.js && node test/lib/wiki/wiki-parse-args.test.js && node test/lib/wiki/wiki-split.test.js && node test/lib/superpowers/superpowers.test.js && node test/worktrees/push-branches.test.js && node test/worktrees/commit-worktrees.test.js && node test/worktrees/push-worktrees.test.js && node test/worktrees/check-env-deep.test.js && node test/lib/openspec/openspec-render.test.js"
22
+ "test": "node test/lib/install/cleanup.test.js && node test/lib/utils/settings.test.js && node test/lib/utils/gitignore.test.js && node test/lib/utils/version.test.js && node test/lib/install/workspaces.test.js && node test/lib/utils/checkbox.test.js && node test/lib/utils/output.test.js && node test/lib/install/cli-help.test.js && node test/lib/install/adapters.test.js && node test/lib/wiki/wiki-publish.test.js && node test/lib/wiki/wiki-parse-args.test.js && node test/lib/wiki/wiki-split.test.js && node test/lib/superpowers/superpowers.test.js && node test/worktrees/push-branches.test.js && node test/worktrees/commit-worktrees.test.js && node test/worktrees/push-worktrees.test.js && node test/worktrees/check-env-deep.test.js && node test/lib/openspec/protected-paths.test.js"
23
23
  },
24
24
  "keywords": [
25
25
  "cbb",