29a066e7e3
- CONVENTIONS 1.9.0：规则新增 boundaries/failure_cases 可选字段（失败定边界， 经验细化为变体而非推翻）；新增 R11 自动执行规则失效时必须记录失败案例； 模块状态表补 abandoned 定义（何时更新蓝图章节早已引用但表中缺失） - 状态词汇统一：github-auth/github-publish 的 deprecated（未定义状态）→ abandoned， BlueprintModal 状态色表补 abandoned 渲染 - 文档防腐：CLAUDE.md 技术栈改为 Gitea（GitHub 已退役）；cicd-workflow 模块 加改造中指针（单一事实来源指向 gitea-integration 的 Gitea Actions 卡） - 蓝图：R2 卡完成解锁（分发随下次发版生效）
86 lines
4.0 KiB
Markdown
86 lines
4.0 KiB
Markdown
# 炼境 (Dev Manager Tauri)
|
||
|
||
Git 多空间开发管理器，Tauri v2 + React + TypeScript + Rust。
|
||
|
||
<!-- 手动维护区：只放技术栈、目录结构、技能规则。蓝图工作流由下方 MANAGED 块统一管理，勿在此重复。 -->
|
||
|
||
## 技术栈
|
||
- 前端：React 19 + TypeScript + TailwindCSS + React Query + Zustand + React Flow
|
||
- 后端：Rust + Tauri v2 + SQLite (rusqlite + r2d2)
|
||
- 包管理：pnpm（禁止 npm/yarn）
|
||
- Git 后端：自建 Gitea（GitHub 已退役，见 .blueprint/modules/github-decommission.md）
|
||
- CI/CD：Gitea Actions 迁移中；发布产物走阿里云 OSS（历史方案见 docs/tauri-cicd-guide.md）
|
||
- 客户端更新：tauri-plugin-updater（详见 docs/tauri-updater-guide.md）
|
||
|
||
## 目录结构
|
||
```
|
||
src/ 前端源码
|
||
src/components/ React 组件（按功能分目录）
|
||
src/lib/commands.ts Tauri command 调用封装
|
||
src-tauri/src/ Rust 后端
|
||
src-tauri/src/commands/ Tauri command 实现
|
||
src-tauri/resources/onboarding/ 接入包分发模板（AGENTS.md、git-workflow、lefthook）
|
||
.blueprint/ 项目蓝图（manifest + 模块详情 + 任务卡）
|
||
.claude/rules/ 路径注入规则（tauri-contract / db-schema / onboarding-sync）
|
||
AGENTS.md 跨工具 AI 上下文（四支柱 + 元规则，单一来源）
|
||
docs/ai-context/ AI 速查文档（project-brief.md、project-context.yaml）
|
||
docs/templates/ 炼境接入包模板草案（agents-meta-rules 等）
|
||
```
|
||
|
||
## 命令执行规则
|
||
|
||
- 所有命令直接用 Bash tool 执行，禁止输出命令让用户手动运行
|
||
- `pnpm tauri build` / `cargo build --release` 等 Rust 构建用 `run_in_background: true` + `timeout: 600000`（首次编译可能需要 10 分钟）
|
||
- 超过 10 分钟的任务（如完整 release build）改为输出单行完整命令，让用户 `! <命令>` 一键执行
|
||
|
||
## 技能使用规则
|
||
|
||
根据任务卡 complexity 决定执行后的检查：
|
||
|
||
| complexity | 执行后必跑 |
|
||
|-----------|-----------|
|
||
| S（简单增删改） | /code-review → /smart-commit |
|
||
| M（中等逻辑） | /Dev-edge-case → /code-review → /smart-commit |
|
||
| L（复杂，应先拆） | /architect → /splitter → 拆成 S/M |
|
||
|
||
- 新功能设计阶段：/architect
|
||
- 代码重构/简化：/simplify → /code-review
|
||
- 发现深层问题：/Dev-deep-think
|
||
|
||
<!-- BLUEPRINT_MANAGED_START version="1.8.0" -->
|
||
## 项目蓝图
|
||
|
||
本项目使用 `.blueprint/` 目录维护项目全景架构图，驱动需求讨论和任务管理。
|
||
|
||
### 对话开始时必须执行
|
||
|
||
1. 读取 `.blueprint/manifest.yaml` 了解项目全景和当前状态
|
||
2. 读取 `.blueprint/CONVENTIONS.md` 了解完整工作流规则
|
||
|
||
### 需求讨论 → 蓝图同步规则
|
||
|
||
| 用户说的 | Claude 应做的 |
|
||
|----------|--------------|
|
||
| "我想加个 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（复杂系统设计） | 先 `/architect` 输出设计文档，用户确认后 `/splitter` 拆成 S/M 任务卡 |
|
||
|
||
> L 级任务禁止直接写代码，必须先经过 `/architect` → `/splitter` 流程。
|
||
|
||
### 任务执行两阶段提交
|
||
|
||
- **开始写代码前**：任务卡前缀改为 🔵，status → in_progress
|
||
- **完成验收后**：任务卡前缀改为 ✅，status → done，更新 manifest `updated` 日期
|
||
|
||
完整规则（迭代管理、阻塞处理、复盘笔记等）详见 `.blueprint/CONVENTIONS.md`。
|
||
<!-- BLUEPRINT_MANAGED_END -->
|