@jspg-ai/coding-bb 0.0.3-beta.3 → 0.0.3-beta.31

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）已提交到需求分支（轻量模式：空间根 main 分支）；未提交时先询问用户是否现在提交（可随 cbb-worktree-push 一并推送；轻量模式提交后即 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,14 @@ 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" 提示语以本段为准。
+
+    **轻量模式变体**（本次 change 完全不涉及应用代码，产物在空间根仓库）：无 worktree push / 测试分支 MR 环节，两条路径替换为——A（推荐）"先 push main 交付、观察无回归后再 archive" / B"立即 archive 落定产物，再 push main"；main 提交不得悬空本地。

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

package/config/workspace-agents.sample.md

@@ -1,38 +1,9 @@
-# 业务空间使用说明（AI Agent 导航）
+# AGENTS.md
 
-本目录是由 `@jspg-ai/coding-bb` 初始化的**多仓库联动开发业务空间**。
-进入本目录工作时，请先按本文件理解目录职责与协作约定，再动手。
+本空间由 `@jspg-ai/coding-bb` 初始化（升级用 `cbb update`）。
 
-## 核心约定
-
-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-*`）。
+- **行为准则与开发纪律**（双模式、基准 = `origin/main`、提交防线、推送出口）：见你所用 AI 工具规则目录中的 `cbb-ai-behavior.md`——各工具自动加载；未适配的工具可任选一处直接读，如 `.claude/rules/cbb-ai-behavior.md` 或 `.qoder/rules/` 下同名文件。
+- **空间事实**：关联应用清单（增减应用即编辑它）见 `CBB-WORKSPACE.json`；目录职责建议维护在你自己的 `README.md`。
 
 ---
 

package/external/frontend-design/.version

@@ -0,0 +1,6 @@
+{
+  "repo": "anthropics/skills",
+  "ref": "41bbe19d1a1a7eaab5e7bb9050a417e5c6cffc8f",
+  "path": "skills/frontend-design",
+  "updatedAt": "2026-09-28T07:10:02.694Z"
+}

package/external/frontend-design/LICENSE.txt

@@ -0,0 +1,177 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS

package/external/frontend-design/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: frontend-design
+description: Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults.
+license: Complete terms in LICENSE.txt
+---
+
+# Frontend Design
+
+Approach this as the design lead at a design studio known for giving every client a distinct visual identity that is not mistaken for anyone else's. This client has already rejected proposals that felt cliché or templated, and is paying for a distinctive point of view: make deliberate, opinionated choices about palette, typography, and layout that are specific to this brief, and take aesthetic risk if justified.
+
+## Ground your designs in the subject matter
+
+If the brief does not identify what the product or subject matter is, identify it yourself before designing, and confirm with the client. You can come up with one concrete subject, the design's audience, and the design's primary job, as a proposal. If there's any information in your memory about the client's preferences or context about what they're building, use that as a hint. The subject's industry, subject matter, materials, and vernacular are where distinctive visual choices come from — a design for a toy for girls aged 8–11 will be very aesthetically different from a dashboard for financial analysts. Build with the brief's real content and subject matter throughout.
+
+## Design principles
+
+For web designs, the hero is the first thing viewers will see. Open with the most characteristic thing in the subject's world, in the form that is most appropriate: a headline, an image, an animation, a live demo, an interactive moment, or other treatments. Be deliberate with your choice: a big number with a small label, supporting stats, and a gradient accent is the default treatment, so only use it if that's truly the best option.
+
+Typography carries the personality of the page. You don't need a different typeface for display or headline text and body content: use one family or two, and if two, make them clearly distinct.
+
+Choose your typefaces deliberately, not the default families you would reach for on any other project, and set a clear type scale following the default guidance of The Elements of Typographic Style with intentional weights, widths, and spacing. When type is used as a headline or visual element, use the type treatment itself as an active part of the design, not a neutral delivery vehicle for the content.
+
+Default to line lengths of less than 80 characters. Serif typefaces can have slightly longer line lengths; give serif body text slightly more line-height than a sans-serif.
+
+Avoid these default typographic treatments; they are the commonest tells of a generated page:
+- Accenting just a single word or phrase in a headline, like putting one word in italic/bold or a different color.
+- Using all caps for labels.
+- Adding unnecessary typographic labels above content.
+
+Visual structure is information. Structural devices like outlines, borders, numbering, eyebrows, dividers, labels, etc., encode useful information about the content rather than decorate it. Many generic designs use numbered markers (01 / 02 / 03), but that's only appropriate if the content actually is a sequence — like a stepped process or a timeline. Before adding numbered markers, check the content really is a sequence.
+
+Use non-user-triggered motion sparingly and deliberately, only to draw attention. A single orchestrated moment — one page-load sequence or one reveal — lands better than scattered effects; fade-and-slide-up entrances on each section and hover transitions on every card are the generic default and read as AI-generated. Motion that answers a person's action (opening, expanding, confirming) is welcome when it shows what changed.
+
+Consider written content carefully. Often a design brief may not contain real content, and it's up to you to come up with copy and placeholder content. Copy can make a design feel as templated as the design itself. See the below section on writing for more guidance.
+
+## Process: plan, review against the brief, build, critique
+
+For calibration, AI-generated design right now clusters around some traits:
+1. a warm cream background (near #F4F1EA) with a high-contrast serif display and a terracotta or warm-clay accent (often near #D97757 — Anthropic's own Claude-interaction accent, so on a user's brief it reads as a tell);
+2. a near-black background with a single bright acid-green or vermilion accent;
+3. a broadsheet-style layout with hairline rules, zero border-radius, and dense newspaper-like columns;
+4. the SaaS-card kit: content chopped into identical rounded cards, one border-radius on everything regardless of hierarchy, the same soft grey shadow (rgba(0,0,0,.1)) under each, and gradient washes as decoration;
+5. template chrome that appears whatever the subject: a tracked-out ALL-CAPS eyebrow label above every heading; meta strings joined with middle dots ('A · B · C'); labels built as 'WORD — fragment' with a spaced em dash; tinted near-black (#0B0B0B, #111) standing in for black; a monospace face for small data labels; a '→' appended to link and button text.
+
+All traits are legitimate for some briefs, but they are defaults rather than choices, and they appear regardless of subject. Where the brief pins down a visual direction, follow it exactly — the brief's own words always win, including when it asks for one of these looks. Where it leaves an axis free, don't spend that freedom on one of these defaults. As with a hired human designer, there's often a careful balance between doing what you're good at and taking each project as a chance to experiment and learn.
+
+Work in two passes. First, brainstorm a short design plan based on the client's design brief: create a compact token system with color, type, layout, and principles.
+- Color: describe the core base palette as 4–6 named hex values.
+- Type: the typefaces and their roles.
+- Layout: a layout concept, using one-sentence prose descriptions and ASCII wireframes to ideate and compare. Include alignment guidance; should the content be left aligned, center aligned, justified?
+- Principles: the high-level guidance for what makes this page unique.
+
+Then review that plan against the brief before building: if any part of it reads like the generic default you would produce for any similar page (work through a similar prompt to see if you arrive somewhere similar) rather than a choice made for this specific brief — revise that part, say what you changed and why. Only after you've confirmed the relative uniqueness of your design plan should you start to write the code, following the revised plan.
+
+When writing the code, be careful of structuring your CSS selector specificities. It's easy to generate CSS classes that cancel each other out (especially with a type-based selector like .section and an element-based selector like .cta). This can happen often with padding/margin between sections.
+
+## Restraint and self-critique
+
+Spend your boldness in one place. Let one element be the memorable thing, keep everything around it quiet and disciplined, and cut any decoration that does not serve the brief. Build to a quality floor without announcing it: responsive down to mobile, visible keyboard focus, reduced motion respected, visually accessible, harmonious color palettes. Critique your own work as you build, taking screenshots to review if your environment supports it — a picture is worth 1000 tokens. Consider Chanel's advice: before leaving the house, take a look in the mirror and remove one accessory. Human creatives have memory and always try to do something new, so if you have a space to quickly jot down notes about what you've tried, it can help you in future passes.
+
+## More on writing in design
+
+Words appear in a design for one reason: to make it easier to understand and use. They are design content, not decoration. Bring the same intentionality and minimalism to copywriting that you would bring to spacing and color. Before writing anything, ask what the design needs to say, and how it can best be said to help the person navigate the experience.
+
+Write from the end user's perspective. Name things by what users will understand in simple language, not by how the system is built. A user manages notifications, not webhook config. Describe what something is or does in plain terms rather than selling it. Being specific and legible to new users is always better than being clever.
+
+Use active voice as default. A CTA says exactly what happens when it is used: "Save changes," not "Submit." An action keeps the same name through the whole flow, so the button that says "Publish" produces a toast that says "Published." The vocabulary of an interface is the signposting for someone navigating the product. Cohesion and consistency are how people learn their way around.
+
+Treat failure and emptiness as moments for direction, not mood. Explain what went wrong and how to fix it, in the interface's voice rather than a person's. Errors don't apologize, and they are never vague about what happened. An empty screen is an invitation to act.
+
+Keep the tone conversational: plain verbs, sentence case, no filler, with tone matched to the brand and the audience. Let each written element do exactly one job.

package/openspec/.version

@@ -1,6 +1,5 @@
 {
-  "sha": "9d4e5974e5c0d9a09b9c6c1e1eb0975e80ec4461",
-  "branch": "main",
+  "version": "1.13.2",
   "repo": "Fission-AI/OpenSpec",
-  "updatedAt": "2026-09-12T00:00:00.000Z"
+  "renderedAt": "2026-09-28T07:29:28.008Z"
 }