---
date: 2026-06-02
topic: geo-launch-sprint
---

# GEO Platform Launch Sprint

## Summary

双轨并行推进 GEO 平台到可收费上线状态：轨道A解决部署阻塞、Dockerfile修复、安全加固和时区迁移让系统可运行；轨道B在时区迁移完成后并行建设完整测试体系、平台规则中心和真实支付集成，让系统可收费且质量有保障。

## Problem Frame

GEO 平台已完成核心功能开发（8个AI Agent、6阶段内容管线、5维品牌评分、前端可视化），但从未作为完整产品在浏览器中端到端运行过。6个现有计划中存在大量标记完成但实际未验证的关键事项：Dockerfile健康检查端点错误、68个DateTime列缺少timezone导致asyncpg运行时错误、Redis无密码/PostgreSQL弱密码、支付仍为mock模式、测试体系大部分未建立、平台规则中心30个测试用例全部未完成。系统目前处于"代码写完但不可运行、不可收费、不可信赖"的状态。

## Key Decisions

- **双轨并行而非顺序推进**: 轨道A（上线阻塞）和轨道B（功能完善）同时推进，速度优先但需协调交叉依赖
- **可收费上线定义**: 核心流程跑通 + 真实支付集成，邮件通知和完整E2E测试覆盖可后续补
- **完整测试体系纳入上线范围**: Plan 002全部11个单元纳入，而非仅关键E2E
- **平台规则中心同步完成**: 30个测试用例纳入本次工作，不推迟到上线后
- **测试体系在时区迁移后搭建**: 68列DateTime(timezone=True)迁移可能影响测试数据，先完成迁移再建测试

## Requirements

**轨道A — 上线阻塞项**

- R1. Docker Compose一键启动成功，前后端均可访问，CORS配置正确
- R2. Dockerfile HEALTHCHECK端点从`/api/health`修正为`/health`，容器健康检查通过
- R3. `.env.test`补充`JWT_SECRET`，测试环境可正常运行认证流程
- R4. 前端浏览器认证流程完整可用（注册→登录→token刷新→401处理）
- R5. Redis配置密码认证，PostgreSQL使用强密码，`.env.production`模板安全完整
- R6. 68个DateTime列迁移为`DateTime(timezone=True)`，Alembic迁移脚本生成并执行成功，asyncpg不再报timezone运行时错误
- R7. 诊断评分非零场景验证通过，品牌健康评分计算逻辑正确

**轨道B — 功能完善项**

- R8. 后端测试目录统一（17个测试迁移到标准目录结构）
- R9. 共享fixture系统建立，测试数据工厂可复用
- R10. E2E测试覆盖诊断-策略流程和内容-监控流程
- R11. CI集成E2E测试，性能基线建立
- R12. CI安全扫描和迁移验证集成
- R13. 测试文档更新，反映新目录结构和fixture使用方式
- R14. 平台规则中心RuleValidator、SensitiveFilter、SEOOptimizer、HTMLGenerator、ContentPipeline全部测试用例通过
- R15. 微信支付和支付宝真实SDK集成，替换mock模式，支付闭环可走通
- R16. 归因系统2-4周窗口验证通过

## Scope Boundaries

**Deferred for later:**

- 真实SMTP邮件集成（当前使用控制台输出）
- 知识库/生命周期/发布等占位页面实现
- Landing page移动端测试和表单后端集成
- 知乎/头条OAuth第三方登录验证
- 前端E2E浏览器自动化测试（Playwright/Cypress）
- Docker Compose部署的完整生产环境验证

**Outside this product's identity:**

- 无

## Dependencies / Assumptions

- 时区迁移（R6）必须在测试体系建设（R8-R13）之前完成，否则测试数据可能因迁移失效
- 真实支付SDK集成（R15）需要微信/支付宝商户号和密钥，假设已具备或可获取
- Docker Compose部署验证（R1）需要本地Docker环境可用
- 归因系统验证（R16）依赖支付闭环（R15）完成后才能端到端验证

## Outstanding Questions

**Deferred to Planning:**

- 微信/支付宝商户资质是否已就绪？若未就绪，支付集成（R15）可能需要调整方案
- CI环境选择（GitHub Actions / 自建Runner），影响R11和R12的实现方式
- 68列时区迁移是否需要数据回填（现有数据时区转换策略）

## Sources / Research

- `geo/docs/plans/2026-06-01-004-chore-geo-launch-readiness-sprint-plan.md` — 上线就绪冲刺计划，U3/U3.5/U4/U5/U6未完成
- `geo/docs/plans/2026-06-01-005-chore-geo-tech-debt-cleanup-plan.md` — 技术债清理计划，U4时区迁移/U6前端验证/U7安全加固未完成
- `geo/docs/plans/2026-05-31-002-test-quality-assurance-system-plan.md` — 测试质量保障体系，11个单元大部分未完成
- `geo/docs/plans/2026-05-31-003-feat-geo-monetization-closed-loop-plan.md` — 变现闭环计划，U6归因/U7邮件/真实SDK未完成
- `.trae/specs/platform-rules-enforcement/spec.md` — 规则中心详细规格
- `.trae/specs/platform-rules-enforcement/tasks.md` — 规则中心30个测试用例全部未完成
- `.understand-anything/knowledge-graph.json` — 项目知识图谱（48节点、30边）