[Decision] Two maintainer rulings collide on boolean aggregates — batch #59's "every other pair refused" would refuse `avg(flag)`, which ruling #11152 pins on six backends as having no per-aggregate exception

[os-trump]

Surfaced by the at-tier contract review of PR #16684 (card #16353, the spec half of #16099) and verified independently by the domain:spec seat. ⛔ Not the dev's to resolve and ⛔ not this seat's: it is a conflict between two maintainer rulings, so it goes to the decision box rather than being settled in a PR.

The collision, measured

Ruling A — decision batch #59 (2026-09-06), which card #16353 implements. Its rows: count/countDistinct any type; sum numeric only (excluding percent); avg numeric including percent; min/max numeric plus temporal; "every other pair: refused". boolean and toggle are not numeric, so that default refuses sum/avg/min/max over them. ⚠️ The ruling's text never names boolean — the refusal arrives via the sweeping default, not a considered call.

Ruling B — #11152 (2026-08-28), pinned in spec's own packages/spec/src/data/aggregation-conformance.ts and enrolled on six backends: sum(flag)=3, avg(flag)=0.5, min(flag)=0, max(flag)=1. Re-read on origin/main by this seat — :61 and :218 both say, in terms, "no per-aggregate exception".

Implementation agrees with B, not A: driver-sql emits a lowering cast for boolean aggregands on Postgres (sql-driver.ts:8497-8516, card #11635, closed).

⇒ A published compatibility table built from ruling A refuses a pair that ruling B requires every backend to answer, and that spec's own conformance suite pins.

⚠️ avg(flag) is not a corner case: it is the "win rate / SLA-violation rate" shape from #11065 — the reason AGGREGATION_CASES exists.

📋 四棱

• 实际业务需求 —— 指向接受布尔。拉动是具名且已实测的:avg over a boolean field returns null on driver-memory and a number on sqlite — same rows, same dataset, same executor #11065 的「胜率 / SLA 违约率」正是 avg(flag),而 AGGREGATION_CASES 在六个后端上把四个布尔聚合答案钉死。⛔ 这不是「读起来像有用」,是已登记、已实现、已 pin 的能力。
• 项目长远合理性(权重 ≥50%) —— 指向接受布尔。最坏的结果是 spec 内部两张表互相矛盾:一张说拒,另一张说每个后端都必须答。必须有一方让路,而让路的应当是批 Validation Protocol: Cross-Field, Async, and Conditional validation #59 的笼统默认(其文本从未点名 boolean),不是 [finding] AGGREGATION_ROWS has no boolean column, so the cross-driver aggregation conformance family cannot see a boolean aggregand on any face #11152 的具名裁决(有 pin、有实现、有六后端登记)。反过来做,等于让一条一般性默认推翻一条专门裁决。
• 防 AI 写元数据犯错 —— 指向接受布尔,而且这是反向的 declared≠enforced:表会拒掉一个平台明明支持、明明有一致性套件保证的形状。作者被拒的是能跑的东西 —— 声明比现实更严,和平常那类「声明了但不兑现」方向相反,同样有害:它教 AI 绕开一个本来正确的写法。
• 创业阶段不扩散 —— 指向接受布尔。接受不是能力扩张:那是保住一个已 pin、已实现、已发布的能力。拒收才是删除,而删除已发布能力属人工地板。

四棱四条同向。⛔ 但这仍必须你裁:它是两条维护者裁决之争,置信门与代裁通道都够不到。

选项

• A — 布尔留在 sum/avg/min/max(批 Validation Protocol: Cross-Field, Async, and Conditional validation #59 的「其余全拒」对布尔类让位于 [finding] AGGREGATION_ROWS has no boolean column, so the cross-driver aggregation conformance family cannot see a boolean aggregand on any face #11152)。表增加 boolean、toggle 两个成员到那四行。AGGREGATION_CASES 与 driver-sql 不动。
• B — 布尔照批 Validation Protocol: Cross-Field, Async, and Conditional validation #59 拒收。则 [finding] AGGREGATION_ROWS has no boolean column, so the cross-driver aggregation conformance family cannot see a boolean aggregand on any face #11152 的 pin 与 driver-sql 的 PG cast 必须一并退役,AGGREGATION_CASES 四个案例删除,avg over a boolean field returns null on driver-memory and a number on sqlite — same rows, same dataset, same executor #11065 的形状变成不可写 —— ⚠️ 这是删除已发布并已保证的能力,连带三处改动。

⛔ 无论哪一边,PR #16684 的 TSDoc 与 changeset 里那句「布尔就是发散类」都必须改 —— 它在本树上是假的,而且会进 CHANGELOG。该修正已作为补丁轮发给 dev,与本裁决无关、不等它。

影响面

• PR feat(spec): declare the aggregate × field-type compatibility matrix (AggregationFunction × FieldType) dataset measures are refused against (#16353) #16684(本卡的表)在裁决前不落地布尔行的任何改动;它同时还停在落地前检 ② 上。
• 消费腿 No layer refuses an incoherent aggregate / field-type pair — a dataset measure avg over a datetime works on SQLite and errors on Postgres #16099(编译期拒收)与 devx lint 腿都 pm:blocked 在 spec: declare the aggregate × field-type compatibility matrix (AggregationFunction × FieldType) that dataset measures are refused against (spec half of #16099) #16353 上,会执行这张表 —— ⚠️ 所以裁决必须在消费腿落地之前到位:落地之后再改就是进一步收窄一个已发布的拒收集。
• 相邻但独立的两条,同样等 director 补行,⛔ 不要和本卡合并:progress 是否留在 sum(裁决排除 percent 用的是 isIncoherentAggregate 的权威,而它没点名 progress);count_distinct × percent(表按裁决收,isIncoherentAggregate 标记不相容 —— 全叉积实测这是唯一分歧对)。

---

维护者速读

事情。 我们在给「聚合函数 × 字段类型」建一张兼容表(哪些组合允许、哪些拒收),依据是你 9 月 6 日批 #59 的裁决。那条裁决说「列出的允许,其余全拒」。

问题是「其余」里扫进了布尔字段 —— 而你 8 月 28 日的另一条裁决(#11152)明确规定:布尔在每一个数据库后端上都按数字聚合,不设例外,而且这条已经写进 spec 的一致性测试、在六个后端上跑着,驱动层也为 Postgres 专门做了转换。

⇒ 两条裁决打架了。 新表会拒掉 avg(布尔字段) —— 也就是「胜率」「SLA 违约率」这类统计,而那正是当初 #11065 要的东西。

选项。

• A — 布尔留着能聚合:承认 9 月 6 日那条的「其余全拒」是个笼统默认,没考虑到布尔;表里给布尔开四个口子。其它什么都不用动。
• B — 按 9 月 6 日的字面拒掉布尔:那就得同时退役 8 月 28 日的裁决、删掉六后端的一致性用例、撤掉驱动层的转换,并且「胜率」这类统计从此写不出来。

席位意见:推荐 A。 四条评估轴罕见地全部同向。核心理由是:让一条笼统的默认推翻一条具名的、有 pin、有实现、六后端登记的裁决,方向反了。而且 B 是删除一个已经发布并且有保证的能力,不是收紧一个空声明。

风险与代价(含回滚)。 A 只改这张还没有人执行的表(加两个成员),回滚是一次 revert。B 要动三处已发布的东西,不可低成本回滚。⚠️ 有时限:执行这张表的两条消费腿正等着本卡;它们一落地,再改就是收窄一个已发布的拒收集,代价从「改一行」变成一次破坏性变更。

你要做的:选 A 还是 B?

[os-zhuang]

Ruling recorded — option A: booleans stay in sum / avg / min / max (director seat, decision batch #80, 2026-09-08)

Maintainer's reply, verbatim (live PM chat, 2026-09-08T00:1xZ, answering the batch #80 presentation where this card was item 3 with recommendation A):

其他同意

⇒ Batch #59's "every other pair refused" was a blanket default that did not contemplate booleans; ruling #11152 (2026-08-28) — booleans aggregate as numbers on every backend, no per-aggregate exception, pinned by the spec conformance suite on six backends — is the specific ruling and stands. The compatibility table adds the boolean and toggle members to sum / avg / min / max. Nothing else moves.

⚠️ Time-limited, as the card says: #16099 (compile-time refusal) and the devx lint are waiting on this table. Landing the table with booleans in it before either consumer lands means no published refusal set ever has to be narrowed.

Label: needs-user-decision → pm:queue. ⛔ Not dispatched by this seat.

---

Generated by Claude Code

[zhuangjianguo]

Claim: PM loop round 1 (seat handover, 2026-09-08T02:34Z)
Session: session_016N6xmWt5hYm94ffVEwGH8x
Branch: claude/issue-16685-boolean-aggregate-members
Worktree: objectstack-issue-16685
Domain: domain:spec
File surface: packages/spec/src/data/aggregate-field-type-compatibility.ts + its test (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: claude-fable-5-1 (CONTRACT_REVIEW_TIER; --tier run this dispatch flags packages/spec/src/data/aggregate-field-type-compatibility.ts ⇢ packages/spec/src/** as a Clause-② SUSPECT surface — the tier is taken from card CONTENT: adding members WIDENS a published accept set)
Clause-②: yes
Thread-read: 5577120138
Serial constraints cleared: packages/spec/src/data/aggregate-field-type-compatibility.ts — created by merged PR #16684 (card #16353, CLOSED); no open lane card names the file and none is in flight. The two consumer legs (#16099 compile-time refusal, the devx lint leg) are the REASON for the time box, not writers of this file. Lane work in flight: #16510 / PR #16592 (another session) touches packages/spec/src/data/seed.zod.ts — a different file in the same directory, DISJOINT at file level. ⛔ Fence honoured: PR #16618 / card #16041 not touched.

Assignee note (read this before touching the field). The assignee zhuangjianguo is this AGENT session's presence bit, not a human assignment — this container authenticates as that account. Identity is the session ID above, per 「assignee 是 presence bit,Claim: 是身份」. ⇒ An agent recovering this card ⛔ must NOT treat the field as a human assignment exempt from clearing.

Executing director-seat ruling A (decision batch #80, 2026-09-08T00:17Z, comment 5577120138, maintainer verbatim 「其他同意」). ⛔ Not re-adjudicable. ⏳ Time-boxed — see the dispatch note for why this card is taken ahead of its place in the lane's age order.

---

Generated by Claude Code

[zhuangjianguo]

Dispatched — PM loop round 1, 2026-09-08T02:36Z.

Backend	mode:subagent (in-process)
Model	claude-fable-5-1 = CONTRACT_REVIEW_TIER, forced by Clause-②: yes (adding members widens a published accept set)
Branch	claude/issue-16685-boolean-aggregate-members

Ruling zone: batch #80 (5577120138) quoted as the constraint — add boolean and toggle to the sum / avg / min / max rows; nothing else moves; option B refused.

⏳ Why this card was taken ahead of its place in the lane's age order — declared, not slipped through

The lane's total order within p2 is Bug-first then card age. By age this card (2026-09-07T20:37Z) sits near the bottom of p2; strict order would have given slot 3 to #14977 (09-03). I took it instead, and the reason is on the card rather than in my head: the ruling itself states the window. The two consumer legs (#16099 compile-time refusal and the devx lint leg) execute this table and were blocked on #16353, which is now CLOSED (merged PR #16684). Landing this table after either consumer converts a two-member widening into a breaking narrowing of a published refusal set. ⇒ The cost of waiting is irreversible; the cost of reordering is one card's delay. 「优先是排序不是豁免」 — so this is recorded as a deviation, not as a rule.

Assumption zone — readings on origin/main 5e53d73, 02:32Z, handed over as falsifiable:

• Table at packages/spec/src/data/aggregate-field-type-compatibility.ts (171 lines), from merged PR feat(spec): declare the aggregate × field-type compatibility matrix (AggregationFunction × FieldType) dataset measures are refused against (#16353) #16684 (6ba0db4). NUMERIC_… :117, ADDITIVE_… :122, TEMPORAL_… :125; rows at :145-148.
• ⚠️ The docblock currently argues the opposite of the ruling, in two places — :57-59 lists booleans among the refused, and :69-79 is a dedicated passage recording the two-ruling collision as unresolved. Editing only the arrays would leave the file contradicting itself and publishing prose the ruling has just falsified. The order requires that prose rewritten to the ruling, citing [finding] AGGREGATION_ROWS has no boolean column, so the cross-driver aggregation conformance family cannot see a boolean aggregand on any face #11152 as the authority.
• Line numbers are handed over as clues, not specification; the dev re-derives them and re-verifies any line-level assertion before repeating it.
• ⛔ I did not pre-decide the changeset bump level — the dev judges it from the actual diff and declares its reasoning.

---

Generated by Claude Code