design: `isSystem` 写入是否在租户审计控制范围内?——#13178 类级装置(A/B/C)的共同前置,从未被裁过

[zhuangjianguo]

由维护者 2026-08-30 决裁批 #7 对 #13178 的裁定(verbatim「批 #7 同意」)同笔立卡:#13178 收窄到 4 处半修复先行,类级控制装置(CI 门禁 / 测试下抛 / 启动报告)暂缓于本卡裁出范围之后。

待裁的问题

isSystem 写入到底该不该在「写入未带租户上下文」控制的范围内?

代码注释写着 "unscoped by design"——那是声明,不是裁过的决定(#13178 普查核实:无任何裁决记录)。而这个从未裁过的默认,决定了整个控制的有效人口。

输入(#13178 普查,AST 级、带反例证明字面扫描漏一半)

• 分母:175 个写调用点;其中 24 个真没带租户上下文;
• 135 个(77%)在 posture 门(guard 4)之前就被 bypassTenantAudit 的 isSystem 门(guard 2)静音——即使在唯一让告警放行的已围墙生产部署里,77% 的写入也到不了该控制;
• 该控制历史上从未发现过任何一例——已知四例(multi-org: sys_file is never org-stamped — StorageMetadataStore.createFile inserts without a context while both callers hold the session #12745 · multi-org: sys_upload_session is never org-stamped either — StorageMetadataStore.createSession inserts without a context #12928 · tenant-audit: updateMany on tenant-scoped sys_http_delivery / sys_notification_delivery runs without options.tenantId — un-isolated writes on multi-org shapes #10673 · The audience-binding-suggestion reconciler writes with a tenant-less system context, so one organization-less row serves every tenant — the second half of the #8577 install-path dead end #8617)全部由人读调用点发现;
• 控制形状自不自洽:最大静音门排在适用条件之前。

悬而未决的定级输入(企业版 stamper 缺口)

企业版 Middleware A(树外)在围墙部署上会 stamp organization_id ⇒「调用点没带」≠「行落 NULL」。这个缺口决定伤害是 p1 还是 p3——未定级,须在本卡内测清或由维护者判。

裁出范围后的下游(#13178 暂缓的三候选,各自的已测代价)

• A(CI 门禁):能判 127/175,对 48 个运行时参数名站点结构性盲——73% 覆盖读起来像全覆盖,假保证风险;
• B(测试下抛):最响亮,但会炸多少套件未测;
• C(启动报告):dogfood 跑 single posture,报告放 posture 门后永远为空。

Refs: #13178(普查与四例)· #12745 · #12928 · #10673 · #8617。

[zhuangjianguo]

⚖️ RULED — 维护者,2026-08-30,第 5 场总监席决裁批 #9,verbatim「同意」(采本席推荐)

裁定:采选项 A —— 追认「isSystem 写入不在本控制范围内」为正式裁定(系统写入系平台自写、合法跨租户;控制目标是应用面调用点)。"unscoped by design" 从此有裁决出处,不再只是一行注释。

• 执行(declared=enforced):守卫顺序与注释同笔改到把该 scoping 显式声明——bypassTenantAudit 的 isSystem 分支旁注明本裁定与本卡号;控制的有效人口如实表述为应用面调用点(≈40/175),⛔ 不得再以「全部写入」的口径描述该控制。
• stamper 缺口测量作为独立后续派发:企业版 Middleware A 在围墙部署上是否使「调用点没带上下文」≠「行落 NULL」——它定 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 修复族的伤害等级(p1 vs p3),同笔另立测量卡。
• 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 暂缓的装置选择(CI 门/测试抛/启动报告):此后对诚实的应用面人口重估;若重估后仍需裁向,按批呈报。
• 回头条款:若 stamper 测量发现系统写入真会落 NULL 租户行,本裁定回箱重裁。

席位边界(裁不派):录裁 + 转 pm:queue,同笔摘 needs-user-decision;派发归车道席。裁决入本场追认摘要表。

---

Generated by Claude Code

[zhuangjianguo]

Claim: PM loop round R7
Session: session_01F3jdziLbAPGeceVNmSox5L
Branch: claude/issue-13491-issystem-scoping-declared
Worktree: objectstack-issue-13491
Domain: domain:engine
Container & model: M, mode:subagent, model: opus.
Clause ②: no — nothing lands under packages/spec/src/**, and a scoping declaration changes neither what the contract accepts nor the public surface. ⚠️ That answer depends on the reading in the next paragraph; if the work turns out to change behaviour, it is not this seat's to wave through.

Picked up from pm:queue per the ruling's own 席位边界 line — 裁不派. Ruling recorded at 5470359920… (批 #9, maintainer verbatim「同意」, adopting option A): 追认「isSystem 写入不在本控制范围内」为正式裁定.

⚠️ One phrase in the ruling has two readings, and they are materially different work

执行(declared=enforced):守卫顺序与注释同笔改到把该 scoping 显式声明……

It can be read as (a) "the guard order and the comment are changed together so the scoping is declared" — i.e. actually reorder the guards — or (b) "the guard-order-and-comment situation is changed, in one stroke, into an explicit declaration" — i.e. make the declaration match what is already enforced, without moving behaviour.

⛔ I am not choosing between them for the executor, and I am not re-adjudicating the ruling. The dispatch carries the phrase verbatim plus a stop condition: declared=enforced most naturally means bring the declaration up to what is enforced, so if the executor finds that satisfying it requires changing which writes actually get audited, that is a behaviour change on a security surface and it stops and reports rather than deciding. Reporting that is a success outcome.

The look-back clause is live, and it points at a card being dispatched alongside this one

回头条款:若 stamper 测量发现系统写入真会落 NULL 租户行,本裁定回箱重裁。

That measurement is #13497, claimed in this same round. ⇒ This card's declaration could be re-opened by that card's result. Both are dispatched in parallel because the ruling created them in the same stroke and they do not contend (this one edits driver-sql; #13497 edits nothing), but the executor is told the clause exists so it does not write the declaration as if it were permanent.

Serial constraints: #13178 landed and is closed, so nothing else holds packages/drivers/driver-sql/** from this lane. ⚠️ Stated as partial: I did not enumerate open PRs' file lists repo-wide; the executor re-derives its write set against the merge base and confirms the single-writer path before its first edit.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 13491,
  "status": "blocked",
  "branch": "claude/issue-13491-issystem-scoping-declared",
  "pr": null,
  "premise_still_valid": false,
  "summary": "HELD on the coordinator's instruction: #13497's stamper measurement met the ruling's own look-back condition, so the premise this card executes is back with the maintainer. No PR was opened and none will be. ⚠️ Stated plainly per instruction 3: the declaration text was already WRITTEN AND PUSHED as commit ca3aacb073 before the hold arrived — the branch on origin carries it; nothing has been pushed since, no PR exists, nothing is enqueued. A later local commit (5965611270, the changeset) is deliberately unpushed. I did not verify #13497's finding myself; premise_still_valid is set false on the coordinator's report of it, not on my own measurement. Work delivered as measurements rather than ratifications: (1) 1.3 resolved by experiment, (2) the population arithmetic reconstructed as far as the evidence allows, (3) the forbidden framing sites enumerated. Behaviour is unchanged in every commit on the branch: no guard moved, no predicate changed, and two ablations prove the pins bite.",
  "tests": "All runs at branch head 5965611270 (tree identical to pushed ca3aacb073 plus a changeset file). Dependency closures built first under scripts/pm/os-verify-lock.sh. NEW PINS: driver-sql src/sql-driver-13491-tenant-audit-scope.test.ts — 'Test Files 1 passed (1) / Tests 8 passed (8)'; objectql src/engine-issystem-tenant-audit-scope.test.ts — 'Test Files 1 passed (1) / Tests 5 passed (5)'. TYPECHECK: 'packages/drivers/driver-sql typecheck: Done', 'packages/objectql typecheck: Done', 'packages/services/service-messaging typecheck' green after building its closure (its first run's TS2307 'Cannot find module @objectstack/objectql' was an unbuilt-dist artifact, not this diff). GATES (verdict lines quoted, exit codes captured before any pipe): check-nul-bytes 'OK (scanned 7518 text file(s) ... no raw ASCII control bytes)'; check-system-context-census 'OK — 109 elevation read sites in 20 packages across 45 files, all anchored; 145 anchors resolve, 27 declared non-read' plus '--self-test: all cases passed'; check-test-source-alias 'OK — 72 packages with tests scanned'; check-role-word OK; check-comment-mask-adoption OK; check-logger-receiver-detach OK; check-objectql-double-limit OK; check-type-source-resolution OK; check-published-files OK; check-docs-single-h1 OK; doc-frontmatter / doc-route-spelling / docs-section-name / doc-anchors / published-readme-links / cross-package-test-inputs / empty-changeset / changeset-no-major / changeset-gate-self-tests / undeclared-dep-imports / durability-log-level all exit 0. check-engine-split-ratio first refused (shallow clone, PREREQUISITE NOT MET); after 'git fetch --shallow-since=2026-05-25' it ran and passed (ratio 98.0%). check-test-completeness 'PREREQUISITE NOT MET — this gate grades a saved turbo run test log' — NOT MEASURED, not green and not red. ABLATION 1 (proves the declaration is now enforced, not merely written): implementation committed first; mutation = the engine's isSystem branch deleted; landed on disk proven by injected-marker grep 1 and removed-text grep 0 plus a disk blob hash differing from the HEAD blob; the two positive objectql pins turned RED ('expected { context: { isSystem: true } } to match object { bypassTenantAudit: true }'), 2 failed | 3 passed. ABLATION 2 (the guard-order question): mutation = the scope gate moved BELOW the posture read; landed on disk proven the same way plus a positional grep; exactly one pin turned RED — 'an out-of-scope write never reaches it, so a malformed posture cannot fail it', AssertionError 'promise rejected Error: Invalid OS_TENANCY_POSTURE=isolat… instead of resolving' — the other 7, including every warn/silence assertion, stayed green. NO REBUILD was needed for either ablation and this is load-bearing: both test files import their subject by relative source path (../src/index.js, ./engine.js), not through a package exports map, so vitest reads the mutated source directly — the stale-dist false-green does not apply here. Both restores proven by an empty 'git diff HEAD' AND a disk blob hash equal to the HEAD blob, under an EXIT INT TERM trap with an absolute repo root.",
  "mcp_calls": "0 — every GitHub read and the report comment went through repo-scoped REST (probed 200 first); no MCP GitHub tool was called",
  "open_questions": [
    {
      "question": "The card's ≈40/175 cannot be fully reconstructed: 175 and 24 are corroborated by committed artifacts, but 135 (hence 40 = 175 − 135) exists ONLY in this card's body. #13178 and #13051 both return HTTP 404 from the REST API, so the census's method is unreachable. Which number does the (re-)ruling want carried?",
      "options": [
        "A — carry 24/175: the sites where the control can ever produce a finding (the 24 with no tenant context must be a SUBSET of the in-scope 40, since a call site carrying no context at all cannot be isSystem-silenced). This is the only figure both corroborated and measurable.",
        "B — carry ≈40/175 as the ruling wrote it, marked as inherited-and-unreproducible, with 135 flagged as uncorroborated.",
        "C — re-run the census before any number is written into code."
      ],
      "recommendation": "A for the number that goes in the code, plus C before anything is described as authoritative — 24 is corroborated on main in two committed places and is the sharper fact (of the ~40 in scope, ~16 already carry a tenant and exit at the tenantId guard, so the control's entire yield surface is the 24, on which it has historically found 0 of 4 known defects). Writing 135/40 into the code would put an unreproducible number where the ruling asked for an honest one."
    },
    {
      "question": "1.3 「守卫顺序与注释同笔改」 — ANSWERED BY EXPERIMENT, and the answer outlives the re-ruling. Does making the scoping explicit require changing which writes reach the audit?",
      "options": [
        "reading (a) — reorder the guards",
        "reading (b) — declare, without moving behaviour"
      ],
      "recommendation": "(b), and the measurement is sharper than the dispatch's own framing. Reordering CANNOT change which writes are audited: every step before the throttle is a pure predicate (isMultiTenantMode reads env, resolveTenantField reads a cache, neither mutates), the only stateful step is the throttle and it is last, so the audited set is their conjunction and is order-independent. The dispatch's premise 'Reordering it would change which writes are audited' is therefore FALSE. But reordering is not free either, and ablation 2 measured the real cost: resolveTenancyPosture() THROWS on a malformed OS_TENANCY_POSTURE rather than guessing, so with the scope gate moved below the posture read a platform write on a misconfigured deployment throws where it previously completed — a diagnostics helper turned into a failing write. ⇒ Whoever implements a NEW boundary after the re-ruling can express it in the current guard order without any behaviour change, and should not move the scope gate below the posture read."
    },
    {
      "question": "If the re-ruling narrows the exclusion (e.g. because the sys_/cloud_/ai_ namespace regexp, not isSystem, is the wrong boundary), where should the new boundary be expressed?",
      "options": [
        "A — in the engine, at buildDriverOptions' isSystem branch (where the flag is produced today)",
        "B — in the driver, at auditMissingTenant's guard 2 (where it is consumed)",
        "C — both, with the engine narrowing what it declares and the driver's guard left alone"
      ],
      "recommendation": "A. The driver's guard reads a caller-supplied option and cannot tell an engine-produced exclusion from a hand-written one, so a boundary expressed there would also silence every deliberate caller-side bypassTenantAudit. The engine branch is the single producer for elevated writes, and the pins added on this branch already fence it: delete or narrow it and the objectql test reddens."
    }
  ],
  "out_of_scope_findings": []
}

---

HELD — the ruling met its own look-back condition; nothing was taken out of draft

⛔ No PR was opened. ⚠️ Stated plainly, because it happened before the hold reached me: the
declaration text was already written and pushed as ca3aacb073 on
claude/issue-13491-issystem-scoping-declared. Nothing has been pushed since; the changeset sits
in a deliberately unpushed local commit 5965611270. Nothing was deleted, nothing enqueued, no
label touched, no assignee touched.

1. The forbidden "all writes" framing — every site, with what each said

Four sites carried it. All four are already rewritten in ca3aacb073 (that is what the hold
caught mid-flight), so this is a list of what was found and what it now says, not a to-do list.

#	Site	What it said	What it says now
1	packages/drivers/driver-sql/src/sql-driver.ts — the auditMissingTenant docblock	"Surface writes that target a tenant-scoped object but don't carry a tenantId. These are almost always system / seed / admin paths that forgot to thread the active session context" — the control's subject stated as every unscoped write, with the sentence pointing at exactly the population that is excluded before the guard	Subject stated as the application-surface write; the exclusion, the population, the ruling and the look-back clause named; the guard-order rationale written down
2	packages/drivers/driver-sql/README.md — "Audit warning"	"Genuine system writes auto-silence; everything else surfaces" — false in the other direction too, since the posture gate silences the whole single-tenant case	Names the walled-posture precondition, the scope exclusion, and that a quiet log is an all-clear over the ~40 only
3	content/docs/permissions/system-context.mdx row 24	"Tenant-audit warning silenced … Lose: the signal that would flag a genuine user-path scoping bug" — frames the exclusion as a loss of in-scope coverage	Framed as a scope verdict; "Lose: nothing the control ever covered"
4	packages/services/service-messaging/src/outbox-dispatcher-scope.ts	"the driver's auditMissingTenant gate treats every unscoped write to them as a finding"	"an unscoped APPLICATION-SURFACE write … its scope stops there"

⚠️ Two adjacent sites were deliberately not touched and are worth naming for the re-ruling:
packages/spec/src/data/driver.zod.ts (fenced, and its text describes the option rather than the
control's population, so it does not carry the framing), and the package CHANGELOGs, which are
historical records rather than live descriptions.

2. The population arithmetic — what reconstructs, and what does not

Corroborated on main, in two committed artifacts authored by the census's own PR (#13527):
.changeset/tenant-audit-update-delete-half-repairs.md and the header of
packages/services/service-storage/src/tenant-audit-update-delete-half-repairs.test.ts both state
"175 service write call sites against a tenancy-enabled object, 24 of them carrying no
tenant context at all".

NOT corroborated anywhere: the 135. git grep over packages/, scripts/, content/,
docs/ and .changeset/ finds it in no committed artifact, and both #13178 and #13051 return
HTTP 404 from the REST API (#13497, #13527 and #13541 return 200 from the same token, so this
is not an access or rate problem). The census's method is therefore unreachable, and ≈40 is
175 − 135, i.e. it inherits that number's unverifiability.

The identity is internally consistent: 135 / 175 = 77.1% matches the card's 77%, and
175 − 135 = 40 matches the ruling's ≈40/175.

One decomposition the ruling did not state, and it sharpens the honest figure. The 24 sites
"carrying no tenant context at all" must be a subset of the in-scope 40, not of the 175: a call
site that carries no context whatever cannot have isSystem === true, so it cannot be silenced at
the scope guard. That leaves roughly 40 − 24 = 16 in-scope sites that do carry a tenant and exit
at the tenantId guard — writes the control has nothing to say about because they are already
correct. ⇒ the control's entire yield surface is the 24, not the 40, and it has historically
produced 0 findings on them while all four known defects were found by people reading call sites.

My own independent count, reported as a bound rather than a reproduction. An AST walk (not a
text scan) over non-test sources: write-verb calls on an ObjectQL-engine receiver number 209
across packages/, 220 including examples/. That is a superset of the census's number
because it does not filter to tenancy-enabled objects, which is the filter I could not apply
cheaply. It is consistent with 175 after such a filter; it does not reproduce it. ⛔ I did not
reproduce 175, 135 or 40 by measurement, and none of them should be read as re-verified here.

3. declared = enforced, if any of this survives

The two new test files are the part that is worth keeping whichever way the re-ruling goes, because
they measure rather than ratify: the engine branch that produces the exclusion is now pinned (delete
it and 2 pins redden), and the guard order is now pinned by the one thing reordering actually
changes (move the scope gate below the posture read and 1 pin reddens, while every warn/silence
assertion stays green). If the boundary moves, both pins move with it rather than standing in the
way.

---

Generated by Claude Code