measure: 企业版 Middleware A 的 `organization_id` stamper 缺口——「调用点没带租户上下文」是否 ≠「行落 NULL」?(定 #13178 修复族伤害等级的唯一输入)

[zhuangjianguo]

由维护者 2026-08-30 决裁批 #9 对 #13491 的裁定(verbatim「同意」)同笔立卡。

任务(纯测量,不改代码)

#13178 普查测出 24 个应用面写调用点真没带租户上下文,其中 4 处半修复已入队(#13178)。伤害等级未定,取决于一个未测事实:

企业版 Middleware A(树外)在围墙(walled)部署上会 stamp organization_id——若它对这 24 个站点的写入路径全部生效,则「调用点没带」≠「行落 NULL」,伤害降为 p3(卫生问题);若存在绕过 stamper 的路径(非 HTTP 入口、后台任务、迁移脚本等),则对应站点是真实的 NULL 租户行风险,维持 p1。

产出:

1. Middleware A 的 stamp 生效条件与覆盖面(哪些入口路径经过它,哪些不经过);
2. 24 个站点逐个归类:stamper 覆盖 / 不覆盖 / 判不了(判不了的说明为什么);
3. 据此给 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 修复族与 design: isSystem 写入是否在租户审计控制范围内?——#13178 类级装置(A/B/C)的共同前置,从未被裁过 #13491 已裁 scoping 的伤害等级建议,落卡评论——定级本身回批次呈报,⛔ 本卡不改优先级标签。

回头条款(#13491 裁定原文承接)

若测量发现系统(isSystem)写入也存在落 NULL 租户行的真实路径,#13491 的「isSystem 出范围」裁定回决策箱重裁。

Refs: #13178(普查与 4 处半修复)· #13491(scoping 裁定)。

[zhuangjianguo]

Claim: PM loop round R7
Session: session_01F3jdziLbAPGeceVNmSox5L
Branch: claude/issue-13497-stamper-gap-measurement
Worktree: objectstack-issue-13497
Domain: domain:engine
Container & model: M, mode:subagent, model: opus.
Clause ②: no — ⛔ this card changes no code at all (纯测量,不改代码), so neither limb can fire.

Picked up from pm:queue per 批 #9's 席位边界 line. Dispatched in parallel with #13491, whose ruling created this card in the same stroke and whose look-back clause this card can trigger: 若测量发现系统(isSystem)写入也存在落 NULL 租户行的真实路径,#13491 的「isSystem 出范围」裁定回决策箱重裁.

⚠️ The hard boundary this card runs into, named up front

Middleware A is out-of-tree (树外). This session's repository scope is objectstack-ai/objectstack and objectstack-ai/objectui — the enterprise middleware is in neither. ⇒ The executor cannot read Middleware A's source, and any claim about what it stamps would be invention rather than measurement.

What is answerable from in-tree, and is where the value sits:

• the 24 sites' entry paths — which are reachable only through an HTTP request (where an HTTP middleware could stamp at all), versus which are reachable through paths that categorically bypass an HTTP middleware: background jobs, schedulers, migration scripts, CLI entry points, boot/seed reconcilers, direct engine calls;
• a site reachable only by a non-HTTP path cannot be covered by Middleware A whatever it does, which is a conclusion that needs no out-of-tree reading;
• everything that turns on Middleware A's own conditions goes in the card's own 判不了 bucket with the reason, exactly as the card provides for.

⇒ The deliverable is honest coverage classification, not a guess at enterprise behaviour. ⛔ A "stamper covers it" verdict that rests on assuming what the middleware does is worse than a 判不了.

Boundaries from the card, carried intact

⛔ 本卡不改优先级标签 — the severity recommendation goes in a card comment and back to the batch; the executor does not re-grade, and neither do I. ⛔ No code changes, no PR.

Serial constraints: none to clear — the card edits nothing.

---

Generated by Claude Code

[claude]

Measurement: the enterprise organization_id stamper gap

Measured against origin/main at 50cf2940b9 (worktree objectstack-issue-13497, detached, nothing edited). Pure measurement per the card — no code change, no PR, no priority label touched.

---

0. FIRST — the look-back clause IS triggered

回头条款:若测量发现系统(isSystem)写入也存在落 NULL 租户行的真实路径,#13491 的「isSystem 出范围」裁定回决策箱重裁。

Such a path exists, it is not hypothetical, and the repository's own test suite pins it.

packages/objectql/src/system-write-organization.test.ts contains, as a passing assertion:

'a platform-namespace object stays org-less on the %s posture' — it.each(['isolated', 'single']) — asserting lastWrite(observed, 'sys_audit_entry').options.tenantId is undefined.

isolated is a walled posture. So on a walled deployment an isSystem insert on a platform-namespace object reaches the driver with no tenant, injectTenantOnInsert stamps nothing, and the row lands organization_id = NULL — with the [tenant-audit] warning explicitly silenced by the same isSystem flag.

Executed, not merely read: pnpm --filter @objectstack/objectql exec vitest run --maxWorkers=2 src/system-write-organization.test.ts gives Test Files 1 passed (1) / Tests 20 passed (20). The same file's refusal tests (#8844 multi-organization — the write is REFUSED, never defaulted, it.each(['isolated','group'])) pass in that same run, so the probe discriminates: it is not answering "undefined" for everything.

The chain, link by link, all in shipped source:

1. SYSTEM_CTX is { isSystem: true } — no tenantId — in 20+ separate definitions across the tree (packages/services/service-queue/src/common.ts:27, packages/services/service-job/src/db-job-adapter.ts:16, packages/services/service-storage/src/attachment-lifecycle.ts:88, and so on).
2. ObjectQLEngine.buildDriverOptions (packages/objectql/src/engine.ts:3543): hasTenant is false, so no opts.tenantId; isSystem sets opts.bypassTenantAudit = true.
3. SqlDriver.injectTenantOnInsert (packages/drivers/driver-sql/src/sql-driver.ts:11944): returns immediately when tenantId is empty — nothing is stamped.
4. SqlDriver.auditMissingTenant (:11968): returns immediately on bypassTenantAudit — nothing is reported.
5. The one mechanism that would otherwise catch this, ObjectQLEngine.resolveSystemInsertOrganization (engine.ts:3754), returns undefined at its second guard: if (isPlatformNamespaceObject(object)) return undefined;.

Why this is more than a re-statement of "unscoped by design". The sys_ / cloud_ / ai_ carve-out is justified in packages/objectql/src/tenancy/system-write-organization.ts:66-77 by #8672's reasoning that "an org-less row is defensible for sys_permission_set". But the tree simultaneously treats a number of sys_* objects as genuinely tenant-scoped, and has been repairing them one door at a time:

• sys_file — insert door repaired multi-org: sys_file is never org-stamped — StorageMetadataStore.createFile inserts without a context while both callers hold the session #12745; update/delete doors repaired 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 (landed today, f087c376ff);
• sys_upload_session — insert door repaired multi-org: sys_upload_session is never org-stamped either — StorageMetadataStore.createSession inserts without a context #12928; update/delete doors repaired 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;
• sys_http_delivery — packages/plugins/plugin-webhooks/src/webhook-outbox-plugin.ts:364 says in as many words: "sys_http_delivery is tenant-scoped, and this is the one door on it a request can reach: an unscoped replay from here is an authenticated user reaching another organization's delivery row on a walled deployment";
• sys_notification_delivery — organization stamping added fix(messaging): stamp organization_id on flow-produced notifications and markRead receipts #11698.

Four objects, four separate repairs, all inside a namespace that the only class-level enforcement excludes wholesale. The blanket exclusion and the per-object repairs cannot both be right. That is the decision this puts back in the box, and it is a stronger statement than "isSystem is unscoped by design" — the design has an enforcement point, and the namespace rule routes exactly the contested objects around it.

---

1. The boundary — stated as a boundary, not as a gap in effort

1a. Middleware A is out of tree. Confirmed. This session's repository scope is objectstack-ai/objectstack and objectstack-ai/objectui; the enterprise middleware is in neither, so its stamp conditions cannot be read. Nothing below asserts what it does.

1b. #13178's census comment is UNREACHABLE. GET /repos/objectstack-ai/objectstack/issues/13178 returns 404 on three independent channels — unauthenticated REST, the rendered web page, and authenticated MCP issue_read. Positive control on the same channels in the same minute: #13497 → 200, #13491 → 200, #13179 → 200. So the 404 is about that number, not a broken channel.

⇒ The canonical list of 24 could be neither copied nor verified. Everything below is an independent re-derivation from the tree, with its criterion stated. The census's summary survives in-tree, in the changeset the #13178 repair landed (.changeset/tenant-audit-update-delete-half-repairs.md, now merged):

"The tenant-audit census counted 175 service write call sites against a tenancy-enabled object, 24 of them carrying no tenant context at all"

Corroboration that the re-derivation is measuring the same family (this matters, because the exact list is gone):

census figure (from #13491 / the changeset)	re-derived here
175 write call sites, of which 127 statically decidable	132 literal-object engine write call sites
48 runtime-parameter-name sites (a gate is structurally blind to them)	479 dynamic-name write calls overall; 152 on an engine-typed receiver
135 silenced by the isSystem guard before the posture gate	141 sites carrying an isSystem/seed context
24 carrying no tenant context at all	29 engine write sites with no tenant channel in the call

The 127 vs 132 and 135 vs 141 agreements are close enough to establish the same population; the differences are line rot, the four doors repaired since, and my scanner's own limits (below). I am not claiming to have reproduced "the 24".

1c. What a purely textual re-derivation cannot decide — measured on myself, twice:

• an argument list longer than my capture window read as "no context" when { context: SYSTEM_CTX } sat past the cut (file-reference-lifecycle.ts:363, db-job-adapter.ts:497);
• a tenant threaded through a variable (...options, ...scope, a row built above the call) is invisible to the call-site text (sql-http-outbox.ts:393 does carry { tenantId } via ...scope; sql-outbox.ts:121 does carry organization_id on its row).

Every site named below was hand-read in full after the scan. This limitation is itself the evidence for #13491's recorded finding that a CI gate can judge only 127/175.

---

2. Output 1 — Middleware A's stamp conditions and coverage

Not readable directly. What is measurable is the complete set of seams through which any tenant value can reach a write — which bounds what any middleware, in tree or out, can do.

There are exactly four channels, and every one of them is explicit at the call site:

#	Channel	Where	Applies to
1	ExecutionContext.tenantId, passed as context	buildDriverOptions, engine.ts:3567	all write ops
2	DriverOptions.tenantId, passed directly in the options bag	preserved by buildDriverOptions (it only fills opts.tenantId when undefined); used this way by sql-http-outbox.redeliver	all write ops
3	the tenant column set on the row payload	injectTenantOnInsert never overwrites an explicit value	insert only
4	the engine's own derivation, resolveSystemInsertOrganization	engine.ts:9383, inside insert()	insert only, application objects only

There is NO ambient channel. The engine's only AsyncLocalStorage is txStore (engine.ts:2225) and it carries transaction and scope — no tenant. Control that fired: the probe for ambient stores did find one, so it is capable of finding another; there is no second. And the injected column carries no database default — TENANT_SCOPE_FIELD_DEF (packages/spec/src/data/injected-system-column-provenance.ts:105) is { type: 'lookup', reference: 'sys_organization', label, required: false, hidden: true, readonly: true, system: true, description }, with no defaultValue, while sibling injected defs in the same module do carry other keys.

Consequence, and it needs no out-of-tree reading. An HTTP middleware can reach a write only by (1)/(2)/(3) at the call site, or by acting below the platform (a column DEFAULT, a trigger, RLS). For a call site that constructs its own row and passes no context — which is precisely the population in question — the first three are unavailable to it, because the middleware never sees that payload and there is no ambient slot to fill. Whether the enterprise deployment closes the gap below the platform is out of tree and is a 判不了.

And the question is narrower than it looks, because the engine already refuses most of it. resolveSystemInsertOrganization (#8844, maintainer ruling 2026-08-15) runs on every insert lacking a context tenant, not only isSystem ones — its first guard is carriesOrganization(execCtx?.tenantId), not isSystem. On a walled posture it throws SystemWriteOrganizationRequiredError (code: 'ERR_SYSTEM_WRITE_ORGANIZATION_REQUIRED', status: 500) rather than landing a NULL row. Its three exclusions are: objects with no tenant column / tenancy.enabled: false / federated; the sys_ / cloud_ / ai_ namespace; and writes already carrying an organization. It is INSERT-only, deliberately.

⇒ For application objects on a walled deployment, the stamper question is moot: an unscoped insert is refused, not stamped-or-NULLed. The entire residual NULL-tenant exposure sits in the platform namespace and on update/delete — and platform-namespace rows are exactly what an HTTP middleware is least placed to stamp, because they are written by services from their own payloads.

---

3. Output 2 — the sites, classified one by one

Population re-derived as: write calls (insert/insertMany/update/delete/upsert/bulkCreate/bulkDelete/updateMany/deleteMany) on an engine-typed receiver, in shipped packages/** source (tests, benchmarks, packages/verify harness, MCP bridge and spec migration doc-strings excluded), on an object whose tenant field resolves.

Object-level facts used: managedBy: 'better-auth' suppresses the injected column entirely (resolveInjectedSystemColumns, packages/spec/src/data/injected-system-columns.ts:156), so sys_user / sys_session / sys_account / sys_oauth_application / sys_two_factor are outside the population; sys_member and sys_invitation are inside it because they declare organization_id themselves. sys_api_key and sys_sso_provider declare tenancy: { enabled: false } and are outside.

3A. NOT COVERABLE by an HTTP middleware — reachable only by a non-HTTP entry path

A site reachable only this way cannot be covered whatever Middleware A does. This needs no out-of-tree reading and is the firmest thing here.

Site	Object	Op	Entry path
packages/cli/src/commands/secret/orphans.ts:396	sys_secret	delete	oclif CLI command; boots its own schema stack in-process (bootSchemaStack) and calls the driver directly (deleting.delete), bypassing the engine and buildDriverOptions entirely. No HTTP server in the process.
packages/services/service-job/src/db-job-adapter.ts:497	sys_job	update	bumpJob, the scheduler's post-run counter write. Carries SYSTEM_CTX.
packages/services/service-messaging/src/sql-http-outbox.ts:319	sys_http_delivery	update	ack, the dispatcher sweep. Already classified as a dispatcher sweep by #11010.
packages/services/service-messaging/src/sql-outbox.ts:300	sys_notification_delivery	update	ack, dispatcher sweep; dispatcherAckCasOptions sets bypassTenantAudit: true deliberately (#11010).
packages/plugins/plugin-webhooks/src/migrate-webhook-secrets.ts:115	webhook subscriptions object (runtime arg)	update	Plugin boot sweep, called from webhook-outbox-plugin.ts:265 during plugin start. Carries SYSTEM_CTX.
packages/services/service-storage/src/backfill-file-references.ts:186	sys_file	insert	Backfill pass. Carries SYSTEM_CTX; the file contains no organization_id reference at all.

3B. NOT COVERABLE — HTTP can trigger it, but the write leaves the request path, and no organization channel exists to carry

Site	Object	Op	Why
packages/services/service-messaging/src/sql-http-outbox.ts:178	sys_http_delivery	insert	EnqueueHttpInput has no organizationId member at all — grep for it in packages/services/service-messaging/src/http-outbox.ts returns nothing, while the sibling EnqueueDeliveryInput in sql-outbox.ts does have one (:37, :80, the #11698 repair). So no caller can supply an organization even if it has one. Producers: the automation HTTP node (service-automation/src/builtin/http-nodes.ts:125) and the webhook auto-enqueuer, which webhook-outbox-plugin.ts:86 documents as running "fire-and-forget (off the write path)".
packages/services/service-storage/src/file-reference-lifecycle.ts:363	sys_file	insert	copyOwnedFile, an engine lifecycle hook, fires for HTTP-originated and background-originated writes alike. Carries { context: { ...SYSTEM_CTX } }; the file contains no organization_id reference. This is the create door #12745 repaired, reached by a second path that does not go through StorageMetadataStore.

sys_http_delivery deserves calling out on its own. Every row this object gets is enqueued through :178 with organization_id = NULL. The driver's tenant term is (organization_id = :tenantId OR organization_id IS NULL) (sql-driver.ts:11931, #2734's deliberate global-row fail-open). So the #10740 wall on redeliver — which correctly threads the caller's active organization to stop "an authenticated user reaching another organization's delivery row on a walled deployment" — is reachable around for 100% of rows, because 100% of them are NULL-tenant. The scoping repair and the enqueue gap are in the same file, 200 lines apart.

3C. Both HTTP and non-HTTP entry — an HTTP middleware could cover at most the HTTP half

Site	Object	Op	Entry paths
packages/metadata-protocol/src/protocol.ts:17672	sys_metadata	update	reassignOrphanedMetadata; metadata protocol, served over HTTP and driven by CLI push and boot-time package install
packages/metadata-protocol/src/protocol.ts:17726	sys_metadata_commit	insert	persistPackageCommitRow; same
packages/metadata-protocol/src/protocol.ts:19429	sys_metadata	delete	deleteMetaItem; same
packages/services/service-datasource/src/datasource-admin-plugin.ts:103	sys_metadata	insert	persistDatasourceRow; admin routes plus programmatic registration
packages/services/service-datasource/src/datasource-admin-plugin.ts:121	sys_metadata	delete	deleteDatasourceRow; same
packages/services/service-datasource/src/datasource-secret-binder.ts:100	sys_secret	insert	bind; datasource credential binding, admin route plus boot registration
packages/services/service-datasource/src/datasource-secret-binder.ts:115	sys_secret	delete	unbind; same
packages/services/service-settings/src/settings-service-plugin.ts:317	sys_secret	insert	settings store; passes { bypassTenantAudit: true } — no tenant, and the report is silenced without an isSystem context
packages/services/service-settings/src/settings-service-plugin.ts:335	sys_secret	update	same
packages/plugins/plugin-auth/src/adopt-membership.ts:230	sys_member	update	adoptExistingMembership, from the better-auth adapter's create door; HTTP auth routes plus server-side auth.api calls

3D. 判不了 — cannot determine, with the reason for each

Site(s)	Reason it cannot be determined
packages/plugins/plugin-auth/src/objectql-adapter.ts — :859, :975, :996, :1015, :1031, :1048, :1079, :1119, :1149, :1162, :1172, :1180 (12 sites)	The object is a runtime parameter (objectName, resolved from a better-auth model name). Most better-auth models carry no tenant column at all (managedBy: 'better-auth' suppresses the injection) and are therefore outside the population; sys_member and sys_invitation declare organization_id themselves and are inside it. Which of the two a given call is depends on the model at runtime. This is exactly #13491's "48 runtime-parameter-name sites, structurally blind".
packages/metadata/src/loaders/database-loader.ts:272, :286, :293	Object is a runtime parameter (table). Additionally the class has an engine-or-driver fork: with no engine it calls this.driver.create/update/delete directly, bypassing buildDriverOptions and the audit entirely. It does have a tenant channel of its own — a constructor-level organizationId conditionally stamped at :1218 — so whether a given write carries an organization depends on how the loader was constructed.
Every question of the form "does Middleware A stamp this one"	Out of tree. Not readable, and answering it would be invention rather than measurement.
Whether a walled enterprise deployment closes the gap below the platform — a column DEFAULT, an insert trigger, or RLS on organization_id	Out of tree. In-tree the column is declared with no default and nothing writes one.

3E. Population II — isSystem writes on tenancy-enabled platform objects

Not part of "the 24" (these are the 135 the isSystem guard silences), but the look-back clause is about them, so they are measured here.

141 engine write sites carry an isSystem/seed context. Of the 87 with a statically resolvable object name, 66 target a tenancy-enabled platform-namespace object; 49 of those carry no tenant value anywhere in the call; 13 of those are inserts, i.e. writes that land a fresh NULL-tenant row. Hand-verified as carrying no organization on any path (the whole file contains no organization_id reference):

• packages/services/service-storage/src/file-reference-lifecycle.ts:363 — sys_file
• packages/services/service-storage/src/backfill-file-references.ts:186 — sys_file
• packages/plugins/plugin-sharing/src/share-link-service.ts:518 — sys_share_link
• packages/plugins/plugin-sharing/src/sharing-service.ts:1232 — sys_record_share
• packages/plugins/plugin-reports/src/report-service.ts:433 — sys_saved_report
• packages/plugins/plugin-reports/src/report-service.ts:635 — sys_report_schedule

The remaining inserts in that bucket (sys_audit_log from auth-event-audit.ts:228, read-audit.ts:460, config-change-audit.ts:199; sys_approval_request from approval-service.ts:2212) do stamp organization_id from a resolved tenant on the row — for example auth-event-audit.ts:265 (row.organization_id = tenantId) and config-change-audit.ts:197 (row.organization_id = entry.tenantId ?? null), both guarded on the column actually existing. They are the counter-example that shows the tree already knows how to do this on sys_* objects, which is why the six above read as gaps rather than as design.

A further 36 update/delete sites in the same bucket carry no tenant. Those do not create a NULL row, but they are an unscoped reach on a walled deployment; most are id-pinned by their where, which bounds the harm without removing it.

---

4. Output 3 — severity recommendation

⛔ No priority label was changed by this card. This is a recommendation back to the batch.

For #13178's repair family: keep p1. Do not downgrade to p3.

The p3 case required the stamper to close the gap for all 24 sites. It does not, and this can be said without reading Middleware A:

1. Six sites (3A) are reachable only by CLI, scheduler, dispatcher sweep, plugin boot sweep or backfill. No HTTP middleware is in the call chain at all.
2. Two sites (3B) are HTTP-triggerable but write off the request path, and for sys_http_delivery the input type carries no organization member at all — there is nothing for a middleware to populate. Every row of that object is NULL-tenant, which reaches around a wall the platform deliberately built on the same object.
3. There is no ambient tenant channel in the platform. All four seams are explicit at the call site, so a middleware cannot supply a tenant to a call site that passes none.
4. The one thing that would make "no tenant context" harmless — the System-context writes land untenanted at RUNTIME, so a single-tenant install keeps re-forking the autonumber scope and minting duplicate business identifiers — the producer #8686's backfill cannot reach (17.0.0 GA) #8844 refusal — is structurally excluded from the entire sys_ namespace, which is where essentially all of these sites write.

Suggested grading of what remains:

• p1 — sys_http_delivery enqueue (sql-http-outbox.ts:178). Not hygiene: it defeats an existing, deliberate cross-organization wall on the same object, for 100% of rows, on walled deployments. Worth its own card whatever happens to the rest.
• p1 — the sys_file NULL-tenant insert paths (file-reference-lifecycle.ts:363, backfill-file-references.ts:186). Same object 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: 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 have been repairing across four doors; these two doors write the same object unstamped.
• p2 — sys_share_link, sys_record_share, sys_saved_report, sys_report_schedule inserts (3E). Sharing and reporting rows landing org-less on a walled install; harm is real but bounded by the layers above.
• p3 — the CLI / scheduler / dispatcher / boot-sweep sites (3A), the settings sys_secret doors, and the metadata-protocol doors. These are the hygiene half: single-tenant-normal, id-pinned, or operator-initiated.

For #13491's ruled scoping: the look-back clause fires — send it back. The ruling scoped isSystem writes out of the control on the strength of "unscoped by design". The measurement says the design does have an enforcement point (#8844's refusal), that it deliberately excludes the whole sys_ namespace, and that at least four objects inside that namespace have needed per-door tenant repairs in the last weeks. The question worth re-deciding is not "is isSystem in scope" but "is the sys_/cloud_/ai_ namespace regexp the right boundary for the #8844 exclusion, or should tenancy be declared per object (ADR-0066's tenancy: { enabled: false }) as the module's own header argues for the neighbouring case?" The module already says a per-write bypass flag is the wrong shape and a per-object declaration is the right one; the namespace regexp is a per-write bypass wearing a different hat.

---

5. What was NOT measured

• Middleware A itself — out of tree. Nothing above asserts its behaviour.
• Any below-the-platform stamping in a walled enterprise deployment (column DEFAULT, insert trigger, RLS). Out of tree; in-tree the column has no default.
• A per-site resolution of the 12 objectql-adapter sites and the 3 database-loader sites — their object is a runtime parameter. Recorded as 判不了, not folded into any count.
• A byte-exact reproduction of "the 24" — the census is unreachable (404). The re-derivation agrees with the census summary on 127-vs-132 and 135-vs-141 but is not the same list.
• The full gate farm — this card changes no code, so no gate is owed. The only suite executed was the System-context writes land untenanted at RUNTIME, so a single-tenant install keeps re-forking the autonumber scope and minting duplicate business identifiers — the producer #8686's backfill cannot reach (17.0.0 GA) #8844 pin (20/20 pass), as a control on the central claim.

---

Generated by Claude Code

[claude]

os-dev-report

{
 "issue": 13497,
 "status": "done",
 "branch": "claude/issue-13497-stamper-gap-measurement — NOT CREATED. The card changes no code (纯测量,不改代码), so there is nothing to branch. Work was done in a DETACHED worktree at origin/main 50cf2940b9 (objectstack-issue-13497); git status --porcelain is empty.",
 "pr": null,
 "premise_still_valid": true,
 "summary": "LOOK-BACK CLAUSE FIRES — see open_questions[0]. A real path exists by which an isSystem write lands a NULL-tenant row on a WALLED deployment, and the repo's own test suite pins it: system-write-organization.test.ts asserts, under posture 'isolated', that an isSystem insert on a platform-namespace object reaches the driver with options.tenantId undefined (executed here: 20/20 pass). The #8844 refusal that would otherwise catch it is structurally excluded from the whole sys_/cloud_/ai_ namespace by isPlatformNamespaceObject (engine.ts:3765) — which is where essentially every site in this population writes, and which contains four objects (sys_file, sys_upload_session, sys_http_delivery, sys_notification_delivery) that have each needed per-door tenant repairs in the last weeks. BOUNDARY: #13178 is UNREACHABLE (404 on unauthenticated REST, the rendered web page, and authenticated MCP issue_read; controls #13497/#13491/#13179 all returned 200 in the same minute), so the canonical list of 24 could be neither copied nor verified — Zone 2 assumption A broke at its root. The census SUMMARY survives in-tree in the merged changeset .changeset/tenant-audit-update-delete-half-repairs.md ('175 service write call sites against a tenancy-enabled object, 24 of them carrying no tenant context at all'), and an independent re-derivation agrees with it closely enough to establish the same population (135-silenced vs 141 measured; 127-statically-decidable vs 132 measured) without reproducing the list. RECOMMENDATION: keep #13178's repair family at p1, do not downgrade to p3 — six sites are reachable ONLY by CLI/scheduler/dispatcher-sweep/plugin-boot-sweep/backfill and cannot be HTTP-stamped whatever Middleware A does, and the platform has NO ambient tenant channel (its only AsyncLocalStorage, txStore at engine.ts:2225, carries transaction+scope, no tenant), so a middleware cannot supply a tenant to a call site that passes none. ⛔ No priority label was changed.",
 "tests": "No gate is owed — the card changes no code and nothing was edited (git status --porcelain empty at HEAD 50cf2940b9). ONE suite was executed, as a control on the central claim rather than as a gate: (1) `pnpm install` -> EXIT=0, 'Done in 5.2s'; (2) `bash scripts/pm/os-verify-lock.sh -c \"pnpm --filter '@objectstack/objectql^...' build\"` -> gate's own verdict line 'os-verify-lock: VERDICT command-exit 0 · held the lock 196s (3m16s) · waited 0s'; (3) `bash scripts/pm/os-verify-lock.sh -c \"pnpm --filter @objectstack/objectql exec vitest run --maxWorkers=2 src/system-write-organization.test.ts\"` -> 'Test Files 1 passed (1) / Tests 20 passed (20)', verdict line 'VERDICT command-exit 0 · held the lock 6s · waited 1s'. THE CONTROL DISCRIMINATES: that one run contains both the exclusion assertion (platform-namespace object stays org-less on the 'isolated' posture — tenantId undefined) and the refusal assertions (#8844 multi-organization — the write is REFUSED, never defaulted, it.each(['isolated','group'])), so the probe is not answering 'undefined' for everything. No ablation was performed — nothing was mutated, because nothing was edited. Channel controls also fired: #13178's 404 was checked against #13497/#13491/#13179 returning 200 on the same three channels; the ambient-store probe DID find txStore (so it can find such stores) and found no tenant store; the dedup listing returned #13497 and #13491 as known-present controls. One control did NOT fire and is reported as a net-zero rather than a zero: GET /search/issues returns 403 for this session ('sessions are bound to their configured repositories') whose body parses to total_count=None, so the semantic search channel is unusable — dedup was done through the repo-scoped list endpoint instead.",
 "mcp_calls": "1 — a single mcp__github__issue_read on #13178 to confirm the 404 on an authenticated channel after unauthenticated REST and the web page both 404'd. Everything else went through zero-quota repo-scoped REST curl (public repo) and local git.",
 "open_questions": [
 {
 "question": "LOOK-BACK CLAUSE (#13491's ruling, verbatim: 若测量发现系统(isSystem)写入也存在落 NULL 租户行的真实路径,#13491 的「isSystem 出范围」裁定回决策箱重裁). The path exists and is pinned by a passing test. But the sharper question the measurement surfaces is not 'is isSystem in scope' — it is: is the sys_/cloud_/ai_ NAMESPACE REGEXP the right boundary for the #8844 exclusion? The design DOES have an enforcement point (resolveSystemInsertOrganization refuses an unscoped insert loudly on a walled posture); the namespace regexp routes exactly the contested objects around it. Four objects inside that namespace — sys_file (#12745, #13178), sys_upload_session (#12928, #13178), sys_http_delivery (#10740), sys_notification_delivery (#11698) — have each needed per-door tenant repairs, which the blanket exclusion says they should not have needed.",
 "options": [
 "A — Replace the namespace regexp with the per-object declaration the module's own header already argues is the right shape: an object that genuinely holds org-less rows declares tenancy: { enabled: false } (ADR-0066), and #8844's refusal then applies to every sys_* object that has NOT declared it. Loud at publish time, checkable once per object instead of per write. Cost: every platform object must be triaged and declared, and the refusal starts firing on walled installs for any that are missed — which is the point, but it is a breaking-shaped change.",
 "B — Keep the namespace exclusion, and repair the leaking objects one door at a time as they are found (the status quo: four objects, six-plus doors, four separate cards so far). Cheapest per step, no new enforcement. Cost: the leak rate is set by how fast doors are discovered by hand, and the control has never found one — all four known cases were found by a person reading call sites.",
 "C — Narrow the exclusion to an explicit ALLOW-LIST of genuinely global platform objects (the sys_permission_set family #8672 reasoned about), leaving every other sys_* object inside the refusal. Smaller blast radius than A, still one checkable list rather than a per-write bypass. Cost: a list that must be maintained, and the same triage as A for deciding who goes on it.",
 "D — Leave the #13491 ruling standing as-is (isSystem out of scope) and treat all of this as hygiene."
 ],
 "recommendation": "A, with C as the pragmatic first step. Real business need: measured, not speculative — four objects have needed repairs and sys_http_delivery currently defeats a deliberate cross-organization wall for 100% of its rows. Long-term soundness: the module header already rules that a per-object declaration is the correct shape and a per-write bypass is not; a namespace regexp is a per-write bypass wearing a different hat, so A is the option that stops re-deciding the same question. Making AI-written code hard to get wrong: A/C make the platform REFUSE loudly at the write rather than land a silent NULL, which is the declared-equals-enforced direction; B is the lenient-consumer shape that lets the defect keep arriving. Startup scope discipline: this argues for C first — it is a bounded list, not a platform-wide triage, and it removes the leak on the objects already known to leak without paying for A's full sweep. ⛔ I do not re-grade and neither does this card; this is input to the decision box."
 },
 {
 "question": "#13178 is unreachable (404 on three independent channels) while #13497 and #13491 — both of which cite it as their input — are open and being executed. PR #13527 landed its four half-repairs today, so the card was real. Is the census recoverable, and should the two live cards keep citing a number that resolves to nothing?",
 "options": [
 "A — Recover or re-file the census as an in-tree artefact (a docs/audits page or a committed AST census like scripts/isystem-census.mjs), so it stops being a comment that can vanish.",
 "B — Re-file the issue and re-point #13491/#13497 at the new number.",
 "C — Leave it; the census summary survives in the merged changeset and that is enough."
 ],
 "recommendation": "A. The tree already has the pattern (the isSystem census is a committed, gate-enforced page, and its own commit message records that its numbers rot and get re-derived). A census that decides the severity of a repair family and the scope of a ruling should not live only in a comment — this round lost it, and the only reason the work was still possible is that the changeset quoted the two figures that mattered."
 }
 ],
 "out_of_scope_findings": [
 "NOT FILED — recommended for PM filing rather than filed by me, because these are the CONTENT of this card's measurement rather than unrelated defects found in passing, and filing them would pre-empt the batch's own triage of the severity recommendation this card exists to produce. Both are recorded durably in the card comment (issuecomment-5471196408) with p1 recommendations. Dedup done through the repo-scoped list endpoint (12 open `security` issues; controls #13497/#13491 present in the result): neither is already filed. (1) sys_http_delivery enqueue lands organization_id = NULL for 100% of rows — packages/services/service-messaging/src/sql-http-outbox.ts:178. EnqueueHttpInput carries no organizationId member at all, so no caller can supply one, while the sibling EnqueueDeliveryInput does (sql-outbox.ts:37,:80, the #11698 repair). Because the driver's tenant term is (organization_id = :tenantId OR organization_id IS NULL), the deliberate #10740 cross-organization wall on redeliver() — 200 lines up the same file — is reachable around for every row. (2) sys_file NULL-tenant insert paths that bypass StorageMetadataStore — packages/services/service-storage/src/file-reference-lifecycle.ts:363 (copyOwnedFile, an engine lifecycle hook) and packages/services/service-storage/src/backfill-file-references.ts:186. Both pass { context: SYSTEM_CTX } (isSystem, no tenant) and neither file contains any organization_id reference, so the copy lands org-less on the same object #12745/#12928/#13178 have been repairing across four doors."
 ]
}

Generated by Claude Code

---

Generated by Claude Code