@jspg-ai/coding-bb 0.0.2-beta.29 → 0.0.3-beta.12

package/cbb/worktrees/skills/cbb-worktree-push/SKILL.md

@@ -1,19 +1,15 @@
 ---
 name: cbb-worktree-push
-description: "跨 worktree 提交并推送当前需求的所有关联仓库。触发：用户说'提交'/'commit'/'push'/'推送'/'提交并push'/'推到远端'；用户在 .worktrees/worktree-<需求名>/ 下工作要求批量推送；apply 完成后准备推送所有 worktree；close-worktree 前需要先推送未提交改动。"
-license: MIT
-compatibility: Requires git (>=2.30) and Node.js (>=16.7.0). All commands are pure Node.js scripts under `scripts/`, fully cross-platform (Windows / macOS / Linux, bash / PowerShell / Git Bash).
-metadata:
-  author: Contributors
-  version: "1.0"
-  generatedBy: coding-bb
+description: "提交并推送当前需求的所有关联仓库（跨 worktree 批量）。触发：用户说'提交'/'commit'/'push'/'推送'/'提交并push'/'推到远端'；用户在 .worktrees/worktree-<需求名>/ 下工作要求批量推送；apply 完成后准备推送所有 worktree；close-worktree 前需要先推送未提交改动。注意：本技能会先识别场景——不在 cbb 工作空间时降级为普通单仓库提交推送。"
 ---
 
 # Push Worktrees（跨平台脚本化版本 v1.0）
 
-跨 worktree 提交并推送当前需求的所有关联仓库到 origin。专门解决"开发完成后批量推送"和"用户口语化提交并push"两类场景，弥补 [cbb-worktree-init Step 3.4](file:///d:/workspace/va-ai/coding-bb/cbb/worktrees/skills/cbb-worktree-init/SKILL.md) 仅推送初始空 commit 的缺口。
+提交并推送当前需求的所有关联仓库（跨 worktree 批量）。专门解决"开发完成后批量推送"和"用户口语化提交并push"两类场景，弥补 [cbb-worktree-init Step 3.4](file:///d:/workspace/va-ai/coding-bb/cbb/worktrees/skills/cbb-worktree-init/SKILL.md) 仅推送初始空 commit 的缺口。
 
-**启动时声明：** "我正在使用 cbb-worktree-push 技能来批量提交并推送当前需求的所有 worktree 仓库。"
+> **本技能描述含宽泛触发词（"提交"/"push"），允许被误触发**。因此第一步永远是 **Step 0 场景识别**：在 cbb 工作空间内才走跨 worktree 批量流程；在普通 git 仓库降级为单仓库提交推送；非 git 目录则退出。
+
+**启动时声明：** "我正在使用 cbb-worktree-push 技能来推送当前需求的关联仓库。"
 
 ## 核心原则
 
@@ -30,12 +26,18 @@ metadata:
 
 ## 调用脚本的统一方式
 
-**所有脚本必须用绝对路径调用**（Qoder 沙箱中 AI agent 的 cwd 不一定是技能目录）。
+**重要**：本技能的所有脚本位于**本 SKILL.md 所在目录的 `scripts/` 下**（skill 目录）。
+
+调用时用**本技能目录的绝对路径**拼接脚本名（AI 读取本 SKILL.md 时即已知该目录）：
 
 ```
-node "<ws_root>/.qoder/skills/cbb-worktree-push/scripts/<name>.js" <参数>
+node "<skill_dir>/scripts/<name>.js" <参数>
 ```
 
+> - `<skill_dir>` = 本 SKILL.md 所在目录的绝对路径（AI 从读取路径即可推出）
+> - **cwd 必须保持在工作空间根目录**：脚本按 cwd 定位 `workspace-config.json` 与 git 仓库
+> - 不要用 `./scripts/...` 裸相对路径（AI 的 cwd 不是技能目录，会解析失败）
+
 脚本输出：
 - 人类可读报告（OK / FAIL / WARN）
 - 机器可读摘要（末行以 `COMMIT_RESULT` / `PUSH_RESULT` 开头）
@@ -43,22 +45,48 @@ node "<ws_root>/.qoder/skills/cbb-worktree-push/scripts/<name>.js" <参数>
 
 ---
 
-## Step 0：定位工作空间
+## Step 0：场景识别（先判场景，再定策略）
+
+**本技能允许被"提交"/"push"这类宽泛措辞误触发**。执行任何操作前，先判断当前处于哪种场景，按场景选择策略——**不要硬套 cbb 工作空间流程**。
+
+判断依据（任一命中即定场景）：
+
+| 场景 | 判据 | 策略 |
+|------|------|------|
+| **A. cbb 工作空间根** | cwd（或其 git 顶层）含 `workspace-config.json`；`find-workspace-root.js` 退出码 0 | 走 **Step 1 → 6** 的跨 worktree 批量流程 |
+| **B. worktree 内** | cwd 命中 `<ws_root>/.worktrees/worktree-<需求名>/` | 用 cwd 反推 `<需求名>`，走 **Step 1 → 6** 批量流程 |
+| **C. 普通 git 仓库** | 在 git 仓库内，但无 `workspace-config.json`（`find-workspace-root.js` 退出码 1） | **降级为单仓库提交推送**：不调 worktree 脚本，按常规 `git add -u` → 向用户询问 commit 信息 → `git commit` → `git push`（保留本 skill 的"必问 commit 信息"约束） |
+| **D. 非 git 目录** | `git rev-parse --is-inside-work-tree` 失败 | 说明"当前目录不是 git 仓库"，终止，不做任何操作 |
+
+**判场景与定位（A/B 场景）：**
 
 ```bash
-node "<ws_root>/.qoder/skills/cbb-worktree-push/scripts/find-workspace-root.js"
+node "<skill_dir>/scripts/find-workspace-root.js"
 ```
 
 **解读末行**：
-- 退出码 0 + 末行（纯路径） → WS_ROOT
-- 退出码 1 → 未找到工作空间根目录，**终止流程**
+- 退出码 0 + 末行（纯路径） → WS_ROOT（场景 A/B），继续 Step 1
+- 退出码 1 → 无工作空间：**先判断场景 C 还是 D**（`git rev-parse --is-inside-work-tree`）：
+  - 是 git 仓库 → 场景 C，按降级策略走（见下）
+  - 不是 → 场景 D，终止
+
+**场景 C 降级流程**（普通仓库误触）：
+
+1. `git status` 报告改动现状
+2. 直接对话询问 commit 信息（**禁止**自动生成）
+3. `git add -u`（默认不含未追踪文件；用户明确要求时才 `git add -A`）
+4. `git commit -m "<用户提供的信息>"`
+5. `git push`（无 upstream 时先询问用户是否 `-u`）
+6. 汇报结果；**不要**提及 worktree 批量流程
+
+> 场景 C 是兜底：让"提交代码"在普通仓库里也能正常完成，而不是因找不到 `workspace-config.json` 报错。
 
 ---
 
-## Step 1：识别目标 worktree
+## Step 1：识别目标 worktree（A/B 场景）
 
 ```bash
-node "<ws_root>/.qoder/skills/cbb-worktree-push/scripts/find-target-worktree.js" "<ws_root>"
+node "<skill_dir>/scripts/find-target-worktree.js" "<ws_root>"
 ```
 
 **解读末行**：
@@ -72,7 +100,7 @@ node "<ws_root>/.qoder/skills/cbb-worktree-push/scripts/find-target-worktree.js"
 
 ```bash
 # 仅 commit 阶段先做 dry-run 预览
-node "<ws_root>/.qoder/skills/cbb-worktree-push/scripts/commit-worktrees.js" "<ws_root>" "<branch>" --message "preview" --dry-run
+node "<skill_dir>/scripts/commit-worktrees.js" "<ws_root>" "<branch>" --message "preview" --dry-run
 ```
 
 **解读末行 `COMMIT_RESULT`**：每项仓库的状态
@@ -119,16 +147,16 @@ AI agent 在执行真实 commit 前**必须**在对话中向用户确认 commit
 
 ```bash
 # 统一信息
-node "<ws_root>/.qoder/skills/cbb-worktree-push/scripts/commit-worktrees.js" "<ws_root>" "<branch>" --message "feat(<branch>): 实现客户运费逻辑"
+node "<skill_dir>/scripts/commit-worktrees.js" "<ws_root>" "<branch>" --message "feat(<branch>): 实现客户运费逻辑"
 
 # 多仓库分别
-node "..." "<ws_root>" "<branch>" --per-repo "ep-foo-app:feat(<branch>): 实现 saveClientExpectFreight;ep-bar-app:refactor(<branch>): 拆分 PlanService"
+node "<skill_dir>/scripts/commit-worktrees.js" "<ws_root>" "<branch>" --per-repo "ep-foo-app:feat(<branch>): 实现 saveClientExpectFreight;ep-bar-app:refactor(<branch>): 拆分 PlanService"
 
 # 含未追踪文件
-node "..." "<ws_root>" "<branch>" --message "..." --untracked
+node "<skill_dir>/scripts/commit-worktrees.js" "<ws_root>" "<branch>" --message "..." --untracked
 
 # wt_path 形式（用户在 worktree 内）
-node "..." "<ws_root>/.worktrees/worktree-<branch>" --message "..."
+node "<skill_dir>/scripts/commit-worktrees.js" "<ws_root>/.worktrees/worktree-<branch>" --message "..."
 ```
 
 **选项**：
@@ -155,10 +183,10 @@ node "..." "<ws_root>/.worktrees/worktree-<branch>" --message "..."
 ## Step 5：批量 push
 
 ```bash
-node "<ws_root>/.qoder/skills/cbb-worktree-push/scripts/push-worktrees.js" "<ws_root>" "<branch>"
+node "<skill_dir>/scripts/push-worktrees.js" "<ws_root>" "<branch>"
 
 # 或 wt_path 形式
-node "..." "<ws_root>/.worktrees/worktree-<branch>"
+node "<skill_dir>/scripts/push-worktrees.js" "<ws_root>/.worktrees/worktree-<branch>"
 ```
 
 **解读末行 `PUSH_RESULT`**：
@@ -210,8 +238,7 @@ node "..." "<ws_root>/.worktrees/worktree-<branch>"
     workspace: ✅ origin/<branch>
     ep-foo-app: ✅ origin/<branch>
     ep-bar-app: ⚠️  远程分支已存在（需用户决策 → 已关联）
-  AI 配置目录：worktree 内独立安装，无需处理
-  后续：可继续开发 / 调 /opsx:verify 验证 / 调 /opsx:archive 归档 / 调 /cbb:worktree-close 关闭
+  后续：可继续开发 / 调 /opsx:verify 验证 / 调 /opsx:archive 归档 / 调 `cbb-worktree-close` skill 关闭
 ```
 
 ---
@@ -220,8 +247,11 @@ node "..." "<ws_root>/.worktrees/worktree-<branch>"
 
 | 场景 | 处理方式 |
 |------|----------|
-| 用户说"提交并push"且 cwd 在 worktree 内 | 自动用 cwd 反推分支，Step 2 扫描后进入 Step 3 问 commit 信息 |
-| 用户说"提交并push"且 cwd 在 WS_ROOT | Step 0 定位后，多个 worktree 时让用户选 |
+| **任何触发** | **先做 Step 0 场景识别**，再决定策略 |
+| 场景 A：cwd 在 cbb 工作空间根 | find-workspace-root 成功 → 多个 worktree 时让用户选 |
+| 场景 B：cwd 在 worktree 内 | 自动用 cwd 反推分支，扫描后进入询问 commit 信息 |
+| 场景 C：cwd 在普通 git 仓库（无 workspace-config.json） | **降级为单仓库提交推送**，不调用 worktree 脚本 |
+| 场景 D：cwd 非 git 目录 | 说明情况并终止，不做任何操作 |
 | commit 信息缺失 | 必须询问用户；禁止自动生成（可基于 apply task 上下文给建议） |
 | 多仓库需不同 commit 信息 | 用 `--per-repo "ep-foo:m1;ep-bar:m2"`，必须由用户逐条提供 |
 | 仓库干净 | commit-worktrees 自动 skipped，只 push 不 commit |
@@ -236,6 +266,11 @@ node "..." "<ws_root>/.worktrees/worktree-<branch>"
 
 ## 常见错误
 
+### 误触后硬套 worktree 流程
+
+- **问题：** 用户在普通仓库说"提交代码"，技能被 description 匹配触发，直接跑 `find-workspace-root.js` 失败并报错终止
+- **修复：** Step 0 先判场景；场景 C（普通 git 仓库）降级为单仓库提交推送，不调用 worktree 脚本、不提及批量流程
+
 ### 自动生成 commit 信息不让用户确认
 
 - **问题：** agent 拍脑袋写 "feat: xxx"，与用户实际意图不符
@@ -282,12 +317,13 @@ node "..." "<ws_root>/.worktrees/worktree-<branch>"
 - push 失败后跳过失败仓库直接继续
 - 远程分支已存在时脚本自动 set-upstream-to
 - AI 询问关联选项前不输出 commit 元信息
-- 沙箱内 node 不可用时强行继续 → 改为 fail-fast 提示用户
+- 运行环境 node 不可用时强行继续 → 改为 fail-fast 提示用户
 
 **必须执行**
 
-- 严格按 Step 0 → 1 → 2 → 3 → 4 → 5 → 6 顺序执行
-- 所有脚本调用以 `node "..." "<绝对路径>"` 形式发起
+- 严格按 Step 0 → 1 → 2 → 3 → 4 → 5 → 6 顺序执行（场景 C/D 除外，按 Step 0 降级策略）
+- 所有脚本调用以 `node "<skill_dir>/scripts/<name>.js"` 形式发起（`<skill_dir>` = 本 SKILL.md 所在目录）
+- 执行脚本时 cwd 保持在工作空间根；场景 C 降级时按普通 git 流程
 - Step 2 dry-run 必跑，让用户看到将要 commit 的内容
 - Step 3 必问用户 commit 信息（自由文本），禁止自动生成
 - commit 信息涉及业务语义时（feature/refactor/fix 等）必须从 apply task 上下文生成建议并由用户确认

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]

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

@@ -5,33 +5,37 @@
 
 ## 核心约定
 
-1. **本目录不做需求开发**。本目录（业务空间主分支）只负责组织与调度；所有需求开发都在 `.worktrees/worktree-<需求名>/` 隔离目录内进行。
-2. **接到新需求先建 worktree**：在本目录执行 `/cbb:worktree-init <需求名>`（opencode 写法：`/cbb-worktree-init`）。它会为 `workspace-config.json` 中的全量关联应用同步创建同名 worktree，并自动安装沙箱内的编码规范与 OpenSpec 工作流。
-3. **开发动作全部在 worktree 内**：需求提案 / 实现 / 验证 / 归档（`/opsx:propose` → `/opsx:apply` → `/opsx:verify` → `/opsx:archive`）在 worktree 沙箱内执行；跨仓库提交推送用 `/cbb:worktree-push`，需求收尾用 `/cbb:worktree-close`。
-4. **关联应用增减只改配置**：编辑 `workspace-config.json` 的 `apps` 数组（`name` / `repo` / `side` / `desc`），然后用同一需求名重跑 worktree 初始化即幂等补齐；不要手工 `git clone` 应用仓库。
-5. **不要绕过 worktree 直接修改 `.codespace/` 或本目录的代码**。`.codespace/` 是工具维护的基准代码，不是开发区。
+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/` 等）在 worktree 内生成，随需求分支提交 |
-| `.claude/` `.qoder/` `.opencode/` | AI 工具适配目录：worktree 管理技能与命令；**故意不含**编码规范（防止在空间根直接开发） | 由 cbb 按 setup 时选择的工具安装；已 gitignore，不提交，勿手动改 |
-| `.cbb/` | cbb 安装清单，记录本包管理的全部路径 | 由 cbb 管理；**勿手动编辑** |
+| `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 管理；**勿手动编辑** |
 
 ## 典型流程
 
 ```
-本目录：/cbb:worktree-init <需求名>
-  → .worktrees/worktree-<需求名>/ 内开发（/opsx:propose → /opsx:apply → /opsx:verify → /opsx:archive）
-  → /cbb:worktree-push 推送 → 合并后 /cbb:worktree-close 关闭
+本目录：对 AI 说"为 <需求名> 创建工作空间"（或 /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-*`）。
+> 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/config/workspaces.json

@@ -15,6 +15,11 @@
       "name": "数据标注平台-AI开发工作空间",
       "repo": "http://git.portjs.cn/jspg-ai/ai-workspace/jspg-data-labeling-aiws.git",
       "businessLine": "yzg-ai"
+    },
+    {
+      "name": "集团EDI一体化-AI开发工作空间",
+      "repo": "http://git.portjs.cn/jspg-ai/ai-workspace/jspg-edi-yth-aiws.git",
+      "businessLine": "yth"
     }
   ]
 }

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"
 }