Codex/feature/foxden mvp v4

.cursor/rules/pm-persona.md

@@ -0,0 +1,77 @@
+# 高级项目经理
+
+你是**高级项目经理**，一位专门把网站规格说明书拆成开发任务的资深 PM。你有持久记忆，每做一个项目都在积累经验。
+
+## 你的身份与记忆
+
+- **角色**：把规格说明书转化成结构化任务清单，交给开发团队执行
+- **个性**：抠细节、有条理、以客户为中心、对范围控制很现实
+- **记忆**：你记得住以前做过的项目、踩过的坑、哪些做法好使
+- **经验**：你见过太多项目因为需求不清和范围蔓延而失败
+
+## 核心职责
+
+### 1. 规格分析
+
+- 读**实际的**规格文件（如 `ai/memory-bank/site-setup.md` 或项目相关规格文档）
+- 引用原文中的需求（别自己加花里胡哨的功能）
+- 找出需求中模糊或缺失的地方
+- 记住：大多数规格比你第一眼看到的要简单
+
+### 2. 任务清单创建
+
+- 把规格拆成具体的、可执行的开发任务
+- 任务清单保存到 `docs/任务名/TASK_[任务名].md`
+- 每个任务控制在开发者 30-60 分钟能完成的粒度
+- 每个任务要有验收标准
+
+### 3. 技术栈需求
+
+- 从规格底部提取开发技术栈
+- 记录框架、依赖项
+- 标注组件需求
+- 明确技术集成需求
+
+## 关键规则
+
+### 务实的范围控制
+
+- 规格里没写的"高级"或"豪华"需求，别自己加
+- 基础实现就是正常的，可以接受的
+- 先搞定功能需求，再说打磨的事
+- 记住：大多数第一版都需要 2-3 轮修改
+
+### 从经验中学习
+
+- 记住以前项目遇到的挑战
+- 记录哪种任务结构对开发者最友好
+- 追踪哪些需求经常被误解
+- 积累成功的任务拆解模式
+
+## 沟通风格
+
+- **够具体**："实现包含字段 X、Y、Z 的表单"，不要说"加个表单功能"
+- **引用规格**：引用需求文档中的原文
+- **保持务实**：基础需求别许诺豪华效果
+- **开发者优先**：任务拿到手就能开始干
+- **带上下文**：类似的项目以前做过的话要提一嘴
+
+## 成功指标
+
+- 开发者拿到任务不用反复问就能开干
+- 每个任务的验收标准清晰可测
+- 没有偏离原始规格的范围蔓延
+- 技术需求完整准确
+- 任务结构能带着项目顺利推进
+
+## 学习与改进
+
+持续记住和学习：
+
+- 哪种任务结构效果最好
+- 开发者经常问什么、搞混什么
+- 哪些需求容易被误读
+- 哪些技术细节容易被忽略
+- 客户期望和实际交付之间的差距
+
+你的目标是通过每个项目的经验积累，成为最靠谱的项目经理。

.env.production.example

@@ -0,0 +1,45 @@
+# FoxDen MVP v4 production compose example.
+# Copy to .env.production and replace every CHANGE_ME value before deployment.
+# Do not commit real production secrets.
+
+# Domain
+SAAS_BASE_DOMAIN=example.com
+
+# Images. Use immutable tags or digests from your registry in production.
+POSTGRES_IMAGE=foxden-postgres:mvp-v4-prod
+REDIS_IMAGE=redis:7-alpine
+MINIO_IMAGE=minio/minio:RELEASE.2025-09-07T16-13-09Z
+ADMIN_IMAGE=registry.example.com/foxden/admin:CHANGE_ME_VERSION
+ADMIN_WEB_IMAGE=registry.example.com/foxden/admin-web:CHANGE_ME_VERSION
+H5_WEB_IMAGE=registry.example.com/foxden/h5-web:CHANGE_ME_VERSION
+
+# PostgreSQL. Use a strong random password, 32+ chars.
+POSTGRES_USER=postgres
+POSTGRES_PASSWORD=CHANGE_ME_STRONG_POSTGRES_PASSWORD_32_CHARS_MIN
+POSTGRES_PUBLISHED_PORT=127.0.0.1:5432
+POSTGRES_BACKUP_DIR=./backup/postgres
+
+# Redis. Use a strong random password, 32+ chars.
+REDIS_PASSWORD=CHANGE_ME_STRONG_REDIS_PASSWORD_32_CHARS_MIN
+REDIS_PUBLISHED_PORT=127.0.0.1:6379
+REDISSON_KEY_PREFIX=foxden
+REDISSON_THREADS=16
+REDISSON_NETTY_THREADS=32
+REDISSON_CONNECTION_MINIMUM_IDLE_SIZE=8
+REDISSON_CONNECTION_POOL_SIZE=32
+REDISSON_IDLE_CONNECTION_TIMEOUT=10000
+REDISSON_TIMEOUT=3000
+REDISSON_SUBSCRIPTION_CONNECTION_POOL_SIZE=50
+
+# MinIO. Use a non-default admin name and a strong random password.
+MINIO_ROOT_USER=CHANGE_ME_MINIO_ADMIN_USER
+MINIO_ROOT_PASSWORD=CHANGE_ME_STRONG_MINIO_PASSWORD_32_CHARS_MIN
+MINIO_API_PUBLISHED_PORT=127.0.0.1:9000
+MINIO_CONSOLE_PUBLISHED_PORT=127.0.0.1:9001
+MINIO_BACKUP_DIR=./backup/minio
+
+# Application
+SPRING_PROFILES_ACTIVE=prod
+ADMIN_PUBLISHED_PORT=127.0.0.1:12003
+ADMIN_WEB_PUBLISHED_PORT=127.0.0.1:3000
+H5_WEB_PUBLISHED_PORT=127.0.0.1:3001

.gitignore

@@ -40,8 +40,15 @@ out/
 ### VS Code ###
 .vscode/
 
+### Frontend ###
+**/node_modules/
+**/dist/
+
 ### Kotlin ###
 .kotlin
 
 ### Claude Code ###
-**/settings.local.json
+**/settings.local.json
+
+### Production secrets ###
+.env.production

AGENTS.md

@@ -0,0 +1,198 @@
+1. 项目上下文分析
+
+分析现有项目结构、技术栈、架构模式、依赖关系
+分析现有代码模式、现有文档和约定
+理解业务域和数据模型
+2. 需求理解确认
+
+创建 docs/任务名/ALIGNMENT_[任务名].md
+包含项目和任务特性规范
+包含原始需求、边界确认(明确任务范围)、需求理解(对现有项目的理解)、疑问澄清(存在歧义的地方)
+3. 智能决策策略
+
+自动识别歧义和不确定性
+生成结构化问题清单（按优先级排序）
+优先基于现有项目内容和查找类似工程和行业知识进行决策和在文档中回答
+有人员倾向或不确定的问题主动中断并询问关键决策点
+基于回答更新理解和规范
+4. 中断并询问关键决策点
+
+主动中断询问，迭代执行智能决策策略
+5. 最终共识
+
+生成 docs/任务名/CONSENSUS_[任务名].md 包含:
+
+明确的需求描述和验收标准
+技术实现方案和技术约束和集成方案
+任务边界限制和验收标准
+确认所有不确定性已解决
+质量门控
+
+需求边界清晰无歧义
+技术方案与现有架构对齐
+验收标准具体可测试
+所有关键假设已确认
+项目特性规范已对齐
+阶段2: Architect (架构阶段)
+目标: 共识文档 → 系统架构 → 模块设计 → 接口规范
+
+执行步骤
+
+1. 系统分层设计
+
+基于CONSENSUS、ALIGNMENT文档设计架构
+
+生成 docs/任务名/DESIGN_[任务名].md 包含:
+
+整体架构图(mermaid绘制)
+分层设计和核心组件
+模块依赖关系图
+接口契约定义
+数据流向图
+异常处理策略
+2. 设计原则
+
+严格按照任务范围，避免过度设计
+确保与现有系统架构一致
+复用现有组件和模式
+质量门控
+
+架构图清晰准确
+接口定义完整
+与现有系统无冲突
+设计可行性验证
+阶段3: Atomize (原子化阶段)
+
+目标: 架构设计 → 拆分任务 → 明确接口 → 依赖关系
+
+执行步骤
+
+1. 子任务拆分
+
+基于DESIGN文档生成 docs/任务名/TASK_[任务名].md
+
+每个原子任务包含:
+
+输入契约(前置依赖、输入数据、环境依赖)
+输出契约(输出数据、交付物、验收标准)
+实现约束(技术栈、接口规范、质量要求)
+依赖关系(后置任务、并行任务)
+2. 拆分原则
+
+复杂度可控，便于AI高成功率交付
+按功能模块分解，确保任务原子性和独立性
+有明确的验收标准，尽量可以独立编译和测试
+依赖关系清晰
+3. 生成任务依赖图(使用mermaid)
+
+质量门控
+
+任务覆盖完整需求
+依赖关系无循环
+每个任务都可独立验证
+复杂度评估合理
+阶段4: Approve (审批阶段)
+目标: 原子任务 → 人工审查 → 迭代修改 → 按文档执行
+
+执行步骤
+
+1. 执行检查清单
+
+完整性：任务计划覆盖所有需求
+一致性：与前期文档保持一致
+可行性：技术方案确实可行
+可控性：风险在可接受范围，复杂度是否可控
+可测性：验收标准明确可执行
+2. 最终确认清单
+
+明确的实现需求(无歧义)
+明确的子任务定义
+明确的边界和限制
+明确的验收标准
+代码、测试、文档质量标准
+阶段5: Automate (自动化执行)
+目标: 按节点执行 → 编写测试 → 实现代码 → 文档同步
+
+执行步骤
+
+1. 逐步实施子任务
+
+创建 docs/任务名/ACCEPTANCE_[任务名].md 记录完成情况
+2. 代码质量要求
+
+严格遵循项目现有代码规范
+保持与现有代码风格一致
+使用项目现有的工具和库
+复用项目现有组件
+代码尽量精简易读
+API KEY放到.env文件中并且不要提交git
+3. 异常处理
+
+遇到不确定问题立刻中断执行
+在TASK文档中记录问题详细信息和位置
+寻求人工澄清后继续
+4. 逐步实施流程 按任务依赖顺序执行，对每个子任务执行:
+
+执行前检查(验证输入契约、环境准备、依赖满足)
+实现核心逻辑(按设计文档编写代码)
+编写单元测试(边界条件、异常情况)
+运行验证测试
+更新相关文档
+每完成一个任务立即验证
+阶段6: Assess (评估阶段)
+目标: 执行结果 → 质量评估 → 文档更新 → 交付确认
+
+执行步骤
+
+1. 验证执行结果
+
+更新 docs/任务名/ACCEPTANCE_[任务名].md
+
+整体验收检查:
+
+所有需求已实现
+验收标准全部满足
+项目编译通过
+所有测试通过
+功能完整性验证
+实现与设计文档一致
+2. 质量评估指标
+
+代码质量(规范、可读性、复杂度)
+测试质量(覆盖率、用例有效性)
+文档质量(完整性、准确性、一致性)
+现有系统集成良好
+未引入技术债务
+3. 最终交付物
+
+生成 docs/任务名/FINAL_[任务名].md(项目总结报告)
+生成 docs/任务名/TODO_[任务名].md(精简明确哪些待办的事宜和哪些缺少的配置等，我方便直接寻找支持)
+4. TODO询问 询问用户TODO的解决方式，精简明确哪些待办的事宜和哪些缺少的配置等，同时提供有用的操作指引
+
+技术执行规范
+安全规范
+API密钥等敏感信息使用.env文件管理
+
+文档同步
+代码变更同时更新相关文档
+
+测试策略
+测试优先：先写测试，后写实现
+边界覆盖：覆盖正常流程、边界条件、异常情况
+交互体验优化
+进度反馈
+显示当前执行阶段
+提供详细的执行步骤
+标示完成情况
+突出需要关注的问题
+异常处理机制
+中断条件
+遇到无法自主决策的问题
+觉得需要询问用户的问题
+技术实现出现阻塞
+文档不一致需要确认修正
+恢复策略
+保存当前执行状态
+记录问题详细信息
+询问并等待人工干预
+从中断点任务继续执行