Codex
60eeb8aef5
## 背景 用户指令：「先将 codex 的任务一并改为 workbuddy 的任务」。 Codex 已不再运行，当前由 WorkBuddy 承担开发执行，文档署名需同步。 ## 判定规则（用大小写精确区分） | 类别 | 写法 | 处置 | |---|---|---| | 工具署名 | 大写 Codex | → WorkBuddy | | 分支名 | codex/ui-v11-fidelity | → workbuddy-ui-v11-fidelity（去斜杠，规避本仓库 ref 清理） | | 已删除文件的历史路径 | 小写 2026-09-11-codex-baseline-cleanup* | 保持原样（记录真实曾存在的文件名，改了即失真） | 结果：26 个文件、126 处署名替换。残留小写 codex 仅 8 处，全部是历史路径。 ## 文件重命名（git mv，保留历史） - Codex开发执行总指令、项目规则与任务拆解.md → WorkBuddy 同名 - Codex首轮启动提示词 + Phase 01～Phase 26 Jira级任务清单 + 每阶段验收条件.md → WorkBuddy 同名 - docs/善缘丹阳 V1.1 Codex 开发执行计划修订版.md → docs/善缘丹阳 V1.1 WorkBuddy 开发执行计划修订版.md - docs/善缘丹阳 V1.1 Codex-Jira 最终开发任务增量清单.md → docs/善缘丹阳 V1.1 WorkBuddy-Jira 最终开发任务增量清单.md - docs/善缘丹阳 V1.1 Codex最终主启动提示词（整合版）.md → docs/善缘丹阳 V1.1 WorkBuddy最终主启动提示词（整合版）.md 引用已同步：AGENTS.md 6 处、AGENTS_SUMMARY.md、以及 4 份计划/规格文档。 ## AGENTS.md 两处特别处理 - 「git config user.name = Codex」一句改为不点名工具的表述 - 「feature/ fix/ codex/ ui/ 前缀」示例去掉 codex/ ## 有意未改动 - ui-tests/ui-document-baseline-contracts.mjs 的废弃清单仍列 codex-baseline-cleanup* 那是「必须不存在」的断言目标，改了会让哨兵失去意义 - 仓库 git config user.name 仍是 Codex —— 未擅自改动环境身份。 如需彻底交接：git config user.name WorkBuddy && git config user.email workbuddy@local 验证：UI 契约门禁 13/13；AGENTS.md 零 Codex 残留；5 个新文件名与全部引用一致
77 lines
1.8 KiB
Markdown
77 lines
1.8 KiB
Markdown
# ADR-001: 技术栈决策
|
|
|
|
**状态**: 已批准
|
|
**日期**: 2026-08-28
|
|
**决策者**: WorkBuddy（依据项目总指令）
|
|
|
|
---
|
|
|
|
## 背景
|
|
|
|
项目需要一个稳定、成熟、易维护的技术栈来支撑 V1.0 开发，同时满足国内运营环境和长期可维护性要求。
|
|
|
|
---
|
|
|
|
## 决策
|
|
|
|
### Backend
|
|
|
|
采用 **Java 21 + Spring Boot 3.x**。
|
|
|
|
理由：
|
|
- 事务管理能力强，对 Match 并发、活动名额等核心场景友好
|
|
- Spring Security 提供成熟的权限框架
|
|
- 国内团队普遍熟悉，便于长期维护
|
|
- 模块化单体架构天然支持
|
|
- MyBatis-Plus 或 Spring Data JPA 均可，V1 优先使用 MyBatis-Plus（国内生态更成熟）
|
|
|
|
### Database
|
|
|
|
采用 **PostgreSQL**。
|
|
|
|
理由：
|
|
- 成熟稳定，事务能力强
|
|
- JSONB 支持良好，适合混合结构化/半结构化数据
|
|
- 索引能力成熟，适合匹配查询优化
|
|
- 开源无授权成本
|
|
- 与 Spring Boot 集成完善
|
|
|
|
### Cache
|
|
|
|
采用 **Redis**。
|
|
|
|
用途：Session、Token 辅助、限流、推荐缓存、未读计数、分布式锁。
|
|
|
|
### Miniapp
|
|
|
|
采用 **微信原生小程序 + TypeScript**。
|
|
|
|
理由：
|
|
- 无需引入跨端框架增加维护成本
|
|
- 官方支持完善
|
|
- 与微信登录/订阅消息生态无缝对接
|
|
|
|
### Admin Web
|
|
|
|
采用 **Vue 3 + TypeScript + Vite + Pinia + Element Plus**。
|
|
|
|
理由：
|
|
- 国内团队生态成熟
|
|
- Element Plus 组件库丰富，适合后台管理系统
|
|
- Vite 构建快，开发体验好
|
|
|
|
### Deployment
|
|
|
|
采用 **Docker + Docker Compose + Nginx**。
|
|
|
|
暂不引入 K8s / Kafka / Elasticsearch 等复杂基础设施。
|
|
|
|
---
|
|
|
|
## 后果
|
|
|
|
- 团队需要熟悉 Java 21 / Spring Boot 3.x 生态
|
|
- PostgreSQL 需要运维支持（备份、监控）
|
|
- Redis 需要运维支持（持久化配置、内存管理）
|
|
- 后期如有扩展需求，可从单体拆分为服务（Messaging → Match → Notification → Analytics 优先拆分）
|