Two derivations of "is this object tenant-scoped" disagree on `systemFields: false`: the wall composes its predicate, the platform withholds the index

[os-zhuang]

Filed by the #8459 dev agent, measured while implementing that card's ruling. Unassigned, out of #8459's scope — that card ruled on who declared the column; this is a different axis (which opt-out row was used) and needs its own decision.

The disagreement

Two places answer "is this object tenant-scoped", and they read different declarations:

declaration	resolveInjectedSystemColumns().tenant (spec, drives the index)	plugin-security's tenancyDisabled (drives the wall)
tenancy.enabled: false	withholds	disabled — no wall
systemFields.tenant: false	withholds	disabled — no wall
managedBy: 'better-auth'	withholds	n/a (no org column exists)
systemFields: false	withholds	NOT disabled — wall still applies

security-plugin.ts derives it as exactly two clauses:

const tenancyDisabled =
 (obj as any)?.tenancy?.enabled === false ||
 (obj as any)?.systemFields?.tenant === false;

systemFields: false — the hard object-level opt-out — is not among them. And Layer 0's other gate is objectFields.has('organization_id'), so an object using the hard opt-out while declaring its own organization_id gets the wall predicate AND-composed onto essentially every read, with no platform index behind it.

Measured

applySystemFields(obj, { multiTenant: true }).indexes, on origin/main plus the #8459 change:

systemFields: false + author-declared organization_id => null
systemFields.tenant: false + author-declared organization_id => null
plain object + author-declared organization_id => [{"fields":["organization_id"]}] (#8459)

Row 2 is correct and deliberate: security agrees the object is not walled, so there is no predicate for an index to serve. Row 1 is the disagreement — the only row where the wall filters on a column the platform declines to index. Same "hottest predicate unindexed" shape #8459 closed, reached by a different route, and not introduced by #8459 (it withheld the index for these objects before that change too, via the injected-column condition).

The security half is asserted from the source above, not measured end to end; the objectql half is measured.

The decision this needs

Which derivation is authoritative for systemFields: false?

• A. The wall is right — the author declared a real tenant column, so the object is walled and the index should follow (An author-declared organization_id withholds the platform's tenant index — the wall's hottest predicate runs unindexed on a multi-tenant deployment #8459's ruling logic, one row over). Fix in resolveInjectedSystemColumns' consumer or in the index predicate.
• B. The spec is right — systemFields: false means the object has no platform tenant semantics at all, so plugin-security should treat it as tenancy-disabled and stop composing the predicate. ⚠️ This one narrows a wall, so it is a security-posture change, not a perf fix, and wants its own scrutiny.
• C. Converge both onto one exported predicate regardless of which answer wins, so the two can never drift again. resolveInjectedSystemColumns is already the spec's single derivation and tenancyDisabledCache is a hand-rolled second reading of the same declarations — the [Decision] applySystemFields injects platform anchors into external objects the platform provisions no storage for — three consumers have now independently re-derived "that column is not really there" #7865 convergence map lists exactly this species of duplicate.

A and B differ in observable behaviour, so this is not a pure refactor and should not be self-adjudicated. Note also that they disagree about which side is the defect, which is why no option here is obviously "the fix".

Dedup

Searched: systemFields false hard opt-out tenancyDisabled organization_id tenant wall, tenancyDisabled cache systemFields false not covered security plugin. Zero open neighbours. Nearest related, none a twin: #8459 (whose declaration governs the index), #8323 (tenant-scoped UNIQUE indexes going global — driver DDL normalization), #6810 (moved the tenant index into indexes[]).

Related

#8459 · #8375 · #6810 · #7865 (the convergence map option C would extend) · ADR-0105

---

Generated by Claude Code

[hotlong]

Triage: auto-adjudicated → pm:queue + domain:engine-core; native type Bug. Triage seat Routine, 2026-08-14 ~02:15Z. Analysis run on claude-fable-5; execution is a veto window, not a permission gate — this round's report carries it in the auto-adjudication section.

Ruling: the wall's derivation is authoritative — the index follows the wall (option A, with C's direction as bounded follow-up)

Mechanical boundary test: accept-set and public face unchanged. Reads on the affected objects already carry the wall predicate; the change only makes the platform index materialize where the wall already filters. Repair lane, not feature — eligible for triage adjudication.

Standing meta-rule applied (maintainer-ratified, 2026-08-07 family): one question — "is this object tenant-scoped?" — with two disagreeing implementations ⇒ the governed side (plugin-security's wall) wins by default and the ungoverned side (the index derivation) rebinds to it. Option B is rejected: it narrows a wall, which only an explicit product ruling can do, and none exists.

Consistency: this is #8459's ruling logic one row over — and #8459 merged as PR #8609 at 01:59Z, so the card's serial constraint is already cleared and its measurement table now describes merged main. An author-declared organization_id on a walled object gets the index; systemFields: false + author-declared organization_id is walled today (the card's clause table) ⇒ same conclusion.

Four-prism (all four point the same way — confidence gate ① satisfied):

1. Coherence: removes the last row where wall and index disagree; extends An author-declared organization_id withholds the platform's tenant index — the wall's hottest predicate runs unindexed on a multi-tenant deployment #8459 rather than adding a case.
2. Measured pull: the wall predicate AND-composes onto essentially every read of such an object with no index behind it — the exact "hottest predicate unindexed" condition meta: applySystemFields stamps indexed on organization_id — a key FieldSchema rejects by name, so every registry-backed object read answers _diagnostics: { valid: false } #6810/An author-declared organization_id withholds the platform's tenant index — the wall's hottest predicate runs unindexed on a multi-tenant deployment #8459 exist to prevent.
3. AI error-resistance: two hand-rolled derivations of one predicate is the drift engine; rebinding the index side to the wall's clauses closes it.
4. Scope discipline: no new surface; deletes a special case.

Scope and boundaries for the dev

• Fix in packages/objectql/src/registry.ts (provisionTenantScopeIndex / its tenancy condition): grant the index whenever the wall would apply — i.e. tenancy not disabled by the wall's two clauses AND organization_id present among object fields. Rows 2 and 3 of the card's measurement table must not change; pin all three rows.
• Premise check first (the card flags this itself): the security half is asserted from source, not measured end to end. Verify plugin-security actually composes the wall for systemFields: false + author-declared organization_id before touching the index side. If it does NOT, the premise flips ⇒ stop and report premise_still_valid: false; ⛔ do not silently pick B.
• Option C (single exported predicate, the [Decision] applySystemFields injects platform anchors into external objects the platform provisions no storage for — three consumers have now independently re-derived "that column is not really there" #7865 convergence map): endorsed as direction; in-scope only if it needs no new @objectstack/spec public export and no plugin-security behavior change (the open #7894 lands five new public exports in @objectstack/spec/shared — should the three predicate helpers stay internal? #8424 question governs new spec exports). Otherwise leave it to the map.
• Routing note: sibling An author-declared organization_id withholds the platform's tenant index — the wall's hottest predicate runs unindexed on a multi-tenant deployment #8459 wore domain:metadata; this card's fix file is packages/objectql ⇒ anchoring rule says domain:engine-core. Discrepancy flagged, closed card not retro-relabelled.

Size/model suggestion: M, mode:subagent, model: opus.

Reversal clause: if implementation shows the contract must move after all (accept/reject behavior or public face changes), the dev stops and the card returns to needs-user-decision — never silently re-adjudicated.

---

Generated by Claude Code

[hotlong]

Claim: PM loop round 2
Session: session_01XeQRiAa7vYRVX5Fog7Zby8
Branch: claude/issue-8608-tenant-index-follows-wall
Worktree: objectstack-issue-8608
Domain: domain:engine-core
File surface: packages/objectql/src/registry.ts — provisionTenantScopeIndex (:737) and its call sites (:637, :640) — plus its co-located tests (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: triage noted the card's own serial on #8459 — landed as 0a5dc29 (PR #8609), so the measurement table now describes merged main. Open-PR list re-read at claim time (5 open): the only other objectql PR is #8737, which is already in the merge queue and whose surface is engine.ts, a different file. Sync with main before opening the PR; if #8737 has landed by then, reconcile against it.

Premises re-verified on origin/main before dispatch, both halves of the card's own table:

• index side (the card measured this) — provisionTenantScopeIndex is where the withholding happens, registry.ts:737.
• security side (the card explicitly did NOT measure this — it says so) — I read it: security-plugin.ts:5013 and :5108 both derive tenancyDisabled as exactly tenancy?.enabled === false || systemFields?.tenant === false. systemFields: false is genuinely not among the clauses, so the disagreement the card describes is real in source.

⚠️ That is still source-reading, not an end-to-end measurement, and triage's ruling makes measuring it the first step: verify plugin-security actually composes the wall for systemFields: false + an author-declared organization_id before touching the index side. If it does not, the premise flips ⇒ stop and report premise_still_valid: false; ⛔ do not silently take option B.

⛔ Option C's plugin-security half is out of scope this round even though triage endorsed C as a direction. Triage already bounded it («in-scope only if it needs no new @objectstack/spec public export and no plugin-security behavior change»), and there is now a second reason: #8536 is in flight in packages/plugins/plugin-security. Reading that package to verify the premise is expected and fine; ⛔ editing it is not. If convergence turns out to require a plugin-security change, report it and it becomes its own card.

---

Generated by Claude Code