Use existing loading state for sparse detail

docs/API_ZH.md

@@ -1,6 +1,6 @@
-# PolyWeather API 文档（v1.5.1）
+# PolyWeather API 文档（v1.5.4）
 
-最后更新：`2026-03-24`
+最后更新：`2026-04-18`
 
 本文档描述当前对外可用 API 口径（`web/app.py` + `web/routes.py` + `frontend/app/api/*`）。
 
@@ -48,6 +48,13 @@ flowchart LR
 - `market_scan.anchor_model / anchor_high / anchor_settlement`
 - `market_scan.yes_buy / no_buy`
 - `market_scan.primary_market.tradable`
+- `probabilities.engine / calibration_mode / calibration_version`
+- `probabilities.raw_mu / raw_sigma / calibrated_mu / calibrated_sigma`
+- `probabilities.shadow_distribution`
+- `intraday_meteorology.headline / confidence`
+- `intraday_meteorology.base_case_bucket / upside_bucket / downside_bucket`
+- `intraday_meteorology.next_observation_time`
+- `intraday_meteorology.invalidation_rules / confirmation_rules / signal_contributions`
 - `peak.first_h / peak.last_h / peak.status`
 - `vertical_profile_signal.heating_setup / suppression_risk / trigger_risk / mixing_strength`
 - `taf.signal.peak_window / suppression_level / disruption_level / markers`
@@ -56,7 +63,50 @@ flowchart LR
 
 `/api/city/{name}/detail` 现在会返回一组更偏交易场景的结构字段：
 
-#### 1. `peak`
+#### 1. `intraday_meteorology`
+
+今日日内分析的专业气象判断层。该字段只做派生，不改变路由和缓存策略。
+
+重点字段：
+
+- `headline`：今日主判断，例如“峰值仍有上修空间 / 峰值受云雨压制”
+- `confidence`：`low | medium | high`
+- `base_case_bucket`：基准温度档位
+- `upside_bucket`：上修路径档位
+- `downside_bucket`：下修路径档位
+- `next_observation_time`：下一次应重点看的本地时间
+- `invalidation_rules`：2-4 条失效条件
+- `confirmation_rules`：1-3 条确认条件
+- `signal_contributions`：气象因子列表，含 `label`、`direction`、`strength`、`summary`
+
+前端如果该字段暂缺，会降级使用现有 `paceView`、`boundaryRiskView`、`upperAirCue`、`probabilitySummary` 等字段。
+
+#### 2. `probabilities`
+
+概率层现在按“校准模型概率”对外解释，而不是直接把模型票数或市场价格当成概率。
+
+新增 / 重点字段：
+
+- `engine`：概率引擎名称，例如 `lgbm_calibrated`、`emos`、`legacy`
+- `calibration_mode`：校准运行模式
+- `calibration_version`：校准产物版本
+- `raw_mu` / `raw_sigma`：原始分布参数
+- `calibrated_mu` / `calibrated_sigma`：校准后分布参数
+- `shadow_distribution`：shadow / 对照分布，供回归与灰度验证
+
+当前前端会优先展示 LGBM / EMOS 等校准概率；模型共识与市场价格只作为辅助参考，不再作为主结论。
+
+#### 3. `detail_depth`
+
+`detail_depth` 用于区分轻量 detail 与完整 detail。前端如果发现：
+
+- `detail_depth != "full"`
+- 或 `forecast.daily` 只有当天一张卡
+- 或模型层只剩单模型
+
+会触发强刷完整 detail，并在 UI 上显示同步状态 / 占位卡，避免用户把中间态误判成完整分析。
+
+#### 4. `peak`
 
 - `first_h`：预计峰值窗口起始小时
 - `last_h`：预计峰值窗口结束小时
@@ -64,7 +114,7 @@ flowchart LR
 
 这组字段用于让日内结构信号围绕真实峰值窗口分析，而不是固定只看下午。
 
-#### 2. `vertical_profile_signal`
+#### 5. `vertical_profile_signal`
 
 重点字段：
 
@@ -86,7 +136,7 @@ flowchart LR
 
 这组字段对应前端“高空结构信号 / Upper-Air Structure”卡片。
 
-#### 3. `taf.signal`
+#### 6. `taf.signal`
 
 仅对**非香港机场城市**启用。当前已支持解析：
 
@@ -109,6 +159,12 @@ flowchart LR
 
 `markers` 会被前端温度走势图拿来做 `TAF 时段 / TAF Timing` 标记。
 
+#### 7. 结算锚点口径
+
+- 多数机场市场以 `METAR` / 机场主站实况为结算锚点。
+- `Wunderground` 是历史页面或参考入口，不应在产品文案里被描述成“站”。
+- `MGM / NMC / JMA / KMA / HKO / CWA` 等官方站网属于增强层或明确官方站点层；只有合约规则明确指定时，才作为最终结算站点。
+
 ## 4. 鉴权与账户接口
 
 | 接口 | 方法 | 用途 |
@@ -196,6 +252,7 @@ flowchart LR
 - `summary?force_refresh=true`：`Cache-Control: no-store`
 - 详情接口与支付接口：`no-store`
 - `METAR` / `TAF` / settlement current 由后端各自维护短 TTL 缓存
+- 前端打开今日日内分析时，如果 full detail 或 market scan 正在同步，会先显示刷新锁，不展示可交互的旧内容
 
 ## 9. 调试示例
 

docs/COMMERCIALIZATION.md

@@ -1,6 +1,6 @@
 # 商业化说明（Production）
 
-最后更新：`2026-03-14`
+最后更新：`2026-04-18`
 
 ## 1. 定位
 
@@ -8,9 +8,10 @@ PolyWeather 是面向温度结算场景的气象决策层，不是通用天气
 
 核心价值：
 
-- 观测优先（METAR/MGM）
-- 结算导向（DEB + 概率桶）
-- 市场映射（行情对照 + 错价雷达）
+- 观测优先（METAR / 机场主站 / 明确官方站点；MGM、NMC、JMA、KMA 等作为增强层）
+- 结算导向（DEB + 校准概率桶）
+- 气象判断优先（证据链、失效条件、下一观测点）
+- 市场映射（行情对照 + 错价雷达），但不把交易建议放在第一层产品承诺
 
 ## 2. 当前收费能力状态
 
@@ -30,6 +31,8 @@ PolyWeather 是面向温度结算场景的气象决策层，不是通用天气
 - 登录用户：账户中心、钱包绑定、积分同步。
 - Pro 用户：
   - 今日日内深度分析（含高温时段）
+  - 专业气象结论条、证据链、失效条件、确认条件
+  - LGBM / EMOS 等校准概率层
   - 历史对账 + 未来日期分析
   - 全平台智能气象推送
 
@@ -57,6 +60,8 @@ PolyWeather 是面向温度结算场景的气象决策层，不是通用天气
 3. 审计能力：支付日志、订阅变更、异常重试可追溯。
 4. 通知策略：支付成功私发、群内通知降噪。
 5. 安全边界：敏感配置不进仓库。
+6. 数据口径：机场市场按 METAR / 机场主站解释；Wunderground 只可描述为历史页面或参考入口，不描述成“站”。
+7. 加载口径：日内分析和右侧详情在 full detail 未补齐前必须显示同步状态，不能把旧缓存伪装成完整付费内容。
 
 ## 7. 后续路线
 

docs/EMOS_LGBM_SYSTEM_ZH.md

@@ -1,5 +1,7 @@
 # EMOS + LGBM 系统说明（中文）
 
+最后更新：`2026-04-18`
+
 本文档用于完整说明 PolyWeather 当前的两条统计/机器学习链路：
 
 - `EMOS`：概率后处理与校准链路
@@ -309,7 +311,14 @@ LGBM 训练样本会优先从：
 - `Taipei`
 - `Shenzhen`
 
-这两个城市已经切到了市场指定的 `Wunderground` 结算口径。
+这两个城市配置了 `Wunderground` 历史页面作为历史观测取数入口。
+
+这里要注意产品文案口径：
+
+- `Wunderground` 不是物理观测站
+- 它只是历史页面 / 数据入口
+- 机场类市场仍应以 METAR / 机场主站作为结算锚点
+- 明确官方站点市场才以规则指定的官方站点作为最终结算锚点
 
 之前的问题是：
 
@@ -334,7 +343,7 @@ LGBM 训练样本会优先从：
 5. 写入永久真值表
 6. 记录来源与审计信息
 
-这一步对 `Taipei/Shenzhen` 尤其关键，因为它们不是 NOAA/HKO 口径。
+这一步对 `Taipei/Shenzhen` 尤其关键，因为它们的历史页面取数和普通 METAR bootstrap 不同。
 
 ---
 
@@ -358,9 +367,12 @@ LGBM 训练样本会优先从：
 
 - 辅助预测源
 - 研究/观测链路
+- 校准概率层的一个可用引擎输入
 
 不适合替代 `DEB` 主路径。
 
+前端展示上，`LGBM 校准概率` 代表概率层已使用 LGBM 上下文生成桶分布；它不是把模型四舍五入票数直接当成概率。模型共识仍只是解释层，市场价格也只作为参考层。
+
 ---
 
 ## 9. 当前最新状态
@@ -650,4 +662,3 @@ EMOS 更依赖：
 - [LGBM_DAILY_HIGH_ZH.md](/E:/web/PolyWeather/docs/LGBM_DAILY_HIGH_ZH.md)
 - [PROBABILITY_SNAPSHOT_ARCHIVE_ZH.md](/E:/web/PolyWeather/docs/PROBABILITY_SNAPSHOT_ARCHIVE_ZH.md)
 - [deep-research-report.md](/E:/web/PolyWeather/docs/deep-research-report.md)
-

docs/LGBM_DAILY_HIGH_ZH.md

@@ -1,5 +1,7 @@
 # LightGBM 日最高温模型（中文）
 
+最后更新：`2026-04-18`
+
 ## 1. 目标
 
 这套 `LightGBM` 模型是给 PolyWeather 增加一个轻量级的统计学习预测源。
@@ -22,9 +24,11 @@
 
 - `D1-D3`
 - 小时级曲线
-- 概率分布
+- 原始独立概率分布
 - 独立结算源
 
+注意：前端出现的“LGBM 校准概率”不是把 LGBM 模型票数直接当成概率，而是概率层基于 LGBM / DEB / 观测上下文输出的校准分布。模型共识只保留为解释性参考。
+
 ## 2. 适用场景
 
 这条链路是为低资源 VPS 准备的。
@@ -214,6 +218,17 @@
 - `LGBM` 需要吃到 `deb_prediction` 特征
 - 但最终 `DEB` 又要把 `LGBM` 当成一个新的输入模型
 
+## 8.1 前端概率展示口径
+
+当前网页的概率区按以下顺序解释：
+
+1. 如果后端 `probabilities.engine` 表示 LGBM 校准概率可用，则标题显示为 `LGBM 校准概率`。
+2. 如果 LGBM 不可用，但 EMOS / legacy 概率可用，则显示为 `校准模型概率`。
+3. 模型舍入票数只保留为“模型共识参考”，用于说明哪些模型四舍五入后落在同一温度档，不作为最终命中概率。
+4. 市场价格只保留为“市场参考”，不和校准概率混成同一结论。
+
+这能避免用户把 `4/8 模型支持 82°F` 误读成 `82°F 有 50% 概率`。模型共识是解释层，概率引擎才是结论层。
+
 ## 9. 环境变量
 
 示例配置见：

docs/MODEL_STACK_AND_DEB_ZH.md

@@ -2,6 +2,8 @@
 
 本文档记录 PolyWeather 当前开放模型接入、区域覆盖差异，以及 DEB 在新增模型后的计权规则。
 
+最后更新：`2026-04-18`
+
 ## 1. 接入方式
 
 当前多模型层通过 Open-Meteo model API 接入开放 NWP / AIFS 等预报模型，不直接下载原始 GRIB。
@@ -33,7 +35,7 @@ Web API 会把这部分元数据挂到：
 | 显示名 | Open-Meteo key | 来源 | 层级 | 说明 |
 | --- | --- | --- | --- | --- |
 | ECMWF | `ecmwf_ifs025` | ECMWF | global | IFS 全球传统数值模式 |
-| ECMWF AIFS | `ecmwf_aifs025_single` | ECMWF | aifs_global | ECMWF AIFS 模型 |
+| ECMWF AIFS | `ecmwf_aifs025_single` | ECMWF | aifs_global | ECMWF AIFS 模型；产品文案保留 AIFS 名称，避免和外部泛神经天气模型混淆 |
 | GFS | `gfs_seamless` | NOAA | global | NOAA 全球参考 |
 | ICON | `icon_seamless` | DWD | global | DWD ICON 全球基准 |
 | ICON-EU | `icon_eu` | DWD | regional_europe | 欧洲区域高分辨率 |
@@ -196,6 +198,32 @@ raw current_forecasts
 
 区域模型不覆盖时不显示空模型。
 
+### 6.1 “来源 Open-Meteo”是什么意思
+
+前端中的 `来源 - Open-Meteo` 表示本次多模型数据通过 Open-Meteo model API 归一化接入。
+
+它不表示：
+
+- Open-Meteo 是单一数值模型
+- Open-Meteo 生成了所有预报
+- ECMWF / DWD / ECCC / NOAA / JMA 的机构来源被替换
+
+所以模型行仍会分别展示：
+
+- 机构：例如 ECMWF、DWD、ECCC、NOAA、JMA
+- 接入接口：例如 Open-Meteo
+- 模型 key：例如 `ecmwf_ifs025`、`icon_d2`、`gem_hrdps_continental`
+
+### 6.2 模型区间、校准概率、市场参考的关系
+
+当前前端把三层拆开展示：
+
+- `模型区间与分歧`：解释不同模型当前给出的最高温范围和分歧，不直接等于命中概率。
+- `校准模型概率`：由概率引擎输出温度桶概率；有 LGBM 时展示 LGBM 校准概率，缺失时降级到 EMOS / legacy 概率。
+- `市场参考`：只展示市场价格和错价背景，不再作为主判断，也不默认输出 BUY YES / BUY NO。
+
+模型票数只用于解释“哪些模型支持某个档位”，不等于最终概率。最终概率应优先读取 `probabilities.engine` 对应的校准分布。
+
 ## 7. 测试覆盖
 
 相关测试：

docs/MONITORING_ZH.md

@@ -1,6 +1,6 @@
 # 外部监控与告警说明
 
-最后更新：`2026-04-10`
+最后更新：`2026-04-18`
 
 ## 1. 目标
 
@@ -131,13 +131,45 @@ python scripts/check_ops_health.py --base-url http://127.0.0.1:8000
   - `total_requests`
   - `cache_hits / cache_misses`
   - `hit_rate / miss_rate`
+- 前端数据完整性状态：
+  - 城市详情是否仍处于 `detail_depth != full`
+  - 多日预报是否只返回当天单卡
+  - 日内分析 full detail / market scan 是否仍在同步
+  - 右侧详情面板是否正在用同步占位卡提示用户
 
 这意味着：
 
 - 外部监控负责“服务活没活、错误有没有暴增”
 - `/ops` 和 `/api/system/status` 负责“预热有没有真的跑、缓存有没有真的被打热”
+- 前端同步状态负责“用户现在看到的是完整分析，还是仍在补齐中的中间态”
 
-## 9. 备注
+## 9. 前端中间态巡检
+
+近期重点避免两类误判：
+
+1. 打开今日日内分析时，先看到上一轮城市 / 日期的旧内容，几秒后才刷新成正确结果。
+2. 右侧详情面板只到达当天单张多日卡，用户误以为未来预报缺失。
+
+当前前端已做这些保护：
+
+- `today/future` 弹窗模式显式分离，今天按钮不会再偶发进入未来日期分析布局。
+- 今日日内分析同步期间显示刷新锁，旧内容降权、禁止交互。
+- 详情面板发现稀疏 detail 或单日 forecast 时显示补齐提示和同步占位卡。
+
+手动验收建议：
+
+```bash
+cd frontend
+npm run build
+```
+
+然后在桌面和移动宽度分别检查：
+
+- 切换城市后立即打开“今日日内分析”，旧城市数据不应可交互。
+- 多日预报未补齐时，应看到同步提示，而不是只有一张“今天”卡。
+- full detail 到达后，占位卡自动消失。
+
+## 10. 备注
 
 这套监控现在已经具备：
 
@@ -153,3 +185,4 @@ python scripts/check_ops_health.py --base-url http://127.0.0.1:8000
 - 数据库体积趋势
 - 更细粒度支付指标
 - 按城市/来源拆分的业务 SLA
+- 按城市拆分的前端补齐耗时与 stale-detail 告警

docs/PROBABILITY_SNAPSHOT_ARCHIVE_ZH.md

@@ -1,5 +1,7 @@
 # 概率训练样本归档说明（中文）
 
+最后更新：`2026-04-18`
+
 ## 1. 目的
 
 这份文档说明两件事：
@@ -27,6 +29,12 @@
 - `max_so_far`
 - `peak_status`
 - `prob_snapshot`
+- `probability_engine`
+- `calibration_mode`
+- `calibration_version`
+- `raw_mu / raw_sigma`
+- `calibrated_mu / calibrated_sigma`
+- `shadow_distribution`
 - 当天最终 `actual_high`
 - 当天最终 `settlement bucket`
 
@@ -167,7 +175,10 @@
   ],
   "probability_engine": "legacy",
   "probability_mode": "emos_shadow",
-  "calibration_version": "emos-20260320130245"
+  "calibration_mode": "emos_shadow",
+  "calibration_version": "emos-20260320130245",
+  "calibrated_mu": 15.4,
+  "calibrated_sigma": 1.1
 }
 ```
 
@@ -176,6 +187,8 @@
 - `actual_high`
 - `settlement_bucket`
 
+当前前端把这类快照解释为“校准模型概率”。如果 `probability_engine` 为 LGBM 相关值，则显示为 LGBM 校准概率；模型舍入票数和市场价格只用于解释，不直接作为最终概率。
+
 ## 7. 现阶段你可以执行的命令
 
 ### 7.1 回填历史天气 CSV

docs/deep-research-report.md

@@ -5,13 +5,13 @@
 PolyWeather（仓库：`yangyuan-zhen/PolyWeather`）定位为**面向温度类结算预测市场（如 Polymarket 的温度结算合约）**的“生产级气象情报系统”，核心在于把多源天气观测/预报转化为**结算导向的概率桶（μ + bucket distribution）**，并进一步映射到市场报价完成**错价扫描**；同时提供 Web 仪表盘与 Telegram Bot 两套交互入口，并包含 Polygon 链上 USDC/USDC.e 支付、自动补单与订阅/积分体系。项目 README 现明确仓库代码采用 `AGPL-3.0-only`，同时将品牌、商标、生产私有数据与运营阈值保留在代码许可证之外。
 从工程实现看，截至 `2026-04-03`，项目已经完成一轮更明确的工程化收口：多源天气采集仍保持现有业务能力，同时已完成采集层与 Web API 大文件拆分、CI 质量门禁、配置分级（`.env.example` / `.env.secrets.example` / 中文部署文档）、EMOS/CRPS 校准链路、运行态状态与缓存迁移到 SQLite 主路径，以及最小外部监控链路（`/healthz`、`/api/system/status`、`/metrics` + Prometheus + Alertmanager + Grafana + Telegram relay）。除此之外，项目还补上了**历史真值治理**：`daily_records` 继续只保留近 14 天运行态缓存，但新增了永久真值表、真值 revision 审计表和长期训练特征表，并开始把监督真值与训练特征从“短期缓存”正式拆到“长期可追溯存储”。
 这意味着报告里最初最突出的“工程地基缺失”问题，已经有一部分被关闭：`src/data_collection/weather_sources.py` 与 `web/app.py` 不再是原来的超大单文件；GitHub Actions 已覆盖 Python、前端和 Docker build；配置与密钥治理已成体系；运行态状态不再只能依赖 JSON/JSONL 文件；EMOS 也不再只是概念，而是进入了可训练、可评估、可 shadow、可门禁判断的阶段；更重要的是，监督真值与训练特征不再只能附着在 14 天运行态缓存上。
-但项目仍处在“从可用走向稳态”的中段，而不是终局。当前真正的高优先级问题已进一步收敛：**EMOS 仍未达到生产切换标准**，当前门禁结论明确为 `hold`，阻塞原因是 shadow bucket brier 明显退化，同时历史长期特征仍处在“刚开始积累”的阶段。SQLite 迁移方面，运行态主读切换和核心离线训练/回填链路已经完成验收：在移除 `data/*.json` / `data/*.jsonl` 后，训练、评估、shadow report 与关键 backfill 脚本仍可仅依赖运行时数据库正常执行；当前保留的 legacy 文件路径主要用于迁移、导出、校验和显式回退输入。历史真值治理方面，新增的永久真值表、revision 审计表与长期训练特征表已经落地，`Taipei` / `Shenzhen` 的 `Wunderground` 历史回填也已接通，因此当前缺口已从“历史真值是否会继续丢失”转为“历史特征是否能持续增长并支撑 EMOS/LGBM 评估”。可观测性方面，最小外部监控链路已经补齐：Prometheus 抓取、Alertmanager 规则、Grafana 面板、Telegram 告警 relay 与巡检脚本均已落地；当前剩余缺口已从“有没有外部监控”转为“监控覆盖深度是否足够”，例如节点级资源、数据库体积趋势、支付细粒度指标、按城市/来源拆分的业务 SLA。支付链路方面，链下审计与容灾已明显增强：事件重放、SQLite 审计事件、RPC 多节点容灾、合约静态检查、`/ops` 支付异常单都已补齐；当前剩余风险主要集中在**链上合约本身仍是最小实现**，尚未升级到 SafeERC20、Pausable、链上套餐绑定等更强防护版本。
+但项目仍处在“从可用走向稳态”的中段，而不是终局。当前真正的高优先级问题已进一步收敛：**EMOS 仍未达到生产切换标准**，当前门禁结论明确为 `hold`，阻塞原因是 shadow bucket brier 明显退化，同时历史长期特征仍处在“刚开始积累”的阶段。SQLite 迁移方面，运行态主读切换和核心离线训练/回填链路已经完成验收：在移除 `data/*.json` / `data/*.jsonl` 后，训练、评估、shadow report 与关键 backfill 脚本仍可仅依赖运行时数据库正常执行；当前保留的 legacy 文件路径主要用于迁移、导出、校验和显式回退输入。历史真值治理方面，新增的永久真值表、revision 审计表与长期训练特征表已经落地，`Taipei` / `Shenzhen` 的历史页面回填也已接通，因此当前缺口已从“历史真值是否会继续丢失”转为“历史特征是否能持续增长并支撑 EMOS/LGBM 评估”。可观测性方面，最小外部监控链路已经补齐：Prometheus 抓取、Alertmanager 规则、Grafana 面板、Telegram 告警 relay 与巡检脚本均已落地；当前剩余缺口已从“有没有外部监控”转为“监控覆盖深度是否足够”，例如节点级资源、数据库体积趋势、支付细粒度指标、按城市/来源拆分的业务 SLA。支付链路方面，链下审计与容灾已明显增强：事件重放、SQLite 审计事件、RPC 多节点容灾、合约静态检查、`/ops` 支付异常单都已补齐；当前剩余风险主要集中在**链上合约本身仍是最小实现**，尚未升级到 SafeERC20、Pausable、链上套餐绑定等更强防护版本。
 因此，当前阶段最正确的策略已经不是继续做“大范围基础重构”，而是围绕**EMOS 上线门禁稳定化、长期训练特征持续积累、监控覆盖深挖、支付合约防护升级**这四条线持续收口。短中期内更高 ROI 的方向依然不是引入新的大模型，而是把现有“采集→后处理→市场映射→支付/订阅”的链路做成**状态一致、指标可见、发布可控、回退明确**的生产平台。
 ## 项目概览
 
 PolyWeather 的目标与范围在 README/README_ZH 中定义得较清楚：为温度结算市场提供气象情报（多源采集→融合→概率→对照市场报价），并提供“官方看板（Vercel 前端）+ VPS 后端 + Telegram Bot”。
 项目主功能可归纳为四层：
-**天气层（数据源/采集）**：聚合 39 个城市的实测与预报；支持 AviationWeather METAR（机场观测）、土耳其 MGM 站网、Open-Meteo（含多模型与集合预报）、美国 NWS（仅美国城市）、以及部分城市使用官方结算源（香港 HKO、台北 RCSS/Wunderground、深圳 ZGSZ/Wunderground）等。
+**天气层（数据源/采集）**：聚合 52 个城市的实测与预报；支持 AviationWeather METAR（机场观测）、土耳其 MGM 站网、Open-Meteo（含多模型与集合预报）、美国 NWS（仅美国城市）、以及部分城市使用明确官方站点或历史页面入口（香港 HKO、台湾/深圳相关历史页面等）等。机场类市场仍以 METAR / 机场主站为结算锚点，Wunderground 不描述为物理观测站。
 **分析层（DEB/趋势/概率/结算口径）**：
 DEB（Dynamic Error Balancing）基于过去 N 天模型误差（MAE）倒数加权，输出融合预报；运行态仍维护近 14 天 `daily_records` 缓存做当前对账，但长期监督真值与训练特征已经迁到 SQLite 永久表中，并支持基于 WU（Weather Underground 口径）四舍五入的结算命中评估。
 趋势/概率引擎在 `trend_engine.py` 中实现：综合“集合预报区间→σ/μ→高温窗口→死盘判定→温度桶概率分布→边界提示”等，用于 bot 展示与 web 结构化数据输出。
@@ -146,12 +146,12 @@ Web/Telegram 请求 → FastAPI 调用采集器抓取/复用缓存 → 分析引
 **可复现性已从“缺模板”进入“模板与生产对齐”的阶段**：`.env.example`、`.env.secrets.example`、中文配置文档、前端部署文档、运行时配置校验器都已存在；当前风险主要在于线上历史 `.env` 与新模板并存、旧变量命名残留、以及密钥轮换与分层是否真正落实。
 **CI 已建立，但组织级质量门禁未必完全收口**：CI 现已覆盖 Python、前端与 Docker build。当前问题不再是“缺 CI”，而是是否把这些 status check 绑定到 `main` 保护策略，以及是否逐步引入更严格的 pre-merge 审查。
 **运行态状态/缓存与核心离线链路的 SQLite 收口已完成**：`daily_records`、`telegram_alert_state`、`probability_training_snapshots`、`open_meteo` 缓存已经支持并在生产中主读 SQLite，迁移/校验脚本可用；进一步地，在临时移除 `data/*.json` / `data/*.jsonl` 后，训练集导出、概率拟合、评估报告、shadow report 和关键 backfill 脚本已验证仍可运行。当前 legacy 文件路径主要是显式回退入口，而不再是默认主输入。
-**历史真值治理已从设计缺陷修复到可追溯运行**：`daily_records` 继续作为近 14 天运行态缓存，但已经不再承担长期监督真值职责；项目新增了永久真值表、真值 revision 审计表和长期训练特征表，并为 `Taipei` / `Shenzhen` 补上了 `Wunderground` 历史回填链路。当前风险已不再是“监督真值会不会继续被 14 天裁剪吞掉”，而是“历史长期特征能否持续积累到足够支撑 EMOS/LGBM 重新评估”。
+**历史真值治理已从设计缺陷修复到可追溯运行**：`daily_records` 继续作为近 14 天运行态缓存，但已经不再承担长期监督真值职责；项目新增了永久真值表、真值 revision 审计表和长期训练特征表，并为 `Taipei` / `Shenzhen` 补上了历史页面回填链路。当前风险已不再是“监督真值会不会继续被 14 天裁剪吞掉”，而是“历史长期特征能否持续积累到足够支撑 EMOS/LGBM 重新评估”。
 **第三方服务合规与稳定性风险**：
 项目强依赖外部 API（Open-Meteo、AviationWeather、NWS、HKO、CWA、Polymarket、Supabase）。其中 AviationWeather Data API 有明确速率限制；Polymarket 官方说明 Gamma/Data/CLOB 三套 API 分属不同域，CLOB 交易端点需鉴权且策略可能变化；Supabase 明确强调 `service_role`/secret keys 绝不可暴露。若缺乏集中治理（重试/退避/熔断/降级/配额监控/密钥轮换），稳定性与合规不可控。
 **可观测性最小闭环已完成，但监控深度仍待加强**：项目现在已有 `/healthz`、`/api/system/status`、`/metrics`，并已补齐 Prometheus 抓取、Alertmanager 规则、Grafana 面板、Telegram relay 与巡检脚本。与此同时，`/ops` 已经逐步演进为后台管理台而不只是状态页：除支付、会员、用户与 EMOS 门禁外，还新增了训练数据治理卡片、城市覆盖矩阵，以及 `/ops/truth-history` 这种可直接查询 `actual_high / settlement_source / station_code / truth_version / updated_by / updated_at` 的真值表浏览页。当前缺口不再是“有没有外部监控”，而是节点级资源、数据库体积趋势、更细粒度支付指标、按城市/来源拆分的业务 SLA，以及是否需要进一步补 `truth revision` 明细页、趋势图和运营日报。
 **EMOS 已完成工程接入，但未完成生产发布**：EMOS/CRPS 校准、shadow 观测、rollout report、上线门禁都已实现；当前真实门禁结果为 `hold`，阻塞原因是 shadow bucket brier 明显退化。因此概率引擎标准化并非未做，而是“工程完成、发布未通过”。
-**许可证/商业使用的潜在冲突点**：仓库自身现为 `AGPL-3.0-only`，但如果未来尝试引入外部 AI 预报模型，仍需单独核验第三方代码与权重的商用条件：GraphCast 仓库代码 Apache-2.0，但权重使用 CC BY-NC-SA 4.0（非商业），Pangu-Weather 权重同样 BY-NC-SA 且明确禁止商业用途；不加区分地把这些模型用于付费产品会留下法律风险。
+**许可证/商业使用的潜在冲突点**：仓库自身现为 `AGPL-3.0-only`，但如果未来尝试引入外部神经天气模型，仍需单独核验第三方代码与权重的商用条件：GraphCast 仓库代码 Apache-2.0，但权重使用 CC BY-NC-SA 4.0（非商业），Pangu-Weather 权重同样 BY-NC-SA 且明确禁止商业用途；不加区分地把这些模型用于付费产品会留下法律风险。
 ## 对标分析
 
 为满足“至少 3 个相似开源项目或近期论文”对标，本报告选择三类代表：
@@ -162,7 +162,7 @@ Web/Telegram 请求 → FastAPI 调用采集器抓取/复用缓存 → 分析引
 
 | 项目/论文 | 解决的问题 | 输出形态 | 性能/效果（公开描述） | 易用性与依赖 | 许可证要点 |
 | --------------------------------------------------------- | ---------------------------------------------------- | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
-| **PolyWeather**（本仓库） | 温度结算市场气象情报：多源→概率桶→错价扫描→订阅/支付 | 生产级应用（Web+Bot+API+支付） | 以工程能力为主；内置 DEB、概率桶、死盘判定、市场扫描；当前覆盖 39 城市，并已补齐真值治理与后台运维视图。 | 主要依赖外部 API；Docker Compose 一键启动。 | 仓库 `AGPL-3.0-only`；品牌、生产私有数据与运营规则不随代码许可证授权。 |
+| **PolyWeather**（本仓库） | 温度结算市场气象情报：多源→校准概率桶→错价扫描→订阅/支付 | 生产级应用（Web+Bot+API+支付） | 以工程能力为主；内置 DEB、LGBM/EMOS 校准概率、死盘判定、市场扫描；当前覆盖 52 城市，并已补齐真值治理与后台运维视图。 | 主要依赖外部 API；Docker Compose 一键启动。 | 仓库 `AGPL-3.0-only`；品牌、生产私有数据与运营规则不随代码许可证授权。 |
 | **GraphCast**（google-deepmind/graphcast） | 10 天全球中期预报（ML 替代/增强 NWP） | 模型代码+权重+notebooks | 论文与介绍提到在大量指标上优于主流确定性系统；仓库提供预训练权重与示例数据入口，并提示 ERA5/HRES 数据条款需另行遵守。 | 完整训练需 ERA5 等；更适合科研/平台级推理，不是产品级 BFF。 | 代码 Apache-2.0；权重 CC BY-NC-SA 4.0（商业限制）。 |
 | **FourCastNet**（NVlabs/FourCastNet） | 高分辨率 data-driven 全球预报（AFNO/ViT） | 模型训练/推理代码+数据/权重链接 | README 描述：0.25° 分辨率、周尺度推理非常快，并可做大规模集合；适合平台型预报。 | 训练/数据依赖大（ERA5 子集 TB 级）；工程集成成本高。 | BSD 3-Clause（代码）。 |
 | **Pangu-Weather**（198808xc/Pangu-Weather + Nature 论文） | 3D Transformer 架构的中期全球预报 | ONNX 推理代码+预训练模型 | Nature 论文称在 reanalysis 上对比 IFS 有更强确定性预报表现，并强调速度优势；仓库提供 ONNX 推理与 lite 版训练说明。 | 模型文件大（多份 ~GB 级），训练资源需求高；更适合科研推理或内部平台。 | 权重 BY-NC-SA 4.0、明确禁止商业用途。 |
@@ -170,19 +170,19 @@ Web/Telegram 请求 → FastAPI 调用采集器抓取/复用缓存 → 分析引
 | **Polymarket/py-clob-client** | Polymarket CLOB 读写 SDK | Python SDK | 官方 SDK，支持 read-only 与交易接口；协议与端点在官方文档中给出。 | 易用，适合增强 PolyWeather 市场层。 | MIT。 |
 | **aiopolymarket** | Polymarket APIs 的 async 客户端 | Python async 客户端 | 强调类型安全（Pydantic）、自动分页、重试与 backoff，适合高并发与健壮性诉求。 | 适合替换/补强当前同步 requests 与自定义缓存。 | 以仓库许可为准（此处建议上线前核验）。 |
 
-**对标结论**：PolyWeather 与这类“全球 AI 预报模型”不在同一层级：PolyWeather 是“面向结算市场的产品化情报系统”，其价值核心是**将预测转成可交易/可结算的决策信息**。短中期内更高 ROI 的方向不是“自训大模型”，而是把现有“采集+后处理+市场映射”的链路做成**可复现、可观测、可评测、可扩展**的工程平台；在许可合规前提下，再评估引入外部模型推理作为额外信号源。
+**对标结论**：PolyWeather 与这类“全球神经天气模型”不在同一层级：PolyWeather 是“面向结算市场的产品化情报系统”，其价值核心是**将预测转成可交易/可结算的决策信息**。短中期内更高 ROI 的方向不是“自训大模型”，而是把现有“采集+后处理+市场映射”的链路做成**可复现、可观测、可评测、可扩展**的工程平台；在许可合规前提下，再评估引入外部模型推理作为额外信号源。
 ## 优先级改进建议
 
 下表按截至 `2026-04-03` 的真实状态重排优先级。已完成项不再继续列为“待做”，只保留当前仍需推进的事项。
 | 优先级 | 改进项 | 预估工作量 | 主要收益 | 主要风险 | 可执行步骤（建议顺序） |
 | ------ | --------------------------------------------------------------------------------------------------------------------------------- | -------------------: | ------------------------------------------------------------------- | ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | 高 | **稳定 EMOS shadow 并收紧上线门禁** | 1–2 周 | 让概率引擎升级具备明确发布条件，避免拍脑袋切换 | 当前 shadow bucket brier 退化明显，存在误上线风险 | 1) 持续积累 snapshot 样本 → 2) 定期重训与生成 `evaluation_report` / `shadow_report` / `rollout_report` → 3) 重点压 `bucket_brier` 退化 → 4) 只有门禁从 `hold` 进入 `observe/promote` 后才考虑上线 |
-| 高 | **持续积累长期训练特征，验证 SQLite 真值治理后的样本增长** | 1–2 周 | 让 EMOS/LGBM 的重训真正建立在长期可信样本上，而不是继续被短期特征缺口卡住 | 当前真值已长期化，但历史长期特征仍偏少，EMOS/LGBM 样本增长会滞后 | 1) 持续写入 `training_feature_records_store` → 2) 每日检查 `/ops` 训练数据与 `/ops/truth-history` → 3) 定期对 `Taipei` / `Shenzhen` 的 Wunderground 回填做抽查 → 4) 观察样本是否自然增长后再重训 |
+| 高 | **持续积累长期训练特征，验证 SQLite 真值治理后的样本增长** | 1–2 周 | 让 EMOS/LGBM 的重训真正建立在长期可信样本上，而不是继续被短期特征缺口卡住 | 当前真值已长期化，但历史长期特征仍偏少，EMOS/LGBM 样本增长会滞后 | 1) 持续写入 `training_feature_records_store` → 2) 每日检查 `/ops` 训练数据与 `/ops/truth-history` → 3) 定期对 `Taipei` / `Shenzhen` 的历史页面回填做抽查 → 4) 观察样本是否自然增长后再重训 |
 | 中 | **把最小外部监控继续补深**：从“可告警”提升到“可运营” | 3–7 天 | 不再只知道服务坏没坏，还能看资源趋势、来源 SLA 和支付波动 | 指标过多会带来维护噪音 | 1) 增加节点 CPU/内存/磁盘 → 2) 增加 SQLite/支付体积与事件趋势 → 3) 把 HTTP/来源指标细分到城市/来源维度 → 4) 增加日报或异常摘要 |
 | 中 | **市场层升级为 async + 类型安全**：引入 `aiopolymarket` 或在现有层加重试/backoff/连接池 | 4–7 天 | 行情层更稳，减少短时网络抖动；更易扩展更多市场/分页 | 依赖升级带来的行为差异 | 1) 把 requests.Session 替换为 aiohttp/httpx → 2) 在 Gamma/CLOB 调用侧实现指数退避 → 3) 引入 typed models，减少解析失败 |
 | 中 | **支付合约从“最小可用”升级到“更强合约防护”** | 1–2 周 | 在已完成的链下审计与容灾之上，进一步收紧链上授权边界 | 合约升级需要重新部署、迁移配置并再次验证 | 1) 维持现有事件重放、SQLite 审计、多 RPC fallback → 2) 升级合约到 SafeERC20 + Pausable → 3) 评估链上 plan/amount/token 绑定或 EIP-712 签名校验 → 4) 迁移后更新 PolygonScan 验证与支付审计文档 |
 | 中 | **将 CI 与分支保护/发布流程真正绑定** | 1–3 天 | 让现有 CI 从“存在”变成“强制门禁” | 历史分支/热修流程可能受影响 | 1) GitHub `main` 开启 required checks → 2) 把 release/tag 流程绑定 CI → 3) 明确热修例外流程 |
-| 低 | **引入外部 AI 预报模型作为附加信号**（GraphCast/FourCastNet/Pangu-Weather 等） | 2–6 周（取决于范围） | 可能提升极端/中期预测能力与差异化 | **商业许可限制**（多为 CC BY-NC-SA/禁止商业）与算力成本 | 1) 先做合规评审（权重许可/数据条款）→ 2) 仅在研究/非商业环境评估 → 3) 若要商用，优先选择可商用权重或自研/购买授权 |
+| 低 | **引入外部神经天气模型作为附加信号**（GraphCast/FourCastNet/Pangu-Weather 等） | 2–6 周（取决于范围） | 可能提升极端/中期预测能力与差异化 | **商业许可限制**（多为 CC BY-NC-SA/禁止商业）与算力成本 | 1) 先做合规评审（权重许可/数据条款）→ 2) 仅在研究/非商业环境评估 → 3) 若要商用，优先选择可商用权重或自研/购买授权 |
 
 ### 文档、测试与贡献流程的具体补强建议（落到仓库层面）
 
@@ -198,7 +198,7 @@ PolyWeather 的评测应围绕“结算场景”而非传统数值天气预报
 
 **数据集**（建议从现有生产数据演进） 
 1）`truth_records_store + training_feature_records_store` 的长期样本：当前长期评测主源应优先来自永久真值表与长期训练特征表；legacy 的 `daily_records.json` 与 `settlement_history.json` 更适合作为迁移恢复与对照来源，而不是长期主输入。
-2）观测“真值”统一口径：对 METAR 城市用 AviationWeather Data API；对香港按 HKO、对台北/深圳按 `Wunderground RCSS/ZGSZ` 等结算源作为真值，和项目当前逻辑一致。
+2）观测“真值”统一口径：对 METAR 城市用 AviationWeather Data API；对香港等明确官方站点按合约指定站点；对需要历史页面取数的城市使用对应历史页面入口。Wunderground 只描述为历史页面 / 数据入口，不描述为物理观测站。
 **指标** 
 1）确定性误差：MAE、RMSE（按城市、按季节、按风险等级分组）； 
 2）结算命中率：`WU_round(pred) == WU_round(actual)`（项目已有统计口径）； 
@@ -214,7 +214,7 @@ PolyWeather 的评测应围绕“结算场景”而非传统数值天气预报
 
 - 若历史样本足够，DEB 应在“系统性偏差明显”的城市提升 MAE；
 - EMOS 类方法通常能在概率校准（可靠性与 CRPS）上更稳定，尤其当 ensemble 信息可用（项目已接入 Open-Meteo ensemble/p10/p90）。
-**算力**：以上评测全部可在 CPU 上完成；数据量按“39 城市 × 180 天”级别，pandas/duckdb 即可。若引入更复杂拟合（如分层贝叶斯/分位数回归），也通常不需要 GPU。
+**算力**：以上评测全部可在 CPU 上完成；数据量按“52 城市 × 180 天”级别，pandas/duckdb 即可。若引入更复杂拟合（如分层贝叶斯/分位数回归），也通常不需要 GPU。
 ### 错价信号与市场有效性基准
 
 **数据集**
@@ -247,7 +247,7 @@ PolyWeather 的评测应围绕“结算场景”而非传统数值天气预报
 **外部 API 速率限制/格式变更**：AviationWeather 明确 rate limit 与建议使用 cache 文件；Open-Meteo 也可能在不同端点策略上变化。缓解：统一“请求预算”与退避/熔断；关键响应做 schema 校验与回放测试；对高频数据优先拉取官方 cache/批量接口（若可用）。
 **密钥泄露与权限滥用**：Supabase 明确强调 `service_role` 属高权限密钥，绝不可出现在前端或公开环境。缓解：密钥分级、CI secret scan、运行时最小权限、日志脱敏。
 **支付链路最终一致性与链上不确定性**：链上事件索引延迟、RPC 不稳定、交易确认数不足都会导致误判。当前项目已经补齐“事件监听 + 确认补单”双路径、事件重放脚本、SQLite 审计事件与多 RPC fallback；现阶段的主要剩余风险不再是“没有防护”，而是链上合约仍为最小实现，owner 为单地址管理，且没有 pause 开关与 SafeERC20。
-**引入外部 AI 预报模型的商业合规风险**：GraphCast/Pangu-Weather 的权重许可均带非商业限制（CC BY-NC-SA/BY-NC-SA）；若 PolyWeather 是付费产品，必须先做法务与授权评审。缓解：只在研究环境评估；商用优先选择可商用权重/购买授权/自研。
+**引入外部神经天气模型的商业合规风险**：GraphCast/Pangu-Weather 的权重许可均带非商业限制（CC BY-NC-SA/BY-NC-SA）；若 PolyWeather 是付费产品，必须先做法务与授权评审。缓解：只在研究环境评估；商用优先选择可商用权重/购买授权/自研。
 **代码公开与生产私有资产边界导致的“公开仓库与生产行为不一致”**：README 明确品牌、商标、生产私有数据与运营阈值不在代码许可证授权范围内。缓解：把“公开核心”的可复现与评测做扎实（接口/数据 schema/测试/评测），私有策略只作为可插拔 policy layer 接入。
 ## 参考链接