@jspg-ai/coding-bb 0.0.3-beta.1 → 0.0.3-beta.13

package/config/openspec/schemas/spec-driven/schema.yaml

@@ -17,15 +17,15 @@ artifacts:
       2. 拿到用户输入后，整理并复述目标，**让用户确认**理解是否正确。未确认前禁止进入下一阶段。
       3. 信息不足或目标模糊时，继续追问，直到目标清晰无歧义。
 
-      ### 阶段二：查阅知识库（需求确认后，代码扫描前）
+      ### 阶段二：收集参考材料（需求确认后，代码扫描前）
 
-      1. 询问用户是否有知识库、参考文档等可提供。
-      2. 若有知识库：通过 INDEX.md（路径见 CLAUDE.md "知识库" 章节）按层级进入。从 INDEX.md → 域索引 → 子域 → 知识条目。仅跟随索引中的已有链接，**禁止 glob 或全库搜索**。记录每个被引用的文档。
-      3. 若无知识库或 INDEX.md 不存在：记录"知识库暂无覆盖"，直接进入阶段三，**禁止编造或强行搜索**。
+      1. 用 AskUserQuestion 询问用户：除 PRD 外还有哪些参考材料（设计文档、WIKI 链接、历史方案等）？
+      2. 用户指认了文档/目录：定向阅读所指范围。指认到目录级时，可浏览该目录内的文件名并阅读相关文档；目录之外的内容与全库 glob 搜索仍然禁止。
+      3. 无参考材料：记录"暂无参考文档"，直接进入阶段三，禁止凭空编造背景信息。
 
-      ### 阶段三：扫描代码（带着确认后的目标 + 知识库结果去扫）
+      ### 阶段三：扫描代码（带着确认后的目标 + 参考材料去扫）
 
-      1. 以阶段一确认的目标和阶段二收集的知识库为上下文，扫描代码库。
+      1. 以阶段一确认的目标和阶段二收集的参考材料为上下文，扫描代码库。
       2. 只扫与本次需求相关的入口类/方法、已有实现、依赖链。**禁止无目标的全库扫描**。
       3. 扫描结果应直接支撑「四、代码改动清单」的编写。
 
@@ -37,7 +37,7 @@ artifacts:
       - **禁止推测**：需求细节必须来自上述三阶段的产出；信息不足时回退到对应阶段补充
       - **来源标注**：一、为什么 / 二、变更简述 / 三、变更清单 / 四、代码改动清单 / 五、影响 中每一条断言后附来源，示例：
         - "（来自 PRD §3.2）"
-        - "（知识库: myb-user-domain/auth-flow.md）"
+        - "（文档: docs/design/auth-flow.md）"
         - "（代码: com.x.user.facade.UserFacade#resetPassword）"
       - **存疑必问，禁止猜测**：撰写过程中遇到以下情况，必须暂停并用 AskUserQuestion 让用户决策，禁止自行假设后继续：
         - 需求逻辑不合理或自相矛盾
@@ -45,18 +45,17 @@ artifacts:
         - 存在潜在风险（资损、性能、兼容性、安全）
         - 多种可行方案各有取舍
         每次向用户确认后，将决策逐条记录到「六、决策记录」表格中。
-      - **知识库引用**还应一并带到 design.md 的"知识库参考"章节
 
       章节（顺序：动机 → 变更简述 → 能力契约 → 代码入口 → 影响 → 决策记录；每章带中文数字序号）：
       - **一、为什么**（必选）：1-3 句话说清问题或机会。要解决什么？为什么是现在？
-      - **二、变更简述**（必选）：1-5 句话最精简易读地描述本需求要做的事情
+      - **二、变更简述**（必选）：1-3 句话最精简易读地描述本需求要做的事情。破坏性变更（接口不兼容、数据结构破坏等）在句尾标注 **BREAKING**
       - **三、变更清单**（必选）：能力维度的变更盘点（新增 / 修改 / 删除）。每个能力对应 `openspec/specs/<name>/spec.md`。identifier 与中文名解耦
         - **identifier 与展示名解耦**：identifier 列（`能力名` / `现有 spec 名` / `已废弃 spec 名`）填英文 kebab-case（用于 path / CLI / 跨引用），新增一列 `中文名` 填人类阅读用名
         - **新增能力**：每个对应一份新建 `specs/<name>/spec.md`
-        - **修改能力**：每个对应一份 delta spec 文件
+        - **修改能力**：每个对应一份 delta spec 文件。仅限 spec 级行为变化——纯实现细节重构不算，避免生成无意义 delta
         - **删除能力**：整段能力下线。spec 文件保留并写 `## REMOVED Requirements` 段，避免后续误用
       - **四、代码改动清单**（必选）：每个代码入口一行。
-        - **必须基于实际扫代码 + 读知识库得出，禁止凭 PRD 直接推测**
+        - **必须基于实际扫代码 + 读参考文档得出，禁止凭 PRD 直接推测**
         - 字段：应用 / 变更类型 / 代码入口类型 / 代码入口 / 所属能力 / 变更简述 / 备注
         - 后端 代码入口类型 仅允许：rpc / rest / mq / job / sql / config / constant / enum
         - 前端 代码入口类型 固定为 `前端`；代码入口列允许 `文件路径 —— 简短描述` 自然语言
@@ -67,7 +66,14 @@ artifacts:
       - **五、影响**（必选）：列出受影响的代码、接口、依赖、上下游系统。**复杂影响分析**（灰度步骤、回滚方案、跨团队协作）进入 § design 阶段
       - **六、决策记录**（必选）：撰写过程中向用户确认过的每个决策点，逐条填入表格。字段：序号 / 决策点 / 用户决策 / 影响。无决策则填一行"无"
 
-      重要：变更清单章节是 proposal 与 spec 阶段的契约核心。动笔前先研究现有 spec。每列出的能力都对应一份 spec 文件。
+      重要：变更清单章节是 proposal 与 spec 阶段的契约核心。动笔前先研究现有 spec，禁止凭空起名：
+      1. `openspec list --specs` 拉取项目能力清单
+      2. 对疑似相关的 spec 先用 `openspec show "<spec-id>" --type spec --json --no-scenarios` 概览（返回能力用途与需求文本，不拉全文）
+      3. 决定增改前，对相关 spec 全文阅读：`openspec show "<spec-id>" --type spec`（含 scenarios）
+      4. 修改能力必须复用 `openspec/specs/` 下已有能力的准确路径，禁止引入近似重复名
+      每列出的能力都对应一份 spec 文件。
+
+      零能力变更的处理：若本次变更不涉及任何能力（纯重构、工具、文档、纯基础设施改动），变更清单三个子表留空，并在 change 的 `.openspec.yaml` 中设置 `skip_specs: true` —— `openspec validate` 会拒绝零 delta 的 change，该标记是唯一出口。禁止为通过校验编造能力或需求。
 
       保持简洁（1-2 页）。专注"为什么"而非"怎么做"——实现细节归 design.md。
 
@@ -105,23 +111,9 @@ artifacts:
     instruction: |
       Create the design document that explains HOW to implement the change.
 
-      **Knowledge Base Reference (MANDATORY):**
-      Before writing design, you MUST consult the project's knowledge base:
-      1. Read the knowledge base root INDEX.md (path defined in CLAUDE.md under "知识库")
-      2. Navigate from INDEX.md → relevant domain index → sub-domain → knowledge chunks
-      3. Collect all knowledge documents relevant to this change's design sections
-      4. Fill the "知识库参考" section in the template with: knowledge point name, full file path, corresponding design section
-      5. If a design section has no matching knowledge base coverage, note it as "知识库暂无覆盖，建议补充"
-
-      Knowledge-to-design-section mapping reference:
-      - 需求背景 → business domain indexes (myb-*-domain/)
-      - 架构设计 → application indexes (project/<app>/)
-      - 领域模型设计 → domain indexes (myb-*-domain/)
-      - 核心流程设计 → domain knowledge chunks
-      - 数据库模型 → application indexes + domain knowledge
-      - MQ设计 → domain knowledge chunks
-      - 稳定性设计 → tech-asset/tech-gray/
-      - 防资损设计 → domain knowledge chunks
+      **Reference documents:**
+      Build on the reference documents gathered during the proposal phase (see its source annotations, e.g. "（文档: …）").
+      If the design needs additional documents, ask the user to designate them (targeted reading only, no repo-wide globbing).
 
       When to include design.md (create only if any apply):
       - Cross-cutting change (multiple services/modules) or new architectural pattern
@@ -130,7 +122,6 @@ artifacts:
       - Ambiguity that benefits from technical decisions before coding
 
       Sections (follow design.md template):
-      - **知识库参考**（必选）：列出本次设计参考的知识库文档路径及对应章节
       - **需求或项目背景**（必选）：问题/目标、PRD/DMPT链接
       - **Checklist事项**（必选）：逐项检查技术风险（新接口、改接口、新枚举、新依赖、新表/MQ、sentinel、敏感数据、SQL、历史兼容、Redis、验签）
       - **功能拆解**（必选）：按模块拆分功能点，标注变更类型和FTAPI
@@ -233,6 +224,14 @@ apply:
 
     `plan.md` 跟 change 同住一个目录，archive 阶段会被一起带走。
 
+    **收尾（全部任务翻成 `- [x]` 后执行；本段为项目级硬约束，覆盖官方 apply 模板自带的完成提示语）：**
+
+    1. **未决项自检**（逐项确认，任何一项未过都不得宣布完成）：
+       - change 产物（proposal.md / design.md / specs/** / tasks.md / plan.md）已提交到需求分支；未提交时先询问用户是否现在提交（可随 cbb-worktree-push 一并推送）
+       - 本会话产生的临时文件与环境改动（备份目录、未回写远端的本地提交、cherry-pick 等）已列清并交用户决策
+    2. **输出顺序纪律**：存在未决项时，本轮只列未决项并等待用户决策；**禁止同轮输出"下一步建议"**，禁止出现"规划与实施均已完成""可运行 archive"之类表述（产物未提交时归档会丢规划产物）
+    3. **全部未决项关闭后，唯一可建议的下一步是 `/opsx:verify`**：本项目工作流为 propose → apply → verify → archive，verify（强制 code-review + 产出 cr.md）是 archive 的前置阶段；**禁止直接建议 archive**，官方模板的 "You can archive this change" 提示语以本段为准
+
 verify:
   tracks: cr.md
   requires: [tasks]
@@ -245,3 +244,12 @@ verify:
        即便 AI 自认能 review,仍必须调 skill。
     2. **MANDATORY 产出 `cr.md`**:把完整 Verification Report 写到 `openspec/changes/<name>/cr.md`,
        缺则视为 verify 未完成。报告必须包含五段:Summary / CRITICAL / WARNING / SUGGESTION / Code Review。
+
+    **收尾（cr.md 产出且无 CRITICAL 遗留后执行；本段为项目级硬约束，覆盖官方 verify 模板自带的完成提示语）：**
+
+    verify 通过后，用 AskUserQuestion（固定选项）向用户提供两条路径并等待选择，禁止替用户决定、禁止单一路径直接建议归档：
+
+    - **路径 A · 先验收后归档（推荐）**：执行 `cbb-worktree-push` 推送 feature 分支并提 MR 到测试分支 → 测试环境部署、用户验收 → 验收要改则在 worktree 内修复后再次 push（小改动无需重跑 verify）→ 验收通过后才 `/opsx:archive`
+    - **路径 B · 先归档后推送**：立即 `/opsx:archive` 落定变更产物（归档移动与 spec 同步发生在 feature 分支上）→ 再执行 `cbb-worktree-push` 一并推送 → 提 MR 到测试分支验收。注意：验收若发现问题，产物已归档，修复需走新 change 或将归档移回后继续；适合改动小、验收把握大的场景
+
+    用户选定后按该路径执行；官方模板的单一 "suggest archive" 提示语以本段为准。

package/config/openspec/schemas/spec-driven/templates/design.md

@@ -12,24 +12,6 @@
 
 ---
 
-## 零、知识库参考（必选）
-
-<!-- AI理解要点：此章节记录本次设计参考了哪些知识库文档，确保设计基于已有知识而非凭空构思。
-     通过知识库索引（INDEX.md）逐级定位后，列出实际读取的知识文档路径。 -->
-
-| 序号 | 参考知识点 | 知识库路径 | 对应设计章节 | 备注 |
-| ---- | ---------- | ---------- | ------------ | ---- |
-| 1    | <!-- 知识点名称 --> | <!-- 从INDEX.md逐级定位的完整路径 --> | <!-- 架构设计/领域模型/... --> | <!-- 参考了什么 --> |
-
-<!-- 知识库导航方式：
-1. 从知识库根索引 INDEX.md 出发
-2. 按业务域/技术域逐级定位到具体知识文档
-3. 将实际读取的文档路径填入上表
-4. 如果某章节无对应知识库文档，在备注中标注"知识库暂无覆盖，建议补充"
--->
-
----
-
 ## 一、需求或项目背景（必选）
 
 <!-- AI理解要点：此章节提供需求的上下文信息，帮助理解业务背景和目标 -->

package/config/openspec/schemas/spec-driven/templates/proposal.md

@@ -2,16 +2,17 @@
 
 <!-- 说明这次变更的动机。要解决什么问题？为什么是现在？ -->
 
-## 二、变更摘要
+## 二、变更简述
 
-<!-- 1-3 句话最精简易读地描述本需求要做的事情。 -->
+<!-- 1-3 句话最精简易读地描述本需求要做的事情。破坏性变更（接口不兼容、数据结构破坏等）在句尾标注 **BREAKING**。 -->
 
 ## 三、变更清单
 
 <!-- 能力维度的变更盘点（新增 / 修改 / 删除）。每个能力对应 `openspec/specs/<name>/spec.md`。
      表格同时承载"能力本身的静态信息（identifier / 中文名 / 简述）"和"本次变更对它的动作"。
      第四章"代码改动清单"是落到代码层的具体改动点。两章通过 identifier 字段双向关联。
-     **identifier 与展示名解耦**：identifier 列填英文 kebab-case（用于 path / CLI / 跨引用）；`中文名` 列填人类阅读用名，可与 identifier 不同。 -->
+     **identifier 与展示名解耦**：identifier 列填英文 kebab-case（用于 path / CLI / 跨引用）；`中文名` 列填人类阅读用名，可与 identifier 不同。
+     零能力变更：三章全部留空（纯重构 / 工具 / 文档 / 纯基础设施），并在 change 的 `.openspec.yaml` 设 `skip_specs: true` —— `openspec validate` 拒绝零 delta 的 change，该标记是唯一出口；禁止为通过校验编造能力。 -->
 
 ### 新增能力
 

package/config/upstream-mirrors.json

@@ -0,0 +1,12 @@
+{
+  "_comment": "维护者拉取上游内容时的镜像前缀列表，按顺序尝试，首个成功即用。空字符串 \"\" 表示直连。",
+  "superpowers": [
+    "https://gh-proxy.com/",
+    "https://ghfast.top/",
+    ""
+  ],
+  "openspec": [
+    "https://registry.npmmirror.com",
+    "https://registry.npmjs.org"
+  ]
+}

package/config/workspace-agents.sample.md

@@ -1,39 +1,43 @@
-# 业务空间使用说明（AI Agent 导航）
-
-本目录是由 `@jspg-ai/coding-bb` 初始化的**多仓库联动开发业务空间**。
-进入本目录工作时，请先按本文件理解目录职责与协作约定，再动手。
-
-## 核心约定
-
-1. **本目录不做需求开发**。本目录（业务空间主分支）只负责组织与调度；所有需求开发都在 `.worktrees/worktree-<需求名>/` 隔离目录内进行。
-2. **AI 配置安装在空间根**：编码规范、OpenSpec 命令、worktree 管理技能都装在本目录（`cbb setup` / `cbb update` 安装）；worktree 内**不安装** AI 配置，AI 会话始终以空间根为基础。
-3. **接到新需求先建 worktree**：在本目录执行 `/cbb:worktree-init <需求名>`（opencode 写法：`/cbb-worktree-init`）。它会为 `workspace-config.json` 中的全量关联应用同步创建同名 worktree。
-4. **开发命令在本会话执行，写操作指向 worktree**：需求提案 / 实现 / 验证 / 归档（`/opsx:propose` → `/opsx:apply` → `/opsx:verify` → `/opsx:archive`）在空间根会话执行；但所有产生写操作的命令（git commit / openspec / 构建 / 测试 / 文件修改）必须以 `.worktrees/worktree-<需求名>/`（或其应用子目录）为工作目录（显式 `cd` 或绝对路径）；**禁止在空间根（主分支）执行写操作**。
-5. **关联应用增减只改配置**：编辑 `workspace-config.json` 的 `apps` 数组（`name` / `repo` / `side` / `desc`），然后用同一需求名重跑 worktree 初始化即幂等补齐；不要手工 `git clone` 应用仓库。
-6. **不要绕过 worktree 直接修改 `.codespace/` 或本目录的代码**。`.codespace/` 是工具维护的基准代码，不是开发区。
-
-## 目录结构与职责
-
-| 路径 | 职责 | 维护方式 |
-|------|----------|----------|
-| `workspace-config.json` | 关联应用清单，所有应用联动的唯一数据源 | 人工编辑 |
-| `.codespace/` | 各关联应用的基准代码（每个应用一个子目录） | `cbb setup` 与 worktree 流程自动 clone / fetch；**勿手动编辑**；已 gitignore，不提交 |
-| `.worktrees/` | 需求隔离开发区（每个需求一个 `worktree-<需求名>/` 目录） | worktree 命令自动创建 / 清理；不提交（首次执行 worktree 流程时自动加入 .gitignore） |
-| `openspec/` | OpenSpec 工作流配置（`config.yaml` + `schemas/`） | 由 cbb 安装；需求变更产物（`openspec/changes/` 等）在**需求工作树内**生成，随需求分支提交 |
-| `.claude/` `.qoder/` `.opencode/` | AI 工具适配目录：编码规范规则、OpenSpec 命令、worktree 管理技能与命令 | 由 cbb 按 setup 时选择的工具安装；已 gitignore，不提交，勿手动改 |
-| `.cbb/` | cbb 安装清单，记录本包管理的全部路径 | 由 cbb 管理；**勿手动编辑** |
-
-## 典型流程
-
-```
-本目录：/cbb:worktree-init <需求名>
-  → 继续在当前会话开发：写操作命令以 .worktrees/worktree-<需求名>/ 为工作目录
-    （/opsx:propose → /opsx:apply → /opsx:verify → /opsx:archive）
-  → /cbb:worktree-push 推送 → 合并后 /cbb:worktree-close 关闭
-```
-
-> 命令写法因 AI 工具而异：Claude Code / Qoder 为 `/cbb:worktree-init`，opencode 为 `/cbb-worktree-init`；`/opsx:*` 同理（opencode 为 `/opsx-*`）。
-
----
-
-本文件由 `@jspg-ai/coding-bb` 生成（仅缺失时写入，之后不会覆盖或删除，可自由增补团队约定）。
+# 业务空间使用说明（AI Agent 导航）
+
+本目录是由 `@jspg-ai/coding-bb` 初始化的**多仓库联动开发业务空间**。
+进入本目录工作时，请先按本文件理解目录职责与协作约定，再动手。
+
+## 核心约定
+
+1. **本目录不做需求开发**。本目录（业务空间主分支）只负责组织与调度；需求开发的**写操作**都在 `.worktrees/worktree-<需求名>/` 隔离目录内进行，**AI 会话仍停在空间根**（worktree 内不装 AI 配置）。
+2. **AI 配置安装在空间根**：编码规范、OpenSpec 命令、worktree 管理技能都装在本目录（`cbb setup` / `cbb update` 安装）；worktree 内**不安装** AI 配置，AI 会话始终以空间根为基础。
+3. **接到新需求先建 worktree**：使用 `/cbb-worktree-init <需求名>`（skill 形态，各工具写法见文末），或直接自然语言说"为 <需求名> 创建工作空间"。它会为 `workspace-config.json` 中的全量关联应用同步创建同名 worktree。
+4. **开发命令在本会话执行，写操作指向 worktree**：需求提案 / 实现 / 验证 / 归档（`/opsx:propose` → `/opsx:apply` → `/opsx:verify` → `/opsx:archive`）在空间根会话执行；但所有产生写操作的命令（git commit / openspec / 构建 / 测试 / 文件修改）必须以 `.worktrees/worktree-<需求名>/`（或其应用子目录）为工作目录（显式 `cd` 或绝对路径）；**禁止在空间根（主分支）执行写操作**。
+5. **关联应用增减只改配置**：编辑 `workspace-config.json` 的 `apps` 数组（`name` / `repo` / `side` / `desc`），然后用同一需求名重跑 worktree 初始化即幂等补齐；不要手工 `git clone` 应用仓库。
+6. **不要绕过 worktree 直接修改 `.codespace/` 或本目录的代码**。`.codespace/` 是工具维护的基准代码，不是开发区。
+
+## 目录结构与职责
+
+| 路径 | 职责 | 维护方式 |
+|------|----------|----------|
+| `workspace-config.json` | 关联应用清单，所有应用联动的唯一数据源 | 人工编辑 |
+| `.codespace/` | 各关联应用的基准代码（每个应用一个子目录） | `cbb setup` 与 worktree 流程自动 clone / fetch；**勿手动编辑**；已 gitignore，不提交 |
+| `.worktrees/` | 需求隔离开发区（每个需求一个 `worktree-<需求名>/` 目录） | worktree 命令自动创建 / 清理；不提交（首次执行 worktree 流程时自动加入 .gitignore） |
+| `openspec/` | OpenSpec 工作流配置（`config.yaml` + `schemas/`） | 由 cbb 安装；需求变更产物（`openspec/changes/` 等）在**需求工作树内**生成，随需求分支提交 |
+| `.claude/` `.qoder/` `.opencode/` `.codebuddy/` `.trae/` | AI 工具适配目录：编码规范规则、OpenSpec 命令、worktree 管理技能（skill 形态） | 由 cbb 按 setup 时选择的工具安装；已 gitignore，不提交，勿手动改 |
+| `.cbb/` | cbb 安装清单与状态（`.managed-by-cbb`、`.last-tools`） | 由 cbb 管理；**勿手动编辑** |
+
+## 典型流程
+
+```
+本目录：对 AI 说"为 <需求名> 创建工作空间"（或 /cbb-worktree-init <需求名>）
+  → 继续在当前会话开发：写操作命令以 .worktrees/worktree-<需求名>/ 为工作目录
+    （/opsx:propose → /opsx:apply → /opsx:verify）
+  → 说"提交并推送"（或 /cbb-worktree-push）→ 结尾会提案生成 MR 预填链接（提往测试分支）
+  → 测试环境验收通过 → /opsx:archive → 正式合并走公司流程
+  → 全链路完成后说"关闭工作空间"（或 /cbb-worktree-close）
+```
+
+> worktree 管理三件套（init / close / push）以 **skill 形态**分发：既能被 AI 在对话中按意图**自动触发**，也能用斜杠命令手动指定（`/cbb-worktree-init` 等，各工具一致）。OpenSpec 命令为 `/opsx:propose`（opencode 扁平化为 `/opsx-propose`）。
+
+---
+
+本文件由 `@jspg-ai/coding-bb` 生成（仅缺失时写入，之后不会覆盖或删除，可自由增补团队约定）。
+
+> ⓘ 本文件仅供导航；目录纪律以 cbb 安装的编码规范规则（`cbb-ai-behavior.md` 第 8 条）为准，该规则随 `cbb update` 更新。

package/openspec/.version

@@ -1,6 +1,5 @@
 {
-  "sha": "9d4e5974e5c0d9a09b9c6c1e1eb0975e80ec4461",
-  "branch": "main",
+  "version": "1.13.1",
   "repo": "Fission-AI/OpenSpec",
-  "updatedAt": "2026-09-12T00:00:00.000Z"
+  "renderedAt": "2026-09-19T13:22:53.815Z"
 }