时间分析发现的引擎问题（0.1.36）

2026-10-23 更新： #156 / #157 已关闭，并在实际下载的 Launcher 0.1.37 上复测通过：原 5 个失败场景均正常，整批 53 项执行与 8 项预期校验拒绝通过。见发行包复测报告。下文保留 0.1.36 的原始失败条件与提交记录。

随后教学默认入口和 18067 也已升级为 0.1.37，正文已撤出旧版替代流程，实际教学端口 33 项执行与 3 项预期拒绝通过，见升级与验证。

2026-10-22。Launcher 0.1.36 预发布版，CLI 0.1.25，SQLite、Java 17.0.12，Runtime http://127.0.0.1:18067。Namespace time-business，数据源 time-business-sqlite，独立教学数据。发行身份与环境见验证报告。本轮已按用户要求分别提交 #156、#157，远端标题及正文已读回核对一致。

1. JOIN 后投影的结果再作为右侧输入，外层 JOIN 丢失列

GitHub：issue #156，关联已关闭的 #150，并明确区别于原先未投影连接键的场景。

条件与步骤

先按实验说明准备数据和模型。执行公开 CLI，依次 validate、preview、execute：

$cli = './lab/tools/cli/Scripts/foggy-runtime.exe'
& $cli --output json --base-url http://127.0.0.1:18067 --namespace time-business compose validate --script lab/time-series/queries/19-08-asof-jan4.fsscript
& $cli --output json --base-url http://127.0.0.1:18067 --namespace time-business compose preview --script lab/time-series/queries/19-08-asof-jan4.fsscript
& $cli --output json --base-url http://127.0.0.1:18067 --namespace time-business compose execute --script lab/time-series/queries/19-08-asof-jan4.fsscript

完整最小脚本约 6 个阶段：目录 → 每对象 MAX 日期 → 原记录 → 按对象/日期 INNER JOIN 后投影 → 目录 LEFT JOIN 该结果 → 最终投影。字段均来自已描述的公开模型或前阶段别名。

预期与实际

预期 A=80、B=40、C=30，D 保留 NULL。实际 validate 和 preview 成功，execute 失败：

error.code: COMPOSE_EXECUTE_FAILED
error.phase: compose.execute
safeToAutoRepair: false
[SQLITE_ERROR] no such column: last_date

生成 SQL 中间层只输出 cte_0.entity_key, cte_0.label，外层却引用 last_date, quantity。这是投影/列传播阶段的问题，不是源表缺列；1 月 5 日与空历史也复现。

缩小范围的对照已执行：

19-11-picked-only：单独执行已关联的最新记录，成功，80/40/30 正确。
19-12-joined-right-base：右侧直接为基础查询，成功。
19-13-joined-right-derived：右侧是基础查询加一层投影，成功。
右侧为 JOIN 结果再投影 后，外层 JOIN 才失败。因此不概括成“所有派生右侧都不可用”。

当前教学替代：19-15-separate-jan4 同次返回目录及已知最新记录两个计划，由报告代码对齐，未知保持空；三个截止场景均正确。没有用物理 SQL 绕开语义执行。

证据

当前运行目录中的 19-08-asof-jan4-{validate,preview,execute}.json、19-09/10 同类输出、19-11/12/13 对照、commands.jsonl。生成 SQL 和 SQLite 错误保留在 execute 响应，集中摘录见 failure-logs.txt。服务 stdout/stderr 未出现同文异常，以已捕获的 CLI 错误响应为准，不伪造服务日志行。

建议修复列传播；若组合不支持，应在校验阶段指出不能引用的输出列与调整方式，避免返回 valid 后才缺列。

2. SQLite 的日期差函数校验与执行方言不一致

GitHub：issue #157，保留两种实际参数写法，要求适配或在校验阶段明确拒绝。

条件与步骤

模型 TeachingWorkTicketQueryModel，startedAt / finishedAt 为已公开 DATETIME。请求只选工单 1/2/3 的同日与跨日记录；完整输入见 DATEDIFF 请求和 TIMESTAMPDIFF 请求。

& $cli --output json --base-url http://127.0.0.1:18067 --namespace time-business query validate TeachingWorkTicketQueryModel --payload lab/time-series/queries/20-10-datediff.json
& $cli --output json --base-url http://127.0.0.1:18067 --namespace time-business query execute TeachingWorkTicketQueryModel --payload lab/time-series/queries/20-10-datediff.json

另将请求换成 20-11-timestampdiff.json 重复。表达式分别为 DATEDIFF(finishedAt, startedAt) 与 TIMESTAMPDIFF('HOUR', startedAt, finishedAt)；前者是文档列出的日期差形状，后者另保留其完整单位参数写法，便于引擎区分协议与方言支持。

预期与实际

若支持这些函数，应按明确单位和方言转换后计算；若 SQLite 或参数写法不支持，应校验拒绝并给出可调整的诊断。实际两者均 validate 成功，execute 失败：

error.code: QUERY_EXECUTE_FAILED
error.phase: query.execute
safeToAutoRepair: false
[SQLITE_ERROR] no such function: DATEDIFF
[SQLITE_ERROR] no such function: TIMESTAMPDIFF

生成 SQL 原样保留函数，没有 SQLite 适配。这里记录的是方言适配/校验缺口，不承诺所有数据库的日期差函数本应采用同一单位。

已验证替代方案：TM 的 dialectFormulaDef.sqlite 使用 julianday 计算自然小时，并在模型内处理 NULL、未来完成与非法起止。该方案的 8 项查询已按 datetime 核对。

证据

运行目录中的 20-10-datediff-{validate,execute}.json、20-11-timestampdiff-{validate,execute}.json 与 failure-logs.txt 的响应摘录。独立核对中工单 1/2/3 实际耗时为 2/12/24 小时；不能只用函数缺失异常判断日期方向或取整语义。

已排除的建模问题

漏写 carrier column 被 models validate 明确拒绝，补齐后通过，是本轮模型写法修正。
sum(overdue)/sum(eligible) 在 SQLite 走整数除法，3/8 得到 0；修改固定公式为 *1.0/nullif(...) 后得到 0.375。这是方言下的公式责任，未列为引擎 bug。
响应省略 NULL 字段不等于返回零；核对与报告均按空处理。

本轮没有发现滚动聚合器、已验证耗时模型或同期群阶段计算的数值错误。此结论只覆盖验收清单列出的输入。