chore: 移除 openspec,迁移项目规范到 AGENTS.md,接入 superpowers 插件
This commit is contained in:
1
.gitignore
vendored
1
.gitignore
vendored
@@ -410,6 +410,7 @@ backend/bin
|
||||
backend/server
|
||||
backend/desktop
|
||||
!src/**/*
|
||||
docs/superpowers
|
||||
|
||||
# Embedfs generated
|
||||
embedfs/assets/
|
||||
|
||||
33
AGENTS.md
33
AGENTS.md
@@ -1 +1,32 @@
|
||||
严格遵守openspec/config.yaml中context声明的项目规范
|
||||
## 项目概览
|
||||
|
||||
- 本项目为 Bun 全栈应用（Alfred·阿福），Bun 是唯一包管理器和运行时，严禁使用 npm、pnpm、yarn、npx、pnpx
|
||||
- docs/user/ 记录用户使用方法，docs/development/ 记录开发技术细节
|
||||
- 使用中文（注释、文档、交流），面向中文开发者
|
||||
- 本项目无需考虑向前兼容性
|
||||
|
||||
## 文档入口（按顺序阅读）
|
||||
|
||||
- **优先阅读 docs/README.md** 获取文档路由、归属矩阵和影响分析规则
|
||||
- **其次阅读 docs/development/README.md** 获取完整开发规范、常用命令和质量门禁
|
||||
|
||||
## 全局红线
|
||||
|
||||
- 前端禁止导入 src/server/ 的后端运行时实现
|
||||
- 后端运行时代码禁止直接使用 console.\*，通过 Logger 实例输出
|
||||
- 新增逻辑必须编写完善的测试，不允许跳过任何测试
|
||||
- 每次代码变更必须执行文档影响分析（详见 docs/README.md）
|
||||
- 新增代码优先复用已有组件、工具、依赖库，不轻易引入新依赖
|
||||
|
||||
## Git 规范
|
||||
|
||||
- 提交信息中文，格式"类型: 简短描述"，类型：feat/fix/refactor/docs/style/test/chore
|
||||
- 禁止创建 git 操作 task
|
||||
|
||||
## 工作方式
|
||||
|
||||
- 积极使用 subagent 并行独立子任务，节省上下文空间；能并行的步骤明确并行
|
||||
- subagent 仅用于只读收集和分析，禁止用于文件修改、代码生成、git 操作或依赖安装
|
||||
- 单个文件或目录只分配给一个 subagent，不重复分配；subagent 输出文件路径、行号和问题摘要，不输出大段源码
|
||||
- 主 agent 负责最终结论：去重、交叉验证、合并同根因问题
|
||||
- 优先使用提问工具对用户确认
|
||||
|
||||
@@ -1,11 +1,7 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"plugin": ["superpowers@git+https://github.com/obra/superpowers.git"],
|
||||
"mcp": {
|
||||
"tdesign-mcp-server": {
|
||||
"enabled": true,
|
||||
"type": "local",
|
||||
"command": ["bunx", "tdesign-mcp-server@latest"]
|
||||
},
|
||||
"antd": {
|
||||
"enabled": true,
|
||||
"type": "local",
|
||||
|
||||
@@ -1,41 +0,0 @@
|
||||
schema: fast-drive
|
||||
|
||||
context: |
|
||||
## 项目概览
|
||||
- 本项目为 Bun 全栈应用（Alfred·阿福），Bun 是唯一包管理器和运行时，严禁使用 npm、pnpm、yarn、npx、pnpx
|
||||
- docs/user/ 记录用户使用方法，docs/development/ 记录开发技术细节
|
||||
- 使用中文（注释、文档、交流），面向中文开发者
|
||||
- 本项目无需考虑向前兼容性
|
||||
|
||||
## 文档入口（按顺序阅读）
|
||||
- **优先阅读 docs/README.md** 获取文档路由、归属矩阵和影响分析规则
|
||||
- **其次阅读 docs/development/README.md** 获取完整开发规范、常用命令和质量门禁
|
||||
|
||||
## 全局红线
|
||||
- 前端禁止导入 src/server/ 的后端运行时实现
|
||||
- 后端运行时代码禁止直接使用 console.*，通过 Logger 实例输出
|
||||
- 新增逻辑必须编写完善的测试，不允许跳过任何测试
|
||||
- 每次代码变更必须执行文档影响分析（详见 docs/README.md）
|
||||
- 新增代码优先复用已有组件、工具、依赖库，不轻易引入新依赖
|
||||
|
||||
## Git 规范
|
||||
- 提交信息中文，格式"类型: 简短描述"，类型：feat/fix/refactor/docs/style/test/chore
|
||||
- 禁止创建 git 操作 task
|
||||
|
||||
## 工作方式
|
||||
- 积极使用 subagent 并行独立子任务，节省上下文空间；能并行的步骤明确并行
|
||||
- subagent 仅用于只读收集和分析，禁止用于文件修改、代码生成、git 操作或依赖安装
|
||||
- 单个文件或目录只分配给一个 subagent，不重复分配；subagent 输出文件路径、行号和问题摘要，不输出大段源码
|
||||
- 主 agent 负责最终结论：去重、交叉验证、合并同根因问题
|
||||
- 优先使用提问工具对用户确认
|
||||
|
||||
rules:
|
||||
design:
|
||||
- fast-drive的design.md章节标题和正文使用中文；仅OpenSpec术语、文件名、schema字段名、命令和代码符号保留英文
|
||||
- 先前的讨论技术方案要尽可能体现在设计文档中，便于指导实现阶段不偏离已定的技术路线
|
||||
tasks:
|
||||
- fast-drive的tasks.md分组标题、任务描述和验证说明使用中文；每个任务必须保留OpenSpec CLI可解析的单行checkbox格式
|
||||
- 一行一个任务，严禁任务内容跨行
|
||||
- 如果是代码存在更新必须
|
||||
- 执行完整的测试、代码检查、格式检查等质量保障手段
|
||||
- 执行文档影响分析，更新 README.md 和/或 docs/ 下对应文档
|
||||
@@ -1,150 +0,0 @@
|
||||
name: fast-drive
|
||||
version: 1
|
||||
description: 快速 OpenSpec workflow - design -> tasks -> apply
|
||||
artifacts:
|
||||
- id: design
|
||||
generates: design.md
|
||||
description: 自包含的方案说明和执行计划
|
||||
template: design.md
|
||||
instruction: |
|
||||
创建 design.md，作为本次变更“改什么、为什么改、如何执行”的自包含事实来源。
|
||||
|
||||
本 workflow 不使用 proposal 或 specs artifacts。design.md MUST 保留前序探索和用户讨论中的重要结论，确保后续 apply 阶段即使经历上下文压缩或进入新会话，也能正确继续执行。
|
||||
|
||||
语言规则（强制）：
|
||||
|
||||
- fast-drive 的 design.md 使用中文章节标题和中文正文；仅文件名、OpenSpec 术语、schema 字段名、命令、代码符号和必要技术名词保留英文
|
||||
|
||||
- 最终 design.md 不得残留英文模板句子或英文占位内容，除非该英文是 OpenSpec 术语、文件名、schema 字段名、代码符号、命令或必要技术名词
|
||||
|
||||
面向看不到早期对话的人编写。简单变更保持精炼，但必须包含足够细节让执行无歧义。遇到以下情况时增加细节：
|
||||
|
||||
- 跨多个系统、团队、工作流或 artifacts 的横切变更
|
||||
|
||||
- 新增依赖、集成、供应商、工具、策略或外部输入
|
||||
|
||||
- 重要的信息模型、流程模型、数据模型或归属关系变化
|
||||
|
||||
- 涉及安全、隐私、合规、性能、运维或迁移复杂度
|
||||
|
||||
- 执行前需要先做决策才能降低歧义
|
||||
|
||||
- 前序讨论已经确认非显而易见的需求、约束或被否决方案
|
||||
|
||||
必需章节（建议使用以下中文章节标题）：
|
||||
|
||||
- **背景**：问题、当前状态、相关参考资料，以及触发本次变更的用户请求
|
||||
|
||||
- **讨论记录**：探索或前序讨论中必须保留的关键点，包括已确认结论、用户偏好、约束和重要的被否决方案
|
||||
|
||||
- **需求**：预期结果、行为/流程/接口/内容变化、连续性要求和验收标准
|
||||
|
||||
- **目标 / 非目标**：本次变更要达成的目标，以及明确不在范围内的内容
|
||||
|
||||
- **执行约束**：必须遵守的约束、禁止的做法、需保持的行为/流程、依赖限制，以及项目或 workflow 特有边界
|
||||
|
||||
- **影响范围**：与本次变更相关的具体 artifacts、参考资料、相关方、系统、工作流、文档、配置、资产或交接事项
|
||||
|
||||
- **决策**：关键选择及理由（为什么选 X 而不是 Y）。每个重要决策都要包含考虑过的替代方案，以及未选择它们的原因
|
||||
|
||||
- **执行计划**：主要工作流或待修改 artifacts、集成或交接点、执行顺序，以及必要的发布/落地说明
|
||||
|
||||
- **验证计划**：用于证明变更完成所需的验证检查、审查、批准、验收检查、文档检查、沟通检查和人工检查
|
||||
|
||||
- **风险 / 权衡**：已知限制和可能出错的事项
|
||||
格式：[风险] -> 缓解措施
|
||||
|
||||
- **待解决问题**：执行前仍需解决的决策、假设或未知项。必须区分会阻塞 apply 的问题和非阻塞后续问题。没有未决问题时使用“无”
|
||||
|
||||
可选章节（相关时添加，建议使用中文章节标题）：
|
||||
|
||||
- **迁移 / 发布计划**：发布步骤、沟通安排、归属、回滚或连续性策略
|
||||
|
||||
聚焦保留需求、理由、约束和方案。除非某个细节是讨论中明确做出的决策，否则避免逐行或逐步骤展开。
|
||||
|
||||
优先写可长期使用的摘要，而不是聊天记录转写。当具体 artifact 名称、数据/信息形状、示例、相关方、归属和边界场景会影响执行时，必须写清楚。
|
||||
|
||||
不要在 design.md 使用任务 checkbox；checkbox 只属于 tasks.md。
|
||||
|
||||
最终 design.md 不得包含未解决的模板注释、空表格行或占位文本。
|
||||
|
||||
如果信息缺失，写明假设和待解决问题，不要编造隐藏需求。不要依赖未写入文档的聊天上下文。
|
||||
requires: []
|
||||
- id: tasks
|
||||
generates: tasks.md
|
||||
description: 从 design.md 派生的可跟踪执行清单
|
||||
template: tasks.md
|
||||
instruction: |
|
||||
创建 tasks.md，将 design.md 拆解为可执行工作项。
|
||||
|
||||
**重要：必须遵守以下模板中的 checkbox 行格式。** apply 阶段会解析 checkbox 格式跟踪进度。未使用 `- [ ]` 的任务不会被跟踪。
|
||||
|
||||
语言规则（强制）：
|
||||
|
||||
- fast-drive 的 tasks.md 使用中文分组标题和中文任务描述；仅文件名、OpenSpec 术语、schema 字段名、命令、代码符号和必要技术名词保留英文
|
||||
|
||||
- 每个可跟踪任务必须保留 OpenSpec CLI 可解析的单行 checkbox 格式，例如 `- [ ] 1.1 任务描述` 或 `- [x] 1.1 已完成任务描述`
|
||||
|
||||
- 最终 tasks.md 不得残留英文模板任务或英文占位内容，除非该英文是 OpenSpec 术语、文件名、schema 字段名、代码符号、命令或必要技术名词
|
||||
|
||||
编写规则：
|
||||
|
||||
- 任务必须从 design.md 派生。不要依赖 proposal.md 或 specs artifacts；任何相关前序讨论都必须已经记录在 design.md 中
|
||||
|
||||
- 相关任务按 `##` 编号标题分组，分组标题使用中文
|
||||
|
||||
- 每个任务 MUST 是单行 checkbox：`- [ ] X.Y 任务描述`
|
||||
|
||||
- 任务粒度应足够小，能在一个会话内完成
|
||||
|
||||
- 按依赖顺序排序（先做必须先完成的事项）
|
||||
|
||||
- 当执行依赖执行约束、影响范围或待解决问题时，从上下文审查任务开始
|
||||
|
||||
- 需要时包含验证任务，覆盖检查、审查、批准、验收、文档、沟通和人工检查
|
||||
|
||||
- 除非仓库、版本控制或发布操作明确属于本次变更范围，否则不要包含这类任务
|
||||
|
||||
- 最终 tasks.md 不得包含未解决的模板注释、空表格行或占位任务文本
|
||||
|
||||
示例：
|
||||
|
||||
```
|
||||
## 1. 上下文审查
|
||||
|
||||
- [ ] 1.1 阅读 design.md，识别范围、需求、决策、执行约束和待解决问题
|
||||
- [ ] 1.2 审查“影响范围”中列出的相关 artifacts 和参考资料
|
||||
|
||||
## 2. 执行
|
||||
|
||||
- [ ] 2.1 执行 design.md 中的第一个具体工作项
|
||||
- [ ] 2.2 执行 design.md 中的下一个具体工作项
|
||||
|
||||
## 3. 验证
|
||||
|
||||
- [ ] 3.1 执行“验证计划”中要求的验证
|
||||
- [ ] 3.2 执行项目或 workflow 要求的质量检查
|
||||
- [ ] 3.3 执行“验证计划”中要求的人工审查或验收检查
|
||||
|
||||
## 4. 文档 / 沟通
|
||||
|
||||
- [ ] 4.1 如果行为、流程、接口、配置或使用方式发生变化，更新相关文档、runbook、沟通材料或项目参考资料
|
||||
```
|
||||
|
||||
以 design.md 中的范围、需求、决策、执行方向和验证预期为依据。
|
||||
|
||||
每个任务都应可验证：必须能明确判断任务何时完成。
|
||||
requires:
|
||||
- design
|
||||
apply:
|
||||
requires:
|
||||
- design
|
||||
- tasks
|
||||
tracks: tasks.md
|
||||
instruction: |
|
||||
先阅读 design.md，再阅读 tasks.md。
|
||||
同时遵守 workflow context/configuration，例如存在时读取 openspec/config.yaml，以及 design.md 引用的相关项目或 workflow 文档。
|
||||
将 design.md 视为范围、需求、决策、执行约束、执行方向和验证预期的事实来源。
|
||||
按依赖顺序处理待办任务，并在完成后及时标记。
|
||||
只有任务执行完成且必要验证完成后，才能标记任务完成。
|
||||
如果 tasks 与 design.md 冲突、design.md 存在阻塞性待解决问题，或需要澄清，必须暂停。
|
||||
@@ -1,77 +0,0 @@
|
||||
## 背景
|
||||
|
||||
<!-- 记录问题、当前状态、相关参考资料，以及触发本次变更的用户请求 -->
|
||||
|
||||
## 讨论记录
|
||||
|
||||
<!-- 记录探索或前序讨论中 apply 阶段必须保留的关键结论 -->
|
||||
|
||||
- 已确认结论：
|
||||
- 用户偏好：
|
||||
- 约束：
|
||||
- 被否决方案：
|
||||
|
||||
## 需求
|
||||
|
||||
<!-- 记录预期结果、行为/流程/接口/内容变化、连续性要求和验收标准 -->
|
||||
|
||||
| 需求 | 验收标准 |
|
||||
| ---- | -------- |
|
||||
| | |
|
||||
|
||||
## 目标 / 非目标
|
||||
|
||||
**目标：**
|
||||
<!-- 记录本次 design 要达成的目标 -->
|
||||
|
||||
**非目标：**
|
||||
<!-- 记录明确不在范围内的内容 -->
|
||||
|
||||
## 执行约束
|
||||
|
||||
<!-- 记录必须遵守的约束、禁止的做法、需保持的行为/流程、依赖限制，以及项目或 workflow 特有边界 -->
|
||||
|
||||
- 依赖限制：
|
||||
- 约束：
|
||||
- 质量门禁：
|
||||
- 相关方：
|
||||
- 文档 / 沟通：
|
||||
- 兼容性 / 连续性：
|
||||
|
||||
## 影响范围
|
||||
|
||||
<!-- 记录与本次变更相关的具体 artifacts、参考资料、相关方、系统、工作流、文档、配置、资产或交接事项 -->
|
||||
|
||||
| 范围 | Artifacts / 参考资料 | 预期变更 | 备注 |
|
||||
| ---- | -------------------- | -------- | ---- |
|
||||
| <!-- 范围 --> | <!-- Artifacts / 参考资料 --> | <!-- 预期变更 --> | <!-- 备注 --> |
|
||||
|
||||
## 决策
|
||||
|
||||
<!-- 记录关键决策、理由和考虑过的替代方案 -->
|
||||
|
||||
| 决策 | 理由 | 已否决替代方案 |
|
||||
| ---- | ---- | ---------------- |
|
||||
| | | |
|
||||
|
||||
## 执行计划
|
||||
|
||||
<!-- 记录主要工作流或待修改 artifacts、集成或交接点、执行顺序，以及必要的发布/落地说明 -->
|
||||
|
||||
## 验证计划
|
||||
|
||||
<!-- 记录用于证明变更完成所需的验证检查、审查、批准、验收检查、文档检查、沟通检查和人工检查 -->
|
||||
|
||||
| 需求 / 风险 | 验证方式 |
|
||||
| ----------- | -------- |
|
||||
| | |
|
||||
|
||||
## 风险 / 权衡
|
||||
|
||||
<!-- 格式：[风险] -> 缓解措施 -->
|
||||
|
||||
## 待解决问题
|
||||
|
||||
| 状态 | 问题 | 所需决策 |
|
||||
| ---- | ---- | -------- |
|
||||
| 无 | 无待解决问题。 | 无需决策 |
|
||||
@@ -1,19 +0,0 @@
|
||||
## 1. 上下文审查
|
||||
|
||||
- [ ] 1.1 阅读 design.md，识别范围、需求、决策、执行约束和待解决问题
|
||||
- [ ] 1.2 审查“影响范围”中列出的相关 artifacts 和参考资料
|
||||
|
||||
## 2. 执行
|
||||
|
||||
- [ ] 2.1 执行 design.md 中的第一个具体工作项
|
||||
- [ ] 2.2 执行 design.md 中的下一个具体工作项
|
||||
|
||||
## 3. 验证
|
||||
|
||||
- [ ] 3.1 执行“验证计划”中要求的验证
|
||||
- [ ] 3.2 执行项目或 workflow 要求的质量检查
|
||||
- [ ] 3.3 执行“验证计划”中要求的人工审查或验收检查
|
||||
|
||||
## 4. 文档 / 沟通
|
||||
|
||||
- [ ] 4.1 如果行为、流程、接口、配置或使用方式发生变化，更新相关文档、runbook、沟通材料或项目参考资料
|
||||
Reference in New Issue
Block a user