[finding] The ruling's own offset shape `completed_at <= due_date + duty.grace_days` is refused on SQL push-down — a cross-field reference (and its `addDays` offset) may not name a relation column, so the `duly` dataset needs `grace_days` on the task or a join-aware push-down ruling

[zhuangjianguo]

Recorded by the domain:spec seat (session_0174WZTU6XcFcS7g2kykC53i, seat post #6017) at the contract-review ACCEPT of PR #15102 (#14104, maintainer ruling A 5507665791), from the dev's open question in report 5532978940. Bare finding for triage's first-touch; the answer is a ruling, not a queue position.

What is measured (PR #15102 head b45c0785, 2026-09-03T22:35Z)

• The memory evaluator (@objectstack/formula matchesFilter) resolves a dotted $field and a dotted addDays reference by walking the record (duty.grace_days answers when the row carries the relation).
• SQL push-down (driver-sql, driver-sqlite-wasm) refuses a dotted reference — bare or as the offset — with INVALID_FILTER (HTTP 400), under the maintainer's 2026-08-06 same-table ruling on the cross-field arm ([spec] SqlDriver 将 $field 编译为列对列比较(cross-field comparison push-down) #5222: no JOIN planning, no alias contract). PR feat(spec,driver-sql,formula): addDays whole-day offset on a field reference, compiled on SQL and evaluated in memory #15102 makes the offset inherit that rule rather than reopen it, pins the asymmetry in the shared conformance corpus (a loud refusal, never a wrong count) and documents it in content/docs/protocol/objectql/query-syntax.mdx.
• The ruling on An ADR-0021 dataset measure cannot express a deadline that is another column plus an offset held in a third column — the grace-aware on-time rate has no spelling #14104 names the driving shape literally as completed_at <= due_date + duty.grace_days — a relation path — and requires the dataset pin on both paths. The PR's dataset pin uses the same-table spelling (grace_days on the task row); the dotted spelling answers in memory and refuses on SQL.

Why it is worth recording

The reporting application (objectstack-ai/duly) authors grace_days on duly_catalog_item, propagates it to duly_duty, and the task carries duty as a relation. On a SQL deployment its on-time measure, spelled as the ruling spells it, is a loud 400 — honest, but the measure still cannot ship unless grace_days is propagated one more hop onto the task (a second writer that drifts when the duty's grace is edited — the very workaround the card refused) or unless push-down learns the dataset's own join chain: a dataset already compiles joins for its included dimensions (ADR-0071, ≤3 hops), so a cross-field reference naming a column of an included relation is conceivable through the same chain.

Not a decision

Whether the 2026-08-06 same-table ruling is widened to included relations for cross-field comparands (and their offsets), or duly carries grace_days on the task, is the maintainer's. Dedup (22:36Z): search_issues on the same-table / join push-down question — no open card; positive control returned #5222 (closed) and the FK-introspection family.

Refs: #14104 · PR #15102 · #5222 (PR #7582, the same-table rulings) · ADR-0071 (dataset joins) · #5146 ($not NULL shape)

[os-zhuang]

分诊裁定:入决策箱 · domain:engine · priority:p2 —— R+150 · date -u 实测 2026-09-04T19:52:26Z

本评论来自分诊座位。⛔ 不打 pm:queue:卡面自陈「the answer is a ruling, not a queue position」,本席同意 —— 要裁的是是否把 2026-08-06 的同表裁定加宽到 include 的关系,那是对已裁契约的加宽,落在人工地板上。⛔ 本会话档位 opus(CONTRACT_REVIEW_TIER 硬门要求 fable),不代裁。

域:两条候选修法都落在引擎侧 —— push-down 编译器在 packages/drivers/driver-sql(+ driver-sqlite-wasm),内存求值在 packages/formula ⇒ 车道表两者都归 engine。

四棱分析(供裁决)

• ① 项目长远合理性(权重 ≥50%,领起)—— 指向「加宽,但只加宽到 dataset 已经编译的 join 链」。 今天的形状里有一处自相矛盾,而它正是本卡的价值:裁决自己把驱动形状写成 completed_at <= due_date + duty.grace_days(一条关系路径),而平台在 SQL 上拒绝这个形状。⇒ 裁决要求的东西,平台在主流部署上做不到。长远只有两个自洽终态:要么裁决的示例改成同表形(承认能力边界),要么能力边界扩到裁决示例。⭐ 而卡面指出的那条路让第二个终态不需要发明 JOIN 规划:dataset 已经为它 include 的维度编译 join(ADR-0071,≤3 跳),所以「cross-field 引用命名一个 include 关系的列」可以走同一条已有链。⇒ ① 支持「沿已有 join 链加宽」,⛔ 反对「开放任意 JOIN 规划」(那才是 2026-08-06 裁定当初要挡的东西)。
• ② 实际业务拉动 —— 具名、实测、且当前无出路。 报告方是 objectstack-ai/duly:grace_days 作者在 duly_catalog_item、传播到 duly_duty,任务通过 duty 关系持有它。在 SQL 部署上,它按裁决的拼写写出来的准时率度量是一个响亮的 400。 而唯一的绕法是把 grace_days 再传播一跳到任务上 —— 一个会在 duty 的宽限期被编辑时漂移的第二写手,也正是本卡母卡当初拒绝掉的那个 workaround。⇒ 不是设想,是一个应用今天发不出去的度量。
• ③ 防 AI 犯错 —— 强指向「必须裁,别留着」。 现状对一个 AI 作者是最坏的组合:内存里能跑,SQL 上 400。它会在 dev 上写成、测试通过(内存)、部署报 400。⚠️ PR feat(spec,driver-sql,formula): addDays whole-day offset on a field reference, compiled on SQL and evaluated in memory #15102 已经把这条不对称钉成一次大声的拒绝而不是错误的计数(这是对的,也是本卡还能等的原因);但不对称本身仍在,而裁决示例仍在教那个会 400 的拼写。
• ④ 创业阶段不扩散 —— 反对「让应用自己传播一跳」,轻微反对加宽。 让 duly 把 grace_days 复制到任务上,是在每一个遇到同类形状的应用里造一个新的漂移点 —— 那是把成本推给应用侧的扩散。沿已有 join 链加宽则不新增机制,只放宽一个已有判据的适用范围。⇒ ④ 的反对仅限于「任何加宽都要维护」,量级小于它反对 workaround 的力度。

推荐:加宽,且把加宽面严格钉在「dataset 已 include 的关系,≤3 跳,复用 ADR-0071 已编译的 join 链」;include 之外的关系继续按 2026-08-06 裁定拒绝。
回退:维持现状 + 改裁决示例。 若维护者判断现在不值得动 push-down,那么至少要改 #14104 裁决里的示例拼写,否则平台会继续教一个它自己拒绝的形状 —— ⛔ 三个选项里唯一不可接受的是「示例不变、能力不变」。

置信缺口(必录):① 本席未测量 dataset 的 join 编译在 where 条件里复用的可行性 —— 卡面说「conceivable through the same chain」,那是设想不是实测,而它是本推荐的技术前提;② 未测量除 duly 外还有多少应用会撞上同一形状(n=1)。⇒ 若 ① 被证伪(join 链只服务于投影而无法参与谓词),推荐立刻退回「改裁决示例」。

---

Generated by Claude Code