release: bump version to 0.37.0

docs/plans/earth-compute-center-bgp-style-plan.md

@@ -275,6 +275,66 @@
 
 这样可以避免一开始把范围摊得过大。
 
+## Unknown Location Strategy
+
+由于部分算力数据源不会直接提供经纬度，未知位置补全不能只依赖“继续找 API 字段”。
+更稳妥的方式是做成一条分层富化链路，而不是单一猜测规则。
+
+推荐按下面优先级推进：
+
+1. 直接源信息
+
+- 源记录显式给出 `latitude / longitude`
+- 源记录给出 `city / region / facility / campus / operator`
+- 源页面详情、内嵌 JSON、结构化元数据、新闻稿链接里能抽出地点线索
+
+2. 名称与机构归一化
+
+- 建立 `canonical_name / aliases / operator / facility` 归一化表
+- 把 `cluster name`、`operator`、`campus name` 归一到同一个实体
+- 优先解决同一对象多写法导致的命中失败，而不是先扩大猜测范围
+
+3. 本地位置注册表
+
+- 用仓库内可维护的 registry 保存高价值对象的位置知识
+- 每条记录至少包含：`canonical_name`、`aliases`、`operator`、`country`、`region`、`city`、`lat`、`lon`、`confidence`、`source_note`
+- 转换层优先读取 registry，避免地点知识长期散落在转换代码里
+
+4. 分层回退定位
+
+- `precise`
+- `estimated_site`
+- `estimated_city`
+- `estimated_region`
+- `estimated_national_hub`
+- `estimated_country`
+
+这里建议把“国家内主要算力城市”作为国家质心之前的一层。
+例如没有美国精确位置时，优先考虑已知的主要算力/数据中心城市候选，而不是直接落在几何质心。
+
+5. 候选证据富化
+
+- 如果源 API 无地点信息，可以允许采集链路读取公开辅助证据
+- 例如机构官网、数据中心介绍页、新闻稿、百科型页面、公开 PDF
+- 但只提取“地点线索”，不把外部页面上的经纬度当真值直接写回
+
+6. 人工校验闭环
+
+- 对高价值且仍然未知的对象输出待核验清单
+- 把人工确认结果回写到位置注册表
+- 后续采集继续优先复用这层人工确认结果
+
+### Additional Solution Paths
+
+除了静态映射表，还可以考虑下面这些办法：
+
+- 基于国家和运营方建立“主要园区候选集”，用稳定散列把同国未知节点分散到若干可信城市，而不是全部压到一个点
+- 基于数据中心/云厂商公开 region 列表建立 `operator -> city set` 候选映射，用于云 GPU 集群类对象
+- 把“估算依据”结构化，例如 `matched_alias`、`matched_operator`、`matched_city_text`、`fallback_country_hub`
+- 给位置补全增加 `last_verified_at`，便于后续按时间重新校验老旧映射
+- 单独维护“不可可靠定位”状态；这类对象仍可在国家级聚合统计中出现，但可以允许用户在地图上过滤掉
+- 后续如果你们愿意投入更多，可把这条链路做成小型 enrichment pipeline，而不是仅在 API 转换时临时判断
+
 ## Non-Goals
 
 第一阶段不建议做这些内容：