measure: census the dependents of the SQL driver's orWhereNull tenant-wall carve-out before deciding its future (NULL org_id rows are globally visible on shared-DB walled deployments)

[hotlong]

Filed by the director seat (session local_c32e5a25-0581-4665-952f-60c1be74b250) executing point 5 of the maintainer's 2026-08-31 joint-case ruling on #13491 (verbatim 「同意」): the carve-out below is the AMPLIFIER of the NULL-tenant-row defect class, and the ruling directs it to its own card — ⛔ never a rider on the #13491 implementation. Left ungraded — domain:*/type/priority are triage's.

The carve-out

packages/drivers/driver-sql/src/sql-driver.ts:7320 — the driver's native tenant scope is

(organization_id = :tenantId OR organization_id IS NULL)

a deliberate fail-open so bootstrap-seeded platform rows stay visible to every organization.

Why it needs a census before any design decision

Measured consequences already on record:

• On a shared-DB walled deployment, ANY row that lands organization_id = NULL in a tenant-scoped table is readable by every organization. cloud#1232 measured real cross-tenant reads through exactly this branch; cloud#1239 repaired two objects (sys_package_installation, sys_environment_credential — a credentials table) by adding scope rules ABOVE the driver, leaving the carve-out itself intact.
• design: isSystem 写入是否在租户审计控制范围内?——#13178 类级装置(A/B/C)的共同前置,从未被裁过 #13491's option-C ruling closes the biggest NULL-row PRODUCER (isSystem writes on tenant-scoped platform-namespace objects), which shrinks — but does not empty — the population this branch exposes: rows already written, application-object sites still unrepaired (tenant-audit: the "write without tenantId" signal is a throttled log warn gated on multi-tenant posture, so it cannot fire in any environment where code is exercised #13178 family, p1), and any future unstamped writer.

Task (measure first, then design)

1. Census the legitimate dependents of NULL-row visibility: bootstrap seeds, Layer-0 environment-scoped metadata (sys_metadata reads fall back to the NULL layer BY DESIGN — see cloud apps/objectos-ee/objectstack.config.ts walled-posture notes), and any other read path that would break if NULL rows stopped being globally visible.
2. Classify by object: for which objects is NULL-visibility load-bearing (metadata fallback) vs. accidental (tenant-scoped tables whose writers failed to stamp)?
3. With the census in hand, bring the design options back through the decision inbox — sketch: (a) keep the carve-out, rely on per-object scope rules above the driver (cloud#1239 pattern); (b) narrow the carve-out to declared-global objects only; (c) posture-dependent behaviour. Each option moves published contract semantics on a security boundary ⇒ maintainer floor, clause-② posture to be judged at claim time.

Refs: #13491 (ruling, point 5) · #13497 (measurement) · #13178 (repair family) · cloud#1232 · cloud#1239.

[os-warren]

Triage → domain:engine · p1 · security.

Anchoring. The carve-out is packages/drivers/driver-sql/src/sql-driver.ts:7320; packages/drivers/driver-* is domain:engine after the 2026-08-19 lane merge. The census also reads Layer-0 sys_metadata fallback paths (packages/metadata* — same lane) and cloud-side config as evidence, not as fix sites. Single lane.

Grade p1. Not for the census itself but for what it is a census of: cloud#1232 measured real cross-tenant reads through this exact organization_id IS NULL branch, and cloud#1239's repair list includes sys_environment_credential — a credentials table. Held at p1 rather than p0 because the acute instances were repaired above the driver and #13491's option-C ruling closes the largest producer; what remains is a population that shrinks but does not empty (rows already written, unrepaired application-object sites in the #13178 family, and any future unstamped writer).

Dispatch shape — this card is a measurement, and its output is a document, not a diff.

⛔ No code change lands under this card. The ruling directs the design options back through the decision inbox with the census in hand, and states plainly that each option moves published contract semantics on a security boundary ⇒ maintainer floor. A dev who arrives here and starts narrowing the orWhereNull has skipped the entire point.

The two questions the census must answer, in the ruling's own division:

1. Which dependents are load-bearing? Bootstrap seeds and Layer-0 environment-scoped metadata fall back to the NULL layer by design — that is a feature, not a leak.
2. Which are accidental? Tenant-scoped tables whose writers simply failed to stamp organization_id.

⚠️ The whole value of the card is in keeping those two apart. A census that returns one list is not usable — the design options (a) per-object scope rules above the driver, (b) narrow to declared-global objects, (c) posture-dependent behaviour, all turn on exactly which objects sit in which bucket.

⛔ Never a rider on #13491's implementation. The ruling says this explicitly (point 5) and the reason is worth restating: #13491 closes a producer, this card is about the amplifier. Folding them would let a contract-semantics change on a security boundary ride in under a card that was ruled for something else.

⚠️ Clause-② posture is judged at claim time, not now — the census itself touches no contract; whichever design option is later chosen probably does.

Refs to read before starting: #13491 (the ruling, point 5) · #13497 (the measurement) · #13178 (the repair family) · cloud#1232 (the measured cross-tenant reads) · cloud#1239 (the two-object repair, and the reason it left the carve-out intact).

---

Generated by Claude Code

[zhuangjianguo]

CLAIMED + dispatch order — #13564

• Session: session_01F3jdziLbAPGeceVNmSox5L · Branch: claude/issue-13564-orwherenull-dependent-census · Worktree: ../objectstack-13564-orwherenull-census, off origin/main
• Labels: pm:queue → pm:dispatched
• Clause ②: does NOT fire. ⛔ Because nothing ships. The census touches no contract because it touches no code. ⚠️ Whichever design option is later chosen almost certainly does fire — that is a future card's problem, not yours, and reaching for it is STOP condition 1.

---

Zone 1 — binding. ⛔ NOT re-adjudicable.

⛔⛔ THE SINGLE MOST IMPORTANT LINE IN THIS ORDER: no code change lands under this card. Your deliverable is a DOCUMENT, not a diff.

Maintainer ruling, point 5 of the 2026-08-31 joint-case ruling on #13491 (verbatim 「同意」), as recorded on this card and by triage:

the carve-out below is the AMPLIFIER of the NULL-tenant-row defect class, and the ruling directs it to its own card — ⛔ never a rider on the #13491 implementation.

With the census in hand, bring the design options back through the decision inbox … Each option moves published contract semantics on a security boundary ⇒ maintainer floor.

1.1 — ⛔ Do NOT narrow, touch, or "improve" the orWhereNull carve-out. Triage says it plainly: "A dev who arrives here and starts narrowing the orWhereNull has skipped the entire point." The carve-out is deliberate fail-open behaviour on a security boundary with a maintainer floor above it.

1.2 — ⭐ The census MUST return TWO separated lists, not one. This is the card's entire value, and a merged list is a failed deliverable:

1. Load-bearing — NULL-visibility is by design. Bootstrap seeds; Layer-0 environment-scoped metadata (sys_metadata reads fall back to the NULL layer deliberately).
2. Accidental — tenant-scoped tables whose writers simply failed to stamp organization_id.

The three design options (per-object scope rules above the driver / narrow to declared-global objects / posture-dependent behaviour) each turn on exactly which object sits in which bucket. A census that cannot place an object must say so and put it in a third UNDETERMINED list — ⛔ never guess it into a bucket to make the table look complete.

1.3 — ⛔ cloud and objectos are OUT OF REACH in this session, and you must say so rather than paper over it. The card and triage both cite cloud#1232, cloud#1239, and cloud apps/objectos-ee/objectstack.config.ts as evidence. This session's repository scope is objectstack-ai/objectstack and objectstack-ai/objectui only. ⚠️ Those cloud references are precisely where walled-posture host configuration lives, so this is a material gap in the census, not a footnote. Declare it as NOT MEASURED, name what you could not read, and state what the missing evidence would have decided. ⛔ Never restate a cloud claim from the card as if you had verified it.

1.4 — Not a fix site. packages/metadata* and cloud-side config are read as evidence. ⛔ Nothing there gets edited either.

---

Zone 2 — PM mechanism assumptions. Measure these; ⭐ falsifying one is a reportable success.

A2.1 — "The carve-out is at sql-driver.ts:7320." ⛔ Re-find it by quoted source, never by line number. sql-driver.ts is one of the largest files in the repo and main has moved since filing. Report the drift. ⚠️ Prior cards in this lane cited both a stale line and an outright wrong file, so confirm the symbol's home, not just its offset.

A2.2 — ⭐ THE ONE MOST LIKELY TO BREAK. "The two buckets can be separated mechanically." My assumption is that running the tenancy resolver over every object declaration yields the split. I expect this to be at best half true. "Is NULL-visibility load-bearing for this object?" is a question about intent and read paths, and a resolver answers a question about declarations. Falsifiable and valuable either way: if a mechanical rule does separate them, say what the rule is; if it does not, say which objects needed a human reading and why. ⚠️ A census that silently substitutes the mechanical answer for the semantic one produces a confident, wrong table — the worst possible output here.

A2.3 — "Layer-0 sys_metadata NULL fallback is by design." The card asserts it. Verify it in-tree (packages/metadata*) rather than inheriting it — it is the anchor member of the load-bearing bucket, and if it is wrong the whole first list is wrong.

A2.4 — "#13491's option-C repair has landed, so the producer population is already shrinking." ⛔ Verify by content on origin/main, never by a merged boolean. The remaining-population estimate depends on it, and so does whether the accidental bucket is a snapshot or a moving target.

---

Zone 3 — advisory, not binding

• Deliverable shape: a comment on this card carrying the two (or three) lists, per-object, with counts, the method that produced them, and the ⭐ positive control. ⛔ A count with no firing control is not a measurement — if your scan returns zero of something, prove the scan can return non-zero.
• Population matters as much as the lists: say how many object declarations you read, how many you could not, and why. An unread declaration is a hole in a security census.
• ⚠️ sys_environment_credential is a credentials table and was one of cloud#1239's two repairs. Whatever bucket it lands in, say so explicitly — a reviewer will look for it first.
• ⛔ Never edit content/docs/releases/.

STOP conditions

1. You find yourself editing driver behaviour, a scope rule, or any object declaration. That is not this card. Report instead.
2. The load-bearing / accidental split cannot be made from in-repo evidence alone — report the gap with the specific objects it blocks (this is an expected outcome given 1.3, ⛔ not a failure).
3. Any other open PR claims your paths. Verify BEFORE your first read-heavy pass. ⚠️ Three sibling seats are live: The undeclared-field door sits in FRONT of the hooks, so a key a beforeInsert hook writes has no door at all — and the drivers then disagree (memory stores it, SQL throws a raw statement error) #13657 (packages/objectql insert/update ↔ hook seam), datasource DELETE does not evict the stuck driver from the data-engine driver registry — /ready keeps naming a datasource that no longer exists, recoverable only by process restart #13578 (data-engine driver registry / datasource delete), [finding] If-Match: "" silently DISABLES optimistic concurrency — a quoted-empty entity-tag is read as "no token" and the guarded write proceeds unguarded #13576 (packages/metadata-protocol OCC token ingress). ⚠️ datasource DELETE does not evict the stuck driver from the data-engine driver registry — /ready keeps naming a datasource that no longer exists, recoverable only by process restart #13578 is the nearest — it works the driver registry while you read packages/drivers/driver-sql. You are read-only, so a true conflict is unlikely; if you find yourself wanting to write anything there, that is STOP condition 1 firing.

Verification expected

The A2.1 re-located needle with drift reported; the two-or-three separated lists with per-object reasoning; the population figures; the firing positive control; the A2.3 and A2.4 verdicts measured rather than inherited; and an explicit NOT MEASURED section naming the cloud/objectos gap and what it would have decided. ⛔ No PR, no branch push of code, no changeset — if you believe a diff is needed, that belief is STOP condition 1. ⛔ Report anything unmeasured as NOT MEASURED, never as a pass.

---

Generated by Claude Code

[zhuangjianguo]

Census: dependents of the orWhereNull tenant-wall carve-out

Session session_01F3jdziLbAPGeceVNmSox5L · branch claude/issue-13564-orwherenull-dependent-census (scratch only — no code changed, no PR opened, per Zone 1 of the dispatch order). Measured against objectstack-ai/objectstack@00d8f6541bb9030f2e339c79320af4c5d49de406 (origin/main, 2026-08-31 13:55 UTC). objectstack-ai/objectui was checked and contributes zero object declarations or driver code to this census (confirmed by repo-wide scan, see Method).

A2.1 — the carve-out, re-found by content (line 7320 is stale)

Not at sql-driver.ts:7320. That line now sits inside unrelated upsert conflict-merge/rotation-shard logic. The real location:

• File: packages/drivers/driver-sql/src/sql-driver.ts (confirmed correct — no wrong-file drift this time)
• Method: protected applyTenantScope(builder, object, options), declared at line 11897
• The carve-out itself: line 11933, void b.where(field, String(tenantId)).orWhereNull(field);
• Drift: ~4600 lines (the file is 16,788 lines total, one of the largest in the repo, exactly as the dispatch order warned)

Its resolver gate is protected resolveTenantField(object) (line 11821), backed by protected computeTenantField(schema) (line 9074). An object only reaches the carve-out at all if computeTenantField resolves a non-null field — precedence: (1) tenancy.enabled === false → excluded entirely, no scoping of any kind; (2) declared tenancy.tenantField; (3) implicit organization_id column presence.

A2.2 — mechanical vs. semantic: half true, and the half that breaks is instructive

What the mechanical resolver gets right: it correctly tells you which objects the carve-out even applies to. That population is bigger than a naive grep suggests — organization_id is auto-injected unconditionally by applySystemFields/resolveInjectedSystemColumns (packages/objectql/src/registry.ts) into every managed object schema except managedBy: 'better-auth' tables and objects with an explicit opt-out (tenancy.enabled: false or systemFields.tenant === false). A file-level grep for an explicit organization_id: field found only 21 of 112 declarations; the true "subject to the carve-out" population is 59 of the 84 platform-namespace objects (see population table) plus effectively all 28 non-platform example/template objects — because the column exists whether or not the author typed it.

What the mechanical resolver gets wrong — falsified concretely on sys_metadata, the load-bearing anchor itself: sys_metadata's primary overlay-fallback read path (SysMetadataRepository.get, and ObjectStackProtocolImplementation.getMetaItem in packages/metadata-protocol/src/protocol.ts) does not rely on the driver's orWhereNull mechanism at all. It calls this.engine.findOne('sys_metadata', { where: { organization_id: oid, ... } }) with an exact-equality where clause and never threads tenantId into DriverOptions (grepped every call site in sys-metadata-repository.ts: zero tenantId occurrences, only context for transactions). The org→null fallback is implemented as an explicit two-step application-level query — findOverlay(orgId) then findOverlay(null) — documented in protocol.ts right at the call site: "Per ADR-0005 (revised), org-scoped row wins; env-wide (organization_id IS NULL) row is the fallback before falling through to the in-memory registry." Since the driver's applyTenantScope early-returns unchanged whenever tenantId is undefined, the SQL driver carve-out never fires on this path.

So: mechanically, sys_metadata is swept into "has a tenant column, therefore a carve-out dependent." Semantically, its primary read path turns out to be independent of that specific mechanism — it has its own app-level fallback. This is exactly the two-different-questions gap the dispatch order predicted. It does not mean sys_metadata is safe to exclude from the load-bearing list — NULL-org rows there are still genuinely load-bearing by design (see A2.3) — it means which mechanism is load-bearing differs from what the driver-level framing assumes, and design option (b) ("narrow the carve-out to declared-global objects") would need to know this per read path, not per object. I found 10+ additional find('sys_metadata', …) call sites outside the specialized repository (protocol.ts elsewhere, packages/objectql/src/plugin.ts, packages/cli/src/utils/secret-reference-union.ts, packages/core/src/fallbacks/authored-translation-sync.ts) that I did not individually trace for whether they pass tenantId — so I cannot say the driver carve-out is irrelevant to sys_metadata altogether, only that its best-known, most-important path doesn't use it.

A second mechanical/semantic split, found independently: the driver's own rationale comment for the carve-out names "bootstrap-seeded platform rows (positions and permission sets, business units, pre-org first-boot seeds)" as the motivating example — but the #13491 per-object ledger (below) has formally ruled only one of that family (sys_permission_set) global. sys_position, sys_business_unit, sys_business_unit_member, sys_user_position, sys_position_permission_set, sys_user_permission_set, sys_capability all carry the tenant column, all fit the driver's own stated rationale, and none has been individually adjudicated. Flagged as split-verdict UNDETERMINED below rather than guessed onto the load-bearing list.

A2.3 — Layer-0 sys_metadata NULL fallback: verified in-tree, confirmed by design

Confirmed independently of the issue's own claim, via packages/metadata-core/src/meta-write-org-scope.ts (write side) and packages/metadata-protocol/src/protocol.ts::getMetaItem (read side):

• Cold boot (loadMetaFromDb) hydrates organization_id IS NULL rows only — that is the ADR-0005 design for platform-built-in metadata.
• 5 metadata types are per-org overridable (DEFAULT_METADATA_TYPE_REGISTRY, allowOrgOverride: true): view, dashboard, report, translation, email_template. For these, an org-scoped write lands org-scoped; every other type's write is deliberately kept env-wide (organizationIdForMetaWrite) specifically so it survives the next restart, per the runtime: thread the session's organization into saveMetaItem only for types declaring allowOrgOverride — the #6190 ruling's runtime half, lands FIRST #7018 defect this module closes.
• sys_view_definition independently confirms the same design in its own code comment: "organization_id is NULL for environment-level [views]."

A2.3 stands: the first list's anchor is correctly placed, with the read-mechanism nuance from A2.2 above.

A2.4 — #13491's option-C repair: landed, verified by content

packages/objectql/src/tenancy/platform-object-tenancy.ts exists on origin/main, is imported into engine.ts:138, and isPlatformObjectOutOfTenantAuditScope is actually called at engine.ts:3582 and engine.ts:3801 (not just defined). .changeset/tenant-audit-scope-by-object-classification.md is present and matches. This is not a merged boolean — it's live code, wired in.

This repair turned out to be the single most useful artifact for this census. It is a per-object, human-adjudicated tenancy ledger for the platform namespace, built for a closely related but distinct question (should an isSystem write to this object bypass the tenant-audit control?), with exactly the three-way verdict shape this card's dispatch order asked for: tenant-scoped (in scope — org-less row is a defect), global (out of scope — org-less row is by design), unclassified (pending adjudication, listed rather than guessed — the ledger's own header quotes the ruling: "判不了的逐个列出回批呈裁，⛔ 不猜"). I am reusing it as primary evidence for the read-side question this card asks, with the caveat stated above (write-defect-scope ≠ read-fallback-load-bearing; they usually coincide but I did not assume it — sys_metadata is the concrete case where the mapping needed a second look).

The ledger's own docstring states its AST census counted 84 platform-namespace objects registered in this repository and 59 carrying a tenant column. Both numbers reconcile exactly against my independent file-level census below.

---

Population

	count
.object.ts declarations found repo-wide (objectstack, non-test)	112
— platform-namespace (sys_*) objects	84
— non-platform (example apps / templates / qa fixtures)	28
objectui object declarations	0 (confirmed, see Method)
Platform objects excluded from the carve-out entirely (resolveTenantField → null)	25
Platform objects subject to the carve-out (resolveTenantField → organization_id)	59
— ledger-adjudicated tenant-scoped (Accidental bucket)	7
— ledger-adjudicated global (Load-bearing bucket)	1
— ledger unclassified (Undetermined)	51

All four platform sub-numbers (84 / 25 / 59 / 7+1+51) were computed independently from the raw object files and then cross-checked against the ledger's own stated counts — they match exactly.

---

LOAD-BEARING (NULL-visibility is by design) — confirmed only

Object	Evidence
sys_permission_set	#13491 ledger, global. Maintainer named this object verbatim in the 2026-08-31 ruling as the case #8672's reasoning inherits from. Caveat the ledger itself states: this object also holds legitimately org-scoped rows — the verdict rests on the maintainer naming it, not on an absence of org-scoped writes.
sys_metadata	ADR-0005 platform-default overlay layer, confirmed in meta-write-org-scope.ts + protocol.ts. Mechanism nuance (A2.2): its primary read path does not exercise the SQL driver's orWhereNull — see above.
sys_view_definition	Object's own code comment: NULL organization_id = environment-level view, by design.

ACCIDENTAL (tenant-scoped tables whose writers failed to stamp) — confirmed only

Object	Evidence (all via #13491 ledger, each independently citable)
sys_file	Writer repaired (StorageMetadataStore.createFile); backfilled 2026-08-28.
sys_upload_session	Writer stamps on insert + update; pre-repair rows ruled FORWARD-STAMP-ONLY.
sys_approval_request	Writer repaired (PR #11311); backfilled 2026-08-23.
sys_approval_action	Child row of sys_approval_request; same backfill.
sys_approval_approver	Child row of sys_approval_request; same backfill.
sys_automation_run	Writer stamps via recordOrgResolver.organizationOf.
sys_notification_delivery	Writer stamps via messaging-service.ts#notificationOrganization.

Presumptive, lower confidence — 28 non-platform example/template/qa objects (examples/app-crm, examples/app-showcase, examples/app-todo, packages/create-objectstack blank template, packages/qa/downstream-contract). None declares organization_id explicitly and none opts out, so all 28 get it auto-injected the same way platform objects do. No design rationale for global visibility exists anywhere in-tree for any of them, and the driver's own carve-out rationale names only platform/bootstrap rows as legitimate. Unlike the 7 platform entries above, none of these 28 has a citable writer-repair fact in this repo (they are demo/fixture data, outside #13491's platform-namespace scope, so the ledger says nothing about them) — flagged as accidental by default reasoning, not by confirmed writer evidence.

UNDETERMINED — 51 platform objects, ledger unclassified (pending maintainer adjudication)

Per the ledger's own discipline, not guessed. Three sub-groups, differently evidenced:

Split-verdict (7) — the driver's own carve-out rationale names this exact family as the motivating example, but only their sibling sys_permission_set has been ruled:
sys_position, sys_business_unit, sys_business_unit_member, sys_user_position, sys_position_permission_set, sys_user_permission_set, sys_capability

Structural siblings of confirmed-load-bearing sys_metadata (3) — same audit/version-history family, not independently read-path-verified:
sys_metadata_audit, sys_metadata_commit, sys_metadata_history

Not individually examined in this census (39):
sys_activity, sys_approval_delegation, sys_approval_token, sys_attachment, sys_audience_binding_suggestion, sys_audit_log, sys_comment, sys_email, sys_email_template, sys_flow_dispatch, sys_http_delivery, sys_import_job, sys_inbox_message, sys_invitation, sys_job, sys_job_queue, sys_job_run, sys_member, sys_metadata_activation, sys_migration, sys_migration_journal, sys_notification, sys_notification_preference, sys_notification_receipt, sys_notification_subscription, sys_notification_template, sys_presence, sys_record_share, sys_report_schedule, sys_saved_report, sys_scim_connection_credential, sys_secret, sys_setting, sys_setting_audit, sys_share_link, sys_sharing_rule, sys_team, sys_user_preference, sys_webhook

NOT SUBJECT to the carve-out (25) — a third bucket, neither load-bearing nor accidental

resolveTenantField resolves null, so applyTenantScope returns the builder unchanged: no scoping of any kind, not even the OR-NULL merge — full unconditional visibility regardless of organization_id's value. Different exposure shape than the carve-out; worth the design options knowing about since it is NOT fixed by narrowing or removing the driver's orWhereNull.

• 24 managedBy: 'better-auth' objects with no explicit organization_id field: sys_account, sys_api_key, sys_device_code, sys_jwks, sys_oauth_access_token, sys_oauth_application, sys_oauth_client_assertion, sys_oauth_client_resource, sys_oauth_consent, sys_oauth_refresh_token, sys_oauth_resource, sys_organization, sys_scim_connection_binding, sys_scim_group, sys_scim_group_member, sys_scim_identity_tombstone, sys_scim_projection_grant, sys_scim_subject, sys_scim_user, sys_session, sys_team_member, sys_two_factor, sys_user, sys_verification
• 1 explicit opt-out despite carrying the field: sys_sso_provider (tenancy: { enabled: false }, on top of managedBy: 'better-auth')

⚠️ sys_environment_credential — a credentials table, explicitly called out by triage as something a reviewer will look for — does not appear in any of these buckets, because it is not declared anywhere in this repository or in objectui at all. See NOT MEASURED.

---

Method

1. Located the carve-out and its resolver by grepping orWhereNull/resolveTenantField/computeTenantField in sql-driver.ts at origin/main, read in full context (not by the issue's cited line).
2. Traced the column-injection layer (applySystemFields/resolveInjectedSystemColumns, packages/objectql/src/registry.ts) to establish the TRUE mechanical population — a field-presence grep alone undercounts by ~3x because the column is usually injected, not declared.
3. Enumerated every *.object.ts file at origin/main repo-wide (git ls-tree -r, 112 files), dumped each via git show origin/main:<path> (no working-tree edits, no worktree needed — read-only), and regex-scanned each for name, explicit organization_id field, tenancy block, tenancy.enabled: false, managedBy, systemFields.
4. Cross-validated the platform-namespace count (84) and tenant-column count (59) against two independent in-tree authorities: packages/spec/src/system/constants/platform-object-names.ts (the canonical name registry) and packages/objectql/src/tenancy/platform-object-tenancy.ts (the design: isSystem 写入是否在租户审计控制范围内?——#13178 类级装置(A/B/C)的共同前置,从未被裁过 #13491 per-object ledger) — both reconcile exactly with the independent file scan.
5. Read the ledger's 7 tenant-scoped and 1 global entries in full for their cited evidence; did not re-verify each cited writer repair's own source file (e.g. metadata-store.ts, approval-service.ts) byte-for-byte — trusted the ledger's own citations as the design: isSystem 写入是否在租户审计控制范围内?——#13178 类级装置(A/B/C)的共同前置,从未被裁过 #13491 ruling's own evidentiary bar.
6. For sys_metadata specifically, read meta-write-org-scope.ts, sys-metadata-repository.ts (grepped every tenantId/context occurrence, zero tenantId), and protocol.ts::getMetaItem in full, because it is this card's named anchor and deserved the deepest read.
7. Checked objectui for object declarations (git ls-tree -r origin/main | grep '\.object\.ts$' → 0 results) and for driver/carve-out code (git grep 'orWhereNull\|organization_id' → UI-layer field-display/filter code only, no data-layer mechanism) — confirmed out of scope for this census's substance, not merely unexamined.
8. Attempted to resolve #13178, cited repeatedly by the issue and by triage as "the repair family" / "the tenant-audit: the "write without tenantId" signal is a throttled log warn gated on multi-tenant posture, so it cannot fire in any environment where code is exercised #13178 census" — 404s in both objectstack-ai/objectstack and objectstack-ai/objectui (verified via GitHub API, not a page-render fluke). The design: isSystem 写入是否在租户审计控制范围内?——#13178 类级装置(A/B/C)的共同前置,从未被裁过 #13491 changeset's own prose clarifies this is not a missing/renumbered issue but an AST census whose results are platform-object-tenancy.ts itself ("the tenant-audit: the "write without tenantId" signal is a throttled log warn gated on multi-tenant posture, so it cannot fire in any environment where code is exercised #13178 census measured 135 of 175 write call sites... 77% silenced") — so the reference resolves to a concrete artifact even though the issue number does not resolve to a GitHub issue in either in-scope repo.

Positive control

The methodology is proven to return non-zero, repeatedly, on the same searches it also returns zero on elsewhere:

• tenancy.enabled: false grep: 0 hits in objectui (expected — no object files at all) vs. 2 hits in objectstack (sys_api_key, sys_sso_provider) — same pattern, same tool, different repos, non-zero where expected.
• managedBy: 'better-auth' grep: 28 hits (non-zero, large).
• .object.ts file enumeration: 112 in objectstack vs. 0 in objectui — same git ls-tree command, different repos; the zero is a real absence, not a broken query (the same command found 112 files one repo over).
• The ledger cross-check is itself a control: an independently computed 84/25/59 was checked against the ledger's own stated 84/25(implied)/59 and matched exactly — if my scan methodology were systematically wrong, this match would be a very unlikely coincidence.

---

NOT MEASURED

Per the dispatch order's Zone 1.3 — cloud and objectos are out of reach in this session. This is a material gap, not a footnote:

1. sys_environment_credential — a credentials table, one of cloud#1239's two repairs, explicitly flagged by triage as something "a reviewer will look for first." Not declared anywhere in objectstack or objectui — not in platform-object-names.ts's CLOUD_PROVIDED_OBJECT_NAMES list (which names only sys_app, sys_environment, sys_environment_member, sys_package, sys_package_installation), not as any .object.ts file. Its schema, its tenancy declaration, and whether it even carries an organization_id column at all are entirely unverifiable from this session. What the missing evidence would decide: whether it belongs in the load-bearing or accidental bucket at all, or in the "not subject to the carve-out" bucket (an intentionally-unwalled credential shape, matching the pattern this repo's own sql-driver-tenant-scope.test.ts tests generically as 'the unwalled credential-table shape') — cannot be told apart without reading the cloud-side object declaration.
2. sys_license — cited repeatedly in this repo's own tests and driver doc comments (ADR-0066, #2734) as the canonical example of the opt-out pattern (tenancy: { enabled: false }), and used throughout sql-driver-tenant-scope.test.ts, memory-tenancy-guard.test.ts, engine.test.ts, security-plugin.test.ts as a live fixture. It does not appear in platform-object-names.ts at all (neither PLATFORM_OBJECTS_BY_PACKAGE nor CLOUD_PROVIDED_OBJECT_NAMES), and there is no .object.ts file for it anywhere in this repo. The pattern it illustrates is real and tested; its own existence as a declared object is unverifiable in-scope — it may be a cloud-only object never added to the registry, or a stale/aspirational example. Flagging the registry gap itself as a finding, not just the missing evidence.
3. sys_package_installation — named in CLOUD_PROVIDED_OBJECT_NAMES (so its existence in cloud is at least acknowledged here), one of cloud#1239's two repairs. Its actual schema, tenancy declaration, and whether the repair "added scope rules ABOVE the driver" (per the issue's own description) is unverifiable from this repo.
4. Walled-posture host configuration (cloud apps/objectos-ee/objectstack.config.ts) — entirely unreachable. What it would decide: which OS_TENANCY_POSTURE (isolated/group/single) real walled deployments actually run, whether cloud applies its own scope rules above the driver for objects beyond the two cloud#1239 repaired, and therefore whether the "accidental" population this census found (7 confirmed + 28 presumptive + 51 undetermined, all in-repo) is fully exposed on a real walled deployment or partially covered by cloud-side mitigations this repo cannot see.
5. cloud#1232 and cloud#1239 themselves — cited by the issue and by triage as measured fact ("cloud#1232 measured real cross-tenant reads"). Not independently re-verified in this session; restated here only as attributed claims from the card, never presented as verified by this census.
6. #13178 as a GitHub issue — 404s in both in-scope repos (see Method item 8). The census it apparently refers to survives as platform-object-tenancy.ts's own docstring prose, which I did read and cite, but the original issue's full text/discussion (if it exists in cloud, or was deleted) is unreachable.
7. ~10 additional sys_metadata read call sites outside the specialized SysMetadataRepository/protocol.ts::getMetaItem path (found in protocol.ts elsewhere, packages/objectql/src/plugin.ts, packages/cli/src/utils/secret-reference-union.ts, packages/core/src/fallbacks/authored-translation-sync.ts) — not individually traced for whether they pass tenantId into DriverOptions. Whether the driver's orWhereNull carve-out is exercised by any of them is undetermined.
8. 39 platform-namespace objects in the UNDETERMINED list's third sub-group — read only far enough to confirm they carry the tenant column and are ledger-unclassified; not individually read for design intent or writer behaviour.
9. Actual live row populations — this census read declarations and code paths only; no database, no boot, no runtime available in this session. Whether any given walled deployment today actually holds NULL-org rows in the accidental-bucket tables, and how many, is unmeasured.

---

Generated by Claude Code

---

Generated by Claude Code