032 计划（历史评估与双地图实施）

2026-10-23 实施计划（当前）

Goal: 普通/多店外卖、自配送运费和闪送双地图可切换回滚。 Architecture: 统一选择器与自部署 HTTP 客户端；外卖矩阵和闪送有序路线保持独立，Google 原实现保留。新选址通过后端聚合。 Tech Stack: JDK21 / Spring Boot / HttpClient4 / fastjson2；Flask / OSRM。 Spec: spec.md 当日实施契约覆盖旧评估计划及历史假设。

约束

后端沿用当前新分支，地图沿用 master；不另建 worktree。按已确认方案继续实施，无需重复确认。App 代码不改，交付接入文档。不自动提交/推送/部署/执行 SQL。外卖车型默认 car 保持现有口径；闪送按用户车型。外卖失败拒绝，闪送直线估时降级；历史订单不重算，改价提示重报。

Review Focus

切回 Google 后三类订单均恢复；矩阵顺序/重复/部分失败；车型与鉴权正确；旧订单与v2的距离/运费快照一致；地址反查不替换点选坐标。

实施任务（每批先补失败测试，再实现，再运行相关回归）

共同配置与算路：新增 app/map/MapSourceSelector、SelfHostedMapClient，修改闪送两个提供器；新增外卖 SelfHosted/DistanceSource 矩阵提供器。客户端接口 getObject(String, Map<String, ?>)、getArray(String, Map<String, ?>)、post(String, Object)；统一超时/鉴权，严格解析距离，显式传 profile。
计价与旧接口：修改 FoodDeliveryPromotionQuoteService/UserOrderController/OrderPromotionHelper/PromotionCalcResponse；报价返回道路米数，普通单保存真实 jvli，旧单金额差异拒绝；旧路线接口转换 legs/distance/duration/overview_polyline。
选址：新增 app/map/MapLocationController、MapLocationService、DTO 与测试；两来源搜索/详情/反查/附近返回统一字段，显式 token/参数、国际化错误；编写 frontend-app-integration.md。
地图配套和商家同步：地图侧补启用读保护缺令牌启动前拒绝；后端手动平台同步稳定门店ID/停用，提供索引发布步骤，不引入默认外部写入任务。
收口：JDK21 定向与模块构建、Python/页面测试、diff/凭据检查，更新文档；真实部署/地址体检/路段/性能/App联调分别记录未执行，不能勾完成。

历史评估计划（保留备查）

2026-10-26 执行记录与实现决策

最终本地验证：完整reactor测试1484项（admin1314/system168/framework2）0失败/错误/跳过，package成功；地图64项及页面测试通过。I001–I008本地交付，V001–V003保留真实部署验收。无提交/推送/迁移/部署。

按既有新分支原地实施，没有创建额外worktree；地图既有master脏修改保留。未自动提交、推送、部署或执行迁移。
外卖/闪送及新地址统一选择器；外卖独立矩阵，闪送有序路线，服务端令牌/超时统一。Google代码保留。
普通旧请求核对道路运费并保存jvli；父子type不一致直接拒绝，防止子外送绕过。v2持久化同源公里数。
旧getyunfei改为道路矩阵，保留响应字段。旧getluxianjvli按当前唯一结算调用方的“收货点在前、门店在后”参数转为配送方向；绘图保留，计价米数用同源矩阵，避免Directions与矩阵选路差异。这一兼容接口暂多一次请求，新完整报价不增加。
新地址使用命名空间ID，切换后详情仍按ID来源；逆查保留点选坐标和近似精度。旧Google地址端点/画面保留，App未改。
商家同步由有权限管理员明确触发，稳定门店ID；普通营业休息不作为删除依据，索引发布须独立手动完成。
复核发现的三个Important均补回归：父子类型绕过、直线报价与道路校验不一致、旧结算坐标反向。测试中缺Spring国际化容器按现有静态测试方式隔离，不改变业务错误返回。
发布验收范围固定为真实OSRM/PostGIS、存量地址、机车法规、性能和前端联调；本地构建通过不代表这些已经完成。

执行方式：在当前会话直接完成用户已确认的四项评估；不创建分支，不交付生产实现。本文件是研究与隔离试验计划，不是地图全量切换实施计划。

Goal: 确定现有 OSRM v5.27.1 是否足以承载当前配送机车规则，以及借鉴 Valhalla 的最小范围和明确限制。

Architecture: 以已部署机车 Lua 的文件指纹和固定上游提交为基线；使用合成小路网及临时 OSRM 容器验证规则。测试候选只在临时目录生成，不覆盖地图仓库或服务器正式文件。

Tech Stack: Python 标准库、SSH、OSRM v5.27.1 Docker、OSM XML 夹具、Lua API v4。

Spec: osm-requirements-assessment.md。用户于 2026-10-12 同意执行其中基线核对、规则对照、小样本验证和最终结论四项工作。

约束

不修改生产 Lua、foodie 业务源码、App 或数据库；不重建台湾全境路网、不部署 Valhalla、不切换线上流量。
临时容器只绑定服务器回环地址，限 CPU/内存，测试结束停止；不操作既有服务容器生命周期。
不读取或记录数据库密码、地图管理令牌等凭据。SSH 使用既有登录配置，不把私钥纳入文件。
固定 Valhalla 源码提交和 OSRM 镜像版本；候选参数仅是可行性探针，不是运营批准参数。
仅验证技术规则和合成样本，不宣称台湾全境合法通行、两段式转弯、真实 ETA 或生产 P99 已达标。

核验重点

本地 master、双车型分支、部署源文件及容器内文件是否一致。
机车禁行优先于路线偏好，不以“降低优先级”替代禁止通行。
路线权重与行驶时间分别设置，软偏好不直接把 ETA 放大。
单行、车型转向限制、吸附失败和不可达应保持明确语义。
动态时间限制、交通、坡度/密度与两段式转弯不能仅凭 Lua 名称或常量复制就认定支持。

任务与文件

基线及规则评估：记录于 model-evaluation.md，包含固定版本、文件哈希、规则对照和结论。
可复现小样本：evaluation/run_model_probe.py，生成隔离夹具和一次性候选 Lua，执行真实 OSRM 请求。
机器证据：evaluation/model-probe-results.json，由脚本生成，包含验证结果、来源哈希及清理结果，不含凭据。
状态追踪：tasks.md，只标记本次四项评估，不把评估通过当作生产实现完成。

执行顺序：先固定来源和部署指纹，再对照规则，随后运行隔离试验，最后依据实际结果写出结论和未验证项。脚本命令为：

& 'C:/Users/99029/.cache/codex-runtimes/codex-primary-runtime/dependencies/python/python.exe' specs/032-self-hosted-map-integration/evaluation/run_model_probe.py

验收：四项均有可审计证据；失败样本明确分类；原有生产文件指纹和服务容器保持不变；不自动提交或推送。

plan.md 7.1 KB History Raw