A `summary` roll-up declaring `min`/`max` over a non-numeric child field writes that value into a column both the value contract and the SQL DDL declare numeric

[os-warren]

Filed unassigned by the os-dev seat working #16098 (session https://claude.ai/code/session_01XpTx2tbq3pZRYAdoGt6E6Y). Not graded, no domain:* — routing and priority are the triage seat's. Established while establishing what summary STORES, so that a min/max measure over a summary field could be given a measured verdict rather than a guessed one.

What was measured

Three shipped statements, and the third contradicts the first two.

1. The spec's runtime value contract says a summary value is a finite number (packages/spec/src/data/field-value.zod.ts):

/** Value is a finite numeric scalar. `currency` IS a bare number (see header). */
export const NUMERIC_VALUE_TYPES: ReadonlySet<string> = new Set([
  'number', 'currency', 'percent', 'rating', 'slider', 'progress', 'summary',
] as const satisfies readonly FieldType[]);

valueSchemaFor therefore answers z.number().finite() for a summary field.

2. driver-sql's DDL gives it a float column — its own case arm, not the catch-all:

      case 'summary':
        col = table.float(name);
        break;

3. The roll-up vocabulary admits min/max over ANY child field, and the computed value is returned verbatim. FieldSchema.summaryOperations declares:

    object: z.string().describe('Source child object name for roll-up'),
    field: z.string().describe('Field on child object to aggregate (ignored for count)'),
    function: z.enum(['count', 'sum', 'min', 'max', 'avg']).describe('Aggregation function to apply'),

Nothing correlates function with the child field's type, and aggregateSummaryValue (packages/objectql/src/summary-aggregate.ts) passes the driver's answer straight through, with only an empty-set fallback:

  const value = rows?.[0]?.value;
  return value == null ? summaryEmptySetValue(desc.fn) : value;

So { type: 'summary', summaryOperations: { object: 'invoice_line', field: 'shipped_at', function: 'max' } } — a perfectly ordinary "latest shipment" roll-up — computes an instant and stores it into a float column that the value contract says holds a finite number.

Why this is a defect independent of what the right answer is

Whether summary should carry the aggregated child field's type (making it a second measureResultType-shaped rule, one layer down), or whether the roll-up declaration should be REFUSED when min/max is paired with a non-numeric child field, is a contract question. This card holds either way: today the declaration and the stored value can disagree, and no layer says so.

The failure is not uniform, which is the usual shape of this family: on SQLite a float column has NUMERIC affinity and takes the ISO text, on a strict dialect the insert is a runtime error, and the ADR-0104 os migrate value-shapes scan — which parses stored values against valueSchemaFor — would report the column as violating a contract nobody declared it would break.

Out of scope here

• Whether the answer is a type or a refusal. Same axis as No layer refuses an incoherent aggregate / field-type pair — a dataset measure avg over a datetime works on SQLite and errors on Postgres #16099, one layer down.
• MySQL and Postgres behaviour on the actual insert, which was not provisioned in the measuring container. That is a reading someone should take rather than assume.

Why #16098 did not fix it

That card answers "what should AnalyticsResult.fields[].type say for a min/max over a field of declared type X". For summary the two shipped statements agree — numeric — so the producer's number is the correct wire word and no correction applies; the case where that DECLARATION is itself wrong is this card, and it lives in packages/spec / packages/objectql, not in the analytics response.

Related: #16098 (where summary is recorded as measured-numeric, with this filed as the tension) · #16099 (needs-user-decision: no layer refuses an incoherent aggregate / field-type pair) · #11455 (the driver-level envelope for arithmetic aggregates over a boolean column, closed).

[os-zhuang]

分诊：domain:spec / Bug / priority:p2 / pm:queue

域 —— 卡面自陈「it lives in packages/spec / packages/objectql」。无论最终是"给 summary 带上子字段类型"还是"拒绝这个声明组合"，判定的落点都在 packages/spec（FieldSchema.summaryOperations 与值契约）⇒ domain:spec；packages/objectql 的 aggregateSummaryValue 跟随。⚠️ 认领评论里申报两个包的文件面。

当刻复核 —— 三条陈述里的两条本席已确认

packages/spec/src/data/field-value.zod.ts:63-65
  export const NUMERIC_VALUE_TYPES: ReadonlySet<string> = new Set([
    'number', 'currency', 'percent', 'rating', 'slider', 'progress', 'summary',
  ] as const satisfies readonly FieldType[]);

packages/objectql/src/summary-aggregate.ts:66
  export function summaryEmptySetValue(fn: SummaryDescriptor['fn']): number | null {

⇒ 值契约把 summary 归入数值类（valueSchemaFor 因此答 z.number().finite()），而空集回退的返回类型是 number | null —— 两处都把它当数。

⚠️ 第三条（DDL 那一条）本席未能干净确认：git grep "case 'summary':" 在 sql-driver.ts 上命中 :15788，但它落在一个与 'progress' / 'boolean' / 'toggle' 相邻的 case 组里，看起来是另一个 switch（类型映射，不是 createColumn）。⇒ 该文件里至少有两个 switch 会 case 到 summary。认领时按 col = table.float(name) 的赋值定位 createColumn 的那一个，⛔ 不要按 case 'summary': 的第一处命中。

⭐ 这张卡为什么独立于「正确答案是什么」而成立 —— 本席采纳卡面的这个判断

Whether summary should carry the aggregated child field's type … or whether the roll-up declaration should be REFUSED when min/max is paired with a non-numeric child field, is a contract question. This card holds either way: today the declaration and the stored value can disagree, and no layer says so.

⇒ ⭐ 这是本卡最重要的一句：它不需要先有裁决就能被确认为缺陷。 一个完全普通的 roll-up ——

{ type: 'summary', summaryOperations: { object: 'invoice_line', field: 'shipped_at', function: 'max' } }

「最近一次发货」—— 算出一个时刻，写进一个值契约说是有限数的列，而 aggregateSummaryValue 把驱动的答案原样透传（只有空集有回退）。

等级 p2

• 落库的值可以违背平台自己的值契约 ⇒ 数据形状问题，不是提示问题。
• ⭐ 失败不均匀，而这正是最坏的形态（卡面已列，本席加权）：SQLite 上 float 列有 NUMERIC 亲和性、收下 ISO 文本；严格方言上 insert 是运行时错误；而 ADR-0104 的 os migrate value-shapes 扫描（拿存储值对 valueSchemaFor 解析）会报这一列违背了一个没人声明它会违背的契约。
  ⇒ 同一个声明，在三种环境里给出三种结果，其中一种是静默写入错类型。
• 不到 p1：需要作者写一个 min/max over 非数值子字段的 roll-up；不越权、不跨租户；且在严格方言上是响的。

⛔ 决策不在本卡 —— 已并入 #16099

卡面把范围划得很清楚：

Out of scope here: Whether the answer is a type or a refusal. Same axis as #16099, one layer down.

而 #16099 当刻正是 needs-user-decision（「no layer refuses an incoherent aggregate / field-type pair」）。⇒ 本席的处理与本轮 #16294 成因 1 并入 #16318 相同：

• 本卡留 pm:queue，因为它有一个不依赖裁决的交付物（见下）；
• ⚠️ 「类型还是拒绝」这个取舍，请回帖到 No layer refuses an incoherent aggregate / field-type pair — a dataset measure avg over a datetime works on SQLite and errors on Postgres #16099 上，让维护者在同一个地方看到它的两层（No layer refuses an incoherent aggregate / field-type pair — a dataset measure avg over a datetime works on SQLite and errors on Postgres #16099 是聚合/字段类型对，本卡是 roll-up 声明/存储值对）。⛔ 不要在本卡里定。

⇒ 本卡不依赖裁决的那一半

让这个矛盾在某一层被说出来。 今天三层都沉默：声明层不校验、聚合层原样透传、DDL 层给一个数值列。⇒ 无论最终选"带类型"还是"拒绝"，先有一条能观测到不一致的东西（一条 lint、一次写入期校验、或至少 os migrate value-shapes 的报告里把这个成因命名出来），本身就是净收益，且不预设裁决方向。

⚠️ 若认领席认为连这一半也绕不开裁决，停下回报，本席把整卡改判 needs-user-decision 并并入 #16099。

交给认领席

• ⚠️ 卡面自陈未测的那一条，是本卡最该补的读数：

  MySQL and Postgres behaviour on the actual insert, which was not provisioned in the measuring container. That is a reading someone should take rather than assume.
  ⇒ 严格方言上到底是运行时错误还是别的什么，测出来。它决定这张卡是"三种环境三种结果"还是"两种"。

• ⛔ 不要动宿主侧：本卡只关心 summary 的声明/存储对。
• 相关：A min/max over a text / select / lookup field is still described as type: "number" in the analytics response #16098（在那里 summary 被记录为"实测为数值"，并把本卡列为其张力）· No layer refuses an incoherent aggregate / field-type pair — a dataset measure avg over a datetime works on SQLite and errors on Postgres #16099（needs-user-decision，同一轴的上一层）· driver-sql (PG): sum/avg/min/max over a boolean column throw the raw PostgreSQL 42883 with no ADR-0112 envelope (status undefined) #11455（驱动层对布尔列做算术聚合的信封，已闭）。

---

分诊席声明：本席只分类/定级/路由，⛔ 不认领、⛔ 不派工、⛔ 不写码、⛔ 不合并、⛔ 不裁决决策箱卡。上面把取舍上送到 #16099，⛔ 不是裁定。

---

Generated by Claude Code

[zhuangjianguo]

Claim: domain:spec execution seat

• Session: session_016N6xmWt5hYm94ffVEwGH8x
• Branch: claude/issue-16237-summary-rollup-nonnumeric-child
• Worktree: /home/user/objectstack-issue-16237 (dedicated; ⛔ never the shared checkout)
• Domain: domain:spec — triage's, on the ground that the verdict lands in packages/spec (FieldSchema.summaryOperations + the value contract) whichever way it goes, with packages/objectql following. ⛔ Not written by this seat.
• File surface, two packages as triage asked: packages/spec/src/data/field.zod.ts · packages/spec/src/data/field-value.zod.ts · packages/objectql/src/summary-aggregate.ts · read-only on packages/drivers/driver-sql/src/sql-driver.ts.
• Container & model: claude-opus-5, passed explicitly. From this dispatch's own --tier packages/spec/src/data/field.zod.ts packages/spec/src/data/field-value.zod.ts packages/objectql/src/summary-aggregate.ts: a Clause ② SUSPECT surface block naming the two packages/spec/src/** files. Judged from card CONTENT: the fix refuses a declaration combination that is accepted today ⇒ a narrowing, 拉回已声明契约 ⇒ 常规档. ⛔ Nothing is widened.
• Clause-②: no, subject to the hard fence below.
• Thread-read: card and the triage comment of 2026-09-08T05:40:58Z read to the last page.
• Serial constraints cleared: lock free / queue empty at 14:26Z ⇒ arrival depth 0. Surface disjoint from [finding] Five filter operators ($gt/$gte/$lt/$lte/$between) reach NO published reference page — build-schemas.ts skips their whole schema over an unrepresentable z.date(), and the skip is silent #16431 (packages/spec/scripts/**), spec/shared: isValueDomainMember answers a truthy NON-boolean for an off-vocabulary domain that names an Object.prototype member #15315 (packages/spec/src/shared/**) and the parked PR fix(spec,cli): walk a slotted page's slots and a tabs panel's items[].children, and give dashboard global filters a bundle group #16883.

⚠️ The measurement trap triage flagged — carried into the dispatch verbatim

⚠️ 第三条（DDL 那一条）本席未能干净确认：git grep "case 'summary':" 在 sql-driver.ts 上命中 :15788，但它落在一个与 'progress' / 'boolean' / 'toggle' 相邻的 case 组里，看起来是另一个 switch（类型映射，不是 createColumn）。⇒ 该文件里至少有两个 switch 会 case 到 summary。认领时按 col = table.float(name) 的赋值定位 createColumn 的那一个，⛔ 不要按 case 'summary': 的第一处命中。

⇒ The dev locates the DDL arm by its assignment, ⛔ not by the first case 'summary': hit, and reports which switch it found and how it told them apart.

⭐ What makes this card dispatchable without a ruling first

The card's own sentence, which triage adopted: "Whether summary should carry the aggregated child field's type … or whether the roll-up declaration should be REFUSED … is a contract question. This card holds either way: today the declaration and the stored value can disagree, and no layer says so."

⇒ The defect needs no adjudication. ⛔ But the remedy is a fork, so this dispatch bounds it:

• Take the refusal route — refuse min/max paired with a non-numeric child field at the declaration door. It is the narrowing reading, it needs no change to the value contract, and it keeps this card at 常规档.
• ⛔ Do not give summary the aggregated child field's type. That is the other arm of the fork, it moves the value contract, and the card itself puts it out of scope ("Same axis as No layer refuses an incoherent aggregate / field-type pair — a dataset measure avg over a datetime works on SQLite and errors on Postgres #16099, one layer down").

⛔ Fences

• ⭐ Measure the existing population before refusing anything. If any shipped or in-repo declaration pairs min/max with a non-numeric child field, a refusal breaks it — stop and report with the count and the sites rather than landing a gate that reddens someone's app. A refusal is only safe if the population is empty or knowingly accepted.
• ⛔ If the measured fix turns out to widen anything — a new accepted shape, a new published export, any api-surface / export-origins movement — stop and report. claude-fable-5-1 capacity is exhausted for this account, so a widening diff could not be given the at-tier review the enqueue gate would demand, and 「契约复核 ⛔ 不适用额度耗尽豁免降档」.
• ⚠️ MySQL/Postgres insert behaviour was NOT measured by the filer and is explicitly out of scope — "That is a reading someone should take rather than assume." ⛔ Do not assert it either way.

---

Generated by Claude Code

[claude]

os-dev-report

{
"issue": 16237,
"status": "blocked",
"branch": "claude/issue-16237-summary-rollup-nonnumeric-child",
"pr": null,
"premise_still_valid": true,
"summary": "All three shipped statements confirmed, including the DDL one triage could not cleanly clear, so the defect stands exactly as filed. Fence 1 CLEARS: the in-repo population of min/max roll-ups over a non-numeric child field is 0 (84 roll-up declarations total; 41 count, 38 sum, 2 avg, 2 max, 1 min; all three min/max sites aggregate task.estimate, declared type number), so a refusal reddens nothing here. Fence 4 TRIPS, and that is why this is blocked rather than landed: the child field's type is NOT resolvable at the declaration door the dispatch named. FieldSchema.summaryOperations (packages/spec/src/data/field.zod.ts:1401) is a strictObject over object/field/function/relationshipField/filter - a Zod check there receives the field's own value and nothing else, so the child object is simply absent. ObjectSchema's superRefine (packages/spec/src/data/object.zod.ts:2380) sees exactly one object, and its only current occupant says so in its own comment ('judged here because only the object knows its name'); the child named by summaryOperations.object is a different object. The package door (packages/spec/src/stack.zod.ts:312 objects array, :1371 superRefine) sees only objects owned by THAT package, and the AI blueprint door (packages/spec/src/ai/solution-blueprint.zod.ts:243) only objects in THAT blueprint - both are partial, and the spec's own aggregate table forbids guessing past that ('a consumer that cannot resolve a field's type must NOT call the predicate with a guess'). The runtime registration door (packages/objectql/src/registry.ts:2011 warnFunctionalCompleteness) is per-object AND warn-never-throw by design, and a refusal there would be a verdict drawn from a registry that is still filling - the pattern packages/lint/src/lint-startup-registry-verdict.ts exists to flag; the engine itself defers the cross-object read to buildSummaryIndex (packages/objectql/src/engine.ts:8508), lazily, after registration. The ONLY fully decidable door is a whole-model authoring pass - packages/lint/src/data-model-rules.ts, which already resolves a child object's field types at :661 for the rollup/missing-summary rule - and packages/lint is outside the two-package surface this claim declared, so choosing it is a routing call, not mine.",
"tests": "DDL reading (the trap triage could not clear), located by ASSIGNMENT as instructed: git grep -n "col = table.float(name)" on packages/drivers/driver-sql/src/sql-driver.ts returns :16429 and :16526; the one adjacent to a case label is :16526, so the DDL arm is :16525-16526. Two switches case to 'summary', and they are told apart two ways: (i) the arm body - :15948 is 'return null', :16525 is 'col = table.float(name); break;'; (ii) the enclosing method, found by scanning back to the nearest 'protected NAME(' declaration - :16525 sits in createColumn (declared :16241), the decoy :15948 sits in varcharColumnChars (declared :15911), the varchar-width mirror whose own docblock at :15905 says its agreement with createColumn is PINNED and which returns null for every non-string primitive. Statement 1 re-confirmed: packages/spec/src/data/field-value.zod.ts:63-65 puts 'summary' in NUMERIC_VALUE_TYPES and :497 'if (NUMERIC_VALUE_TYPES.has(t)) return z.number().finite();'. Population scan: a script resolving every roll-up declaration's child field type against every in-repo object literal reports 3 min/max sites (summary-backfill.test.ts:138, :139; summary-rollup.test.ts:313), all task.estimate = number = NUMERIC-OK, and IN-REPO NON-NUMERIC COUNT 0. POSITIVE CONTROL, required because that is a zero: the card's own example plus a resolvable child (invoice_line.shipped_at, datetime) was fed to the same scanner from a scratch file and came back 'NON-NUMERIC ***', CONTROL FIRED True - so the zero is a fact about the corpus, not about the scanner. Alias spellings were in the scan (rollup/aggregate/summary as the outer key; function/aggregate/operation/op/aggregation as the inner one). NO ablation, NO package build or test was run, and that is declared rather than omitted: there is no diff to verify. Exit codes captured before any pipe - node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack exits 2 with 'this branch changes nothing against origin/main (merge base 142c01c) - nothing to derive'; git status --porcelain and git diff --stat against BASE 142c01c are both empty. The branch is pushed at the base commit (the routing probe) and carries no commits.",
"mcp_calls": "0 - card, comments, related-card states and the branch push all went through the REST channel (repo-scoped probe returned 200, core quota 15000 remaining) and git",
"open_questions": [
{
"question": "Which door should refuse a summary roll-up whose min/max reads a non-numeric child field? Every candidate was measured; none is both fully decidable AND inside the declared two-package surface, so the choice is a routing decision. NOTE: this dispatch carried no decision_frame, so per the standing clause I am NOT inventing axes - this is options and measured costs only, not an axis-by-axis analysis.",
"options": [
"A. packages/lint/src/data-model-rules.ts, a new error-severity rollup/ rule beside rollup/missing-summary. FULLY decidable: the pass runs over the merged normalized object set (its own docblock cites 44 platform-objects plus one metadata-core object in one array) and :661 already reads a child object's field types. Costs: adds a THIRD package to a surface the claim comment declared as two; refuses at os lint / os validate only - it does NOT reach a tenant Studio write, because the object-write runtime gate crosses five named rules and fences the advisory tier out BY NAME under the 2026-08-18 adjudication on #4716; and a new exported rule id would need an api-surface / export-origins reading before fence 2 can be cleared.",
"B. packages/spec/src/stack.zod.ts superRefine, at the package door. Inside packages/spec. Costs: decides ONLY when the child object is owned by the same package - a roll-up onto a platform-objects child, or onto an object contributed by objectExtensions, is silently unjudged. A refusal that can answer for some declarations and not others is a partial gate, and the spec's own aggregate table forbids filling the gap with a guess.",
"C. Widen the object-write runtime gate so a cross-object rule can refuse a Studio publish. This is the only route that reaches the door a tenant actually uses. Costs: #4716's adjudication ruled that scope by tier and pinned the fence by name so a widening 'moves this line consciously rather than by drift' - i.e. it needs its own ruling, not a rider on this card.",
"D. Do nothing at a refusal door and make the contradiction merely OBSERVABLE - triage's own no-ruling-needed half ('一条 lint、一次写入期校验,或至少 os migrate value-shapes 的报告里把这个成因命名出来'). Costs: this dispatch explicitly chose the refusal route over it, so adopting it is a change of remedy, not an implementation detail."
],
"recommendation": "A, with the surface expansion declared and re-claimed first - it is the only candidate that is fully decidable today, it reuses a cross-object resolution that already exists three lines from where the rule would sit, and the aggregate-compatibility table in spec already names 'the authoring-time lint rule' as one of its two intended consumer legs. But it needs the seat to (i) extend the declared file surface to packages/lint and re-check disjointness against the other in-flight claims, and (ii) take an api-surface / export-origins reading on the new rule id before fence 2 can be called clear. If the requirement is that a tenant's Studio publish be refused, then A is insufficient on its own and C is the real ask - and C needs a ruling."
},
{
"question": "If a refusal is written, must its accepted set be NARROWER than the spec's own AGGREGATE_FIELD_TYPE_COMPATIBILITY table? Measured: yes, and this is a trap worth stating before anyone writes the rule.",
"options": [
"Reuse isAggregateCompatibleWithFieldType verbatim at the roll-up door. It ACCEPTS min/max over the temporal class - the table's docblock says so deliberately, because there min/max 'return a value of the field's OWN type (#15768)'. So it would accept the card's own example, max over shipped_at, and the refusal would never fire.",
"Write the roll-up door's own predicate: for a summary roll-up the ANSWER must satisfy the summary value contract, z.number().finite(). That accepts the numeric class and the boolean class (min(flag)=0 / max(flag)=1 per #11152, pinned in AGGREGATION_CASES) and refuses temporal and everything else - narrower than the analytics table by exactly the temporal class."
],
"recommendation": "The second. The analytics table and the roll-up door answer two different questions - 'can every backend give one answer' versus 'does that answer fit the column this roll-up is stored in' - and conflating them produces a gate that is green because it never fires."
}
],
"out_of_scope_findings": [
"noted, not filed: packages/spec/src/data/aggregate-field-type-compatibility.ts is exported (packages/spec/src/data/index.ts:216) but has ZERO consumers in-tree - grep finds only the module and its own test, while its docblock states 'this table is the contract both consumer legs execute'. Not filed because the承接者 is named and open: #16099 (open, pm:queue, domain:services) owns both legs, and the table landed ahead of them by design under #16353.",
"noted, not filed: the platform states the numeric-child contract in ONE of its two spellings already. The AI blueprint's roll-up schema describes its field as 'Numeric field on the CHILD to aggregate' (packages/spec/src/ai/solution-blueprint.zod.ts, StrictSummaryOperations) while FieldSchema.summaryOperations.field says only 'Field on child object to aggregate (ignored for count)' - and neither is enforced. This is corroboration for the refusal route rather than a separate defect, and its承接者 is this card. Filed nowhere on purpose: it is the same declaration/storage disagreement #16237 already names.",
"noted, not filed: MySQL / Postgres insert behaviour on the float column remains UNMEASURED. The dispatch put it out of scope and this run did not provision either engine, so nothing is asserted in either direction. 承接者: none today - it needs a container with both engines."
]
}

---

Generated by Claude Code

[zhuangjianguo]

⛔ Not landed — fence 4 tripped honestly, and the routing question is the triage seat's. pm:retriage hung with this comment in the same write.

domain:spec execution seat, session session_016N6xmWt5hYm94ffVEwGH8x, at 2026-09-08T14:41Z. pm:dispatched → pm:queue + pm:retriage, assignee released. Tier fuse: the dev's transcript carries 103 harness-stamped "model" values, all claude-opus-5, zero others — at the dispatched tier.

⛔ No PR was opened and nothing was written. The branch is pushed at its base carrying zero commits; git status --porcelain and git diff --stat are both empty.

⭐ The trap triage could not clear — cleared, and I verified it myself

Triage flagged that sql-driver.ts has at least two switches casing to summary and warned against locating by the first case 'summary': hit. The dev located by the assignment, as instructed, and told the two apart two independent ways. Re-derived by this seat on origin/main:

• git grep -n "col = table.float(name)" → :16429 and :16526; the one adjacent to a case label is :16526, so the DDL arm is :16525-16526.
• The decoy at :15948 sits in a case group with percent / rating / slider / progress / boolean / toggle — exactly the neighbours triage described — inside varcharColumnChars (declared :15911), whose arm body is return null, versus createColumn (declared :16241), whose arm body is col = table.float(name); break;.

⇒ Statement 2 is confirmed. All three shipped statements now stand, so the defect is exactly as filed.

✅ Fence 1 clears — a refusal would redden nothing in this repo

The dev scanned every roll-up declaration and resolved each child field's type: 84 declarations (41 count, 38 sum, 2 avg, 2 max, 1 min), and all three min/max sites aggregate task.estimate, declared number. ⇒ in-repo non-numeric population = 0.

⭐ And the zero carries a positive control, which is why it is a reading: the card's own example (invoice_line.shipped_at, datetime) was fed to the same scanner from a scratch file and came back NON-NUMERIC ***, CONTROL FIRED True. Alias spellings were in the scan on both keys. ⇒ the zero is a fact about the corpus, not about the scanner.

⛔ Fence 4 trips — the child field's type is NOT resolvable at the door this dispatch named

Every candidate door was measured, and none is both fully decidable and inside the two-package surface this claim declared:

door	why it cannot decide
FieldSchema.summaryOperations (field.zod.ts:1401)	a Zod check there receives the field's own value and nothing else — the child object is simply absent
ObjectSchema.superRefine (object.zod.ts:2380)	sees exactly one object; the child named by summaryOperations.object is a different object. Its only current occupant says so in its own comment: "judged here because only the object knows its name"
package door (stack.zod.ts:312 / :1371)	only objects owned by that package ⇒ a roll-up onto a platform-objects child, or onto one contributed by objectExtensions, is silently unjudged
AI blueprint door (solution-blueprint.zod.ts:243)	only objects in that blueprint ⇒ partial for the same reason
runtime registration (registry.ts:2011)	per-object and warn-never-throw by design; a refusal there draws a verdict from a registry that is still filling — the very pattern packages/lint/src/lint-startup-registry-verdict.ts exists to flag. The engine itself defers the cross-object read to buildSummaryIndex (engine.ts:8508), lazily, after registration

⇒ The only fully decidable door is a whole-model authoring pass: packages/lint/src/data-model-rules.ts, which already resolves a child object's field types three lines away at :661 for the rollup/missing-summary rule.

Why this seat is not simply expanding the surface — it is a cross-lane routing call

packages/lint is domain:devx on the lane table, not domain:spec. Extending this card's file surface into it is 「跨域 PR 指定车道」, which is the triage seat's to assign — ⛔ not an execution seat's to take by widening its own claim. Hence pm:retriage rather than a re-dispatch.

⚠️ And there is a second, harder blocker on that route right now: a new exported lint rule id would be a new published export, which trips this dispatch's widening fence. claude-fable-5-1 capacity is exhausted for this account, so a widening diff cannot get the at-tier review the enqueue gate demands, and 「契约复核 ⛔ 不适用额度耗尽豁免降档」. ⇒ even with the routing settled, option A may not be landable until fable returns. That should be part of the routing decision rather than a surprise afterwards.

⭐ The trap the next dev must not walk into — measured, and worth more than the block

If a refusal is written, do not reuse isAggregateCompatibleWithFieldType verbatim. That table deliberately accepts min/max over the temporal class, because there they "return a value of the field's OWN type (#15768)" — so it would accept the card's own example (max over shipped_at) and the refusal would never fire.

⇒ The roll-up door needs its own predicate: the answer must satisfy the summary value contract, z.number().finite() — which accepts the numeric class and the boolean class (min(flag)=0 / max(flag)=1 per #11152, pinned in AGGREGATION_CASES) and refuses temporal. Narrower than the analytics table by exactly the temporal class.

⭐ Two questions that look alike and are not: "can every backend give one answer" versus "does that answer fit the column this roll-up is stored in". Conflating them yields a gate that is green because it never fires.

The routing question, for triage

Four measured options with their costs are in the dev's report; the short form:

• A — new error-severity rule in packages/lint/src/data-model-rules.ts. Fully decidable. Costs: third package on the surface; refuses at os lint / os validate only — it does not reach a tenant Studio write, because that runtime gate fences the advisory tier out by name under the 2026-08-18 adjudication on [P2] 运行时授权门扩到 object 写入 + 全量 runtime-safe 规则快照(#4463 P1 之后) #4716; and the new rule id needs an api-surface / export-origins reading.
• B — stack.zod.ts package door. Inside packages/spec, but partial — and the spec's own aggregate table forbids filling the gap with a guess.
• C — widen the object-write runtime gate so a Studio publish refuses. The only route reaching the door a tenant actually uses; [P2] 运行时授权门扩到 object 写入 + 全量 runtime-safe 规则快照(#4463 P1 之后) #4716 pinned that fence by name, so it needs its own ruling, ⛔ not a rider here.
• D — make the contradiction merely observable (triage's own no-ruling-needed half). Costs: this dispatch chose the refusal route over it, so adopting it is a change of remedy.

⛔ This seat does not choose among them: A crosses a lane, C needs a ruling, and D reverses a remedy this dispatch already picked.

Recorded, not filed

packages/spec/src/data/aggregate-field-type-compatibility.ts is exported with zero in-tree consumers while its docblock calls itself "the contract both consumer legs execute" — ⛔ not filed, because #16099 (open, pm:queue, domain:services) owns both legs and the table landed ahead of them by design under #16353. Also: the AI blueprint's roll-up schema already says "Numeric field on the CHILD to aggregate" while FieldSchema.summaryOperations.field says only "Field on child object to aggregate" — the platform states the contract in one of its two spellings and enforces neither. ⚠️ MySQL/Postgres insert behaviour stays UNMEASURED; ⛔ nothing asserted in either direction.

---

Generated by Claude Code