---
title: "chore: GEO Tech Debt Cleanup Sprint"
type: chore
status: active
date: "2026-06-01"
origin: docs/brainstorms/2026-06-01-geo-tech-debt-cleanup-requirements.md
---

## Summary

分三批清理 GEO 平台技术债：Batch 1 修复 28 个模型文件中 68 个缺失 `DateTime(timezone=True)` 的 datetime 列（`monitoring_record.py` 是废弃文件不修）；Batch 2 统一前端 2 个页面组件的 API 客户端调用并扩展 `fetchWithAuth` 支持非 JSON 响应；Batch 3 完成前端端到端验证和部署安全加固。

## Problem Frame

Plan 004 端到端验证暴露了 asyncpg 严格时区检查的系统性问题。当前仅修复了变现闭环涉及的 4 个核心表，其余 28 个模型文件的 68 个 datetime 列仍是确定的运行时炸弹——任何写入 `datetime.now(UTC)` 到未标记 timezone 的列都会直接报错。同时前端 2 个页面绕过统一 API 客户端，认证 token 不被附加导致 401。Docker 部署从未验证成功，Redis/PostgreSQL 安全配置缺失。这些技术债不清理，系统无法真正上线。

---

## Requirements

**时区修复（Batch 1）**

R1. 28 个模型文件的 68 个 datetime 列添加 `DateTime(timezone=True)`，PostgreSQL 对应列类型改为 TIMESTAMPTZ

R2. 时区修复按 API 调用路径分三批执行：核心变现路径 → Agent 框架路径 → 辅助路径

R3. 每批修复后验证对应 API 路径可正常写入和读取 datetime 数据

R4. 生成对应的 Alembic 迁移脚本

R5. 删除废弃的 `monitoring_record.py` 文件（无任何代码引用，与 `monitoring.py` 定义同名表但字段不同）

**前端 API 客户端统一（Batch 2）**

R6. `reports/page.tsx` 的 CSV 导出改用统一 API 客户端

R7. `lifecycle/new/page.tsx` 的项目创建改用统一 API 客户端

R8. 统一 API 客户端支持非 JSON 响应（blob/PDF 导出）

**前端端到端验证（Batch 3）**

R9. 浏览器中可完成完整变现闭环：注册→登录→创建品牌→诊断→查看健康分→付费墙→支付→解锁

R10. 公开健康分页面无需登录即可访问

R11. Onboarding 流程在浏览器中可正常走通

**部署安全加固（Batch 3）**

R12. Redis 配置密码保护

R13. PostgreSQL 默认弱密码更换为强密码

R14. 创建 `.env.production` 模板

R15. Docker Compose 部署验证通过

---

## Key Technical Decisions

KTD1. **时区修复按 API 调用路径分批，而非一次性全量迁移。** 68 列同时 ALTER TABLE 风险高，按实际调用路径修复风险可控。核心变现路径（brand、query、content 等）最优先，因为这是用户最可能触发的路径。

KTD2. **`monitoring_record.py` 是废弃文件，删除而非修复。** 代码引用分析确认所有 import 都指向 `monitoring.py`，`monitoring_record.py` 无任何引用。两个文件定义同名表但字段结构不同，保留 `monitoring.py`（更完整，有 relationship 和 user_id/query_id 外键）。

KTD3. **扩展 `fetchWithAuth` 支持非 JSON 响应，而非新增独立函数。** `reports.ts` 的 PDF blob 导出被迫绕过统一客户端，因为 `fetchWithAuth` 只返回 JSON。扩展一个 `responseType` 参数比新增 `fetchWithAuthBlob` 更符合 DRY 原则，且对现有调用方无侵入。

KTD4. **Alembic 迁移按 Batch 生成，而非一个大迁移。** 每个 Batch 生成一个迁移文件，便于回滚和增量部署。Batch 1 因模型数量多可能需要 2-3 个迁移文件。

---

## Implementation Units

### U1. Batch 1a: 核心变现路径时区修复

- **Goal:** 修复核心变现路径涉及的模型文件 datetime 列，确保品牌创建、查询、内容管理、GEO 计划、建议生成等 API 不再触发 asyncpg 时区错误
- **Requirements:** R1, R2, R3, R4
- **Dependencies:** none
- **Files:**
  - `backend/app/models/brand.py` — 4 列（last_queried_at, next_query_at, created_at, updated_at）
  - `backend/app/models/query.py` — 4 列（last_queried_at, next_query_at, created_at, updated_at）
  - `backend/app/models/citation_record.py` — 1 列（queried_at）
  - `backend/app/models/attribution_record.py` — 4 列（published_at, window_end_at, created_at, updated_at）
  - `backend/app/models/content.py` — 4 列（Content: created_at, updated_at; ContentVersion: created_at; ContentReview: created_at）
  - `backend/app/models/geo_plan.py` — 5 列（GeoPlan: created_at, updated_at; GeoPlanAction: completed_at, created_at, updated_at）
  - `backend/app/models/suggestion.py` — 2 列（generated_at, updated_at）
  - `backend/app/models/competitor.py` — 1 列（created_at）
  - `backend/app/models/competitor_insight.py` — 2 列（created_at, updated_at）
  - `backend/app/models/distribution.py` — 2 列（created_at, updated_at）
  - `backend/app/models/brand_knowledge.py` — 3 列（BrandKnowledge: created_at, updated_at; Keyword: created_at）
- **Approach:** 每个文件添加 `DateTime` import（如缺失），将所有 `Mapped[datetime]` 列的 `mapped_column()` 添加 `DateTime(timezone=True)` 参数。对于已有 `DateTime` 但无 `timezone=True` 的列（如 brand.py 的 last_queried_at），改为 `DateTime(timezone=True)`。修复后启动后端服务，通过 curl 验证品牌创建和查询 API 的 datetime 读写正常。
- **Patterns to follow:** 已修复的 4 个核心表（diagnosis_record.py, payment_order.py, subscription.py, user.py）的修改模式
- **Test scenarios:**
  - 品牌创建 API 返回的 created_at 包含时区信息
  - 查询品牌列表 API 返回的 datetime 字段包含时区信息
  - 创建 GEO 计划后 completed_at 可写入 timezone-aware datetime
  - attribution_record 的 published_at 和 window_end_at 可写入 timezone-aware datetime
- **Verification:** 启动后端服务，通过 curl 调用品牌创建、查询、内容管理 API，确认 datetime 读写无 asyncpg 时区错误

### U2. Batch 1b: Agent 框架路径时区修复

- **Goal:** 修复 Agent 框架和监控相关模型文件的 datetime 列
- **Requirements:** R1, R2, R3, R4
- **Dependencies:** U1
- **Files:**
  - `backend/app/models/agent.py` — 9 列（AgentRegistry: last_heartbeat, created_at, updated_at; AgentConfig: updated_at; AgentTask: scheduled_at, started_at, completed_at, created_at; AgentTaskLog: created_at）
  - `backend/app/models/detection_task.py` — 4 列（last_run_at, next_run_at, created_at, updated_at）
  - `backend/app/models/monitoring.py` — 5 列（MonitoringRecord: last_checked_at, next_check_at, created_at, updated_at; ContentBaseline: recorded_at）
  - `backend/app/models/trend_insight.py` — 4 列（period_start, period_end, created_at, updated_at）
  - `backend/app/models/query_task.py` — 3 列（scheduled_at, started_at, completed_at）
  - `backend/app/models/usage_record.py` — 2 列（timestamp, created_at）
  - `backend/app/models/api_key.py` — 3 列（last_verified_at, created_at, updated_at）
- **Approach:** 同 U1 模式。注意 `detection_task.py` 的 `next_run_at` 有 `default=lambda: datetime.now(timezone.utc)`，这已经是 timezone-aware 的，但列类型仍是 `DateTime`（无 timezone），需要改为 `DateTime(timezone=True)`。
- **Patterns to follow:** U1 的修改模式
- **Test scenarios:**
  - Agent 注册时 last_heartbeat 可写入 timezone-aware datetime
  - AgentTask 的 scheduled_at、started_at、completed_at 可写入 timezone-aware datetime
  - detection_task 的 next_run_at 默认值写入不触发时区错误
  - monitoring_record 的 last_checked_at、next_check_at 可写入 timezone-aware datetime
- **Verification:** 启动后端服务，通过 curl 调用 Agent 相关 API，确认 datetime 读写无错误

### U3. Batch 1c: 辅助路径时区修复 + 废弃文件清理

- **Goal:** 修复剩余辅助路径模型文件的 datetime 列，删除废弃的 monitoring_record.py
- **Requirements:** R1, R2, R3, R4, R5
- **Dependencies:** U2
- **Files:**
  - `backend/app/models/knowledge.py` — 6 列（KnowledgeBase: created_at, updated_at; KnowledgeDocument: created_at, updated_at; KnowledgeChunk: created_at; KnowledgeSearchLog: created_at）
  - `backend/app/models/knowledge_graph.py` — 3 列（KnowledgeEntity: created_at, updated_at; KnowledgeRelation: created_at）
  - `backend/app/models/organization.py` — 3 列（Organization: created_at, updated_at; OrgMember: joined_at）
  - `backend/app/models/lifecycle.py` — 4 列（LifecycleProject: created_at, updated_at; ProjectStage: started_at, completed_at）
  - `backend/app/models/alert.py` — 1 列（created_at）
  - `backend/app/models/alert_setting.py` — 2 列（created_at, updated_at）
  - `backend/app/models/platform_rule.py` — 1 列（updated_at）
  - `backend/app/models/platform_rule_version.py` — 1 列（created_at）
  - `backend/app/models/schema_suggestion.py` — 2 列（created_at, updated_at）
  - `backend/app/models/monitoring_record.py` — 删除整个文件
  - `backend/app/models/__init__.py` — 移除 monitoring_record 的 import（如有）
- **Approach:** 同 U1 模式。删除 `monitoring_record.py` 前确认 `__init__.py` 无引用（已验证无任何代码 import 此文件）。删除后检查 `__init__.py` 是否有相关 import 需清理。
- **Patterns to follow:** U1 的修改模式
- **Test scenarios:**
  - knowledge 相关 API 的 created_at/updated_at 可写入 timezone-aware datetime
  - lifecycle project 的 started_at/completed_at 可写入 timezone-aware datetime
  - 删除 monitoring_record.py 后后端服务正常启动，无 import 错误
- **Verification:** 启动后端服务，确认无 import 错误；调用 knowledge 和 lifecycle API 验证 datetime 读写

### U4. Alembic 迁移生成与执行

- **Goal:** 为 U1-U3 的所有模型变更生成 Alembic 迁移脚本，并在本地数据库执行
- **Requirements:** R4
- **Dependencies:** U1, U2, U3
- **Files:**
  - `backend/alembic/versions/` — 新增迁移文件
- **Approach:** 运行 `alembic revision --autogenerate` 生成迁移。检查生成的迁移脚本确认所有 ALTER COLUMN 操作正确（`TIMESTAMP → TIMESTAMPTZ`）。执行迁移后验证数据库列类型已更新。如果项目未配置 Alembic，则通过 `init_schema.py` 或手动 SQL 完成数据库更新。
- **Patterns to follow:** 已有的 Alembic 迁移文件（如存在）
- **Test scenarios:**
  - 迁移脚本可成功执行，无错误
  - 迁移后数据库列类型为 TIMESTAMPTZ
  - 迁移可回滚（downgrade）
- **Verification:** 执行迁移，检查数据库列类型

### U5. 前端 API 客户端统一

- **Goal:** 统一前端 2 个页面组件的 API 调用，扩展 fetchWithAuth 支持非 JSON 响应
- **Requirements:** R6, R7, R8
- **Dependencies:** none（可与 U1-U4 并行）
- **Files:**
  - `frontend/lib/api/client.ts` — 扩展 fetchWithAuth 支持 responseType 参数
  - `frontend/app/(dashboard)/dashboard/reports/page.tsx` — CSV 导出改用 fetchWithAuth
  - `frontend/app/(dashboard)/dashboard/lifecycle/new/page.tsx` — 项目创建改用 fetchWithAuth
  - `frontend/lib/api/reports.ts` — PDF blob 导出改用 fetchWithAuth（responseType: 'blob'）
- **Approach:** 在 `fetchWithAuth` 中添加可选 `responseType` 参数，默认 `'json'`，当为 `'blob'` 时返回 `Response` 对象而非解析 JSON。修改 reports/page.tsx 和 lifecycle/new/page.tsx 使用 `fetchWithAuth` 替代手动 `fetch`。修改 reports.ts 使用 `fetchWithAuth` 的 blob 模式。
- **Patterns to follow:** `frontend/lib/api/client.ts` 现有的 fetchWithAuth 实现
- **Test scenarios:**
  - fetchWithAuth 默认行为不变（返回 JSON）
  - fetchWithAuth responseType='blob' 返回 Response 对象
  - reports 页面 CSV 导出认证 token 正确传递
  - lifecycle/new 页面项目创建认证 token 正确传递
  - PDF 导出通过 fetchWithAuth blob 模式正常工作
- **Verification:** 前端构建通过，浏览器中访问 reports 和 lifecycle/new 页面无 401 错误

### U6. 前端端到端验证

- **Goal:** 在浏览器中验证完整变现闭环和关键用户流程
- **Requirements:** R9, R10, R11
- **Dependencies:** U4, U5
- **Files:**
  - 无代码修改，纯验证
- **Approach:** 启动前后端服务，在浏览器中手动走通完整变现闭环。重点验证：注册→登录→Onboarding→创建品牌→诊断→健康分→付费墙→支付→解锁。同时验证公开健康分页面无需登录可访问。
- **Test scenarios:**
  - 完整变现闭环：注册→登录→创建品牌→诊断→健康分→付费墙→支付→解锁
  - 公开健康分页面无需登录可访问并生成报告
  - Onboarding 流程可正常走通
  - reports 页面 CSV 导出正常
  - lifecycle/new 页面项目创建正常
- **Verification:** 所有流程在浏览器中走通，无 401、无页面报错

### U7. 部署安全加固

- **Goal:** Redis 密码保护、PostgreSQL 强密码、.env.production 模板、Docker Compose 部署验证
- **Requirements:** R12, R13, R14, R15
- **Dependencies:** U4
- **Files:**
  - `docker-compose.yml` — Redis 添加密码配置、PostgreSQL 密码更新
  - `backend/.env` — Redis 密码和 PostgreSQL 密码同步更新
  - `backend/.env.production` — 新建生产环境配置模板
  - `docker-compose.prod.yml` — 更新生产环境配置（如存在）
- **Approach:** 在 docker-compose.yml 中为 Redis 添加 `--requirepass` 命令和环境变量。PostgreSQL 密码从弱密码 `geo123` 改为强密码。创建 `.env.production` 模板包含所有必需配置项。后端代码中 Redis 连接需同步添加密码参数。执行 `docker compose up` 验证 4 个服务正常启动和通信。
- **Patterns to follow:** docker-compose.yml 现有配置结构
- **Test scenarios:**
  - Redis 无密码连接被拒绝
  - Redis 有密码连接成功
  - PostgreSQL 弱密码连接被拒绝
  - PostgreSQL 强密码连接成功
  - Docker Compose 4 个服务正常启动
  - 后端服务可连接 Redis 和 PostgreSQL
- **Verification:** `docker compose up` 成功，4 个服务健康检查通过，后端 API 可正常响应

---

## Scope Boundaries

**In scope:**
- 28 个模型文件的 DateTime(timezone=True) 修复
- 废弃文件 monitoring_record.py 删除
- Alembic 迁移生成和执行
- 前端 2 个页面组件 API 客户端统一
- 统一 API 客户端非 JSON 响应支持
- 浏览器端到端验证
- Docker Compose 部署验证
- Redis/PostgreSQL 安全配置
- .env.production 模板

**Deferred for later:**
- 真实微信/支付宝 SDK 接入
- CI/CD 流水线
- 性能优化和压力测试
- 生产环境域名和 HTTPS 配置
- 完整测试覆盖
- pgvector 镜像优化
- JWT_SECRET 强密钥生成
- UI 打磨和视觉优化

**Outside this sprint:**
- 新功能开发
- 代码重构（除时区修复和废弃文件删除外）

---

## Risks & Dependencies

- **Alembic 未配置或配置不完整。** 如果项目未正确配置 Alembic，自动迁移生成可能失败。回退方案：通过 `init_schema.py` 或手动 SQL 完成 ALTER COLUMN。
- **Docker Hub 网络问题。** Plan 004 中 Docker 部署因网络问题失败，U7 可能遇到同样问题。回退方案：配置 Docker 镜像源或使用本地构建。
- **前端构建可能暴露其他问题。** 前端代码从未在浏览器中完整验证，E2E 验证可能发现新的 bug，这些 bug 需要额外修复。
- **Redis 密码变更影响后端连接。** 后端代码中 Redis 连接配置需同步更新，否则服务启动失败。

---

## Sources / Research

- Plan 004 端到端验证记录：时区 bug 在 diagnosis_records 和 payment_orders 上的具体表现
- `backend/app/models/` — 28 个待修复模型文件，68 个 datetime 列
- `backend/app/models/monitoring.py` — 实际使用的监控模型（被 4 处代码引用）
- `backend/app/models/monitoring_record.py` — 废弃文件（零引用）
- `frontend/lib/api/client.ts` — 统一 API 客户端
- `frontend/app/(dashboard)/dashboard/reports/page.tsx` — 绕过统一客户端
- `frontend/app/(dashboard)/dashboard/lifecycle/new/page.tsx` — 绕过统一客户端
- `frontend/lib/api/reports.ts` — PDF blob 导出被迫绕过
- `docker-compose.yml` — Redis 无密码、PostgreSQL 弱密码