dev-manager-tauri/CLAUDE.md
lanrtop 29a066e7e3 chore(conventions): v1.9.0 自洽体检——规则边界结构 + R11 + 状态词汇统一
- 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 卡完成解锁(分发随下次发版生效)
2026-07-02 14:09:09 +09:00

4.0 KiB
Raw Blame History

炼境 (Dev Manager Tauri)

Git 多空间开发管理器Tauri v2 + React + TypeScript + Rust。

技术栈

  • 前端React 19 + TypeScript + TailwindCSS + React Query + Zustand + React Flow
  • 后端Rust + Tauri v2 + SQLite (rusqlite + r2d2)
  • 包管理pnpm禁止 npm/yarn
  • Git 后端:自建 GiteaGitHub 已退役,见 .blueprint/modules/github-decommission.md
  • CI/CDGitea 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/ 目录维护项目全景架构图,驱动需求讨论和任务管理。

对话开始时必须执行

  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