logo
0
0
WeChat Login
dylancheong<neocheung@163.com>
docs(rules): 把 Java + Vue 栈规则从 .archived/ 提升到主 rules/ 目录

.codebuddy/ 框架总览

本目录是 CodeBuddy Agent 在本项目中的行为规范可复用能力包。任何 AI Agent 或人类开发者接手本项目前,先读本文。

目录结构

.codebuddy/
├── README.md              # 本文件:总览与导航
├── rules/                 # 规则(强制性约束)—— 开发者 / Agent 执行层
│   ├── *.md              # 9 份规则,详见下表
│   └── .archived/
│       ├── feedback/     # 使用框架过程中发现的问题与改进记录
│       └── README.md     # 归档说明
├── skills/                # 技能(可复用工作流)—— 开发者 / Agent 执行层
│   └── */SKILL.md        # 9 个 skill,详见下表
└── governance/            # 治理层 —— Leader / workshop 负责人视角
    ├── README.md                  # 治理层导航
    ├── delivery-lifecycle.md      # 交付流程契约(流程通用性)
    ├── quality-dashboard.md       # 质量仪表盘(质量维度)
    ├── retrospective-sop.md       # 复盘 SOP(经验沉淀)
    ├── architecture-fitness.md    # 架构健康度(技术先进性)
    └── tooling-landscape.md       # 管理工具全景(管理工具协同)

三层分工

层次读者产出
governance/Leader、workshop 负责人治理框架、健康度评估、经验复盘机制
rules/开发者、Agent执行期的强制约束
skills/Agent可按需加载的工作流模板

上层不重复下层内容,只做导航和抽象;下层变更不引起上层级联修改。

Rules 规则索引

Rules 是强制性约束。Agent 在本项目内工作时必须遵守。

编号文件主题关键约束
R0meta-principles.md元原则(所有规则的根)真实编译 / 不可执行测试 / 棘轮阈值 / 抽象化 / 契约优先——技术栈无关,alwaysApply: true
R1requirement-expansion.md需求扩写规范将原始需求扩写为结构化文档,强制审视 + 主动提问
R2project-architecture.md项目架构规范三层架构、模块化、目录组织、技术栈声明
R3frontend-core.md前端核心规范(技术栈无关)组件设计 / 类型系统 / 状态分层 / API 契约消费 / 路由 / 样式 / 错误边界 / 性能
R3-vuefrontend-vue.md前端规范 · Vue 3 + TypeScript 参考实现R3 在 Vue 栈的完整落地
R4backend-core.md后端核心规范(技术栈无关)分层 / 边界对象 / API 契约 / 异常 / 配置 / 日志 / 并发 / 安全基线
R4-javabackend-java-spring.md后端规范 · Java Spring Boot 参考实现R4 在 Java 栈的完整落地(~1600 行)
R4+domain-modeling.md领域建模指引(DDD 工程化)限界上下文 / 聚合 / 领域事件 / 仓储 / CQRS / 防腐层——中等以上复杂度业务必读
R4++microservice-architecture.md微服务架构规范服务划分 / 通信(同步+异步)/ 分布式事务(Saga)/ 治理 / 可观测性 / 部署演进——采用微服务时必读
R5testing-standards.md测试规范总纲单元/集成/功能测试分层;派生自 R0 原则 1~3
R5aunit-testing.md单元测试规范与打分JUnit 5 + Mockito;6 维度打分(满分 100)
R5bfunctional-testing.md功能测试规范与打分@SpringBootTest + 真实外部依赖(compose 或容器库);验收标准驱动
R6git-conventions.mdGit 提交规范分支策略、Conventional Commits、commit 粒度
requirement-analysis.md需求分析原则最小必要原则,避免"所有需求都搭全家桶"

Skills 技能索引

Skills 是可按需加载的工作流模板。通过 use_skill 工具调用。

详细元数据与依赖图skills/SKILLS.md(v2 Agent Harness 规格);规格定义skills/_AGENT_HARNESS_SPEC.md

Skill定位典型触发场景
requirement-workflow需求处理 SOP(顶层工作流)确认处理 <PM-Tool> 需求:自动分支切换、分析、开发、测试、验证、通知
requirement-analysis需求复杂度分析<PM-Tool> 读取需求后,判断需要前端/后端/数据库/Docker
scaffold模块脚手架生成按字段清单生成后端分层文件 + 前端 api/store/view
code-review深度代码审查完成开发后、提交前的代码质量审查
api-docsAPI 文档生成基于 OpenAPI / 等效契约输出 Markdown API 文档
cicd-pipelineCI/CD 配置生成生成 <CI-Platform> 流水线 + 质量门禁配置
changelog变更日志生成基于 Conventional Commits 生成 CHANGELOG
tapd<PM-Tool> 集成(以 TAPD 为参考实现)查询/更新需求、bug、迭代、工时;替换 <PM-Tool> 时此 skill 需整体替换
skill-creator元能力:创建 skill创建新 skill 时的引导

关键字段(每个 skill 的 _meta.json 都含):

  • triggers — 关键词 + 上下文触发规则
  • dependencies — 依赖的其他 skills / rules / 外部工具
  • inputs / outputs — 机器可读的输入输出契约
  • side_effects — 五维副作用分类(fs / net / db / git / external-api)
  • idempotent / requires_confirmation — 幂等性与用户确认要求
  • cost — 成本预估(时长、LLM 调用数、复杂度)

核心硬门禁(必读)

1. 真实编译门禁(见 R5 §五)

"静态检查通过 ≠ 代码能运行"。任何交付必须跑通真实编译(mvn compile / tsc --noEmit),不允许仅凭 read_lints 0 错误、括号平衡通过来断言代码正确。工具链版本不匹配时用容器锁死项目目标版本。

2. 审查前置条件(见 code-review/references/backend-checklist.md §0

代码评审前必须已通过:

  • 源码真实编译
  • 测试代码编译
  • 至少 1 个上下文加载测试(@SpringBootTest 或等效)

3. 需求处理工作流(见 requirement-workflow

<PM-Tool> 拿到需求后必须:

  1. 需求扩写(R1)
  2. 需求分析(最小必要原则)
  3. Git 分支切换
  4. 开发 + 测试
  5. Phase 4.0 真实编译验证 → 4.1 运行测试
  6. 代码就绪通知 → 等待确认 → 推送远端

使用建议

开发者 / Agent 执行视角

场景该读什么
刚接手项目本 README → project-architecture.mdrequirement-workflow/SKILL.md
准备写后端代码backend-core.md(通用)+ 对应栈实现(如 backend-java-spring.md)→ code-review checklist
准备写测试testing-standards.md 总纲 → unit-testing.mdfunctional-testing.md
准备提交代码git-conventions.mdcode-review skill
想新增模块scaffold skill → 产出后跑 mvn compile → 补业务逻辑
改动涉及循环依赖、拦截器、过滤器backend-core.md §1.2 + 对应栈参考实现(Java 见 backend-java-spring.md §1.1 §6.8

Leader / workshop 负责人视角

场景该读什么
刚接手团队 / 项目governance/README.md → 按 5 维度依次读
流程卡壳、责任不清governance/delivery-lifecycle.md
不知道质量怎么衡量governance/quality-dashboard.md
要启动复盘(周会 / 季度 / 事故)governance/retrospective-sop.md
判断技术栈要不要升级governance/architecture-fitness.md
新人不知道用哪个工具 / 告警分派governance/tooling-landscape.md

反馈与迭代

在使用本框架过程中发现的问题(规则漏洞、skill 缺陷、工具盲区)记录在 .archived/feedback/FB-XX-*.md,每条 FB 有明确的"来源 / 触发条件 / 建议修复 / 状态"。RESOLVED 的 FB 保留作为历史案例追溯;OPEN 的是下一轮迭代的待办输入。完整的复盘触发时机与闭环机制见 governance/retrospective-sop.md