bcoder 0.0.1

package/README.en.md

@@ -0,0 +1,36 @@
+# bcoder
+
+#### Description
+best coder 一个极轻量级的AI Coder助手
+
+#### Software Architecture
+Software architecture description
+
+#### Installation
+
+1.  xxxx
+2.  xxxx
+3.  xxxx
+
+#### Instructions
+
+1.  xxxx
+2.  xxxx
+3.  xxxx
+
+#### Contribution
+
+1.  Fork the repository
+2.  Create Feat_xxx branch
+3.  Commit your code
+4.  Create Pull Request
+
+
+#### Gitee Feature
+
+1.  You can use Readme\_XXX.md to support different languages, such as Readme\_en.md, Readme\_zh.md
+2.  Gitee blog [blog.gitee.com](https://blog.gitee.com)
+3.  Explore open source project [https://gitee.com/explore](https://gitee.com/explore)
+4.  The most valuable open source project [GVP](https://gitee.com/gvp)
+5.  The manual of Gitee [https://gitee.com/help](https://gitee.com/help)
+6.  The most popular members  [https://gitee.com/gitee-stars/](https://gitee.com/gitee-stars/)

package/README.md

@@ -0,0 +1,37 @@
+# bcoder
+
+#### 介绍
+best coder 一个极轻量级的AI Coder助手
+
+#### 软件架构
+软件架构说明
+
+
+#### 安装教程
+
+1.  xxxx
+2.  xxxx
+3.  xxxx
+
+#### 使用说明
+
+1.  xxxx
+2.  xxxx
+3.  xxxx
+
+#### 参与贡献
+
+1.  Fork 本仓库
+2.  新建 Feat_xxx 分支
+3.  提交代码
+4.  新建 Pull Request
+
+
+#### 特技
+
+1.  使用 Readme\_XXX.md 来支持不同的语言，例如 Readme\_en.md, Readme\_zh.md
+2.  Gitee 官方博客 [blog.gitee.com](https://blog.gitee.com)
+3.  你可以 [https://gitee.com/explore](https://gitee.com/explore) 这个地址来了解 Gitee 上的优秀开源项目
+4.  [GVP](https://gitee.com/gvp) 全称是 Gitee 最有价值开源项目，是综合评定出的优秀开源项目
+5.  Gitee 官方提供的使用手册 [https://gitee.com/help](https://gitee.com/help)
+6.  Gitee 封面人物是一档用来展示 Gitee 会员风采的栏目 [https://gitee.com/gitee-stars/](https://gitee.com/gitee-stars/)

package/bcoder/agent/architect.md

@@ -0,0 +1,212 @@
+---
+name: architect
+name_cn: 架构师
+description: 软件架构专家，专注于系统设计、可扩展性和技术决策。在规划新功能、重构大型系统或做出架构决策时积极使用。
+tools: ["Read", "Grep", "Glob"]
+model: auto
+---
+
+你是一位资深软件架构师，专注于可扩展、可维护的系统设计。
+
+## 你的角色
+
+- 为新功能设计系统架构1
+- 评估技术权衡
+- 推荐模式和最佳实践
+- 识别可扩展性瓶颈
+- 为未来增长做规划
+- 确保代码库一致性
+
+## 架构审查流程
+
+### 1. 当前状态分析
+- 审查现有架构
+- 识别模式和约定
+- 记录技术债务
+- 评估可扩展性限制
+
+### 2. 需求收集
+- 功能需求
+- 非功能需求（性能、安全性、可扩展性）
+- 集成点
+- 数据流需求
+
+### 3. 设计方案
+- 高级架构图
+- 组件职责
+- 数据模型
+- API 契约
+- 集成模式
+
+### 4. 权衡分析
+对于每个设计决策，记录：
+- **优点**：收益和优势
+- **缺点**：劣势和限制
+- **替代方案**：考虑的其他选项
+- **决策**：最终选择和理由
+
+## 架构原则
+
+### 1. 模块化与关注点分离
+- 单一职责原则
+- 高内聚，低耦合
+- 组件间清晰的接口
+- 独立部署能力
+
+### 2. 可扩展性
+- 水平扩展能力
+- 尽可能无状态设计
+- 高效的数据库查询
+- 缓存策略
+- 负载均衡考虑
+
+### 3. 可维护性
+- 清晰的代码组织
+- 一致的模式
+- 全面的文档
+- 易于测试
+- 易于理解
+
+### 4. 安全性
+- 深度防御
+- 最小权限原则
+- 边界处的输入验证
+- 默认安全
+- 审计跟踪
+
+### 5. 性能
+- 高效的算法
+- 最小化网络请求
+- 优化的数据库查询
+- 适当的缓存
+- 懒加载
+
+## 常见模式
+
+### 前端模式
+- **组件组合**：从简单组件构建复杂 UI
+- **容器/展示器**：将数据逻辑与展示分离
+- **自定义钩子**：可重用的有状态逻辑
+- **全局状态上下文**：避免属性传递
+- **代码分割**：懒加载路由和重量级组件
+
+### 后端模式
+- **仓库模式**：抽象数据访问
+- **服务层**：业务逻辑分离
+- **中间件模式**：请求/响应处理
+- **事件驱动架构**：异步操作
+- **CQRS**：分离读写操作
+
+### 数据模式
+- **规范化数据库**：减少冗余
+- **为读取性能反规范化**：优化查询
+- **事件溯源**：审计跟踪和可重放性
+- **缓存层**：Redis、CDN
+- **最终一致性**：适用于分布式系统
+
+## 架构决策记录（ADRs）
+
+对于重要的架构决策，创建 ADRs：
+
+```markdown
+# ADR-001: 使用 Redis 进行语义搜索向量存储
+
+## 背景
+需要存储和查询 1536 维嵌入向量用于语义市场搜索。
+
+## 决策
+使用具有向量搜索能力的 Redis Stack。
+
+## 后果
+
+### 积极
+- 快速向量相似度搜索（<10ms）
+- 内置 KNN 算法
+- 部署简单
+- 最多 10 万向量的良好性能
+
+### 消极
+- 内存存储（大型数据集成本高）
+- 无集群时单点故障
+- 限于余弦相似度
+
+### 考虑的替代方案
+- **PostgreSQL pgvector**：速度较慢，但持久存储
+- **Pinecone**：托管服务，成本更高
+- **Weaviate**：功能更多，设置更复杂
+
+## 状态
+已接受
+
+## 日期
+2025-01-15
+```
+
+## 系统设计清单
+
+设计新系统或功能时：
+
+### 功能需求
+- [ ] 用户故事已记录
+- [ ] API 契约已定义
+- [ ] 数据模型已指定
+- [ ] UI/UX 流程已映射
+
+### 非功能需求
+- [ ] 性能目标已定义（延迟、吞吐量）
+- [ ] 可扩展性需求已指定
+- [ ] 安全需求已识别
+- [ ] 可用性目标已设定（正常运行时间 %）
+
+### 技术设计
+- [ ] 架构图已创建
+- [ ] 组件职责已定义
+- [ ] 数据流已记录
+- [ ] 集成点已识别
+- [ ] 错误处理策略已定义
+- [ ] 测试策略已规划
+
+### 运维
+- [ ] 部署策略已定义
+- [ ] 监控和告警已规划
+- [ ] 备份和恢复策略
+- [ ] 回滚计划已记录
+
+## 红色警报
+
+注意这些架构反模式：
+- **大泥球**：无清晰结构
+- **金锤子**：对所有问题使用相同解决方案
+- **过早优化**：过早进行优化
+- **非此处发明**：拒绝现有解决方案
+- **分析瘫痪**：过度规划，建设不足
+- **魔法**：不清楚、无文档的行为
+- **紧耦合**：组件过于依赖
+- **上帝对象**：一个类/组件做所有事情
+
+## 项目特定架构（示例）
+
+AI 驱动的 SaaS 平台示例架构：
+
+### 当前架构
+- **前端**：Next.js 15（Vercel/Cloud Run）
+- **后端**：FastAPI 或 Express（Cloud Run/Railway）
+- **数据库**：PostgreSQL（Supabase）
+- **缓存**：Redis（Upstash/Railway）
+- **AI**：Claude API 结构化输出
+- **实时**：Supabase 订阅
+
+### 关键设计决策
+1. **混合部署**：Vercel（前端）+ Cloud Run（后端）以获得最佳性能
+2. **AI 集成**：使用 Pydantic/Zod 进行类型安全的结构化输出
+3. **实时更新**：Supabase 订阅获取实时数据
+4. **不可变模式**：使用展开运算符实现可预测状态
+5. **多小文件**：高内聚，低耦合
+
+### 可扩展性计划
+- **1 万用户**：当前架构足够
+- **10 万用户**：添加 Redis 集群，静态资产使用 CDN
+- **100 万用户**：微服务架构，分离读写数据库
+- **1000 万用户**：事件驱动架构，分布式缓存，多区域
+
+**记住**：良好的架构实现快速开发、易于维护和自信扩展。最佳架构简单、清晰，并遵循既定模式。

package/bcoder/commands/bc-execute-plans.md

@@ -0,0 +1,6 @@
+---
+description: 分批执行计划并带有审查检查点
+disable-model-invocation: true
+---
+
+调用 bc-execute-plans 技能并完全按照呈现的方式遵循它

package/bcoder/commands/bc-requirements-analysis.md

@@ -0,0 +1,6 @@
+---
+description: "您必须在任何创造性工作之前使用此功能 - 创建功能、构建组件、添加功能或修改行为。在实施之前探索用户意图、需求和设计。"
+disable-model-invocation: true
+---
+
+调用 bc-requirements-analysis 技能并完全按照呈现的方式遵循它

package/bcoder/commands/bc-write-plans.md

@@ -0,0 +1,6 @@
+---
+description: 创建详细的实施计划，包含小规模任务
+disable-model-invocation: true
+---
+
+调用 bc-write-plans 技能并完全按照呈现的方式遵循它

package/bcoder/rules/coding-style.md

@@ -0,0 +1,70 @@
+# 编码风格
+
+## 不可变性（关键）
+
+始终创建新对象，永不修改：
+
+```javascript
+// 错误：修改
+function updateUser(user, name) {
+  user.name = name  // 修改！
+  return user
+}
+
+// 正确：不可变性
+function updateUser(user, name) {
+  return {
+    ...user,
+    name
+  }
+}
+```
+
+## 文件组织
+
+许多小文件 > 少数大文件：
+- 高内聚，低耦合
+- 通常200-400行，最多800行
+- 从大组件中提取工具函数
+- 按功能/域组织，而非按类型
+
+## 错误处理
+
+始终全面处理错误：
+
+```typescript
+try {
+  const result = await riskyOperation()
+  return result
+} catch (error) {
+  console.error('操作失败：', error)
+  throw new Error('详细的用户友好消息')
+}
+```
+
+## 输入验证
+
+始终验证用户输入：
+
+```typescript
+import { z } from 'zod'
+
+const schema = z.object({
+  email: z.string().email(),
+  age: z.number().int().min(0).max(150)
+})
+
+const validated = schema.parse(input)
+```
+
+## 代码质量检查清单
+
+在标记工作完成之前：
+- [ ] 代码可读且命名良好
+- [ ] 函数很小（<50行）
+- [ ] 文件专注（<800行）
+- [ ] 没有深层嵌套（>4层）
+- [ ] 正确的错误处理
+- [ ] 没有console.log语句
+- [ ] 没有硬编码值
+- [ ] 没有修改（使用不可变模式）

package/bcoder/skills/bc-create-backend-project/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: bc-create-backend-project
+description: 只有是空项目的时候才会被触发。当用户想要创建、构建、脚手架、设置或初始化新的 Spring Boot 应用程序、微服务、REST API 或后端服务项目时使用；需要架构指导（分层、按模块打包、模块化单体、番茄、DDD+六边形）；或请求 Spring Initializr 设置。也会在讨论 Spring Boot 架构模式、值对象、CQRS 或领域驱动设计时触发。
+---
+
+# 创建 Spring Boot 项目
+
+**开始时声明：** "我正在使用 后端服务初始化（ bc-create-backend-project ） 技能来实施此计划。"
+
+## 关键规则
+
+**绝不直接跳到实现。始终先评估复杂度。**
+
+**强制版本：** Java 25 + Spring Boot 3.5.8
+
+## 工作流程
+
+### 第一步：评估复杂度
+
+询问用户：
+1. **领域复杂度** - 简单 CRUD 还是复杂业务规则？
+2. **团队规模** - 1-3、3-10 还是 10+ 人？
+3. **生命周期** - 几个月、1-2 年还是 5+ 年？
+4. **类型安全** - 基本验证还是需要强类型？
+5. **有界上下文** - 单一领域还是多个子领域？
+
+### 第二步：选择架构
+
+| 模式 | 适用场景 | 复杂度 |
+|---------|------|-----------|
+| **分层** | 简单 CRUD、原型、MVP | ⭐ |
+| **按模块打包** | 3-5 个不同功能、中等应用 | ⭐⭐ |
+| **模块化单体** | 需要模块边界、Spring Modulith | ⭐⭐ |
+| **番茄** | 丰富领域、值对象、类型安全 | ⭐⭐⭐ |
+| **ddd-六边形** | 复杂领域、CQRS、基础设施独立 | ⭐⭐⭐⭐ |
+
+**详细标准、包结构和命名约定：** 参见 [architecture-guide.md](references/architecture-guide.md)
+
+### 第三步：创建项目
+
+**必需配置：**
+- 项目：Maven 项目
+- 语言：Java
+- Spring Boot：3.5.8
+- Java：25
+
+**核心依赖：**
+- Spring Web MVC (`spring-boot-starter-webmvc`)
+- Mybatis
+- Lombok
+- Validation
+- MySQL Driver
+
+**附加依赖：**
+- Spring Modulith - 用于模块化单体/番茄
+- ArchUnit - 用于 DDD+六边形
+
+### 第四步：实现模式
+
+- 加上跨域的代码，方便本地前端调用接口；
+
+
+### 第五步：基础设施设置
+
+**始终包含：**
+- Testcontainers 集成测试
+- 用于本地开发的 Docker Compose
+- Swagger/OpenAPI 文档
+- ProblemDetail 错误处理
+- JSpecify 空安全
+
+**可选（基于需求）：**
+- API 版本控制
+- HTTP Service Clients
+- OpenAPI 文档（第三方，例如 Springdoc）
+
+## 快速参考
+
+**包结构：** [architecture-guide.md](references/architecture-guide.md)
+**命名约定：** [architecture-guide.md](references/architecture-guide.md)
+**反模式：** [architecture-guide.md](references/architecture-guide.md)
+**升级路径：** [architecture-guide.md](references/architecture-guide.md)
+
+## 关键原则
+
+**从简单开始。当复杂度需要时再升级。**
+

package/bcoder/skills/bc-create-backend-project/references/architecture-guide.md

@@ -0,0 +1,241 @@
+# Spring Boot 架构模式指南
+
+## 架构决策矩阵
+
+| 标准 | 分层 | 按模块打包 | Modulith | 番茄 | DDD+六边形 |
+|----------|---------|-------------------|----------|--------|---------|
+| 团队规模 | 1-3 | 3-10 | 5-15 | 5-15 | 10+ |
+| 生命周期 | 几个月 | 1-2 年 | 2-5 年 | 3-5 年 | 5+ 年 |
+| 类型安全 | 低 | 低 | 低 | 高 | 高 |
+| 学习曲线 | ⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
+
+## 包结构
+
+### 分层架构
+```
+com.example.app/
+├── controller/
+├── service/
+├── repository/
+└── domain/
+```
+
+**适用场景：** 简单 CRUD 应用程序、原型、MVP、单个开发者项目。
+
+### 按模块打包
+```
+com.example.app/
+├── products/
+│   ├── domain/
+│   └── rest/
+├── orders/
+│   ├── domain/
+│   └── rest/
+└── shared/
+```
+
+**适用场景：** 3-5 个不同功能、中等规模应用、需要功能隔离。
+
+### 模块化单体（Spring Modulith）
+```
+com.example.app/
+├── products/
+│   ├── internal/      ← 包私有的实现
+│   ├── ProductsAPI.java  ← 公共模块 API
+│   └── domain/
+├── orders/
+│   ├── internal/
+│   ├── OrdersAPI.java
+│   └── domain/
+└── shared/
+```
+
+**适用场景：** 需要强制模块边界、想要测试模块独立性、计划潜在的微服务提取。
+
+### 番茄架构
+```
+com.example.app/
+├── products/
+│   ├── domain/
+│   │   ├── vo/
+│   │   │   ├── ProductSKU.java
+│   │   │   ├── Price.java
+│   │   │   └── Quantity.java
+│   │   ├── ProductEntity.java
+│   │   ├── ProductService.java
+│   │   └── ProductQueryService.java
+│   └── rest/
+│       ├── ProductController.java
+│       └── converters/
+│           └── StringToProductSKUConverter.java
+└── shared/
+    └── vo/
+        ├── Money.java
+        └── Email.java
+```
+
+**适用场景：** 丰富领域模型、需要类型安全、金融/医疗领域、遇到原始类型导致的验证错误。
+
+### DDD+六边形架构
+```
+com.example.app/
+├── products/
+│   ├── application/
+│   │   ├── command/
+│   │   │   ├── CreateProductHandler.java
+│   │   │   └── UpdateProductHandler.java
+│   │   └── query/
+│   │       └── ProductQueryService.java
+│   ├── domain/
+│   │   ├── model/
+│   │   │   ├── ProductAggregate.java
+│   │   │   └── ProductFactory.java
+│   │   ├── vo/
+│   │   │   ├── ProductSKU.java
+│   │   │   └── Price.java
+│   │   └── ports/
+│   │       └── ProductRepository.java (接口)
+│   ├── infra/
+│   │   └── persistence/
+│   │       └── JpaProductRepository.java (实现)
+│   └── interfaces/
+│       └── rest/
+│           └── ProductController.java
+└── shared/
+    └── domain/
+```
+
+**适用场景：** 复杂业务领域、需要 CQRS、需要基础设施独立、10+ 团队成员、5+ 年生命周期。
+
+## 命名约定
+
+### 番茄/DDD 模式
+
+| 类型 | 模式 | 示例 | 包 |
+|------|---------|---------|---------|
+| 实体 | `*Entity` | `ProductEntity` | `domain/model/` |
+| 聚合根 | `*Aggregate` | `OrderAggregate` | `domain/model/` |
+| 值对象 | 领域名称 | `ProductSKU`、`Price`、`Email` | `domain/vo/` |
+| 命令 | `*Cmd` | `CreateProductCmd` | `application/command/` |
+| 命令处理器 | `*Handler` | `CreateProductHandler` | `application/command/` |
+| 视图模型 | `*VM` | `ProductVM` | `domain/models/` 或 `interfaces/rest/dto/` |
+| 写服务 | `*Service` | `ProductService` | `domain/` |
+| 读服务 | `*QueryService` | `ProductQueryService` | `application/query/` |
+| 仓储接口 | `*Repository` | `ProductRepository` | `domain/ports/` (DDD) 或 `domain/` |
+| 仓储实现 | `Jpa*Repository` | `JpaProductRepository` | `infra/persistence/` |
+| 模块 API | `*API` | `ProductsAPI` | 包根目录 |
+| 转换器 | `StringTo*Converter` | `StringToProductSKUConverter` | `rest/converters/` |
+
+### 通用约定
+
+- 使用单数名称作为包：`product/` 而不是 `products/`
+- 值对象是不可变的，使用 `of()` 工厂方法
+- 命令是不可变的记录
+- 视图模型是用于 API 响应的不可变记录
+- 聚合封装业务逻辑和不变量
+
+## 避免的反模式
+
+| 不要 | 应该 | 原因 |
+|-------|-----|-----|
+| 直接跳到实现 | 首先询问评估问题 | 防止过度工程或工程不足 |
+| 对简单 CRUD 使用 DDD | 使用分层或按模块打包 | DDD 在简单情况下增加复杂度而无益处 |
+| 对复杂领域使用分层 | 使用番茄或 DDD+六边形 | 分层架构导致贫血领域模型 |
+| 跳过基础设施 | 始终包含 Flyway、Testcontainers、Docker | 生产就绪需要适当的基础设施 |
+| 盲目复制模板 | 阅读模板注释，适应领域 | 模板是起点，不是解决方案 |
+| 原始类型痴迷 | 对领域概念使用值对象 | 类型安全防止错误，使意图明确 |
+| 贫血领域模型 | 将业务逻辑放入实体/聚合 | 领域驱动设计原则 |
+| 上帝服务 | 按命令/查询职责拆分 | CQRS 提高可维护性 |
+| 共享可变状态 | 使用不可变值对象 | 线程安全和可预测性 |
+
+## 架构升级路径
+
+### 何时升级
+
+| 从 | 到 | 触发条件 | 工作量 |
+|------|-----|---------|--------|
+| 分层 | 按模块打包 | 3+ 功能、团队增长到 3+ | 低 |
+| 按模块打包 | 模块化单体 | 需要强制边界、测试独立性 | 中等 |
+| 模块化单体 | 番茄 | 类型混淆错误、验证分散在各层 | 中等 |
+| 番茄 | DDD+六边形 | 需要基础设施独立、CQRS、复杂业务规则 | 高 |
+
+### 迁移策略
+
+**分层 → 按模块打包：**
+1. 创建模块包（products/、orders/）
+2. 将相关的控制器、服务、仓储移动到模块中
+3. 提取共享工具到 shared/
+4. 重构跨模块依赖
+
+**按模块打包 → 模块化单体：**
+1. 添加 Spring Modulith 依赖
+2. 为每个模块创建 `*API.java` 接口
+3. 使内部类成为包私有
+4. 添加 `@ApplicationModuleTest` 进行模块验证
+5. 使用 `modularity-test.java` 模板
+
+**模块化单体 → 番茄：**
+1. 识别当前使用原始类型的领域概念
+2. 为每个概念创建值对象（SKU、Price、Email 等）
+3. 用值对象替换实体中的原始类型
+4. 为 @PathVariable 绑定添加 Spring 转换器
+5. 更新测试以使用值对象
+
+**番茄 → DDD+六边形：**
+1. 将命令与查询分离（CQRS）
+2. 创建带有处理器的应用层
+3. 定义领域端口（domain/ 中的仓储接口）
+4. 将基础设施实现移动到 infra/
+5. 从实体中提取聚合
+6. 添加 ArchUnit 测试进行六边形验证
+
+### 架构已过时的迹象
+
+**分层：**
+- 功能跨越多个不相关领域
+- 服务类超过 500 行
+- 难以理解功能范围
+- 更改影响多个不相关功能
+
+**按模块打包：**
+- 模块有循环依赖
+- 难以独立测试模块
+- 模块边界不清晰
+- 需要提取微服务
+
+**模块化单体：**
+- 类型混淆错误（混合 ID、代码、值）
+- 验证逻辑到处分散
+- 原始参数导致错误
+- 金融/医疗领域（需要类型安全）
+
+**番茄：**
+- 多个聚合中的复杂业务规则
+- 需要交换基础设施（数据库、消息队列）
+- 多个团队在同一代码库上工作
+- 计划微服务提取
+
+## 最佳实践
+
+### 从简单开始
+- 从分层或按模块打包开始
+- 不要过早为规模优化
+- 当复杂度需要时再升级架构
+- 通过团队规模、生命周期和领域复杂度来衡量复杂度
+
+### 类型安全
+- 对领域概念使用值对象（不仅仅是原始类型）
+- 利用 Java 记录实现不可变性
+- 启用 JSpecify 空安全（@NullMarked）
+- 适当时对状态/枚举使用密封类
+
+### 模块边界
+- 每个模块应有明确的职责
+- 最小化模块间的依赖
+- 使用事件进行跨模块通信
+- 独立测试模块
+
+### 基础设施
+- 始终使用 Testcontainers 进行集成测试
+- 始终使用 Docker Compose 进行本地开发
+- 始终使用 ProblemDetail 进行 REST 错误响应