@jspg-ai/coding-bb 0.0.1 → 0.0.2-beta.23

package/cbb/bin/cbb.js

@@ -0,0 +1,6 @@
+#!/usr/bin/env node
+'use strict';
+
+// 用户命令入口：cbb setup / update / uninstall
+process.env.CBB_ENTRY = 'cbb';
+require('../lib/install/init.js');

package/cbb/bin/cbbm.js

@@ -0,0 +1,6 @@
+#!/usr/bin/env node
+'use strict';
+
+// 内部命令入口：cbbm init / check-update / wiki / wp（由流程、hook、Agent 技能调用）
+process.env.CBB_ENTRY = 'cbbm';
+require('../lib/install/init.js');

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

@@ -1,104 +1,104 @@
----
-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 直接改了代码没打招呼"而感到意外。
-
----
-
+---
+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 直接改了代码没打招呼"而感到意外。
+
+---
+
 **这些准则生效的标志：** diff 中不必要的改动减少、不会因过度设计而重写、澄清问题在实现前而非出错后提出。

package/cbb/dev-standards/rules/cbb-priority.md

@@ -1,56 +1,56 @@
----
-trigger: always_on
----
-# 规范优先级
-
-全局规范与项目现有约定冲突时，按以下优先级处理：
-
-| 优先级 | 来源 | 说明 |
-|--------|------|------|
-| 1（最高） | 项目现有约定 | 包括代码中实际观察到的风格，以及项目目录下的显式规范（lint 配置、CLAUDE.md 等）。两者冲突时以显式规范为准 |
-| 2（最低） | 本规范库 | 统一规范，作为默认兜底。已吸收语言/框架官方惯例（如 PEP 8、Effective Go 等）作为基线 |
-
-**豁免**：以下情况不属于"沿用"范围，发现问题必须指出：
-
-- 会导致运行时错误或数据损坏的明显 bug
-- 安全缺陷（如 SQL 注入、敏感信息明文存储、XSS 风险等）
-- 已废弃的 API
-- 会导致严重性能退化的模式（如 N+1 查询、全表扫描后内存过滤、大事务长连接等）
-- 违反合规/法律要求的处理方式（如数据保留、隐私保护等）
-- 会导致可维护性灾难的模式（如单体方法超 500 行、循环嵌套深度 > 4 层等）
-
----
-
-## 执行原则
-
-### 首次进入项目
-
-生成或修改代码前必须：
-
-1. **探测现有风格** — 检查目标文件所在目录的代码风格
-2. **识别架构模式** — 确认项目使用的分包模式、命名约定、注解风格
-3. **保持一致性** — 新代码遵循项目风格，而非套用全局规范
-
-> 目录内风格不一致时，以目录内多数文件的风格为准；仍无法判断时，以项目显式规范为准。
-
-### 冲突处理
-
-| 场景 | 处理方式 |
-|------|----------|
-| 项目已有分层架构 | 沿用现有分层，不强制统一为某种架构 |
-| 项目已有命名风格 | 保持统一，不自创新风格 |
-| 项目已用某中间件 | 继续使用，不强行切换 |
-| 项目内存在多种风格混用 | 以当前文件风格为准，不引入第三种风格；当前文件无明确风格时以目录内多数文件风格为准 |
-| 项目无先例可循（如首次使用 Redis、首次写 MQ 消费者） | 使用本规范库作为默认起点 |
-| 全局规范更新 | 以项目实际安装的版本为准，不自动覆盖 |
-| 全新项目 | 使用本规范库作为起点 |
-| 已有项目中的新模块 | 沿用项目现有约定，不另起风格 |
-
-> **显式规范与代码风格冲突时的处理**：显式规范优先用于新代码；不要求对已有代码做大规模 reformat。判断标准：涉及命名约定、架构分层、中间件选型等**结构性决策**时以显式规范为准；仅涉及缩进、换行等**格式细节**时以当前文件风格为准。
-
-### 重构场景
-
-当本次需求涉及架构重构时：
-
-- 以重构目标为准，而非沿用旧模式
+---
+trigger: always_on
+---
+# 规范优先级
+
+全局规范与项目现有约定冲突时，按以下优先级处理：
+
+| 优先级 | 来源 | 说明 |
+|--------|------|------|
+| 1（最高） | 项目现有约定 | 包括代码中实际观察到的风格，以及项目目录下的显式规范（lint 配置、CLAUDE.md 等）。两者冲突时以显式规范为准 |
+| 2（最低） | 本规范库 | 统一规范，作为默认兜底。已吸收语言/框架官方惯例（如 PEP 8、Effective Go 等）作为基线 |
+
+**豁免**：以下情况不属于"沿用"范围，发现问题必须指出：
+
+- 会导致运行时错误或数据损坏的明显 bug
+- 安全缺陷（如 SQL 注入、敏感信息明文存储、XSS 风险等）
+- 已废弃的 API
+- 会导致严重性能退化的模式（如 N+1 查询、全表扫描后内存过滤、大事务长连接等）
+- 违反合规/法律要求的处理方式（如数据保留、隐私保护等）
+- 会导致可维护性灾难的模式（如单体方法超 500 行、循环嵌套深度 > 4 层等）
+
+---
+
+## 执行原则
+
+### 首次进入项目
+
+生成或修改代码前必须：
+
+1. **探测现有风格** — 检查目标文件所在目录的代码风格
+2. **识别架构模式** — 确认项目使用的分包模式、命名约定、注解风格
+3. **保持一致性** — 新代码遵循项目风格，而非套用全局规范
+
+> 目录内风格不一致时，以目录内多数文件的风格为准；仍无法判断时，以项目显式规范为准。
+
+### 冲突处理
+
+| 场景 | 处理方式 |
+|------|----------|
+| 项目已有分层架构 | 沿用现有分层，不强制统一为某种架构 |
+| 项目已有命名风格 | 保持统一，不自创新风格 |
+| 项目已用某中间件 | 继续使用，不强行切换 |
+| 项目内存在多种风格混用 | 以当前文件风格为准，不引入第三种风格；当前文件无明确风格时以目录内多数文件风格为准 |
+| 项目无先例可循（如首次使用 Redis、首次写 MQ 消费者） | 使用本规范库作为默认起点 |
+| 全局规范更新 | 以项目实际安装的版本为准，不自动覆盖 |
+| 全新项目 | 使用本规范库作为起点 |
+| 已有项目中的新模块 | 沿用项目现有约定，不另起风格 |
+
+> **显式规范与代码风格冲突时的处理**：显式规范优先用于新代码；不要求对已有代码做大规模 reformat。判断标准：涉及命名约定、架构分层、中间件选型等**结构性决策**时以显式规范为准；仅涉及缩进、换行等**格式细节**时以当前文件风格为准。
+
+### 重构场景
+
+当本次需求涉及架构重构时：
+
+- 以重构目标为准，而非沿用旧模式
 - 重构范围必须明确界定，不在范围内的代码保持现有风格

package/cbb/lib/install/claude-code.js

@@ -13,6 +13,8 @@ module.exports = {
   rulesDir: '.claude/rules',
   skillsDir: '.claude/skills',
   commandsDir: '.claude/commands/opsx',
+  // worktree 管理命令（非 openspec 上游）：独立命名空间 /cbb:worktree-*
+  worktreeCommandsDir: '.claude/commands/cbb',
   // 用户级 settings，写入全局生效，不污染项目目录
   settingsFile: path.join(os.homedir(), '.claude', 'settings.json'),
   settingsFileIsUserLevel: true,