返回正文目录

Launcher 0.1.25 安装与 #139–#142 复测

日期：2026-10-20。结论：在本次原始 Chinook/SQLite 复现条件下，四项原问题均未再复现。 共 17 组用例，16 组执行结果与原始数据独立核对一致，1 组非法重复聚合在校验阶段被明确拒绝。不是只依据 issue 已关闭或 release 标记作结论。

实际安装版本与环境

项目 本次记录
Release foggy-runtime-launcher-v0.1.25，GitHub 标记为 prerelease
Launcher 0.1.25；内部 Java 项目版本仍为 9.3.0-SNAPSHOT
Release manifest source commit db5db39aa36dc30b51d9db7d941e333c8d39e0d2
JAR SHA256 b3fe4b6a3189132363b59ba16c143ef6ddab2fd7886ef0d7e7c0838fef1c350a
Java / Python / PowerShell 17.0.12 / 3.11.5 / 7.6.5，Windows
CLI 0.1.24，沿用发行版 CLI；本次升级对象为 Launcher
新实例 http://127.0.0.1:18068，启动 PID 82592，独立 work 目录
Namespace / 数据源 chinook / chinook-sqlite，使用独立 Chinook SQLite 副本
查询模型 ChinookInvoiceTimeQueryModel
API / 模式 Java；foggy-runtime-api/v1；schema 2026-06-06；none-dev-test-only；匿名查询
Console / FAP 未启用，本轮为定向查询回归

所有 SHA256SUMS 条目及六项 GitHub asset digest 均核对通过；JAR 大小、哈希和版本与 manifest 一致。确认版本采用“发行 manifest + JAR 哈希 + 实际进程命令行 + 监听 PID”，没有用 CLI 版本或仍显示 9.3.0-SNAPSHOT 的启动日志代替 Launcher 版本。

实际 Java 进程命令行指向 lab/releases/launcher-0.1.25/foggy-runtime-launcher-0.1.25.jar，18068 监听 PID 与官方脚本返回 PID 相同。证据：安装核对、进程与端口。

安装、启动与接入步骤

  1. 通过 gh release view/download 获取指定 tag 的全部六项资产，保存在 独立发行目录。保存 Release 元数据，阅读下载的原版 README 和 PowerShell 脚本，核对全部摘要后才启动。
  2. 检查 18068 没有监听，执行发行包原版脚本，未编辑脚本或重打包 JAR：
$releaseDir = '练习目录\lab\releases\launcher-0.1.25'
& "$releaseDir\start-foggy-runtime.ps1" -Port 18068 -WorkDir "$releaseDir\work"
  1. 通过公开 CLI wait-ready、capabilities 确认就绪及所需能力。服务启动日志记录 18068，初始化约 8.2 秒；没有接管旧版 18067 或其他服务。
  2. 从公开 Chinook v1.4.5 原件复制新测试数据，TM/QM 也逐字节复制原 issue 使用的两个文件。数据哈希 bdf635be69850bd3be09c9a2dbeef7ddfb80036bd3ef3381383cd03b61e4a61a 与旧验收一致。
  3. 按 issue 的接入步骤执行：添加命名数据源、绑定 chinook、测试连接、检查 Invoice 结构、校验两个模型文件、登记新 Bundle、刷新并实时 describe。模型 2 valid / 0 invalid；默认 Runtime SQLite 仍没有 Invoice 表，未通过复制表到默认库来避开 #139。
  4. 原诊断的 13 个 payload 逐字节复用，主要请求与 GitHub issue 正文中的 JSON 再次比对一致。额外补四个期间边界用例。全部使用 18068；先 validate，再 explain/execute，校验拒绝的输入不执行。
  5. 从只读原始 Invoice 行用 Python Decimal 独立核算金额、张数、上期、差额和比例，误差容许值 1E-12。比对输出行数、顺序、日期范围和空值，未仅检查 success。
  6. 保存日志后，只停止本次启动且路径核对一致的 PID 82592，并确认 18068 释放；旧版 PID 86344 / 18067 保持不变。安装文件、独立数据和 work 记录保留，清理记录已保存。

启动、安装依照发行版的 README和脚本。完整 CLI 采集脚本保存首次配置与查询操作顺序；它是首次配置入口，现有 work 下不要直接重复添加同名数据源/Bundle。

各 issue 预期与实际结果

Issue 预期 0.1.25 实际结果 本次结论
#139 数据源回退 命名源同比正常，默认库不含 Invoice 也可执行 原同比请求 validate/explain/execute 均通过，完整返回 2012 年 12 个月；当前值、2011 年上期值、差额和比例逐月匹配原件；没有缺表错误 原场景不再复现
#140 月度环比 只按年月分组即可比较，正确跨年 原年月请求返回 12 个月；十一月金额 37.62、十月 42.62、差额 −5.00、比例 −0.11731581417175035；2011-12 到 2012-01 两组跨年比较核对通过 原场景及跨年检查通过
#141 期间范围 约束当前期输出，同时保留正确上期读取范围 explain SQL 有当前/上期日期 WHERE 与四个参数；全年请求只返回 2012 年 12 个月，十月至十一月请求只返回两个月，上期金额仍为对应 2011 年值 SQL 与实际行范围均通过
#142 窗口依赖与校验 正确规划依赖或拒绝；不能返回错误差额 原依赖请求及复合 LAG 算术表达式均返回 12 行，差额逐月正确；十一月为 −5.00。重复 SUM 请求在 query.validate 明确拒绝，含 code、field、path、原因和修正建议 原错误结果/非法 SQL 均未再出现，校验有改善

本次结果均来自刚安装的官方二进制，不是源码修改后的本地构建。

#142 校验和 AI 修正建议的实际返回

原错误调用 lag(sum(invoiceAmount), 1) 在 0.1.24 曾返回一行且 success=true；0.1.25 的 CLI 返回 exit 3，关键内容如下：

{
  "code": "WINDOW_NESTED_AGGREGATE_UNSUPPORTED",
  "field": "previousAmount",
  "path": "calculatedFields[0].expression",
  "phase": "query.validate",
  "message": "WINDOW_NESTED_AGGREGATE_UNSUPPORTED: Nested aggregate/window syntax inside LAG is unsupported in calculatedFields.",
  "safeToAutoRepair": false,
  "suggestedNextAction": "Select the grouped aggregate with an alias, then use that alias as the window argument (for example lag(amount))."
}

校验失败后未执行这个请求。原先会被拒绝的 lag(totalAmount,1) 选择别名写法，本次也已执行并逐月核对正确；lag(invoiceAmount,1)、83 行逐账单 LAG、包含上年十二月的 13 个月 LAG 均通过。单独 validate/execute、不先 explain 的控制用例也得到相同结果。

依赖计算的 explain 已出现明确后续层次：stage1 聚合、__POST_RESULT_STAGE__ 计算 LAG、result_calc_2 计算差额和比例。复合表达式也先提取 LAG 到窗口层，再在外层求差，未再次把 OVER 追加到整段算术表达式上。

边界与未验收范围

在上述已测条件下没有剩余复现；若后续失败，应保留对应输入的 namespace、数据源、年月粒度、日期范围及失败 phase，再区分计划、SQL 执行和数值结果问题。

关键证据