来源：#16642 分诊裁定里的「必须一并做」一条，按该裁定验收口径第 5 条的指示另立并回链。
分诊（#16642，os-zhuang，2026-09-08）把卡面三条 Expected 定了序，第 2 条原文：
必须一并做 —— 授权时点的可见性（卡面第 3 条）。 无论回落是否落地，os validate / os lint 都应当让作者在写下 filter / derived 时就知道它在哪些驱动上不可移植。⛔ 只做回落而不做提示，下一个不可移植的键还会以同样方式被发现（#16178 的 timeDimensions[].granularity 已经是同一个 app 撞到的第二个）。
同一份裁定的验收口径第 5 条，对这件事的通用形状已经自己给了处置：
若承接席认为该有一张"能力矩阵"的总卡，请另立并回链，⛔ 不要在本 PR 里造。
本卡就是那张总卡。
⛔ 为什么不是在 #16642 的 PR 里一并做（这是 PM 的裁量，请随时推翻）
#16642 的修法最后落在 PR #17251：engine.aggregate 的 in-memory lowering 不再把 groupBy / aggregations / having 下发给 driver.find()。其后果是，分诊那句「让作者知道 filter / derived 在哪些驱动上不可移植」所要报告的那条具体不可移植性 —— measure filter 在 driver-memory 上不可用 —— 已经不存在了（两驱动数值相等已量：501 → 15 与 501 → 0.17045454545454544，sqlite 四格不动）。照原样做，会做出一条假的警告。
活下来的是分诊那句话的一般性理由：「下一个不可移植的键还会以同样方式被发现」。那是一张能力矩阵，⇒ 正是验收口径第 5 条点名要另立的形状。
⛔ 本席（domain:services PM，seat #6021）在此明确：这是把一条被裁定为"必须一并做"的要求改为承接卡，不是分诊改口。总监 / 维护者若认为应当阻塞 #17251 直到本卡落地，请直接推翻。
问题
一个 analytics 数据集键可以是已声明、已文档化、os validate 接受的，同时在某个受支持的驱动上运行时不可用（拒绝，或更糟：静默给出一个貌似合理的错数）。作者在授权时点得不到任何信号；他发现问题的地方是 console 上的一张错误卡，而那张卡上的归因还是错的。
已知的两个实例，都来自同一个 app（objectstack-ai/ats）：
| # |
键 |
运行时症状（修复前） |
| #16642 |
DatasetMeasureSchema.filter / derived: {op:'ratio'} |
driver-memory 上 501 NOT_IMPLEMENTED |
| #16178 |
AnalyticsQuery.timeDimensions[].granularity |
driver-memory 上静默不分桶 —— 一个 timestamp 一组，"按月新增"图上一行一根柱 |
⭐ 第二个才是这张卡真正的理由：它不拒绝。 一条只在"被拒绝"时才报警的提示救不了它。
期望（不定实现，交给承接席）
一条授权时点的检查，让作者在写下一个 analytics 键时就知道它在目标驱动上会发生什么。至少要能回答：这个键在这个驱动上（a）原生支持 /（b）引擎在内存里代偿 /（c）拒绝 /（d）接受但不生效？ —— (d) 是最重要的一格，也是今天完全没有表示的一格。
packages/lint/src/ 下已有形状相近的先例可参考，尤其 validate-rls-predicate-enforceability.ts（判定一个已声明的东西是否真的可执行）与 validate-page-visualization-bindings.ts。
⚠️ 承接前请先量的两件事（⛔ 不要假设）
- 能力事实从哪里来。 今天
drv.supports.queryDateGranularity 是一个驱动自报的能力面（见 packages/objectql/src/engine.ts:13778 一带的分叉），但它只覆盖 date granularity 一个维度。⛔ 不要新造一份手写的驱动×键矩阵——那是第二处真相，本仓反复在清的形状。先量清楚现有的 supports 面能承载到什么程度。
- 授权时点知不知道目标驱动。
os validate / os lint 跑的时候，目标驱动可能未知或有多个。⇒ 提示的正确语气可能是「这个键在 X 上不生效」而不是「这个键错了」。⛔ 一条把可移植性问题报成语法错误的 lint 比没有更糟。
关联
定级说明
priority:p3，理由：两个已知实例中，急性的那个（#16642）已修，另一个（#16178）有 PR 在跑 ⇒ 现在剩下的是类的可见性，不是某个具体的坏掉的东西。⛔ 但如果承接席认为 (d) 那一格「接受但不生效」的静默错数值得更高的级别，请直接改——本席不认为 p3 是个强判断。
来源：#16642 分诊裁定里的「必须一并做」一条，按该裁定验收口径第 5 条的指示另立并回链。
分诊（#16642，
os-zhuang，2026-09-08）把卡面三条 Expected 定了序，第 2 条原文：同一份裁定的验收口径第 5 条，对这件事的通用形状已经自己给了处置：
本卡就是那张总卡。
⛔ 为什么不是在 #16642 的 PR 里一并做（这是 PM 的裁量，请随时推翻）
#16642 的修法最后落在 PR #17251：
engine.aggregate的 in-memory lowering 不再把groupBy/aggregations/having下发给driver.find()。其后果是，分诊那句「让作者知道filter/derived在哪些驱动上不可移植」所要报告的那条具体不可移植性 —— measurefilter在 driver-memory 上不可用 —— 已经不存在了（两驱动数值相等已量：501 → 15与501 → 0.17045454545454544，sqlite 四格不动）。照原样做，会做出一条假的警告。活下来的是分诊那句话的一般性理由：「下一个不可移植的键还会以同样方式被发现」。那是一张能力矩阵，⇒ 正是验收口径第 5 条点名要另立的形状。
⛔ 本席（
domain:servicesPM，seat #6021）在此明确：这是把一条被裁定为"必须一并做"的要求改为承接卡，不是分诊改口。总监 / 维护者若认为应当阻塞 #17251 直到本卡落地，请直接推翻。问题
一个 analytics 数据集键可以是已声明、已文档化、
os validate接受的，同时在某个受支持的驱动上运行时不可用（拒绝，或更糟：静默给出一个貌似合理的错数）。作者在授权时点得不到任何信号；他发现问题的地方是 console 上的一张错误卡，而那张卡上的归因还是错的。已知的两个实例，都来自同一个 app（
objectstack-ai/ats）：DatasetMeasureSchema.filter/derived: {op:'ratio'}NOT_IMPLEMENTEDAnalyticsQuery.timeDimensions[].granularity⭐ 第二个才是这张卡真正的理由：它不拒绝。 一条只在"被拒绝"时才报警的提示救不了它。
期望（不定实现，交给承接席）
一条授权时点的检查，让作者在写下一个 analytics 键时就知道它在目标驱动上会发生什么。至少要能回答：这个键在这个驱动上（a）原生支持 /（b）引擎在内存里代偿 /（c）拒绝 /（d）接受但不生效？ —— (d) 是最重要的一格，也是今天完全没有表示的一格。
packages/lint/src/下已有形状相近的先例可参考，尤其validate-rls-predicate-enforceability.ts（判定一个已声明的东西是否真的可执行）与validate-page-visualization-bindings.ts。drv.supports.queryDateGranularity是一个驱动自报的能力面（见packages/objectql/src/engine.ts:13778一带的分叉），但它只覆盖 date granularity 一个维度。⛔ 不要新造一份手写的驱动×键矩阵——那是第二处真相，本仓反复在清的形状。先量清楚现有的supports面能承载到什么程度。os validate/os lint跑的时候，目标驱动可能未知或有多个。⇒ 提示的正确语气可能是「这个键在 X 上不生效」而不是「这个键错了」。⛔ 一条把可移植性问题报成语法错误的 lint 比没有更糟。关联
filter(or aratioover two of them) answers 501NOT_IMPLEMENTEDon driver-memory — the ObjectQL strategy hands the conditional aggregate todriver.find, which refuses it, and never falls back to the in-memory evaluator that supports it #16642（来源卡）· PR fix(objectql): the in-memory aggregate lowering asks the driver for rows, so a measurefilterstops being refused on driver-memory (#16642) #17251（修掉了上表第一行）driver-memoryanalytics acceptstimeDimensions[].granularityand never buckets by it — one group per distinct timestamp #16178（上表第二行）· PR fix(driver-memory): an analytics time dimension buckets by its declaredgranularity(#16178) #17206 在跑/api/v1/analytics/querystill drops per-measure and dataset-levelfilteron the ObjectQL path —engine.aggregatereceives no filter at all #10413（driver-memory 的 per-aggregationfilter拒绝——⛔ 该拒绝本身是对的，不在本卡范围内）filter(or aratioover two of them) answers 501NOT_IMPLEMENTEDon driver-memory — the ObjectQL strategy hands the conditional aggregate todriver.find, which refuses it, and never falls back to the in-memory evaluator that supports it #16642 分诊验收口径第 4 条（console 显示「Analytics capability is not installed on this deployment」，归因完全错误——能力装了，是这一条查询走不通）落在 objectui，需要在那边另立。本会话的仓库范围够不到，一并记在这里以免丢失。定级说明
priority:p3，理由：两个已知实例中，急性的那个（#16642）已修，另一个（#16178）有 PR 在跑 ⇒ 现在剩下的是类的可见性，不是某个具体的坏掉的东西。⛔ 但如果承接席认为 (d) 那一格「接受但不生效」的静默错数值得更高的级别，请直接改——本席不认为 p3 是个强判断。