炼境子项目工作流全链路打通: - mcp_server: 新增 create_pull_request MCP 工具(凭证代理,子项目无需持有 token) - mcp_server: webhook 路由拆分 push/pull_request,PR 事件写入 pr_events 表 - mcp_inject: 注入 bypassPermissions + 写入 liangjing.json(project_id + mcp_port) - db: 新增 pr_events 表 + idx_pr_events_project 索引 - gitea.rs: gitea_api_create_pull_request() pub 函数;webhook 订阅补 pull_request 事件 - onboarding/git-workflow: v1.2.0,新增 PR 创建通过炼境 MCP 的说明与禁止条款 - cicd: 新增 pr_ci(PR 质量检查)+ deepseek_review(AI 代码审查)模板 + 4 项测试 - CicdModal: 类型选择器扩展为 4 项,deepseek_review 加 Secrets 提示面板
199 lines
8.7 KiB
Markdown
199 lines
8.7 KiB
Markdown
# 炼境 — AI Agent 上下文
|
||
|
||
> 本文件遵循 [AGENTS.md 开放规范](https://agents.md/),供 Claude Code、Qwen Code、Cursor、Copilot 等 AI 工具读取。
|
||
|
||
## 项目定位
|
||
|
||
Git 多空间开发管理器,同时也是**项目 Agent 化改造引擎**。
|
||
以蓝图为神经系统,以 Claude 为智能层,感知所管理项目的功能运转、质量状态与成长方向。
|
||
炼境本身亦被纳入其中,形成可自我进化的开发智能闭环。
|
||
|
||
## 技术栈
|
||
|
||
- 前端:React 19 + TypeScript + TailwindCSS + React Query + Zustand + React Flow
|
||
- 后端:Rust + Tauri v2 + SQLite(rusqlite + r2d2)
|
||
- MCP Server:内嵌于 Tauri 进程(HTTP),供 Claude Code 调用炼境数据
|
||
- 包管理:pnpm(禁止 npm/yarn/npx/bun)
|
||
|
||
## 核心开发约束
|
||
|
||
**包管理**:pnpm 唯一,禁止 npm / yarn / npx / bun。
|
||
|
||
**TypeScript**:优先 TypeScript,避免 `any`;函数/变量 camelCase,组件 PascalCase;async/await,不用裸 Promise 链;try/catch 不吞异常。
|
||
|
||
**Rust 业务函数**:禁止在函数内部调用 `pool().get()`,连接由调用方传入(依赖注入,便于 in-memory DB 测试)。Tauri command 层负责获取连接并调用(薄包装,无需测试)。
|
||
|
||
## 架构速查
|
||
|
||
```
|
||
src/lib/commands.ts 所有 Tauri command 的前端封装(唯一调用入口)
|
||
src-tauri/src/commands/ Rust 后端实现(每功能一个 .rs 文件)
|
||
src-tauri/src/db.rs SQLite 建表 + migration 逻辑
|
||
src-tauri/src/mcp_server.rs 内嵌 MCP Server(agent 调用炼境的入口)
|
||
src-tauri/src/mcp_inject.rs MCP 配置注入(写入被管理项目的 .claude/settings.json)
|
||
src-tauri/resources/onboarding/ 接入包分发模板(AGENTS.md/lefthook/git-workflow)
|
||
.blueprint/ 项目蓝图(manifest + 模块详情 + 任务卡)
|
||
docs/ai-context/ AI 上下文文档(速查卡、契约映射)
|
||
docs/templates/ 炼境接入包模板草案(设计层)
|
||
```
|
||
|
||
## 关键约定
|
||
|
||
1. **新增 Tauri command → 必须同步更新 `src/lib/commands.ts`**,否则前端无法调用
|
||
2. **SQLite 新增表或字段 → 必须在 `db.rs` 的 `migrate()` 里补 migration 语句**,否则旧版本升级后启动报错
|
||
3. **修改接入包模板(`resources/onboarding/`)→ 检查 `docs/templates/agents-meta-rules.md` 是否需要同步**
|
||
|
||
## 多 AI CLI 协作
|
||
|
||
本项目可由多个 AI CLI 协同。交接时附上:
|
||
|
||
```
|
||
已完成:<修改了哪些文件 + 核心决策>
|
||
待验证:<需要对方确认的地方>
|
||
约束继承:<影响后续工作的关键限制>
|
||
```
|
||
|
||
---
|
||
|
||
## Agent 友好工程四支柱
|
||
|
||
修改代码前,确认这个项目满足四支柱:
|
||
|
||
**可导航**:凭文件名/目录名可在 30 秒内定位某功能的代码。通用能力有独立家,不寄生在业务模块下。
|
||
|
||
**可推理**:公共类型只在一处定义。改一个接口,类型检查能报出所有受影响处。
|
||
|
||
**可验证**:typecheck / lint / test 各有一条命令真能跑。关键路径有冒烟测试。
|
||
|
||
**可记忆**:规则按场景注入(不是一份巨型文档)。决策只写"为什么",代码自己回答"是什么"。
|
||
|
||
---
|
||
|
||
## 文档防腐元规则
|
||
|
||
做任何改动时,判断它属于哪类变更:
|
||
|
||
### T1 外部契约变更(最高优先级)
|
||
其他代码、服务、或 agent 依赖的定义——Tauri command 接口、MCP 接口、数据库 schema、共享类型。
|
||
→ 查 `docs/ai-context/project-context.yaml` 找到对应文档,检查并同步更新。
|
||
|
||
### T2 架构边界变更
|
||
模块划分、目录结构、依赖方向、命令分组变化。
|
||
→ 检查本文件架构速查和 `docs/ai-context/project-brief.md` 是否需要同步。
|
||
|
||
### T3 工具链变更
|
||
引入或替换库、Tauri 版本升级、Rust 依赖变更。
|
||
→ 更新本文件技术栈声明;更新 `docs/ai-context/project-context.yaml`。
|
||
|
||
### T4 常驻上下文过期
|
||
本文件(AGENTS.md)或 `docs/ai-context/project-brief.md` 描述的现实已经改变。
|
||
→ 立即更新。这两份文档常驻 agent 上下文,过期危害最大。
|
||
|
||
### 不触发检查
|
||
内部重构、性能优化、bug fix(外部行为不变)、测试文件、UI 样式调整。
|
||
|
||
---
|
||
|
||
## 文档防腐铁律
|
||
|
||
- 文档只写稳定的:为什么、铁律、意图、架构决策。
|
||
- 易变的(端口、表名、命令清单)交给工具自省,不写死进常驻文档。
|
||
- 单一事实来源:两处说同一事时,删掉派生的那处。
|
||
- 两份文档打架时,信代码,不信文档。
|
||
|
||
---
|
||
|
||
## 定期防腐自查
|
||
|
||
- [ ] 技术栈声明还和 `package.json` / `Cargo.toml` 一致吗?
|
||
- [ ] `project-brief.md` 最近 30 天有没有随架构改动更新?
|
||
- [ ] `src/lib/commands.ts` 的封装覆盖了所有 `src-tauri/src/commands/` 下的 command 吗?
|
||
- [ ] 接入包模板(`resources/onboarding/`)和 `docs/templates/` 内容一致吗?
|
||
|
||
<!-- BLUEPRINT_MANAGED_START version="1.10.0" -->
|
||
## 项目蓝图
|
||
|
||
本项目使用 `.blueprint/` 目录维护项目全景架构图,驱动需求讨论和任务管理。
|
||
本节适用于任何 AI 编程工具(Claude / Qwen / Cursor / Copilot 等)。
|
||
|
||
### 对话开始时必须执行
|
||
|
||
1. 读取 `.blueprint/manifest.yaml` 了解项目全景和当前状态
|
||
2. 读取 `.blueprint/CONVENTIONS.md` 了解完整工作流规则
|
||
|
||
### 需求讨论 → 蓝图同步规则
|
||
|
||
| 用户说的 | AI 应做的 |
|
||
|----------|--------------|
|
||
| "我想加个 XX 功能" | 确认需求后:manifest 新增模块(status: concept),创建 `.blueprint/modules/<id>.md` |
|
||
| "XX 功能需要 A、B、C" | 在模块文件中拆分为任务卡 |
|
||
| "这个方案确定了" | 模块 status → planned,补充任务卡 files/acceptance |
|
||
| "开始做 XX" | 模块 status → in_progress |
|
||
| 没提蓝图但在讨论功能 | 主动提议更新蓝图 |
|
||
|
||
### 复杂度决策(讨论新功能 / 拆解需求时)
|
||
|
||
| complexity | 执行流程 |
|
||
|-----------|---------|
|
||
| S / M | 直接拆任务卡,确保每张卡有 `files` + `acceptance` + `complexity` → 标记 📋 |
|
||
| L(复杂系统设计) | 先做架构设计(Claude 用 `/architect` 技能,其他工具按 CONVENTIONS「复杂功能分析流程」章节执行)输出设计文档,用户确认后拆成 S/M 任务卡 |
|
||
|
||
> L 级任务禁止直接写代码,必须先经过 架构设计 → 任务拆解 流程。
|
||
|
||
### 任务执行两阶段提交
|
||
|
||
- **开始写代码前**:任务卡前缀改为 🔵,status → in_progress
|
||
- **完成验收后**:任务卡前缀改为 ✅,status → done,更新 manifest `updated` 日期
|
||
|
||
完整规则(迭代管理、阻塞处理、复盘笔记等)详见 `.blueprint/CONVENTIONS.md`。
|
||
<!-- BLUEPRINT_MANAGED_END -->
|
||
|
||
<!-- ONBOARDING_MANAGED_START version="1.1.0" -->
|
||
## 核心开发约束
|
||
|
||
### 包管理
|
||
- **pnpm 唯一**:禁止 npm / yarn / npx / bun
|
||
- lock 文件只有 `pnpm-lock.yaml`,不生成其他
|
||
|
||
### 代码规范
|
||
- TypeScript 优先,避免 `any`
|
||
- 函数/变量 camelCase;组件 PascalCase
|
||
- 异步统一 `async/await`,不用裸 Promise 链
|
||
- 错误处理明确 `try/catch`,不吞异常
|
||
- 优先编辑现有文件,避免创建不必要的新文件
|
||
|
||
## Git 工作流
|
||
|
||
见 `docs/ai-context/git-workflow.md`(分支策略 + Conventional Commits + Rules-Applied trailer + PR 规范)。
|
||
**commit 必须符合 Conventional Commits**(lefthook 强制),炼境据此采集飞轮数据。
|
||
|
||
## agent 按钮与验证路径
|
||
|
||
功能的本体是代码层的能力;UI 按钮是它给人的投影,**agent 按钮**是给 agent 的投影
|
||
(可发现 + 可调用 + 有边界的能力声明)。开发任何功能时遵守:
|
||
|
||
1. **边界单点实现**:业务校验只写在能力本体层(API/command),UI 只呈现不复制逻辑——
|
||
否则人与 agent 的验证路径会分裂
|
||
2. **载体就近选择**(本项目的 agent 按钮是什么,按项目类型对号入座):
|
||
| 项目类型 | agent 按钮载体 |
|
||
|---------|---------------|
|
||
| Web 服务 | HTTP API 本身(前端按钮与 curl 调同一 endpoint,天然双投影) |
|
||
| CLI/脚本 | 命令与 npm scripts |
|
||
| 桌面应用 | 测试直接调用 command 函数 |
|
||
| UI 呈现层 | Playwright 驱动真界面(最后手段,仅关键路径) |
|
||
3. **完成的定义**:功能实现后,由 agent 沿投影路径真实走通一次(起服务 → 调接口 →
|
||
断言行为),再交人做 UI 终验——不许绕过功能手改产物冒充验证
|
||
4. **侦察 → 驻军**:agent 走通的关键路径,顺手固化为一条测试(vitest / cargo test);
|
||
一次性验收不固化(少而稳 > 多而脆)
|
||
|
||
## 多 AI CLI 协作
|
||
|
||
本项目可由多个 AI CLI 协同。交接时把结果总结成 3 条传给下一个:
|
||
|
||
```
|
||
1. 已完成:<改了哪些文件 + 核心决策>
|
||
2. 待验证:<需要确认的地方>
|
||
3. 约束继承:<影响后续的关键限制>
|
||
```
|
||
<!-- ONBOARDING_MANAGED_END -->
|