perf(sector_radar): narrow publication reads and index rank history

.trellis/tasks/09-07-api-performance-diagnosis/prd.md

@@ -0,0 +1,27 @@
+# 接口性能诊断与缓存方案评估
+
+## 目标
+解释用户观察到的多个接口约 3 秒延迟，以概念板块 BK1147.DC 在 2026-09-04 的详情接口为切入点，在不引入 Redis 的情况下优化冷请求读取与计算，供用户自行发布后评估效果。
+
+## 已确认事实
+- 用户已在诊断与方案回顾后明确批准按优化顺序开始实施，由用户自行发布；Redis 留待上线效果验证后评估。
+- 公网 GET 四次均返回 HTTP 200，总耗时 3.045–3.442 秒，响应体 10750 字节；主要等待发生在首字节之前。
+- 排查开始时本地 develop 分支工作区干净；生产是否与当前提交一致尚未确认。
+- 静态检查及本地调用追踪确认：详情与金额榜单每次调用两次 load_publication_sources；来源查询读取完整 payload（application/details.py:145、:182、:294；infrastructure/postgres.py:194）。
+
+## 范围与要求
+- 低频只读测量示例请求，分析本地路由、查询、连接管理与部署配置。
+- 区分观测事实、代码风险和待生产证据验证的假设。
+- 实施资金雷达详情、历史和榜单的最小充分读取优化；不修改外部系统。
+
+## 验收标准
+- 详情/榜单/历史不再加载完整发布快照，按需读取来源组、目标日与成员；历史只传输目标板块排名及完整池统计。
+- 保留全部 HTTP 字段、Decimal 精度、旧批次独立缺失值、历史发布选择与相似板块口径。
+- 通过真实 PostgreSQL 查询验证、语义回归测试和后端质量门禁，给出同一数据集的前后性能比较；不承诺未上线的公网秒数。
+- 记录可复现请求的分段耗时，避免把总耗时直接等同于 SQL 耗时。
+- 为关键判断提供代码位置或实测依据。
+- 说明 Redis 是否必要、适用条件及失效策略边界。
+- 明确未验证事项及下一步建议。
+
+## 不在范围内
+生产压测、部署、迁移、创建索引、接入 Redis、修改共享规范、推送远端。用户已另行授权提交本地 develop。