diff --git a/docs/brainstorms/2026-06-02-geo-launch-sprint-requirements.md b/docs/brainstorms/2026-06-02-geo-launch-sprint-requirements.md
new file mode 100644
index 0000000..b8a0070
--- /dev/null
+++ b/docs/brainstorms/2026-06-02-geo-launch-sprint-requirements.md
@@ -0,0 +1,86 @@
+---
+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边）
diff --git a/docs/plans/2026-06-02-007-chore-geo-launch-sprint-plan.md b/docs/plans/2026-06-02-007-chore-geo-launch-sprint-plan.md
new file mode 100644
index 0000000..51832a0
--- /dev/null
+++ b/docs/plans/2026-06-02-007-chore-geo-launch-sprint-plan.md
@@ -0,0 +1,403 @@
+---
+title: "chore: GEO Platform Launch Sprint — Dual-Track to Billable Launch"
+type: chore
+status: active
+date: 2026-06-02
+origin: docs/brainstorms/2026-06-02-geo-launch-sprint-requirements.md
+---
+
+# GEO Platform Launch Sprint — Dual-Track to Billable Launch
+
+## Summary
+
+双轨并行推进 GEO 平台到可收费上线状态：轨道A解决部署验证、生产环境配置和安全加固让系统可运行；轨道B并行建设完整测试体系、平台规则中心测试补全和支付SDK集成让系统可收费且质量有保障。研究阶段发现 R2/R3/R6 在代码层面已修复，转为验证确认；支付SDK当前为骨架状态需真实API接入。
+
+## Problem Frame
+
+GEO 平台核心功能开发已完成（8个AI Agent、6阶段内容管线、5维品牌评分、前端可视化），但从未作为完整产品端到端运行。6个现有计划中标记完成的关键事项实际未验证：生产环境配置缺失、支付为mock模式、测试体系大部分未建立、规则中心30个测试用例全部未完成。系统处于"代码写完但不可运行、不可收费、不可信赖"的状态。
+
+---
+
+## Requirements
+
+**轨道A — 上线阻塞项**
+
+- R1. Docker Compose一键启动成功，前后端均可访问，CORS配置正确
+- R2. Dockerfile HEALTHCHECK端点验证通过（代码已修复为`/health`，需确认运行时行为）
+- R3. `.env.test` JWT_SECRET验证可用（代码已配置，需确认测试环境运行正常）
+- R4. 前端浏览器认证流程完整可用（注册→登录→token刷新→401处理）
+- R5. 生产环境安全配置完整：Redis密码认证、PostgreSQL强密码、`.env.production`文件创建、生产镜像切换为pgvector
+- R6. DateTime timezone验证通过（代码已全部使用`DateTime(timezone=True)`，需确认asyncpg运行时无报错）
+- R7. 诊断评分非零场景验证通过，品牌健康评分计算逻辑正确
+
+**轨道B — 功能完善项**
+
+- R8. 后端测试目录统一，散落的测试文件迁移到标准目录结构
+- R9. 共享fixture系统扩展，测试数据工厂可复用
+- R10. E2E测试覆盖诊断-策略流程和内容-监控流程
+- R11. CI集成E2E测试，性能基线建立
+- R12. CI安全扫描和迁移验证集成
+- R13. 测试文档更新
+- R14. 平台规则中心RuleValidator、SensitiveFilter、SEOOptimizer、HTMLGenerator、ContentPipeline测试用例补全至30个
+- R15. 微信支付和支付宝真实SDK集成，未配置时降级mock模式
+- R16. 归因系统窗口可配置（当前硬编码28天），2-4周窗口验证通过
+
+---
+
+## Key Technical Decisions
+
+- **生产PostgreSQL镜像切换为pgvector**: `docker-compose.prod.yml`使用`postgres:15-alpine`缺少pgvector扩展，切换为`pgvector/pgvector:pg15`以支持向量搜索功能 (see origin)
+- **支付SDK集成策略**: 代码层面完成真实API调用集成，`_is_configured()`检测未配置时自动降级为MockGateway，SDK申请在功能验证后进行 (see origin)
+- **测试体系在时区迁移验证后搭建**: R6验证通过后再开始R8-R13，避免测试数据因迁移失效 (see origin)
+- **双轨并行而非顺序推进**: 轨道A和轨道B同时推进，速度优先但需协调交叉依赖 (see origin)
+- **已有测试文件保留而非重写**: `test_content_pipeline/`已有6个测试文件，在其基础上补全至30个用例
+
+---
+
+## High-Level Technical Design
+
+```mermaid
+flowchart TB
+    subgraph TrackA["轨道A — 上线阻塞"]
+        U1[U1. Docker Compose部署验证] --> U2[U2. 生产环境安全配置]
+        U2 --> U3[U3. 浏览器认证流验证]
+        U3 --> U4[U4. DateTime/评分运行时验证]
+    end
+
+    subgraph TrackB["轨道B — 功能完善"]
+        U5[U5. 测试体系基础设施] --> U6[U6. E2E测试+CI集成]
+        U5 --> U7[U7. 规则中心测试补全]
+        U6 --> U8[U8. 支付SDK集成+归因窗口]
+    end
+
+    U4 -.->|验证通过| U5
+    U2 -.->|环境就绪| U6
+```
+
+---
+
+## Implementation Units
+
+### U1. Docker Compose Deployment Verification
+
+**Goal:** 验证 Docker Compose 一键启动成功，前后端可访问，CORS配置正确
+
+**Requirements:** R1, R2, R3
+
+**Dependencies:** none
+
+**Files:**
+- `docker-compose.yml`
+- `docker-compose.prod.yml`
+- `backend/Dockerfile`
+- `frontend/Dockerfile`
+- `.env.example`
+- `backend/.env.test`
+- `backend/tests/test_infrastructure/test_docker_health.py`
+
+**Approach:** 从 `.env.example` 创建 `.env` 文件，执行 `docker compose up --build`，验证所有服务启动成功。确认后端 `/health` 端点返回200，前端3000端口可访问，CORS头正确返回。验证 `.env.test` 中 JWT_SECRET 在测试环境中生效。生产docker-compose需切换PostgreSQL镜像为pgvector。
+
+**Patterns to follow:** 现有 `docker-compose.yml` 开发环境配置模式
+
+**Test scenarios:**
+- Docker Compose up: 所有4个服务(backend, frontend, db, redis)启动成功，无错误日志
+- Backend health: `GET /health` 返回200和健康状态JSON
+- Frontend access: `GET http://localhost:3000` 返回200
+- CORS headers: 开发模式允许所有来源，生产模式仅允许配置的来源
+- JWT_SECRET in test: pytest运行时使用`.env.test`中的JWT_SECRET，认证fixture正常工作
+
+**Verification:** `docker compose up --build` 成功，`curl http://localhost:8000/health` 返回200，`curl http://localhost:3000` 返回HTML
+
+---
+
+### U2. Production Environment Security Configuration
+
+**Goal:** 创建生产环境安全配置，包括Redis密码、PostgreSQL强密码、`.env.production`文件、pgvector镜像切换
+
+**Requirements:** R5
+
+**Dependencies:** U1
+
+**Files:**
+- `docker-compose.prod.yml`
+- `.env.production.example`
+- `.env.production` (新建)
+- `backend/app/config.py`
+- `backend/alembic/env.py`
+
+**Approach:** 1) 将 `docker-compose.prod.yml` 中 PostgreSQL 镜像从 `postgres:15-alpine` 切换为 `pgvector/pgvector:pg15`；2) 从 `.env.production.example` 创建 `.env.production`，替换所有 `CHANGE_ME` 占位符为强密码/密钥；3) 确认 Redis 密码配置在生产 docker-compose 中生效；4) 验证 Alembic 迁移在生产数据库上可执行。
+
+**Patterns to follow:** 现有 `docker-compose.prod.yml` 双网络架构，`.env.production.example` 变量结构
+
+**Test scenarios:**
+- Production compose up: `docker compose -f docker-compose.prod.yml up` 启动成功
+- Redis auth: 无密码连接被拒绝，使用配置密码连接成功
+- PostgreSQL auth: 默认密码被拒绝，使用强密码连接成功
+- pgvector extension: `CREATE EXTENSION IF NOT EXISTS vector` 在生产数据库中执行成功
+- Alembic migration: `alembic upgrade head` 在生产数据库上执行成功
+- Network isolation: 外部无法直接访问PostgreSQL和Redis端口
+
+**Verification:** 生产docker-compose启动成功，Redis/PostgreSQL密码认证生效，pgvector扩展可用，Alembic迁移成功
+
+---
+
+### U3. Browser Authentication Flow Verification
+
+**Goal:** 验证前端浏览器认证流程完整可用，包括注册、登录、token刷新、401处理
+
+**Requirements:** R4
+
+**Dependencies:** U1
+
+**Files:**
+- `frontend/lib/api/client.ts`
+- `frontend/lib/auth.ts`
+- `frontend/app/(auth)/login/page.tsx`
+- `frontend/app/(auth)/register/page.tsx`
+- `frontend/app/api/auth/[...nextauth]/route.ts`
+- `frontend/e2e/tests/login.spec.ts`
+- `frontend/e2e/tests/login-redirect.spec.ts`
+- `frontend/e2e/tests/login-access.spec.ts`
+
+**Approach:** 使用现有Playwright E2E测试验证完整认证流程。确认NextAuth JWT策略工作正常，refreshAccessToken轮换机制正确，fetchWithAuth的401自动重试逻辑有效。若现有E2E测试覆盖不足则补充。
+
+**Patterns to follow:** 现有 `e2e/tests/login*.spec.ts` 测试模式，`e2e/pages/login.page.ts` Page Object模式
+
+**Test scenarios:**
+- Registration: 新用户注册成功，跳转到onboarding页面
+- Login: 已注册用户登录成功，跳转到dashboard
+- Token refresh: access token过期后自动刷新，用户无感知
+- 401 handling: API返回401时自动重试一次（刷新token后），仍失败则跳转登录页
+- Session persistence: 刷新页面后保持登录状态
+
+**Verification:** Playwright E2E认证测试全部通过，手动浏览器验证注册→登录→使用→刷新→登出流程
+
+---
+
+### U4. DateTime Timezone and Scoring Runtime Verification
+
+**Goal:** 验证DateTime timezone配置在asyncpg运行时无报错，诊断评分非零场景正确
+
+**Requirements:** R6, R7
+
+**Dependencies:** U2
+
+**Files:**
+- `backend/app/models/` (所有含DateTime列的模型)
+- `backend/alembic/versions/a79329c23b20_initial_complete_schema.py`
+- `backend/app/services/scoring/scoring_service.py`
+- `backend/app/services/attribution/attribution_engine.py`
+- `backend/tests/test_models/`
+- `backend/tests/test_services/test_scoring.py`
+
+**Approach:** 1) 连接生产PostgreSQL（asyncpg驱动），执行涉及DateTime列的CRUD操作，确认无timezone相关运行时错误；2) 创建品牌评分记录，验证5维度评分计算逻辑产生非零分数；3) 验证归因窗口计算正确。
+
+**Patterns to follow:** 现有 `tests/test_models/` 和 `tests/test_services/` 测试模式
+
+**Test scenarios:**
+- DateTime CRUD: 创建/读取/更新含DateTime列的记录，asyncpg不报timezone错误
+- DateTime round-trip: 写入带时区的datetime，读取后时区信息保留
+- Scoring non-zero: 对有引用数据的品牌执行评分，5个维度均产生非零分数
+- Health score calculation: 品牌健康评分 = 加权总分，等级划分正确(excellent/good/pass/danger)
+- Attribution window: 归因窗口从start_at到window_end_at计算正确，28天后状态变为completed
+
+**Verification:** 所有DateTime操作无asyncpg错误，评分计算产生合理非零分数，归因窗口计算正确
+
+---
+
+### U5. Test Infrastructure — Directory Unification and Shared Fixtures
+
+**Goal:** 统一后端测试目录结构，扩展共享fixture系统
+
+**Requirements:** R8, R9
+
+**Dependencies:** U4
+
+**Files:**
+- `backend/tests/conftest.py`
+- `backend/tests/fixtures/` (扩展)
+- `backend/tests/test_api/`
+- `backend/tests/test_services/`
+- `backend/tests/test_models/`
+- `backend/tests/test_content_pipeline/`
+- `backend/tests/test_agent_framework/`
+- `backend/tests/test_integration/`
+- `backend/tests/test_middleware/`
+- `backend/tests/test_infrastructure/`
+- `backend/tests/test_repositories/`
+- `backend/pyproject.toml`
+
+**Approach:** 1) 将根目录散落的测试文件（test_config.py, test_performance.py, test_security.py, test_scheduler.py等）迁移到对应的`tests/`子目录；2) 扩展`tests/fixtures/`添加品牌、用户、内容的工厂fixture；3) 更新`conftest.py`统一fixture注册；4) 确保迁移后所有测试仍通过。
+
+**Execution note:** 迁移前先运行全部测试记录基线，迁移后验证所有测试仍通过
+
+**Patterns to follow:** 现有 `tests/conftest.py` 的 SQLite内存数据库 + 依赖注入覆盖模式，`tests/fixtures/` 的工厂fixture模式
+
+**Test scenarios:**
+- Directory structure: 所有测试文件位于`tests/`子目录下，根目录无散落测试文件
+- Fixture availability: 新工厂fixture在所有测试文件中可用
+- Test pass rate: 迁移后测试通过率与迁移前一致
+- Import paths: 迁移后的测试文件import路径正确
+
+**Verification:** `pytest` 全部通过，无根目录散落测试文件，新fixture可被任意测试文件使用
+
+---
+
+### U6. E2E Tests and CI Integration
+
+**Goal:** 补充诊断-策略和内容-监控E2E测试，集成到CI，建立性能基线，添加安全扫描
+
+**Requirements:** R10, R11, R12
+
+**Dependencies:** U5
+
+**Files:**
+- `frontend/e2e/tests/diagnosis-strategy.spec.ts` (新建)
+- `frontend/e2e/tests/content-monitoring.spec.ts` (新建)
+- `frontend/e2e/pages/` (新增Page Objects)
+- `.github/workflows/ci.yml`
+- `.github/workflows/pr-check.yml`
+- `backend/tests/test_performance.py`
+- `backend/tests/test_security.py`
+
+**Approach:** 1) 新增两个Playwright E2E spec覆盖诊断→策略推荐和内容生成→监控流程；2) 在CI workflow中添加E2E测试步骤（启动服务→运行Playwright→收集结果）；3) 建立性能基线（API响应时间p95）；4) 添加CI安全扫描步骤（bandit for Python, npm audit for frontend）。
+
+**Patterns to follow:** 现有 `e2e/tests/core-flow-smoke.spec.ts` E2E测试模式，`.github/workflows/ci.yml` CI配置模式
+
+**Test scenarios:**
+- Diagnosis-strategy E2E: 用户提交品牌→系统执行诊断→生成策略推荐→用户可查看
+- Content-monitoring E2E: 用户生成内容→内容发布→监控任务创建→监控数据展示
+- CI E2E step: PR提交时自动运行E2E测试，失败则阻止合并
+- Performance baseline: API端点p95响应时间记录，回归时CI告警
+- Security scan: bandit扫描后端代码，npm audit扫描前端依赖，高危漏洞阻止合并
+
+**Verification:** CI pipeline中E2E测试步骤运行成功，性能基线文件生成，安全扫描步骤存在且可执行
+
+---
+
+### U7. Platform Rules Center Test Completion
+
+**Goal:** 补全平台规则中心测试用例至30个，覆盖RuleValidator、SensitiveFilter、SEOOptimizer、HTMLGenerator、ContentPipeline
+
+**Requirements:** R14
+
+**Dependencies:** U5
+
+**Files:**
+- `backend/tests/test_content_pipeline/test_rule_validator.py`
+- `backend/tests/test_content_pipeline/test_sensitive_filter.py`
+- `backend/tests/test_content_pipeline/test_seo_optimizer.py`
+- `backend/tests/test_content_pipeline/test_html_generator.py`
+- `backend/tests/test_content_pipeline/test_content_pipeline.py`
+- `backend/tests/test_content_pipeline/test_content_generation.py`
+- `.trae/specs/platform-rules-enforcement/tasks.md`
+- `.trae/specs/platform-rules-enforcement/spec.md`
+
+**Approach:** 以 `.trae/specs/platform-rules-enforcement/tasks.md` 中的30个测试用例为蓝图，在现有6个测试文件基础上补全。每个组件的测试覆盖：平台特定规则校验、边界条件、错误处理、组件间集成。优先覆盖P0平台（知乎、微信、百家号）的规则。
+
+**Execution note:** 参照tasks.md中的TDD RED阶段测试用例，逐个实现
+
+**Patterns to follow:** 现有 `test_content_pipeline/` 测试模式，`platform_rules.py` 中的规则配置结构
+
+**Test scenarios:**
+- RuleValidator: 微信诱导分享检测、知乎营销检测、小红书引流检测、百家号标题党检测、抖音水印检测、AI模式检测
+- SensitiveFilter: 4类基础词库过滤、自定义词库、平台容差级别、替换策略
+- SEOOptimizer: 关键词密度计算、密度范围校验、位置建议、平台特定SEO规则
+- HTMLGenerator: 禁用标签过滤、微信外部链接移除、多格式输出（HTML/Markdown/纯文本）
+- ContentPipeline: 4阶段顺序执行、高严重级别阻断、每阶段耗时记录、错误传播
+- Cross-platform: 10个平台的规则配置完整性校验
+
+**Verification:** 30个测试用例全部通过，`pytest tests/test_content_pipeline/` 无失败
+
+---
+
+### U8. Payment SDK Integration and Attribution Window
+
+**Goal:** 集成微信支付和支付宝真实SDK，支持未配置时降级mock；归因窗口可配置
+
+**Requirements:** R15, R16
+
+**Dependencies:** U5
+
+**Files:**
+- `backend/app/services/payment/wechat_pay.py`
+- `backend/app/services/payment/alipay.py`
+- `backend/app/services/payment/mock_gateway.py`
+- `backend/app/services/payment/base.py`
+- `backend/app/services/payment/__init__.py`
+- `backend/app/api/payments.py`
+- `backend/app/services/attribution/attribution_engine.py`
+- `backend/app/models/attribution_record.py`
+- `backend/app/config.py`
+- `backend/tests/test_services/test_payment.py`
+- `backend/tests/test_services/test_attribution.py`
+
+**Approach:** 1) 微信支付：使用`wechatpayv3`官方SDK或`requests`直接调用V3 API，实现NATIVE扫码支付的create_order（实际发送HTTP请求到微信）、verify_callback（验签）、query_order（查询订单状态）、refund（退款）；2) 支付宝：使用`alipay-sdk-python`或`requests`直接调用API，实现WAP支付的完整流程；3) 保留`_is_configured()`降级机制，未配置时自动使用MockGateway；4) 归因窗口：将硬编码28天改为从配置或订阅计划读取，支持14天/28天可配置。
+
+**Patterns to follow:** 现有 `PaymentGateway` ABC接口，`_is_configured()` 降级模式，`config.py` 配置字段模式
+
+**Test scenarios:**
+- WeChat create_order: 配置完整时发送真实API请求（mock HTTP for test），返回支付二维码URL
+- WeChat verify_callback: 微信回调签名验证通过/失败
+- WeChat query_order: 查询已支付订单返回成功状态
+- WeChat refund: 企业用户发起退款成功
+- Alipay create_order: 配置完整时生成WAP支付表单
+- Alipay verify_callback: RSA2签名验证通过/失败
+- Fallback: 未配置时自动降级为MockGateway，所有操作返回模拟成功
+- Attribution window 14 days: 配置14天窗口，归因在14天后完成
+- Attribution window 28 days: 默认28天窗口行为不变
+- Attribution scoring: 窗口期内维度变化正确计算delta
+
+**Verification:** 支付网关在配置完整时调用真实API（测试环境用mock HTTP），未配置时降级mock；归因窗口可配置且计算正确
+
+---
+
+## Scope Boundaries
+
+**Deferred for later:**
+- 真实SMTP邮件集成（当前使用控制台输出）
+- 知识库/生命周期/发布等占位页面实现
+- Landing page移动端测试和表单后端集成
+- 知乎/头条OAuth第三方登录验证
+- 前端Playwright E2E浏览器自动化测试扩展
+- 限流中间件从内存迁移到Redis
+- 微信/支付宝SDK商户资质申请
+
+**Deferred to Follow-Up Work:**
+- Docker Compose生产环境的完整部署验证（需真实服务器）
+- 归因系统端到端验证（依赖支付闭环完成后）
+- 前端`reports/page.tsx`和`lifecycle/new/page.tsx`绕过统一API客户端的修复
+
+---
+
+## Risks & Dependencies
+
+- **支付SDK商户资质未就绪**: 微信/支付宝SDK申请需要商户资质审核，可能需要1-2周。缓解：代码层面完成集成，未配置时降级mock
+- **生产pgvector镜像兼容性**: `pgvector/pgvector:pg15`与现有迁移脚本的兼容性需验证。缓解：U1中优先验证
+- **E2E测试环境依赖**: Playwright E2E测试需要完整运行的服务栈。缓解：CI中使用docker-compose启动服务
+- **测试迁移风险**: 散落测试文件迁移可能引入import路径问题。缓解：U5中先记录基线再迁移
+- **归因窗口可配置化**: 修改硬编码28天可能影响现有归因记录。缓解：仅影响新创建的归因记录，已有记录不受影响
+
+---
+
+## Open Questions
+
+**Deferred to Planning:**
+- CI环境选择（GitHub Actions / 自建Runner）—— 当前已有`.github/workflows/`，默认使用GitHub Actions
+- 68列时区迁移是否需要数据回填—— 研究发现代码已修复，仅需运行时验证
+- 微信支付V2(MD5签名) vs V3(RSA签名)选择—— V3是微信推荐的新协议，优先使用V3
+
+---
+
+## Sources & Research
+
+- `docs/plans/2026-06-01-004-chore-geo-launch-readiness-sprint-plan.md` — 上线就绪冲刺计划
+- `docs/plans/2026-06-01-005-chore-geo-tech-debt-cleanup-plan.md` — 技术债清理计划
+- `docs/plans/2026-05-31-002-test-quality-assurance-system-plan.md` — 测试质量保障体系
+- `docs/plans/2026-05-31-003-feat-geo-monetization-closed-loop-plan.md` — 变现闭环计划
+- `.trae/specs/platform-rules-enforcement/spec.md` — 规则中心规格
+- `.trae/specs/platform-rules-enforcement/tasks.md` — 规则中心30个测试用例
+- `docker-compose.prod.yml` — 生产PostgreSQL镜像需切换为pgvector
+- `backend/app/services/payment/wechat_pay.py` — 微信支付当前未实际调用API
+- `backend/app/services/payment/alipay.py` — 支付宝当前未实际调用API
+- `backend/app/services/attribution/attribution_engine.py` — 归因窗口硬编码28天