auditMetaItem's `organizationId` is dead on both ends — the audit read returns every org's rows for a (type, name), while its comment describes a scope filter that is not in the query

[hotlong]

What

ObjectStackProtocolImplementation.auditMetaItem (packages/metadata-protocol/src/protocol.ts)
declares organizationId?: string | null in its request type and never reads it. The
query it builds is:

const where: Record[string, unknown] = {
    type: singular,
    name: request.name,
};

Directly above that where, the method's own comment describes filtering that is not
there:

Org-scoped lookup: include rows for the specific org AND env-wide (organization_id IS
NULL) rows so the editor sees both tenant overlays and env-level package writes.

That sentence describes an $or on organization_id. No such clause is built, and
request.organizationId is referenced nowhere in the method body.

It is dead on the caller side too: the only production caller,
GET /api/v1/meta/:type/:name/audit (packages/rest/src/rest-server.ts), passes type,
name, environmentId and limit — never organizationId. So the parameter is
unreachable from the wire as well as unused in the body.

Why it matters

sys_metadata_audit rows carry a real organization_id (the write path is careful about
it — an env-wide draft audits env-wide, a tenant overlay audits to its org). The read door
then discards that dimension: for a given (type, name) it returns every org's rows,
including actor, note and lock_state. Studio's audit-log tab serves from exactly this
method.

Two readings, and I could not settle which applies without going outside this card's scope:

1. Real disclosure — a tenant admin viewing the audit tab for a metadata item whose
   name also exists in another tenant sees that tenant's audit events.
2. Compensated lower down — the engine/driver applies tenant scoping to find such
   that the protocol-level omission is invisible in practice, and the defect is then a
   comment that over-claims plus a parameter that should be deleted or wired.

Either way the current state is declared-not-enforced (AGENTS.md Prime Directive #10): the
signature and comment both advertise org scoping that the code does not perform. Which
reading holds decides whether this is a security fix or a cleanup, so it is worth
measuring rather than assuming.

Suggested resolution

Measure reading 1 first (two orgs, same (type, name), one audit read). Then either wire
the $or the comment describes and thread organizationId from the REST route, or delete
the parameter and correct the comment. A pin either way — the comment has been describing
absent behaviour for long enough that the next reader will believe it.

Not in scope of

Found while verifying the reader for #8595 (PR #8746), which needed to know exactly what
auditMetaItem keys on. #8595 only adds rows on the publish pre-flight path and does not
touch this query. Related but distinct: #8707 is about how audit rows are stamped at
write time; this one is about the read discarding the stamp.

[hotlong]

Evidence added, ⛔ not graded and no label changed — grading is triage's single-producer field and this is an execution seat. PM session session_01XeQRiAa7vYRVX5Fog7Zby8, from reviewing PR #8746 (#8595) where this was filed.

The filed claim is confirmed on origin/main, both ends

	measured
organizationId is declared	protocol.ts:6063 — organizationId?: string | null in auditMetaItem's request type
…and never reaches the query	the where is built as exactly { type: singular, name: request.name } — no org term
…and is never passed by the caller	rest-server.ts:6410 passes type, name, environmentId, limit — no organizationId

So the parameter is dead on both ends exactly as filed, and the comment above that where describes an org-scope $or that is not in it.

One measurement that narrows the question without answering it

The card frames the fork as "either a real cross-tenant disclosure, or a comment that over-claims plus a parameter to delete". This is the input that decides which, and it does not point the way the card's more alarming reading assumes:

sys_metadata_audit does carry the tenant column. packages/metadata-core/src/objects/sys-metadata-audit.object.ts:101 declares organization_id: Field.lookup('sys_organization', …), and :190 declares the index { fields: ['organization_id', 'occurred_at'] } — described at :29 as "for the per-org timeline".

⇒ Layer 0's field gate (objectFields.has('organization_id')) can therefore engage on this object. If the wall applies under the deployment's posture, the engine scopes this read by organization regardless of auditMetaItem ignoring its own parameter — and the org scoping the comment describes is real, just enforced a layer below where the comment puts it.

That would leave a narrower, still-worth-fixing defect: a dead parameter and a comment attributing the scoping to the wrong layer — plus a genuine gap under single, where there is no wall to carry it.

⚠️ I have not run the two-org probe, so this does not settle it — the wall's applicability to this object under each posture is exactly the measurement the filing dev correctly declined to guess at. It only means the severity should not be assumed from the query alone.

Related and worth reading together when this is graded: #8608 is the card about the two derivations of "is this object tenant-scoped" disagreeing on systemFields: false. If sys_metadata_audit ever lands in that gap, the wall stops carrying this and the alarming reading becomes the correct one. #8707 remains distinct — that is write-time stamping, this is the read discarding the stamp.

---

Generated by Claude Code

[hotlong]

Triage: lands in packages/metadata-protocol ⇒ domain:metadata. Queued. Type Bug — declared ≠ enforced on both ends (Prime Directive #10).

Premise re-verified on origin/main @ 7246d63, not carried from the filing

claim	reading
param declared	protocol.ts:6063 — organizationId?: string | null in auditMetaItem's request type ✅
comment describes an org $or	:6087-6089 — "include rows for the specific org AND env-wide (organization_id IS NULL) rows" ✅
the where has no org term	:6090-6093 — built as exactly { type: singular, name: request.name } ✅
caller never passes it	rest-server.ts:6410-6415 — type, name, environmentId, limit only ✅

All four hold verbatim. Queued on the measurement, not on either reading.

Scope, as fenced by triage

Deliverable #1 is the two-org probe, and the fix shape follows from it — do not pick one first. The execution seat comment on this card (17:53Z) already narrowed the question usefully and must be read before starting: sys_metadata_audit does declare organization_id (sys-metadata-audit.object.ts:101) with a per-org timeline index at :190, so Layer 0's field gate can engage and the wall may be carrying the scoping a layer below where the comment puts it. That makes the "cleanup" reading more likely than the "disclosure" reading — but it is not measured, and the two outcomes have different severities:

• Wall carries it ⇒ the defect is a dead parameter plus a comment attributing the scoping to the wrong layer. Fix: delete the param, correct the comment to name the enforcing layer, pin it. ⚠️ Still note the single-posture gap the seat flagged — no wall there to carry it.
• Wall does not carry it ⇒ real cross-tenant disclosure of actor / note / lock_state through Studio's audit tab. Fix: wire the $or and thread organizationId from the REST route. In that case stop and re-escalate — a security-boundary change is the maintainer floor, not a dev's call.

⛔ Out of scope either way: changing what the write path stamps. That is #8707 (pm:queue, domain:identity), which carries a maintainer ruling from #8287 about stamping from the record's own org. Distinct card, distinct lane.

Serial constraints for the claiming seat

• [finding] a THIRD copy of the union-branch selection ranking lives in packages/metadata-protocol/src/protocol.ts — outside the reach of #8318's package-internal consolidation, with no mechanical parity enforcement #8660 (pm:queue, same lane, promoted this fire) also names packages/metadata-protocol/src/protocol.ts. Its cheapest option adds a parity test and may not touch protocol.ts at all — but declare file surface to the region level and check its claim comment before batching the two together.
• Two derivations of "is this object tenant-scoped" disagree on systemFields: false: the wall composes its predicate, the platform withholds the index #8608 (pm:dispatched, domain:engine-core) is the card about the two derivations of "is this object tenant-scoped" disagreeing. If sys_metadata_audit ever lands in that gap, the wall stops carrying this and the alarming reading becomes the correct one. Read its outcome before concluding "the wall has it".

---

Generated by Claude Code

[hotlong]

Claim: PM loop round 8
Session: session_01XeQRiAa7vYRVX5Fog7Zby8
Branch: claude/issue-8747-audit-org-scope
Worktree: objectstack-issue-8747
Domain: domain:metadata
File surface: packages/metadata-protocol/src/protocol.ts — region: auditMetaItem only, :6091–~:6170 — and, only if the measurement calls for threading the parameter, packages/rest/src/rest-server.ts around :6411–:6421, plus tests (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: region-declared, because protocol.ts is contended three ways. Line numbers taken from origin/main at dispatch, not from the card:

region	lines	holder
canonicalizeMetaRequestType + call sites + the saveMetaItem door	:211, 6 sites	PR #8770, open and unlanded
searchAll	~:7177–:7411	#7643, in flight
auditMetaItem	:6091–~:6170	this card

Three disjoint regions in a 15k-line file. Each dispatch carries a merge-origin/main-before-PR instruction and a stop-and-report if the work reaches outside its region; the merge queue arbitrates loudly if I have judged the separation wrong. This is deliberate parallelism under a maintainer instruction to keep the slots full, not an accident — recording it so the rebase churn, if it comes, is legible rather than mysterious.

⚠️ This card is measure-first and may be a security finding: if reading 1 holds (a tenant admin sees another tenant's actor / note / lock_state for a same-named metadata item), that is a live cross-tenant disclosure and I want it reported the moment it is measured, before any fix. If reading 2 holds, it is a comment that over-claims plus a dead parameter. The fix direction is narrowing — restoring the scoping the signature and comment already advertise — so it stays in the repair lane rather than the human floor either way.

---

Generated by Claude Code

[hotlong]

🚨 MEASURED: reading 1 holds — this is a live cross-tenant disclosure. No fix pushed; escalating first, as dispatched.

Dev seat session_01XeQRiAa7vYRVX5Fog7Zby8, branch claude/issue-8747-audit-org-scope (branch exists, no commits, no PR — the dispatch said report before implementing, and this is that report).

The 17:53Z execution-seat comment narrowed the question toward the cleanup reading on the grounds that sys_metadata_audit declares organization_id, so Layer 0's field gate can engage. That input is correct and the conclusion it pointed at is falsified: the field gate never gets asked, because the middleware that would ask it short-circuits several steps earlier.

---

1. The probe the card prescribed — two orgs, same (type, name), one audit read

Real ObjectQL + real SqlDriver over on-disk better-sqlite3 + real ObjectStackProtocolImplementation + the real SysMetadataObject / SysMetadataHistoryObject / SysMetadataAuditObject declarations. Rows seeded through the real saveMetaItem write path, not hand-inserted. Harness copied from packages/runtime/src/package-uninstall-org-scope.integration.test.ts, which is the existing precedent for exactly this shape.

Three saves of one view named shared_grid:

save	organizationId	actor
1	org_alpha	alice@alpha.example
2	org_beta	bob@beta.example
3	(none — env-wide)	package-installer

Then one read, spelled exactly as the production route spells it:

await protocol.auditMetaItem({ type: 'view', name: 'shared_grid' })

Measured output:

auditMetaItem() ACTORS: [ 'package-installer', 'bob@beta.example', 'alice@alpha.example' ]

Three rows, three organizations, one caller. A tenant admin in org_alpha opening Studio's audit tab receives org_beta's actor, and with it that row's note, lock_state, code, operation, source and request_id.

2. The mechanism, measured layer by layer — nothing compensates

Three candidate compensators, all eliminated:

(a) The driver's implicit tenant wall does not engage — it is never handed a tenant. SqlDriver.applyTenantScope builds (organization_id = :tenant OR organization_id IS NULL) only when DriverOptions.tenantId is set. The engine sets it from execCtx.tenantId in buildDriverOptions (packages/objectql/src/engine.ts:2850 — hasTenant requires execCtx?.tenantId !== undefined). auditMetaItem passes no context at all. Measured on a recording driver, with a positive control so the null result cannot be a harness artifact:

DRIVEROPTIONS context-less:  {"where":{"type":"view","name":"shared_grid"}}
DRIVEROPTIONS tenant-scoped: {"where":{...},"context":{"userId":"u1","tenantId":"org_alpha"},"tenantId":"org_alpha"}

The wall works. It is simply not asked.

(b) plugin-security's Layer 0 does not engage either — the middleware falls open before reaching it. security-plugin.ts:1230-1236:

if (positions.length === 0 && explicitPermissionSets.length === 0 && !opCtx.context?.userId) {
    return next();
}

A context-less engine.find has no positions, no permission sets and no userId, so it takes this return next(). computeLayeredRlsFilter — and with it the objectFields.has('organization_id') gate at :4537 that the 17:53Z comment identified — sits ~3300 lines further down the same function and is unreachable on this path. The field gate's readiness was real and is irrelevant.

(c) The posture question is moot, but worth recording. Even if the middleware did run, computeTenantLayer0Filter (tenant-layer.ts:119) returns null outright under the single posture, and under isolated it reads context?.tenantId — which is absent here, so :146 would return the fail-closed deny sentinel rather than a scope. So there is no posture in which the current call shape yields correct scoping: it is unscoped in every one.

3. Blast radius

GET /api/v1/meta/:type/:name/audit (rest-server.ts:6404) carries no capability gate in its handler — unlike its PUT /meta/:type/:name sibling at :6100, which gates on manage_metadata. The only guard is the anonymous floor (enforceAuth → shouldDenyAnonymous). So the reachable cohort is any authenticated principal, of any tenant, with no capability required. Route ledger disposition sdk, client meta.getAudit, so it is also on the published SDK surface.

Exposure requires a (type, name) collision across tenants. That is not exotic: metadata names are authored from a shared vocabulary and the same package installed into two tenants produces identical (type, name) pairs by construction.

Not affected: the dispatcher twin (packages/runtime/src/domains/meta.ts) has no audit route, so rest-server.ts is the sole production door, exactly as filed.

4. Why I stopped here

The dispatch was explicit — measure first, report a positive reading 1 immediately, and do not fold a security fix into a routine cleanup PR. It also flagged that this changes who decides. Beyond that, the fix genuinely forks in a way this card did not settle, and one branch runs into a recorded precedent:

rest-server.ts:6731-6742 states, about the sibling /published route, that packages/rest carries no resolveActiveOrganizationId and no org plumbing at all, and that inventing it there "would be a new seam smuggled in under a bug fix". So the card's option A as literally worded — thread organizationId from the REST route — walks straight into that.

But there is a third option the card did not name, and I think it is the right one. The obstacle above is specific to the organizationId-as-protocol-argument seam. The ExecutionContext seam already exists in this very file: computeExecCtx (rest-server.ts:2915) assembles tenantId: authz.tenantId, and resolveExecCtx is already called by 15+ handlers in rest-server.ts — including the PUT /meta/:type/:name twin at :6133. Threading that context into the audit read is using the seam that is already there, not adding one.

option	shape	closes it?	cost
A — wire $or, thread organizationId from REST	hand-built $or [{organization_id: oid}, {organization_id: null}]; new org-resolution plumbing in packages/rest	yes	hits the :6731 precedent; hand-reimplements the wall the platform already owns; a second place to get tenancy right
B — delete the param, correct the comment	signature and comment stop advertising scoping	no — leaves the disclosure open	ruled out by measurement; this was only viable under reading 2
C — thread the caller's ExecutionContext into the engine read	auditMetaItem accepts a context and passes { context } to engine.find; route supplies it via the existing resolveExecCtx	yes	the platform's own Layer 0 + driver wall do the scoping

My recommendation is C, on the three axes:

• Real business need. The need is measured, not speculative: the disclosure above is the demand. C also delivers the comment's exact promised semantics for free — the driver wall is literally (organization_id = :tenant OR organization_id IS NULL), i.e. own-org plus env-wide, which is the both-halves behaviour the editor needs so package-level env-wide writes stay visible. A hand-built $or re-derives that by hand and can drift from it.
• Long-term soundness. Contract-first and no workaround: tenant isolation stays owned by the one layer that owns it everywhere else, instead of gaining a second implementation inside one protocol method. A hand-built predicate in auditMetaItem is exactly the "second implementation of the same contract, blind to every widening mechanism" shape the security plugin's own :5492 comment warns about.
• Hard to get wrong. C makes the absence of scoping the thing you have to write explicitly, rather than the thing you get by forgetting an argument — which is precisely how this defect happened. An optional organizationId?: string | null that every caller may silently omit is a declared-not-enforced trap by construction; a threaded context is the shape every other scoped read in this codebase already uses, so the next author copies a correct pattern rather than an inert one.

⚠️ One caveat C does not solve, and A does not either: under the single tenancy posture Layer 0 contributes nothing by design, so on a single-posture deployment C leaves the read unscoped. That is correct-by-design for single (one tenant, nothing to isolate) — but it means C's guarantee is "scoped wherever the platform scopes anything", not "scoped unconditionally". If the intent is the stronger unconditional guarantee, that is A, and it needs saying out loud rather than assuming. This is the sharpest thing I want a decision on.

5. What I deliberately did not do

• No fix, no commits, no PR. Reporting first was the instruction, and the option fork above is a real decision, not a detail.
• Did not touch the write path. Audit rows are stamped from the ACTOR's active organization in preference to the record's own — and the record-side fallback cannot see sys_api_key.active_organization_id #8707 owns stamping; every measurement above reads rows the current write path already stamps correctly.
• Stayed inside the dispatched region. Nothing read or written near canonicalizeMetaRequestType (PR fix(metadata): refuse a /meta type name the platform does not have, instead of minting a namespace for it (#8421) #8770) or searchAll (⌘K global-search palette recall is strictly narrower than the $search executor (no pinyin/companion recall) #7643).
• Filed nothing new. One adjacent observation, recorded here rather than as a card because it is inside this card's own region: the route also passes environmentId to auditMetaItem, which its request type does not declare and its body never reads — a second dead parameter on the same call, and whichever option lands should sweep it.

Probe kept and re-runnable; say the word and I will land the chosen option with the both-directions pins the card asks for (own-org and env-wide visible, third org not visible).

---

Generated by Claude Code

---

Generated by Claude Code

[hotlong]

{
  "issue": 8747,
  "status": "needs_decision",
  "branch": "claude/issue-8747-audit-org-scope",
  "pr": null,
  "premise_still_valid": true,
  "summary": "MEASURED reading 1: this is a live cross-tenant disclosure, not a cleanup. Real ObjectQL + real SqlDriver (sqlite) + real ObjectStackProtocolImplementation, three saves of one view name under org_alpha / org_beta / env-wide through the real saveMetaItem path, then one auditMetaItem({type,name}) read returned ALL THREE rows: actors package-installer, bob@beta.example, alice@alpha.example. Nothing compensates lower down and all three candidates were eliminated by measurement, not by reading: (a) the driver's tenant wall never engages because buildDriverOptions sets DriverOptions.tenantId only from execCtx.tenantId and auditMetaItem passes no context (recorded DriverOptions were bare, with a tenant-scoped positive control proving the wall does engage when a context IS threaded); (b) plugin-security's Layer 0 never engages because the middleware hits its principal-less `return next()` at security-plugin.ts:1230-1236, ~3300 lines before the objectFields.has('organization_id') gate at :4537 that the triage comment expected to carry this; (c) even if it ran, computeTenantLayer0Filter returns null under `single` and the deny sentinel under `isolated` with no tenantId, so no posture yields correct scoping. Reachable by ANY authenticated principal of any tenant: GET /api/v1/meta/:type/:name/audit carries no capability gate, only the anonymous floor, unlike its PUT twin which gates on manage_metadata. NO fix written and NO PR opened, per the dispatch's instruction to report a positive reading 1 before implementing. NOTE the card's option A runs into a recorded precedent (rest-server.ts:6731-6742 states packages/rest carries no org plumbing and that adding it under a bug fix would be a smuggled seam) and its option B is now falsified by measurement, so the fork needs a decision.",
  "tests": "No production code changed, so no gate union and no HEAD to quote — this run is a measurement, not a diff. Probe run: `pnpm --filter @objectstack/runtime exec vitest run src/zz-probe-8747.integration.test.ts --maxWorkers=2` under flock /tmp/os-heavy-verify.lock, on a fresh worktree at origin/main ab8b10f82 after `pnpm --workspace-concurrency=2 --filter '@objectstack/runtime^...' build` (EXIT=0 — the dogfood-adjacent point that the probe reads the built dist of objectql/driver-sql/metadata-protocol/metadata-core, which is why the closure was built first). Both probe cases were written to assert an impossible value so vitest would print the real output rather than let a green mask it; measured output verbatim: `auditMetaItem() ACTORS: [ 'package-installer', 'bob@beta.example', 'alice@alpha.example' ]`, `DRIVEROPTIONS context-less: {\"where\":{\"type\":\"view\",\"name\":\"shared_grid\"}}`, `DRIVEROPTIONS tenant-scoped: {\"where\":{...},\"context\":{\"userId\":\"u1\",\"tenantId\":\"org_alpha\"},\"tenantId\":\"org_alpha\"}`. The tenant-scoped line is the positive control: it proves the empty DriverOptions above is the omission under test and not an artifact of the harness. Probe file removed from the worktree afterwards (git status clean, no commits) and kept at /tmp/claude-0/-home-user/fa8d55b6-f99c-53bb-bdc4-f2b492970093/scratchpad/issue-8747/probe.test.ts. No reverse verification: there is no fix to revert, and the disclosure is established by the forward measurement plus its control.",
  "open_questions": [
    {
      "question": "How should the audit read be scoped, given that the card's option A collides with a recorded precedent and its option B is falsified by measurement?",
      "options": [
        "A - wire the $or the comment describes and thread organizationId from the REST route. Closes it, but rest-server.ts:6731-6742 explicitly states packages/rest carries no resolveActiveOrganizationId and no org plumbing at all, and that inventing it to close a bug would be 'a new seam smuggled in under a bug fix'. Also hand-reimplements the wall the platform already owns, creating a second place tenancy must be kept right.",
        "B - delete the parameter and correct the comment. FALSIFIED: this was only viable under reading 2 and would leave the disclosure open. Listed so the record shows it was measured out, not skipped.",
        "C - thread the caller's ExecutionContext into the engine read: auditMetaItem accepts a context and passes { context } to engine.find, the route supplies it via the resolveExecCtx that rest-server.ts already calls in 15+ handlers including the PUT /meta twin at :6133, and the platform's own Layer 0 plus driver wall do the scoping."
      ],
      "recommendation": "C. Real business need: the need is the measured disclosure, and C delivers the comment's exact promised semantics for free because the driver wall is literally (organization_id = :tenant OR organization_id IS NULL) — own-org PLUS env-wide, the both-halves behaviour the editor needs so package-level env-wide writes stay visible, which a hand-built $or re-derives and can drift from. Long-term soundness: contract-first, no second implementation of tenant isolation inside one protocol method — exactly the 'second implementation blind to every widening mechanism' shape the security plugin's own :5492 comment warns about. Hard to get wrong: an optional organizationId?: string | null that every caller may silently omit is a declared-not-enforced trap by construction and is precisely how this defect happened, whereas a threaded context is the shape every other scoped read here already uses, so the next author copies a correct pattern instead of an inert one. CAVEAT the maintainer should rule on explicitly: under the `single` tenancy posture Layer 0 contributes nothing by design, so C's guarantee is 'scoped wherever the platform scopes anything', not 'scoped unconditionally'. That is correct-by-design for single-tenant deployments, but if the intent is the stronger unconditional guarantee then A is the option that provides it and the extra seam is the price. This is the sharpest open point."
    }
  ],
  "out_of_scope_findings": []
}

Full evidence, mechanism and blast radius in the sibling comment posted immediately above.

---

Generated by Claude Code

---

Generated by Claude Code