spec: declare the aggregate × field-type compatibility matrix (`AggregationFunction` × `FieldType`) that dataset measures are refused against (spec half of #16099)

[os-zhuang]

Spec half of #16099, split by director ruling (decision batch #59, 2026-09-06, "both legs, table in spec"). The two consumer legs — compile-time refusal in dataset-compiler (#16099 itself, services) and an authoring-time lint rule (devx sub-card) — are pm:blocked on this card and consume this one table.

Why

A dataset measure pairing avg with a Field.datetime compiles to AVG(col) and reaches the backend: SQLite renders a mean of epoch milliseconds, Postgres fails with 42883. Nothing between author and driver correlates aggregate with the field's type. Which pairs are accepted is a narrowing of a published acceptance set, so it is a contract, declared once in @objectstack/spec and executed by both legs.

Scope

• Export a compatibility table from the spec (next to AggregationFunction / DatasetMeasureSchema), e.g. AGGREGATE_FIELD_TYPE_COMPATIBILITY: Record<AggregationFunction, readonly FieldType[]> plus a predicate isAggregateCompatibleWithFieldType(aggregate, fieldType).
• Starting rows (director's ruling; the spec seat finalises against the full FieldType membership):
  • count, countDistinct: any type
  • sum: numeric types only (number, currency, integer-class) — excludes percent (analytics-service.ts already calls that pair incoherent)
  • avg: numeric types including percent
  • min, max: numeric types plus temporal (date, datetime)
  • every other pair: refused
• TSDoc states the rule and the reason (backend-divergent results, Prime Directive Add comprehensive test suite for Zod schema validation #12).
• Clause-② conformance limb: yes (a previously accepted authoring shape becomes refused once the consumers land) — carry needs:contract-review on the landing PR; changeset states the narrowing.

Out of scope

• The refusals themselves (compile leg: No layer refuses an incoherent aggregate / field-type pair — a dataset measure avg over a datetime works on SQLite and errors on Postgres #16099; lint leg: devx sub-card).

Acceptance

• table and predicate exported and pinned in the api-surface baselines
• every AggregationFunction member has a row; every FieldType member is classified
• changeset present

[os-trump]

Claim: PM loop round R1 wave 2 — domain:spec seat, 2026-09-07T19:25Z.
Session: session_01F8SRGcf2eKTK7RRpWCGxwf
Branch: claude/issue-16353-aggregate-field-type-matrix
Worktree: objectstack-issue-16353
Domain: domain:spec
File surface: wherever AggregationFunction / DatasetMeasureSchema are declared (measured: packages/spec/src/api/analytics.zod.ts, packages/spec/src/shared/enums.zod.ts) + the new table/predicate and its pins + regenerated api-surface / export-origins / authorable-surface / docs references (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: claude-fable-5-1 (ceiling — the card states Clause-②: yes on the ruling's authority)
Clause-②: yes
Serial constraints cleared: measured at 19:19Z against origin/main. AggregationFunction occurs in api/analytics.zod.ts · data/query.zod.ts · shared/enums.zod.ts · ui/action.zod.ts · ui/chart.zod.ts. ⭐ packages/spec/src/data/analytics.zod.ts has ZERO hits, so the predecessor's linger fence (PR #16618) is not implicated — that was the first thing checked, since the card's subject word is "analytics" and the fence's file is named analytics.zod.ts. Disjoint from all four of this seat's held PRs: #16636 (kernel/metadata-loader), #16635 (automation/execution), #16640 (contracts/approval-service), #16652 (api/error-code-ledger + api/contract + api/dispatcher* + stack.zod.ts + kernel/plugin.zod.ts) — note #16652 touches api/** but not api/analytics.zod.ts. Also disjoint from the surface reserved for the #15442/#15449 re-dispatch (ui/page.zod.ts, ui/component.zod.ts) — this card's ui/ files are action and chart. Verify-lock at 19:19Z: queue: empty ⇒ arrival depth 1, below LOCK_DEPTH_HOLD.

⚠️ Landing note, stated at claim time rather than discovered at arming: four PRs from wave 1 are complete and at-tier PASSed but held on landing pre-check ②, which cannot be answered in this container. This card's PR will very likely join that queue rather than land promptly. That is a landing-side blocker, ⛔ not a reason to narrow the work or to skip the contract-review tier.

---

Generated by Claude Code