@jspg-ai/coding-bb 0.0.3-beta.13 → 0.0.3-beta.14
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.
|
@@ -101,18 +101,28 @@ trigger: always_on
|
|
|
101
101
|
|
|
102
102
|
## 8. 业务空间目录纪律
|
|
103
103
|
|
|
104
|
-
**仅当工作目录是业务空间根（存在 `workspace-config.json
|
|
104
|
+
**仅当工作目录是业务空间根（存在 `workspace-config.json`）时生效。空间根支持两种开发模式，接到需求先判定本次属于哪种，再动手。**
|
|
105
105
|
|
|
106
|
-
|
|
106
|
+
**模式一 · worktree 模式（默认；凡涉及应用代码改动必走此路）：**
|
|
107
|
+
|
|
108
|
+
接到需求先建工作树（`cbb-worktree-init` skill，或斜杠命令 `/cbb-worktree-init`），之后：
|
|
107
109
|
|
|
108
110
|
- 一切产生写操作的命令（git commit / openspec / 构建 / 测试 / 文件修改）必须以 `.worktrees/worktree-<需求名>/`（或其应用子目录）为工作目录：显式 `cd` 或绝对路径
|
|
109
|
-
-
|
|
110
|
-
- 只读命令（git status / log、查看文件）在空间根执行无妨
|
|
111
|
+
- 不在空间根主分支提交应用代码、不在空间根创建本模式的 openspec 变更产物
|
|
111
112
|
- 会话开始时确认本次需求对应的工作树路径；存在多个未完成工作树时，先与用户确认目标，不要猜
|
|
112
113
|
|
|
113
|
-
|
|
114
|
+
**模式二 · 轻量模式（仅限空间根仓库自身内容：openspec 产物、docs、空间配置）：**
|
|
115
|
+
|
|
116
|
+
需求完全不触碰任何应用代码文件时，可直接在空间根开发：变更产物落空间根 `openspec/`，走完整 opsx 流程后提交 main 分支，**提交后即 push——main 就是交付线，无 worktree、无 MR，不得悬空本地提交**。
|
|
117
|
+
|
|
118
|
+
**两模式共同红线（无例外）：**
|
|
119
|
+
|
|
120
|
+
- `.codespace/` 是工具维护的基准代码，不是开发区——任何模式下都不许在其中改应用代码
|
|
121
|
+
- 只读命令（git status / log、查看文件）在空间根执行无妨
|
|
122
|
+
|
|
123
|
+
**会话与工作目录是两回事：** AI 会话窗口始终停在**空间根**（worktree 内不装 AI 配置，无工作流命令），`/opsx:*` 等命令仍在空间根会话发起；worktree 模式下**产生写操作的工作目录**指向需求工作树（显式 `cd` 或绝对路径）。不要把会话切到 worktree 内。
|
|
114
124
|
|
|
115
|
-
**检验标准：**
|
|
125
|
+
**检验标准：** worktree 模式的变更产物只出现在需求工作树内；空间根 main 的 `git status` 干净（除工具维护的配置文件外），且轻量模式产生的 main 提交都已 push（本地 main 不长期领先 origin/main）。
|
|
116
126
|
|
|
117
127
|
---
|
|
118
128
|
|
|
@@ -227,7 +227,7 @@ apply:
|
|
|
227
227
|
**收尾（全部任务翻成 `- [x]` 后执行；本段为项目级硬约束，覆盖官方 apply 模板自带的完成提示语）：**
|
|
228
228
|
|
|
229
229
|
1. **未决项自检**（逐项确认，任何一项未过都不得宣布完成）：
|
|
230
|
-
- change 产物（proposal.md / design.md / specs/** / tasks.md / plan.md
|
|
230
|
+
- change 产物（proposal.md / design.md / specs/** / tasks.md / plan.md）已提交到需求分支（轻量模式：空间根 main 分支）；未提交时先询问用户是否现在提交（可随 cbb-worktree-push 一并推送；轻量模式提交后即 push）
|
|
231
231
|
- 本会话产生的临时文件与环境改动（备份目录、未回写远端的本地提交、cherry-pick 等）已列清并交用户决策
|
|
232
232
|
2. **输出顺序纪律**：存在未决项时，本轮只列未决项并等待用户决策；**禁止同轮输出"下一步建议"**，禁止出现"规划与实施均已完成""可运行 archive"之类表述（产物未提交时归档会丢规划产物）
|
|
233
233
|
3. **全部未决项关闭后，唯一可建议的下一步是 `/opsx:verify`**：本项目工作流为 propose → apply → verify → archive，verify（强制 code-review + 产出 cr.md）是 archive 的前置阶段；**禁止直接建议 archive**，官方模板的 "You can archive this change" 提示语以本段为准
|
|
@@ -253,3 +253,5 @@ verify:
|
|
|
253
253
|
- **路径 B · 先归档后推送**：立即 `/opsx:archive` 落定变更产物（归档移动与 spec 同步发生在 feature 分支上）→ 再执行 `cbb-worktree-push` 一并推送 → 提 MR 到测试分支验收。注意：验收若发现问题，产物已归档，修复需走新 change 或将归档移回后继续；适合改动小、验收把握大的场景
|
|
254
254
|
|
|
255
255
|
用户选定后按该路径执行；官方模板的单一 "suggest archive" 提示语以本段为准。
|
|
256
|
+
|
|
257
|
+
**轻量模式变体**（本次 change 完全不涉及应用代码，产物在空间根仓库）：无 worktree push / 测试分支 MR 环节，两条路径替换为——A（推荐）"先 push main 交付、观察无回归后再 archive" / B"立即 archive 落定产物，再 push main"；main 提交不得悬空本地。
|
|
@@ -5,12 +5,12 @@
|
|
|
5
5
|
|
|
6
6
|
## 核心约定
|
|
7
7
|
|
|
8
|
-
1.
|
|
8
|
+
1. **双模式开发**：涉及**应用代码**的需求在 `.worktrees/worktree-<需求名>/` 隔离目录内进行（worktree 模式，默认）；完全不触碰应用代码的需求（openspec 产物、docs、空间配置）可直接在空间根开发（轻量模式，提交 main 后即 push）。**AI 会话始终停在空间根**（worktree 内不装 AI 配置）。
|
|
9
9
|
2. **AI 配置安装在空间根**：编码规范、OpenSpec 命令、worktree 管理技能都装在本目录（`cbb setup` / `cbb update` 安装）；worktree 内**不安装** AI 配置，AI 会话始终以空间根为基础。
|
|
10
|
-
3.
|
|
11
|
-
4.
|
|
10
|
+
3. **涉及应用代码的新需求先建 worktree**：使用 `/cbb-worktree-init <需求名>`（skill 形态，各工具写法见文末），或直接自然语言说"为 <需求名> 创建工作空间"。它会为 `workspace-config.json` 中的全量关联应用同步创建同名 worktree。
|
|
11
|
+
4. **开发命令在本会话执行，写操作按模式定落点**：需求提案 / 实现 / 验证 / 归档（`/opsx:propose` → `/opsx:apply` → `/opsx:verify` → `/opsx:archive`）在空间根会话执行；worktree 模式下所有产生写操作的命令（git commit / openspec / 构建 / 测试 / 文件修改）必须以 `.worktrees/worktree-<需求名>/`（或其应用子目录）为工作目录（显式 `cd` 或绝对路径），**不得往主分支提交应用代码**；轻量模式在空间根直接写、提交 main 后即 push。
|
|
12
12
|
5. **关联应用增减只改配置**：编辑 `workspace-config.json` 的 `apps` 数组（`name` / `repo` / `side` / `desc`），然后用同一需求名重跑 worktree 初始化即幂等补齐；不要手工 `git clone` 应用仓库。
|
|
13
|
-
6. **不要绕过 worktree 直接修改 `.codespace
|
|
13
|
+
6. **不要绕过 worktree 直接修改 `.codespace/`**。`.codespace/` 是工具维护的基准代码，不是开发区；应用代码改动任何模式都必须走 worktree。
|
|
14
14
|
|
|
15
15
|
## 目录结构与职责
|
|
16
16
|
|
|
@@ -19,7 +19,7 @@
|
|
|
19
19
|
| `workspace-config.json` | 关联应用清单，所有应用联动的唯一数据源 | 人工编辑 |
|
|
20
20
|
| `.codespace/` | 各关联应用的基准代码（每个应用一个子目录） | `cbb setup` 与 worktree 流程自动 clone / fetch；**勿手动编辑**；已 gitignore，不提交 |
|
|
21
21
|
| `.worktrees/` | 需求隔离开发区（每个需求一个 `worktree-<需求名>/` 目录） | worktree 命令自动创建 / 清理；不提交（首次执行 worktree 流程时自动加入 .gitignore） |
|
|
22
|
-
| `openspec/` | OpenSpec 工作流配置（`config.yaml` + `schemas/`） | 由 cbb
|
|
22
|
+
| `openspec/` | OpenSpec 工作流配置（`config.yaml` + `schemas/`） | 由 cbb 安装；变更产物（`openspec/changes/` 等）worktree 模式在**需求工作树内**生成随需求分支提交，轻量模式直接在空间根生成提交 main |
|
|
23
23
|
| `.claude/` `.qoder/` `.opencode/` `.codebuddy/` `.trae/` | AI 工具适配目录：编码规范规则、OpenSpec 命令、worktree 管理技能（skill 形态） | 由 cbb 按 setup 时选择的工具安装；已 gitignore，不提交，勿手动改 |
|
|
24
24
|
| `.cbb/` | cbb 安装清单与状态（`.managed-by-cbb`、`.last-tools`） | 由 cbb 管理；**勿手动编辑** |
|
|
25
25
|
|
|
@@ -34,6 +34,8 @@
|
|
|
34
34
|
→ 全链路完成后说"关闭工作空间"（或 /cbb-worktree-close）
|
|
35
35
|
```
|
|
36
36
|
|
|
37
|
+
> 轻量模式（需求完全不涉及应用代码）跳过上述流程：空间根直接 `/opsx:*` 全程 → 提交 main → 立即 push。
|
|
38
|
+
|
|
37
39
|
> worktree 管理三件套（init / close / push）以 **skill 形态**分发：既能被 AI 在对话中按意图**自动触发**，也能用斜杠命令手动指定（`/cbb-worktree-init` 等，各工具一致）。OpenSpec 命令为 `/opsx:propose`（opencode 扁平化为 `/opsx-propose`）。
|
|
38
40
|
|
|
39
41
|
---
|