analytics: 数据集维度只解析 lookup 字段,user 字段维度返回原始用户 id —— 以人为轴的图表/报表标签是一串 id

[baozhoutao]

现象

数据集(dataset)的维度解析只认 lookup 字段:同一次 POST /api/v1/analytics/dataset/query 里,lookup 维度返回目标记录的名称,user 维度返回原始用户 id。于是任何以「人」为轴的图表 / 报表,轴标签是一串 id,不是姓名。

同一个数据集的两次查询(应用对象 kpi_result:unit 是 Field.lookup('sys_business_unit'),person 是 Field.user()):

// dimensions: ["unit"]
{"rows":[{"unit":"客户成功部","avg_score":91.5},{"unit":"华东分公司","avg_score":106.12}, …],
 "fields":[{"name":"unit","type":"string","label":"组织单元"}]}

// dimensions: ["person"]
{"rows":[{"person":"7zLYIwpX82If4BvtWGdx2FJeP1S3yyrE","avg_score":124.25},
         {"person":"F8Ue761QN8IwpEXDcqjvmElGMrBxbEXs","avg_score":128.6}, …]}

两个字段都带 reference,差别只在 type:

Field.user({ label: '人员' })                       // {"type":"user","reference":"sys_user","label":"人员"}
Field.lookup('sys_business_unit', { label: '组织单元' }) // {"type":"lookup","reference":"sys_business_unit","label":"组织单元"}

数据集侧把维度声明成 type: 'lookup' 不改变结果 —— 解析看的是对象字段的类型,不是维度声明。

最小复现

1. 建一个对象,含一个 Field.user() 字段(例:person)与一个 Field.lookup() 字段(例:unit),各写入若干行;
2. defineDataset 声明两个维度分别指向这两个字段(type: 'lookup'),一个 avg measure;
3. POST /api/v1/analytics/dataset/query,dimensions: ["unit"] → 返回名称;dimensions: ["person"] → 返回用户 id;
4. 把该数据集挂到 dashboard widget / report 上,人员轴显示的就是 id。

期望能力

user 字段作为数据集维度时,与 lookup 同样按 reference(sys_user)解析出显示名(sys_user 的 nameField),或提供一个显式的维度选项(如 displayField)让作者指定用哪一列显示 —— 现在 DatasetDimensionSchema 是 strict 的,只有 name / label / field / type / dateGranularity,应用侧没有任何声明式出口;能绕开它的只有「换一个本身存着姓名的列」,那要求应用把姓名反规范化进结果表。

平台版本

@objectstack/runtime / @objectstack/spec / @objectstack/cli 17.2.0(SQLite 驱动,单租户 dev 实例)。

上报来源:objectstack-ai/kpi 的看板「人员得分」与「到人得分」报表;应用侧按纪律不绕平台、不打补丁,当前用「结果记录名称(含姓名)」作展示维度顶着,平台补上后换回 person 维度。

[os-zhuang]

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

域 —— 读代码判定：解析发生在 packages/services/service-analytics/src/dimension-labels.ts，按车道表 packages/services/* ⇒ domain:services。packages/spec 在本卡里只被读，不被改（见下），所以不是跨域。

复核：现象成立，而且比卡面报的更硬

上报把这件事写成「期望能力」（像是 Feature）。读代码之后我判它是 Bug，依据是本仓自己声明的一个类，被同一个包的两条路径拆开处理了：

packages/spec/src/data/field-value.zod.ts:128-130 —— 声明了一个四成员的引用类：

/**
 * Value points at another record: a record-id string in stored form, the
 * related record object in expanded form (`$expand` overwrites in place).
 */
export const REFERENCE_VALUE_TYPES: ReadonlySet<string> = new Set([
  'lookup', 'master_detail', 'user', 'tree',
] as const satisfies readonly FieldType[]);

同一个 analytics 包已经按这四个成员是同一类东西在办事：

packages/services/service-analytics/src/measure-result-type.ts:81
  | `REFERENCE_VALUE_TYPES` | lookup, master_detail, tree, user | … all four share
    `ReferenceIdValueSchema` (`z.string()`); the stored value is the referenced row's id,
    never the expanded record. |
packages/services/service-analytics/src/measure-result-type.ts:234
      ...REFERENCE_VALUE_TYPES,

而标签解析只认其中两个：

packages/services/service-analytics/src/dimension-labels.ts:80
  const LOOKUP_TYPES = new Set(['lookup', 'master_detail']);

⇒ 同一个包，一条路径 import 了 spec 声明的四成员集合并对四者一视同仁，另一条路径手写了它的一个二成员子集。 这不是「尚未支持 user」，这是一个已声明契约在同包内被两种读法对待。按类型判据「违背已声明契约 ⇒ Bug」，落 Bug。

dimension-labels.ts 自己的模块头也把理由说全了，只是把成员数说少了：

:11  *  - **lookup / master_detail** — grouped by the foreign-key `id` …
     *    but the user-facing text is the related record's display field (its name/title).

user 字段带 reference: 'sys_user'，存的就是 FK id，读者要看的就是那条记录的显示名——上报给出的 Field.user({...}) → {"type":"user","reference":"sys_user"} 与 Field.lookup(...) → {"type":"lookup","reference":"sys_business_unit"} 的对比，差别只在 type 一个词，这段话对 user 逐字成立。

⭐ 卡面没报到的第四个成员：tree 有同一个洞。 同一行 LOOKUP_TYPES 少的是 user 和 tree。⛔ 不要只补 user ——这个类是修复的单位，只补一半就是把同一个缺陷重新种一遍，而且下一次只会由另一个用户在另一个字段类型上重新报一遍。

为什么不进决策箱

「把 user/tree 加进 LOOKUP_TYPES」不是在两种都说得通的语义之间选一个：同一个模块已经为同一个声明类的另外两个成员选定了「显示名」这一种语义，本卡只是把剩下两个成员对齐到那个既定选择。任何依赖 user 维度返回原始 id 的消费者，依赖的正是本卡上报的这个缺陷本身。⇒ 确定，pm:queue，不需要维护者裁决。

⚠️ 一条硬性验收条件（认领席必须做，不是可选项）

dimension-labels.ts 的标签解析带读作用域，而现有测试把这件事钉在了那个二成员集合上：

packages/services/service-analytics/src/__tests__/dimension-labels.test.ts:167
  expect(scopeCalls).toBe(0); // scope is only resolved for lookup/master_detail dims
:121  // ── #3602 — the label lookup must carry the REFERENCED object's read scope ──

⇒ 扩了 LOOKUP_TYPES 就必须同时扩 #3602 的作用域解析。sys_user 尤其如此：把用户 id 解析成姓名，是一次对 sys_user 的读；不带读作用域地做这件事，就是把「谁是谁」泄给一个本来读不到 sys_user 的调用者。这是本卡最容易在实现时漏掉、且漏掉就是安全缺陷的一处，写进验收：

• user / tree 维度的标签解析走与 lookup/master_detail 完全相同的 LabelScopeResolver 路径；
• dimension-labels.test.ts:167 那条断言必须被改成「四类都解析作用域」的正面断言，⛔ 不是删掉；
• 一个读不到 sys_user 的调用者拿到的仍是原始 id（按 :71 既定的「unresolved 留原值、不置空」），不是姓名。

顺带：dataset-executor.ts:69 的排序钩子也按同一个二成员集合描述自己（「a select or lookup/master_detail dimension sorts by the DISPLAY …」），⇒ 人员轴今天还按 id 排序。同一个类、同一个修复面，一起处理。

⛔ 卡面的第二个诉求不在本卡

上报还提了一条备选：给 DatasetDimensionSchema 加一个显式的 displayField 选项。那是扩大公开面（Feature），且 DatasetDimensionSchema 是 strict 的、动它要过 spec 的发布面判断 ⇒ 与本卡的「类一致性修复」是两件事，代价和评审路径都不同。

本卡只做类一致性修复。 修完之后 user 维度直接给 sys_user 的 nameField，上报场景（objectstack-ai/kpi 的「人员得分」「到人得分」）就已经解决；若届时仍需要「指定用哪一列显示」，另开卡，那时它是一张诉求清楚的 Feature，而不是一个缺陷的绕路。

等级 p2

• 不到 p1：无数据损坏、无跨租户面、无鉴权面；应用侧当前用「结果记录名称（含姓名）」顶着，可运行。
• 高于 p3：可达面很大——Field.user() 作为图表/报表的轴是这个产品最常见的分组之一，一旦用到，轴标签全是 id；且唯一的绕法（把姓名反规范化进结果表）要求应用违反正常建模，上报方明确按纪律不绕平台。
• ⚠️ 由 MEMBER 从真实应用（objectstack-ai/kpi）带最小复现上报，非推演。若 domain:services PM 认为「人员轴」在产品定位里的分量够 p1，请在本卡回帖改级——我按可达面和有无绕法定在 p2，不代裁。

平台版本

上报测于 17.2.0（SQLite 驱动、单租户 dev）。⚠️ 上面所有读数取自 origin/main 当刻，缺陷在 main 上仍在（LOOKUP_TYPES 未变），⇒ 不是已修未发的卡。

---

分诊席声明：本席只分类/定级/路由，⛔ 不认领、⛔ 不派工、⛔ 不写码、⛔ 不合并、⛔ 不裁决决策箱卡。

---

Generated by Claude Code

[claude]

Claim: PM loop round 1
Session: session_01ToDPcx9AESFubJkDiFMtKW
Branch: claude/issue-16390-user-dimension-display-name
Worktree: objectstack-issue-16390
Domain: domain:services
File surface: packages/services/service-analytics/src/dimension-labels.ts (+ its test siblings) — the resolution site triage identified by reading the code (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus (default judgment tier — the card offers two routes and one of them crosses this lane's red line, so the route call is judgment, ⛔ not mechanical. dispatch-gates.mjs --tier: no path-derived mandate ⇒ this seat's per-card call)
Clause-②: no — ⚠️ declared for route (a) only, and this is a PREDICTION made before the diff exists (see the route ruling in the next comment). Resolving a user dimension through its existing reference the way lookup already is changes a returned VALUE from an id to a display name; it publishes no symbol, mints no code, and adds no authorable key. ⚠️ Route (b) — a displayField key on the strict DatasetDimensionSchema — WOULD be yes AND would touch packages/spec; it is ⛔ ruled out. This declaration is re-tested against the actual diff before enqueue (this seat got a declaration's REASON wrong on #16683 and its ANSWER wrong on #16418 this round; the fix is to re-test, not to trust the claim).
Thread-read: 5579223270
Serial constraints cleared: service-analytics is held by NOTHING in flight. This seat's open PRs are #17450 (plugin-audit), #17443 (plugin-auth), #17436 (plugin-security/src/objects + scripts + translations); other seats' are #17332 (plugin-security ×5 + mcp + spec/contracts, queued) and #17334 (trigger-schedule / service-automation / lint). ⇒ Zero overlap at file AND package level.
⚠️ Same-day churn, named rather than discovered later: PR #16778 merged today into this very package and moved dataset-compiler.ts (+158) and analytics-service.ts (+69), among others. dimension-labels.ts is not in its changed-file stat, but this card was filed 2026-09-06 — three days before that landing — so ⛔ none of its premises may be carried across unverified. Re-measurement against today's main is the dev's first task.
Verify-lock arrival depth read immediately before dispatch: 1 (state: lock is free, queue: empty), under LOCK_DEPTH_HOLD = 2.

---

Generated by Claude Code

[claude]

PM route ruling — take (a) symmetric resolution. ⛔ Route (b) is ruled out, and the reason is this lane's red line

domain:services seat, session session_01ToDPcx9AESFubJkDiFMtKW, 2026-09-10T15:2xZ. The card's 「期望能力」 offers two routes and does not pick. Picking is needed before dispatch because one of them leaves this lane.

① The route

(a) — a user dimension resolves its display name through its existing reference (sys_user → that object's nameField), the same way a lookup dimension already does. ⇒ The asymmetry the card measured (「差别只在 type」, both fields carry reference) is closed at the resolution site, dimension-labels.ts.

⛔ (b) is NOT taken — a declarative displayField option on DatasetDimensionSchema. Two independent reasons, either sufficient:

1. DatasetDimensionSchema lives in packages/spec, which is this lane's red line — 「凡触 packages/spec 一律转 domain:spec 座位」. This seat cannot authorise it and ⛔ will not have a dev do it.
2. It is a new authorable key on a published strict schema — an accept-set widening, i.e. Clause-②: yes and a Feature. That is a bigger act than the card's own measured defect requires, and 「创业阶段不扩散」 argues against buying it when (a) closes the reported symptom.

⇒ (a) is the smaller act, stays in-lane, and needs no new authorable surface. ⛔ This does not say (b) is wrong forever — only that it is not this card, and not this seat's to grant.

② The premise it hangs on — ⛔ verify FIRST

A user field carries everything the resolution needs — a reference naming sys_user — so resolving it requires no new declaration from the app author.

The card measured exactly this: Field.user({label:'人员'}) → {"type":"user","reference":"sys_user","label":"人员"} versus Field.lookup(...) → {"type":"lookup","reference":"sys_business_unit",...}. ⚠️ Re-measure it on today's main anyway — see ③.

③ ⚠️ Same-day churn — the card's premises are THREE DAYS older than the tree

PR #16778 merged today into service-analytics, moving dataset-compiler.ts (+158), analytics-service.ts (+69), measure-result-type.ts, both strategy files and plugin.ts. dimension-labels.ts is not in that stat list, but this card was filed 2026-09-06.

⇒ Re-verify the card's repro against today's main before writing anything. If the behaviour already changed, or the resolution moved out of dimension-labels.ts, STOP and report — premise_still_valid: false is a successful dispatch, ⛔ not a failure.

④ ⛔ The prohibition

If (a) cannot be done without touching packages/spec — for any reason, including a type that must widen — STOP and report the exact shape you would need. ⛔ Do not edit packages/spec; ⛔ do not fall back to (b) on your own; ⛔ do not denormalise a name into the result table (the card names that as the workaround the app is already forced into, and closing it is the point).

⚠️ Also ⛔ out of scope: anything about kpi_result or the reporting app — the defect is the platform's resolution, not the app's modelling.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 16390,
  "status": "done",
  "branch": "claude/issue-16390-user-dimension-display-name",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/17470",
  "premise_still_valid": true,
  "summary": "Route (a) as ruled, and packages/spec is untouched (read only). dimension-labels.ts no longer carries a private two-member LOOKUP_TYPES set; all three sites that classified a dimension (the display pass in resolveDimensionLabels, plus isLabelBearing and the label fetch in the #3680 order-label hook) now ask spec's referenceTargetOf, the declared single arbiter for the REFERENCE_VALUE_TYPES class (lookup, master_detail, user, tree). Two consequences a LOOKUP_TYPES.add('user') patch would not have had: a `user` field authored WITHOUT `reference` resolves too (sys_user is a constant of the type), and the #3602 referenced-object read scope now covers the added members on the same LabelScopeResolver path, so turning a user id into a name is a scoped read of sys_user rather than an unscoped one. Triage's class argument was followed: `tree` had the identical hole and was fixed in the same edit. No new export, no error code, no authorable key.",
  "tests": "pnpm --filter @objectstack/service-analytics test :: 106 files / 2284 tests passed (exit 0). typecheck :: clean; tsc --noEmit --listFiles | grep -c on the new test file returns 1, so the typecheck program really compiles it. Targeted: vitest run on dataset-reference-dimension-labels.test.ts + dimension-labels.test.ts :: 43 passed. REPRO RE-VERIFICATION (Zone 3): the new pin was written and run BEFORE the fix, against unmodified main at base 9788f1e91 :: 7 failed / 5 passed - the defect reproduces on today's tree, resolution has not moved out of dimension-labels.ts (last touch #17061, before this card). ABLATION (C5): fix committed first; referenceLabelTarget mutated back to the pre-fix two-member classification. On-disk proof, not an editor exit code - deleted text 1 -> 0, injected marker 0 -> 1, blob c1ece3783868ecd962650165dd60c566f4ca3073 != HEAD blob 352a94e60a00890fab5cf374bb7020d2e18c72f6. Ablated run :: 2 files failed, 10 failed / 33 passed, matching the predicted-before-running direction exactly (ordinary red, no inversion, no count movement; 7 red in the new file + 3 in the sibling; master_detail was already inside the old subset so it is a control, not a casualty). Restoration proven BY STATE: restored blob == HEAD blob 352a94e60a00890fab5cf374bb7020d2e18c72f6, and `git diff HEAD -- target` emits 0 bytes. Resolution path: the pin imports its subject relatively inside its own package, so it reads source, not dist; check:test-source-alias passes and the spec dependency it does read from dist is unchanged by the mutation.",
  "gates": {
    "derivation": "node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack, no paths passed (script derived the change set itself: 4 paths vs merge base fd62a66b7)",
    "derived": 60,
    "ran_green": 57,
    "not_measured": 3,
    "unrun": 0,
    "reconciliation": "node scripts/pm/dispatch-gates.mjs --ran <file with `<command> :: exit <code>` lines> :: 60 derived accounted for - 57 run, 3 NOT-MEASURED (3 DERIVED from a recorded exit 3), 0 UNRUN",
    "not_measured_detail": [
      "pnpm check:dual-build-cjs-loads :: exit 3 - PREREQUISITE NOT MET, reads built output for the whole workspace (78 packages have no dist)",
      "pnpm check:lean-entry-closure :: exit 3 - PREREQUISITE NOT MET, loads built entry points (@objectstack/objectql dist absent)",
      "pnpm check:type-check-debt :: exit 3 - PREREQUISITE NOT MET, --re-measure needs 24 workspace dependency closures built"
    ],
    "not_measured_reason": "all three want a repo-scale `pnpm build`; that is CI's run, not a per-card local one. Recorded as NOT MEASURED, never as passes.",
    "exit_codes": "captured with `cmd > log 2>&1; EXIT=$?` before any pipe; per-command log kept",
    "eslint": "declared narrowing at HEAD 44918e39d. (1) universe: `pnpm lint` = `eslint . --no-inline-config` over the repo root per package.json. (2) count from --format json: 3 files, 0 errors, 0 warnings - the changeset .md is not a lint target (eslint answers 'File ignored because no matching configuration was supplied'), so 3 is the diff's whole lint surface. (3) invariance: this repo runs one eslint.config.mjs which never enables type-aware linting for ANY file (no parserOptions.project, no typed @typescript-eslint rules - stated and positively controlled in the config's own header above QUERY_OPTIONS_TEST_GLOBS), so an edit confined to 3 files cannot move any untouched file's verdict.",
    "manual_control_char_scan": "grep -naP over all 4 changed files :: exit 1, no matches",
    "derivation_caveat": "derivation taken at 44918e39d, by which time origin/main had moved one derivation-source script (scripts/measure-test-shard-timings.mjs); the family it feeds (report-test-timings.mjs --self-test) is in the run list and green. The full gate sweep was re-run in its entirety at the final commit 44918e39d, after the last edit."
  },
  "line_budget": "n/a - no `skills/**` path in the diff (governed surfaces untouched: no docs/adr/**, .claude/**, skills/**, AGENTS.md or CLAUDE.md)",
  "clause_2": "no - holds against the actual diff, not just the claim: `git diff fd62a66b7...HEAD -- packages/services/service-analytics/src | grep '^+' | grep export` returns nothing (exit 1). No exported symbol, no error code, no authorable key; packages/spec is read only. A line-initial literal `Clause-②: no` is in the PR body (line 3), read back from the stored body.",
  "files_changed": [
    "packages/services/service-analytics/src/dimension-labels.ts (+55/-17)",
    "packages/services/service-analytics/src/__tests__/dimension-labels.test.ts (+74)",
    "packages/services/service-analytics/src/__tests__/dataset-reference-dimension-labels.test.ts (+319, new)",
    ".changeset/analytics-reference-dimension-display-labels.md (+19, new, @objectstack/service-analytics: patch)"
  ],
  "file_surface": "C1 held - only dimension-labels.ts and its test siblings, plus the changeset. Nothing in plugin-audit, plugin-auth, plugin-security, service-automation or trigger-schedule. C2 held - packages/spec read (referenceTargetOf, REFERENCE_VALUE_TYPES, Field builders, DatasetDimensionSchema), never written; the prohibition in Zone 1 never fired because route (a) needed no spec type to widen.",
  "repo_root": "/home/user/objectstack-issue-16390",
  "negative_control_c4": "An unresolvable user degrades to the raw id and the query still answers - nothing throws, nothing blanks. Four shapes pinned: (1) an orphaned or RLS-hidden user id keeps its id while a sibling row in the SAME result still resolves; (2) a sys_user carrying no display field at all leaves every id raw; (3) a sys_user unknown to the engine leaves every id raw; (4) fail-closed - when the read-scope provider throws for sys_user, fetchRecordLabels is never called and the id renders. This is the pre-existing contract for an unresolved lookup id, now reached by the same code path, so a working id-labelled chart cannot become an error.",
  "zone3_reverification": "premise still valid, defect still live. Site unmoved (dimension-labels.ts, last touch #17061 which predates the card; #16778 did not touch it). M2 re-measured on today's tree and now asserted by the pin on every run: Field.user() -> {type:'user',reference:'sys_user'}, Field.lookup(ref) -> {type:'lookup',reference:ref}. M3 confirmed by code and pinned both ways: outside the date branch the resolver reads only the OBJECT field's type, and DatasetDimensionSchema.type has no 'user' member at all ('string','number','date','boolean','lookup'), which is the structural reason there is no author-facing declaration to fix this with.",
  "mcp_calls": "0 - the whole run used the container's authenticated REST egress (repo-scoped probe returned 200 at the start) plus git; no MCP GitHub tool was called, including for the duplicate search.",
  "deviations": [
    "PR body footer uses the repo's session-URL form `_Generated by [Claude Code](https://claude.ai/code/session_...)_` (the os-dev contract's spelling for a created PR body) rather than the harness-injected two-line wording, because AGENTS.md forbids a model identifier in a PR body and the contract names this exact form. Read back byte-identical.",
    "3 of 60 derived gate families are NOT MEASURED (exit 3, repo-scale build prerequisite) - declared, not silently skipped.",
    "`pnpm lint` was run as a declared narrowing (3 files) rather than repo-wide; the three required pieces of evidence are in `gates.eslint`.",
    "origin/main was merged into the branch once (7200f324f) so the gate derivation could run on a non-stale tree; main has moved again since and the branch is now behind, which the merge queue rebuilds anyway.",
    "No labels were applied: this repo's size/documentation/tests/tooling labels come from the labeler workflow, and `skip-changeset` does not apply because a changeset ships. Nothing on this PR was set by another actor and nothing was corrected."
  ],
  "open_questions": [],
  "out_of_scope_findings": [
    "noted, not filed: `plugin.ts` relationshipResolver admits only lookup/master_detail when mapping a dataset `include` to a joined table - the same two-member spelling, but on the JOIN path, not the dimension-label path this card fixes, and a `user` join has a fixed target so it is a different question. Outside C1's file surface. Carrier: the next PR that touches dataset joins in service-analytics.",
    "noted, not filed: `dataset-executor.ts` (order-hook prose) and `analytics-service.ts` (a doc comment) still describe the sort as `select` or `lookup`/`master_detail`. The BEHAVIOUR is already corrected by this PR - both read createOrderLabelResolver, which now covers the class, so a person axis sorts by name from this commit on; only the two comments are understated. Comment-only drift, outside C1's file surface. Carrier: the same next PR.",
    "noted, not filed: triage's stated acceptance condition asked that `dimension-labels.test.ts` line 167's `expect(scopeCalls).toBe(0)` be converted to a positive four-member assertion. Read on the tree, that assertion is about a SELECT dimension, which reads no other object and stays correct after the widening - so it was kept (its now-stale trailing comment rewritten) and the positive counterpart was ADDED beside it instead, asserting the scope resolver is consulted for crm_account, sys_user and task in order and that each scope reaches fetchRecordLabels. A sub-claim of triage falsified, with the requested guarantee delivered."
  ]
}

---

Generated by Claude Code

[os-sales]

ACCEPT — PR #17470 @ 44918e39da (domain:services seat review of record, default tier)

Reviewed by session_01ToDPcx9AESFubJkDiFMtKW (os-sales), 2026-09-10T16:46Z, against GitHub and the tree — ⛔ not against the report's self-description.

Checklist

item	reading
CI (newest run per name)	28 success · 5 skipped · 0 running · 0 failing across 33 distinct checks. ⚠️ 39 raw rows exist on this head, so a raw count would have lied
Check Changeset · Governed Surface Queue Guard	both completed / success
changed files	4 — src/dimension-labels.ts (+55/−17), two test files, one changeset. 0 governed surface, 0 packages/spec, 0 content/docs/** ⇒ normal landing path
Clause-②	no, line-initial — re-measured by this seat below
changeset	@objectstack/service-analytics: patch

⚠️ A platform reading worth carrying: at 16:41Z the check-runs list still reported Lint & Repo Gates as in_progress while the job API already had it completed / success at 16:41:37Z. Correction 39's lag, live. ⇒ On a long job, read the job by id before concluding it is stuck.

⭐ Clause-②: no re-measured independently

⛔ Not taken from the report. On the diff itself: 0 added lines containing export in packages/** outside __tests__, against a control of 55 added source lines; 0 added ERROR_CODE_LEDGER / code: entries; 0 added throws in source (the only two in the diff are throw new Error('store unreachable') and throw new Error('sink exploded') — mock failure injection in the test file); 0 packages/spec edits.

⚠️ The exported FieldMetaLite gained no member — its reference?: string was already there and only its docblock moved. ⇒ no stands.

And on patch rather than minor, since this changes a returned value: correct. The changeset's own argument is the one that decides it — packages/spec declares one reference class (REFERENCE_VALUE_TYPES = lookup, master_detail, user, tree) and this same service already treats it as one class where it annotates measure result types (measure-result-type.ts imports that very set). ⇒ Within a single dataset query one axis came back as a name and the other as a raw id, for two fields differing by one word. The previous behaviour was the anomaly; aligning to the declared class is a bug fix.

Spot-checks

The subset is gone, not extended — and that is the part worth keeping. The resolver now asks referenceTargetOf (@objectstack/spec/data), the declared single arbiter, at all three sites that classified a dimension: the display pass, the #3680 sort-key hook's isLabelBearing, and its resolveLabels. ⛔ Adding two literals to a private Set would have left the next member of the class to be re-reported by the next user. packages/spec is read, never written — the red line held without needing the stop-clause.

Two consequences a LOOKUP_TYPES.add('user') patch would not have had, both real: a user field authored without reference resolves too (sys_user is a constant of the type that referenceTargetOf materialises), and the #3602 referenced-object read scope now covers the added members on the same LabelScopeResolver path — so turning a user id into a name is a scoped read of sys_user, not an unscoped one. ⭐ That second half had to land with this change, not after it.

Nothing degrades into an error or a blank. Four shapes pinned: an orphaned or RLS-hidden id keeps its id while a sibling in the same result still resolves; a sys_user with no display field; a sys_user unknown to the engine; and fail-closed — when the read-scope provider throws, fetchRecordLabels is never called and the id renders. That is the pre-existing contract for an unresolved lookup id, now reached by the same path.

Ablation proved by state. Mutation on the committed tree reverting referenceLabelTarget to the pre-fix two-member classification; on-disk proof before any result was read (deleted text 1→0, injected marker 0→1, blob c1ece378… ≠ HEAD blob 352a94e6…); ablated run 10 failed / 33 passed, matching the direction predicted before running, with master_detail correctly identified as a control rather than a casualty (it was already inside the old subset). Restored by state — restored blob == HEAD blob, git diff HEAD -- <target> emits 0 bytes.

Repro re-verification on today's tree, not on the card. The new pin was written and run before the fix against unmodified main at 9788f1e91 — 7 failed / 5 passed. ⇒ The defect reproduces now, and resolution has not moved out of dimension-labels.ts (last touch #17061, which predates this card).

Gates: 60 derived, 57 green, 3 NOT MEASURED (dual-build-cjs-loads, lean-entry-closure, type-check-debt — all exit 3 = PREREQUISITE NOT MET, one cause: they want a repo-scale build). ⭐ Recorded as NOT MEASURED, ⛔ never as passes. Exit codes captured before any pipe.

⭐ Triage's acceptance condition — the dev declined one sub-claim, and the dev is right

Triage asked that dimension-labels.test.ts's expect(scopeCalls).toBe(0) be converted into a positive four-member assertion. The dev declined and reported it rather than silently complying. Checked on the tree: that test is titled 'a select dimension is unaffected by scope resolution (no referenced object)' and drives a status select dimension, which reads no other object — so 0 is correct and stays correct after the widening. Converting it would have destroyed a valid test.

⇒ Triage's sub-claim is falsified. The genuinely stale part was the trailing comment (// scope is only resolved for lookup/master_detail dims), which the dev rewrote, and the requested positive counterpart was added beside it — asserting the scope resolver is consulted for crm_account, sys_user and task in order, and that each scope reaches fetchRecordLabels. The requested guarantee is delivered in the right place. ⭐ Reporting a disagreement with evidence instead of quietly doing the wrong thing is the behaviour this lane wants.

The docs-drift advisory — answered, and its blind half swept by hand

Re-derived on the tree the bot actually read (the merge commit 46332726…, ⛔ not the PR head): 27 rows = 21 hand-written + 6 release-owned. ⭐ Every row is anchored on one item — master_detail (literal, a string literal in LOOKUP_TYPES) — because this diff deletes LOOKUP_TYPES. ⇒ Correct rows carrying zero signal about which page states the rule, so each was read individually.

• 1 of 21 falsified: content/docs/data-modeling/analytics.mdx:210–:211. Verified verbatim by this seat on origin/main.
• ⭐ 1 more, found by the emitter-blind hand sweep and reachable by no anchor: content/docs/ui/dashboards.mdx:146–:147 (the #3680 sort rule). It names neither master_detail nor any symbol in the diff — exactly the class the bot's own "What this run could not see" section says it can never list, on this or any run. Also verified verbatim by this seat.
• The other 20 split cleanly (5 already enumerate all four members; 11 field-type vocabulary with no analytics claim; 4 error/permission pages) and the 6 release-owned pages were read and left alone — two of them state the rule and are not falsified for a reason rather than by exemption: a release page is a dated record of what that release shipped, and both remain true of v9 and 17.0.

⇒ Both falsified sites filed together as #17483 with Blocked-by: #16390, ⛔ not edited here (content/docs/** is domain:devx). ⚠️ Both sentences are true until this PR merges — the block names the issue, not the PR, per this lane's vocabulary.

Noted, ⛔ not acted on

• The body carries two attribution footer blocks (the REST edit path re-landed one). Cosmetic, and ⛔ deliberately left: removing one costs a gate re-run and re-triggers the same append.
• Three out-of-surface observations the dev reported rather than widening into: plugin.ts's relationshipResolver admitting only lookup/master_detail on the join path (a different question — a user join has a fixed target); and comment-only drift in dataset-executor.ts and analytics-service.ts where the behaviour is already corrected by this PR. ⇒ Carrier named: the next PR touching dataset joins in service-analytics. ⛔ Correctly not filed as cards.

⇒ ACCEPT. Moving to ready and the merge queue; ⛔ this seat does not merge.

---

Generated by Claude Code