plugin-sharing re-derives materializeDeclaredFields instead of importing it — a second copy of the declared-field binding contract, already diverged

[os-zhuang]

Filed unassigned from the domain:services seat (#6021) while reviewing PR #8483 against the maintainer's 2026-08-06 ruling on #4953. ⛔ This records a finding only — no fix commitment, no pm:queue.

What is there

packages/plugins/plugin-sharing/src/share-link-service.ts defines its own declared-field binder:

function bindDeclaredFields(record: Record<string, unknown>, schema: any): Record<string, unknown> {
  const declared = schema?.fields;
  if (!declared || typeof declared !== 'object') return record;
  const bound: Record<string, unknown> = { ...record };
  for (const name of Object.keys(declared)) {
    if (!(name in bound)) bound[name] = null;
  }
  return bound;
}

Its own doc comment names what it is a copy of:

"The same materialisation the two server-side CEL gates in @objectstack/objectql do (materializeDeclaredFields, behind the validation and hook-condition evaluators)."

It is used by assertEligible to bind the record before evaluating publicSharing.eligibility.

Why this is a finding rather than a style nit

It could have imported the real helper. plugin-sharing/package.json lists @objectstack/objectql as a runtime dependencies entry (not a devDependency), and materializeDeclaredFields is exported from packages/objectql/src/declared-fields.ts. There is no structural obstacle here — unlike trigger-record-change, where objectql is dev-only.

The repo has already written down why duplication is the failure. packages/objectql/src/cel-fault.ts:

"the only durable way to keep two messages worded alike is to stop writing them twice — the same argument that put declared-fields.js#materializeDeclaredFields in front of every server-side evaluator"

It has already diverged. The local copy early-returns record unchanged when schema.fields is absent or not an object. The shared helper is not reached that way by its callers, which gate on the groundTruth rule instead (fetch-the-prior-row, "do not fabricate"). So the two answer differently in at least one input class today.

⚠️ The live exposure is the pinned !has(...) reversal. PR #6454 deliberately changed what !has(record.{declared field}) means once bindings are materialised, pinned by two tests, on the grounds that has() guards an UNDECLARED key and never an empty value (the declared-fields.ts contract since #4649). A hand-rolled mirror does not inherit that change, nor the next one. The entire point of the seam programme in #4953 is that one predicate means one thing on every server-side surface.

Blast radius, stated honestly

⭐ This is not a live security hole, and it should not be graded as one. assertEligible fails closed: an unevaluable predicate raises ELIGIBILITY_UNEVALUABLE and refuses to mint the link. So the divergence's current worst case is a refused share link, not a leaked one. The bindDeclaredFields bail on a missing schema lands in the same safe direction.

The cost is drift, not breach: this is the surface where a future change to the shared contract silently fails to apply, in a gate whose verdicts are security-relevant.

Suggested shape (⛔ not a prescription — the owning lane decides)

The convergent option, which also resolves the same question now open on PR #8483: move materializeDeclaredFields into @objectstack/core, which objectql, plugin-sharing and trigger-record-change all already depend on at runtime, and re-export from objectql for compatibility. That lets all three seams share one copy without promoting any dependency.

Counting the seams for whoever picks this up: objectql has 2 importers (hook-wrappers.ts, validation/rule-validator.ts); this file is copy #2 of the pattern; PR #8483 proposes copy #3.

Related

• #4649 的「记录对已声明字段全量」只落在两个接缝上 —— 另外三处求值仍是稀疏绑定 #4953 — the seam programme and its 2026-08-06 ruling (decision anchor; ⛔ already ruled, do not re-open)
• PR fix(objectql): 字段 readonlyWhen 求值补 materializeDeclaredFields —— 服务端第三个接缝 (#4953) #6454 — the readonlyWhen seam and the !has(...) pin
• PR fix(trigger-record-change): materialize declared fields on the seeded flow record #8483 — the flow-trigger seam, where the same duplication question is live
• validate-null-guards.ts 的接缝台账在 PR #6454 合并后会说假话 —— 字段 readonlyWhen 那行仍写着 "sparse / never materializes" #6458 — the seam-ledger staleness this family keeps producing

Verified by reading share-link-service.ts and both package.json files on main, not by code search alone.

[hotlong]

Triage (first-touch grade): held as finding, routed domain:engine-core (the convergent fix's home is moving materializeDeclaredFields into @objectstack/core with an objectql re-export; consumers then take mechanical import swaps). Hold reason, one line: PR #8483 has the same copy-vs-import question live for copy #3, and its review outcome decides the consolidation shape — grading this before #8483 lands would either duplicate that review's decision or contradict it. Re-grade when #8483 merges: expected promotion to pm:queue as the consolidation card (this card already counts the seams: 2 importers in objectql, copy #2 here, copy #3 proposed there). Blast-radius framing is accepted as stated: fail-closed today, drift-not-breach — graded as debt on a security-relevant gate, ⛔ not as a security hole.

本评论来自分诊座位 Routine。

---

Generated by Claude Code

[hotlong]

Re-grade — the 2026-08-13 hold's restart condition ("re-grade when #8483 merges") resolved, differently than expected: PR #8483 was closed unmerged; its successor PR #8548 (Fixes #8482) merged instead and settled copy #3 the other way — trigger-record-change keeps a deliberate local copy with a byte-level parity test (materialize-declared-fields-parity.test.ts), because objectql is a devDependency there. So the copy-vs-import review outcome now exists, and it does not create a cross-package consolidation programme; what remains is exactly this card's copy #2.

Promoted to pm:queue, re-routed domain:engine-core → domain:identity per the anchoring rule: the fix lands in packages/plugins/plugin-sharing only. Verified on origin/main: materializeDeclaredFields is publicly consumable via @objectstack/objectql/core (re-export at core.ts:77), and plugin-sharing has @objectstack/objectql as a runtime dependency (workspace:*) — so this is a mechanical import swap replacing bindDeclaredFields (share-link-service.ts:122, used at :274). The card's suggested move into @objectstack/core is not prescribed: it would widen core's public surface for a consumer that no longer needs it. Native type Task — behavior converges to the shared declared-fields contract (including the #6454 !has(...) semantics); today's divergence fails closed.

Guard for the implementing dev: if the swap changes an eligibility verdict in a direction that widens acceptance (a link minted that the local copy refused), stop and flag back — that would be a contract-behavior question, not a cleanup.

本评论来自分诊座位 Routine。

---

Generated by Claude Code