第十四章发现的 Compose 边界

2026-10-21，Launcher 0.1.30 / CLI 0.1.25，SQLite/Chinook，http://127.0.0.1:18067，Namespace chinook。已按用户要求分别提交 #150（连接键校验）与 #151（输入 limit）；发布后的正文已读取核对。

1. JOIN 引用了右侧未输出的列，validate 仍返回成功

最小变体来自已成功的 03-aggregate-left.fsscript。右侧仅输出 bill_customer_id、total_amount、bill_count，把 JOIN 条件的 right 改为 missing_customer_id。

复现文件：10-invalid-join-key.fsscript。

.\lab\foggy.ps1 compose validate --script .\lab\queries\chapter-14\10-invalid-join-key.fsscript

预期：在关联列解析/校验阶段明确拒绝，指出右侧计划不包含这个列，提示使用已输出的键。

实际：success=true、data.valid=true、warnings 为空，生成 SQL 的 ON 条件仍为 cte_0.customer_id = cte_1.missing_customer_id。该列不在右侧 CTE 投影中。没有执行这个故意无效的请求，不把推测的数据库报错写成实测。

证据：validate 原响应。合法基线请求可正常查询，因此不是业务字段尚未建模的问题。

2. JOIN 输入计划上的 limit 没有生效

从同一合法基线出发，在左侧客户输入增加 orderBy: ['customer_id'], limit: 5，最终结果保持 limit: 100。

复现文件：11-early-limit-demonstration.fsscript。先 compose validate，再 compose preview、compose execute，参数同上替换脚本名。

预期：若输入计划支持 limit，左侧应仅有排序后的前 5 位客户，最终 LEFT JOIN 也应为 5 行；若不支持，应明确拒绝或告知限制，不能静默忽略。

实际：validate 通过；preview 中客户 CTE 保留排序但没有 LIMIT 5，最终 LIMIT 100 仍在；execute 返回全部 59 位客户，与没有输入 limit 的基线一致。

证据：validate、preview、execute。最终分页的 start/limit 已用前两页各 5 行验证；问题出现在 JOIN 输入阶段，不是最终分页整体不可用。

对教材的处理

主线仅使用已验证的输出键、输入 slice 和最终分页，两种正常 JOIN 与聚合 JOIN 可继续讲解。两项边界独立记录，未计为通过。未采用私有接口或 SQL 直通绕行，不将不支持的写法改成业务含义不同的查询。