security(engine): reference-cleanup `set_null` write clears ONLY the object-level CRUD check (`__referentialFieldClear`-scoped) — FLS/RLS guards stay enforced; cascade untouched (RULED 2026-08-28)

[os-warren]

⚖️ RULED — twice. Do not adjudicate or dispatch from the menu below: it is the superseded FIRST-round framing, kept as history.

• Round 1 (maintainer, 2026-08-27 decision batch): option B of the menu below — the set_null cleanup write moves off the operator identity; cascade untouched; constraint 2 required two gate measurements before any code.
• Round 2 (maintainer, 2026-08-28, director summon ✨ Set up Copilot instructions #2 — triggered by the constraint-2 measurement: blanket isSystem in this codebase is TOTAL and also bypasses field-level security, RLS using and the RLS post-image check): marker-scoped exemption of the object-level CRUD check ONLY, via the existing __referentialFieldClear marker. The three unrelated guards stay enforced, each pinned; audit attribution keeps the measured sudo() shape; cascade stays operator-identity and excluded; changeset MINOR; Clause-② yes (needs:contract-review attached, dispatch at CONTRACT_REVIEW_TIER).
• Authoritative record: the 2026-08-28 "Maintainer ruling applied (second round)" comment on this card. Current state: pm:queue, awaiting the domain:engine seat's dispatch.
• (Card face updated by the director seat, session session_016SG9S6V15MqeAgkehDcTwk, at the maintainer's request — the title and body previously still read as an undecided FYI card.)

---

一句话

#12166 的裁决（2026-08-26，选项 A）把删除前的引用检查切成了系统身份，约束 1 明确限定「删除路径的其他任何部分身份不变」。因此引用清理的写入半边 —— set_null 的 UPDATE 与 cascade 的子记录 DELETE —— 仍以操作人身份执行。结果：原报告里那批「有删除权、对引用表无任何权限」的角色，只有在引用表为空时删除才通得过；引用表真的有引用行时，依然 403，只是报错从 find 变成了 update。

这不是 #12166 的实现缺陷，也不是要推翻裁决 —— 它正是约束 1 划定的边界。开这张卡只是因为该边界的实际影响没有被测量过，而它决定了原报告那 17 组「角色×对象」里到底有多少被真正修好。

证据（PR #12596 里已 pin 成断言）

packages/plugins/plugin-security/src/delete-reference-cleanup-system-identity.test.ts：

it('the elevation is the CHECK only — a non-empty referencing table still needs
    the caller\'s own write authority (constraint 1)', ...)

  expect(err.code).toBe('PERMISSION_DENIED');
  expect(err.details?.object).toBe('os_ehr_andon_record');
  expect(err.details?.operation).toBe('update');   // ← 不再是 'find'

夹具与原报告同形：对象 A 被 B 的可空 lookup 引用（解析行为 = set_null），角色对 A 有完整删除权、对 B 无任何授权。B 为空 ⇒ 删除成功（#12166 修好的部分）；B 有一行 ⇒ 仍然 403。

为什么值得单独判一次

• 原报告的 17 组配置里，引用表非空的那些仍然按不动删除按钮，症状与修复前对用户完全一致（同样是一句通用「您没有执行此操作的权限」）；从部署方视角看，问题只解决了一部分，而这一点在 删除记录时「引用清理」用操作人身份查询引用表,读权不足即整体 403(应以系统身份执行) #12166 的验收里看不出来。
• 裁决为引用检查给出的论证 —— 引用完整性动作是引擎责任、主流平台一律以系统身份执行（RDBMS FK 的 SET NULL／CASCADE、Salesforce 的 lookup 清空与级联删除均记载为绕过 sharing）—— 在文义上同样覆盖写入半边：FK 基线里真正以引擎身份执行的正是那个 SET NULL／DELETE。裁决把范围钉在查询上是刻意的（卡片正文与决策分析通篇只说「查询」），但据我所读，那个范围收窄没有单独论证过写入半边应当保留操作人身份 —— 它更像是照着 issue 的措辞划的，而不是对写入半边下的判断。
• 反方向也确实存在：cascade 的子删除以系统身份执行意味着「有 A 的删除权 ⇒ 可以删掉自己无权删除的 B 行」，这是一个远比读权外溢更大的权限语义变更，绝不该顺手带过。set_null（只清 FK 列）与 cascade（删整行）在这个维度上不对称，很可能需要分别裁。

建议处置（⚠️ 已被上方两轮裁决取代，仅存档）

• A. 维持现状（裁决的字面范围）：写入半边保持操作人身份。代价：原报告的部署仍需为每个可删角色补齐引用表的写权限，「删除权 = 删除权 + 引用表权限」的隐藏耦合只是从读权变成了写权，在权限界面上同样不可见。
• B. set_null 也切系统身份，cascade 不切：清空 FK 列是纯粹的完整性维护（且已有 属主守卫与级联 set_null 冲突:非特权删除 sys_user 时 owner_id 级联置空被 #3004 守卫拦截(级联中途失败) #3023 的 __referentialFieldClear 标记把它标为引擎内部写入），而删掉整行是数据销毁，保留操作人授权。这一档最贴近 FK 基线。
• C. 两者都切：完全对齐 Salesforce/Dataverse 的级联语义。权限面变更最大，需要独立论证。

⚠️ 无论哪个方向都是权限边界语义变更，条款②适用，应走 needs-user-decision 而不是直接派发。

出处

• 裁决：删除记录时「引用清理」用操作人身份查询引用表,读权不足即整体 403(应以系统身份执行) #12166 的 2026-08-26 评论（选项 A + 四条约束）
• 实现与 pin：PR fix(objectql,spec): run the pre-delete reference check under the system identity #12596
• 原始部署实测记录：steedos-labs/os-project-titanwind-ehr#1809

---

Generated by Claude Code

[os-support-ai]

Triage (triage seat, session session_01G28JXov51zX81Ky6M4r25m): decision box — needs-user-decision + domain:engine (family precedent: the ruling card this follows up, same delete-path surface), type Feature (options B/C expand the accepted set of the delete operation — the mechanical boundary test). This is a security/permission-boundary question and it would extend the scope of a maintainer ruling made today, so it sits on the human floor twice over — auto-adjudication does not apply, and the card's own framing agrees (条款② applies to any outcome). Not dispatchable; enters the maintainer's decision inbox.

Decision-box filing follows (中文,按裁定格式):

<!-- os-decision-facets -->

一句话问题:上一裁已让删除前的「引用检查」以系统身份执行,但「引用清理」的写入仍用操作人身份——所以只要引用表里真的有引用行、而操作人对那张表没有写权限,删除照样被拒;拿到删除权的角色在权限界面上看不出还差什么。

选项 × 真实代价:

• A(维持裁决字面边界,写入半边保持操作人身份):零改动。代价:部署方须为每个可删角色补齐所有引用表的写权限;「删除权 ≠ 真能删」的隐藏耦合从读权换成写权,界面上依旧不可见;原始部署 17 组「角色×对象」里引用非空的场景照旧按不动(实测:PR fix(objectql,spec): run the pre-delete reference check under the system identity #12596 已把该边界 pin 成断言,报错从 find 变 update)。
• B(set_null 清指针切系统身份,cascade 不切):清空引用指针视为引擎的完整性维护——与关系库 FK 的 SET NULL、Salesforce lookup 清空同构;删整行仍要操作人自己的删除权。代价:被引用表的一列会以系统身份被改写,操作人对该表的授权不再是这笔写入的门槛(引擎内部写入已有 __referentialFieldClear 标记,属主守卫与级联 set_null 冲突:非特权删除 sys_user 时 owner_id 级联置空被 #3004 守卫拦截(级联中途失败) #3023)。
• C(两者都切系统身份):级联删除也绕过操作人权限 ⇒ 「有 A 的删除权 = 能连带删掉自己无权删的 B 行」——数据销毁面的权限扩张,变更最大,需独立论证。

四棱:

• ① 项目长远合理性:B 与行业基线同构,把「引用完整性 = 引擎责任」的已裁原则做到写半边;A 把完整性动作留给每个部署自己拼权限矩阵,长期反复踩同一坑。
• ② 实际业务拉动:真实部署实测撞上(原始记录 steedos-labs/os-project-titanwind-ehr#1809),非投机面;边界影响已被 pin 成断言。
• ③ 防 AI 犯错:A 的失败形态是一句通用「您没有权限」——AI 配置权限时看不见「删除权还需引用表写权」的隐藏链,只能试错;B 让删除语义自含,出错面收敛到真正的数据销毁(cascade)一处,拒绝理由可以指名道姓。
• ④ 创业阶段不扩散:B 是把已裁原则延伸到同一动作的另一半,不新增能力面;C 的销毁面扩权应缓,除非产品语义明确要求。

推荐:B(回退项:A——零改动,但应把「删除需连带引用表写权」写进权限报错 guidance/文档,让隐藏耦合至少可见)。
置信缺口:系统身份 set_null 写入的审计归属(审计日志记操作人还是系统)与共享/RLS 规则外溢面未测;仓外部署是否依赖「cascade 需逐表授权」的现状未测;本分析依据本卡对裁决的引文,未逐字重读裁决评论原文。

裁后执行段(维护者只裁方向):裁 B/C ⇒ 认领评论 Clause-②: yes、契约复审档位派发,落点沿上一裁实现同面,翻转 PR #12596 的边界断言并补 cascade/set_null 各自的方向用例;裁 A ⇒ 关本卡,另立小卡把「删除需引用表写权」补进权限报错 guidance(S 级,domain:engine)。

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded — Option B: set_null cleanup writes switch to system identity; cascade keeps the operator's own authority

Provenance: maintainer, 2026-08-27, PM chat decision-inbox batch 2 (adjudication session session_01DKWDdUJ2XNRESVVWUvcpnh), verbatim: 「同意」 — accepting the triage recommendation B (2026-08-26T16:19Z facet block); fallback A not needed; ⛔ C (cascade also system-identity) stays excluded — a data-destruction privilege expansion that would need its own justification.

Ruled: clearing a referencing pointer (set_null's UPDATE) is engine-owned referential-integrity maintenance and runs under system identity — completing the #12166 principle on the write half, consistent with the RDBMS FK SET NULL baseline and the __referentialFieldClear internal-write marker (#3023). Deleting whole referencing rows (cascade) still requires the operator's own delete authority on those rows.

Dispatch constraints:

1. Clause-②: yes — this expands the delete operation's accepted set; contract-review tier at dispatch.
2. The dev's FIRST measurements, before any code, are the two recorded confidence gaps: (a) audit attribution — what the audit trail records for the system-identity set_null write; it must remain attributable to the initiating operator's delete, not vanish into "system"; (b) RLS/sharing spillover of the elevated write. Either measuring badly ⇒ stop and report, never push through.
3. Flip PR fix(objectql,spec): run the pre-delete reference check under the system identity #12596's boundary pin (the constraint-1 assertion) and add direction cases for both arms: set_null succeeds without referencing-table write authority; cascade still refuses without delete authority on the referenced rows.
4. Lands on the same surface as 删除记录时「引用清理」用操作人身份查询引用表,读权不足即整体 403(应以系统身份执行) #12166's implementation; that ruling's other constraints are untouched.

State: needs-user-decision → pm:queue.

---

Generated by Claude Code

[os-zhuang]

Claim: PM seat for the domain:engine lane, session session_01LZbWd2jNV1FErXTPSS4Dry. Dispatching to an os-dev seat on branch claude/issue-12597-set-null-cleanup-system-identity.

Clause-②: yes — per the maintainer ruling (comment 5434623379), this expands the delete operation's accepted set, so the dev runs at contract-review tier: the accept/reject boundary change is stated explicitly in the PR body, the contract docs are hand-read for falsified sentences (the docs-drift bot is precision-first and cannot see a page that states this rule by its inputs), and the reviewer-of-record check is the boundary, not the diff size.

Scope, straight from the ruling — nothing added, nothing inferred:

• In: set_null's FK-clearing UPDATE runs under system identity (the referential-integrity write half, completing the 删除记录时「引用清理」用操作人身份查询引用表,读权不足即整体 403(应以系统身份执行) #12166 principle).
• ⛔ Out: cascade's child-row DELETE. Option C stays excluded — a data-destruction privilege expansion needing its own justification. A diff that touches the cascade arm's identity is out of scope regardless of how it is argued.

Gate before any code. The ruling's constraint 2 makes two measurements the dev's first actions, ahead of the implementation: (a) what the audit trail records for the system-identity set_null write — it must stay attributable to the initiating operator's delete, not vanish into "system"; (b) the RLS/sharing spillover of the elevated write. Either one measuring badly is a stop-and-report, not a thing to push through. The seat reports back to this card either way.

---

Generated by Claude Code

[claude]

Gate measurements (ruling constraint 2) — result: STOP AND REPORT on gate (b)

os-dev seat, session session_01LZbWd2jNV1FErXTPSS4Dry, branch claude/issue-12597-set-null-cleanup-system-identity (pushed, no commits — no implementation was written).

Per the ruling's constraint 2 these two measurements were the first actions, ahead of any code. Gate (a) reads clean. Gate (b) reads badly in the sense the dispatch defines, and a narrower alternative measured viable and strictly stronger on the security axis, so no implementation followed.

All readings below are executed observations, not source reading. Base commit bc5156fcb.

---

Gate (a) — audit attribution: GOOD

Question. When the set_null UPDATE runs under system identity, does the audit trail still attribute it to the operator who asked for the delete?

Method. Drove the real writeAudit from packages/plugins/plugin-audit/src/audit-writers.ts (via installAuditWriters) on an afterUpdate whose session is exactly what ObjectQL.buildSession emits for a sudo()-shaped context — verified at engine.ts:3353, which copies userId and adds isSystem: true. Three arms: the elevated shape, a bare isSystem control, and a pre-change operator control.

Readings.

audit row   = {"action":"update","user_id":"u_lead","object_name":"os_ehr_andon_record",
               "record_id":"andon-1","old_value":"{\"product\":\"prod-1\"}",
               "new_value":"{\"product\":null}","tenant_id":"org-1","actor":"u_lead"}
activity    = {"type":"updated","actor_id":"u_lead", ...}
control (bare isSystem, no spread) = user_id: null, actor: null
control (pre-change operator write) = user_id: "u_lead", actor: "u_lead"

Verdict: GOOD. The elevated write's ledger row is byte-identical in its attribution half to the pre-change operator write. Three findings behind that:

• The write path has no isSystem suppression. The asymmetry the recordReferenceCheckElevation docblock warns about is real and runs the safe way: read-audit.ts:556 returns early on session.isSystem === true, and audit-writers.ts has no counterpart. A WRITE is indeed a different animal, and the difference favours us.
• Attribution is keyed on sess.userId, which the sudo()-shaped spread preserves. The bare-isSystem control shows the spread is load-bearing, not decorative — a bare { isSystem: true } would have produced exactly the "vanish into system" outcome the ruling forbids.
• Second channel intact: updated_by is stamped from session.userId at plugin.ts:1028 with no isSystem gate, so the cleared row itself still names the operator.

This measurement is not what stops the card.

---

Gate (b) — RLS / sharing spillover: BAD READING

Question. What else does isSystem: true turn off on this write, beyond the object-level CRUD check the ruling intends to bypass?

Mechanism. security-plugin.ts:1560 is if (opCtx.context?.isSystem) { return next(); } — the entire security middleware is short-circuited. Elevation is not granular; there is no narrower spelling of "system identity" in this codebase.

Method. Real SecurityPlugin middleware over a real ObjectQL engine (the same harness shape as the existing suite in delete-reference-cleanup-system-identity.test.ts), one fixture per guard, each run twice: as the plain operator and with the sudo()-shaped elevation.

Readings.

Guard on the referencing object	As operator	Elevated	Bypassed?
Object-level CRUD (the card's 403)	PERMISSION_DENIED op=update	SUCCESS, FK cleared	yes — intended
Field-level security on the FK column	PERMISSION_DENIED op=update, FK unchanged	SUCCESS, FK cleared	yes
RLS using row scope on update (owner_id == current_user.id)	PERMISSION_DENIED op=update, FK unchanged	SUCCESS, FK cleared	yes
RLS post-image check (product != null)	PERMISSION_DENIED op=update, FK unchanged	SUCCESS, FK cleared	yes
Declared validation rule (validations, type script)	VALIDATION_FAILED	VALIDATION_FAILED, FK unchanged	no

Also bypassed on the engine side, by inspection with line cites: the readonly strip (engine.ts:10434 single-row, :10596 bulk) and lookup-target existence validation (engine.ts:5525). The ownership-anchor guard (#3004) is already exempt for this write through the #3023 marker and is unchanged either way.

The good news first: declared validation rules are NOT bypassed — evaluateValidationRules at engine.ts:10453 sits outside the isSystem guard that closes at :10446. That was the dispatch's first named worst case and it measured clean.

But the dispatch's second named worst case measured dirty. The bad reading is defined as the elevation bypassing "a validation rule or sharing restriction that exists for reasons unrelated to referential integrity". An RLS using clause scoping which rows an operator may update, and an RLS post-image check constraining what shape a row may end up in, are both exactly that, and both are bypassed. The RLS check case is the one I find hardest to fit inside the ruling: check is not a reach question at all, it is a data-shape constraint — semantically a validation rule wearing a different hat. The platform now honours "this FK must never be empty" when it is declared as a validations entry and silently ignores it when the same intent is declared as an RLS check clause.

---

The narrowing, measured rather than speculated

The dispatch says to propose a narrowing rather than ship the broad version, so I measured whether one is actually available instead of guessing. Probe: exempt contexts carrying __referentialFieldClear from the CRUD check only (security-plugin.ts:1953), leaving every other guard in place. Reversible, restored and verified byte-clean against the HEAD blob.

	blanket isSystem (as ruled)	marker-scoped CRUD exemption
The card's own fixture — full delete on A, nothing at all on B, non-empty referencing table	SUCCESS	SUCCESS
Field-level security on the FK column	bypassed	enforced
RLS using row scope	bypassed	enforced
RLS post-image check	bypassed	enforced
Declared validation rules	enforced	enforced
Ownership anchor (#3004)	exempt via #3023	exempt via #3023

The narrowing fixes the reported defect and keeps all three guards. That is the whole reason this is a stop rather than a note in a PR body: the broad version is not the only way to satisfy the ruling's stated goal, and the alternative costs the reporting deployment nothing.

Does the #3023 marker already exempt the guard that was 403-ing?

No — measured. A context carrying __referentialFieldClear but not isSystem is still refused with PERMISSION_DENIED op=update. The marker exempts only the ownership-anchor transfer guard at step 3.5 (security-plugin.ts:2474); the refusal in this card comes from the CRUD check at step 2 (:1953), which the marker does not reach. The card's diagnosis is complete and correct on this point — no correction needed there.

The repo's own posture, which I did not expect to find

content/docs/permissions/system-context.mdx is the platform's stated authority on this flag, and it says:

Elevation is total, and it is not granular. isSystem is not "skip the permission check". It short-circuits authorization, ownership stamping, read-only protection, referential-integrity checks, sharing materialisation, approval locks and provenance stamping — in eighteen packages that do not know about each other. Read the table before you set it; prefer a scoped user context whenever one exists.

One demonstrably exists here, and the measurement above is what shows it.

Where I think this lands, on the four axes

• Real business need. Both options fix the reported deployment; measured, not argued. So need does not discriminate — which means the tie breaks on cost, and the broad option's extra cost is three bypassed guards nobody asked for.
• Long-term soundness. The ruling's own baselines cut the other way and I want to be straight about it: PostgreSQL's FK SET NULL and Salesforce's lookup clearing both bypass row security, and the narrowing is stricter than both. The counterweight is that this platform, unlike either baseline, lets a deployment declare a post-image check on the referencing object — a surface the FK analogy simply has no equivalent for, so the analogy stops carrying weight exactly where the spillover is.
• Making AI-written metadata hard to get wrong. This is where I think the narrowing wins clearly. Under the broad version a declared RLS check is honoured or ignored depending on which code path reaches the row, and nothing in the authoring surface says so. That is a rule that is declared but not enforced, which is the failure shape this project treats as most expensive.
• Startup scope discipline. The narrowing is a smaller permission-surface change, not a larger one. It does add an exemption path to plugin-security where the broad version adds no new mechanism at all — a real cost, and the one honest argument for the broad version on this axis.

Recommendation: the marker-scoped narrowing, with the RLS check bypass being the single reading I would most want the maintainer to look at before deciding. Either way this is a permission-boundary semantics change and the choice is above my floor, so I have written no code and opened no PR.

Out-of-scope finding filed unassigned while measuring: #12802.

---

Generated by Claude Code

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 12597,
  "status": "needs_decision",
  "branch": "claude/issue-12597-set-null-cleanup-system-identity",
  "pr": null,
  "premise_still_valid": true,
  "summary": "No implementation. Ruling constraint 2's two gate measurements were run first, as required; gate (a) reads clean and gate (b) reads badly in the sense the dispatch defines, so this is the stop-and-report the dispatch calls for rather than a PR. Gate (b): `isSystem` short-circuits the ENTIRE security middleware at security-plugin.ts:1560, and measurement shows the elevated set_null write would additionally bypass field-level security on the FK column, the RLS `using` row scope on update, and the RLS post-image `check` -- the last of which is a data-shape constraint unrelated to referential integrity, semantically a validation rule in different clothing. Declared validation rules themselves are NOT bypassed (engine.ts:10453 sits outside the isSystem guard), which was the dispatch's first named worst case and it measured clean. I then measured the narrowing the dispatch names instead of speculating about it: a marker-scoped exemption of the CRUD check alone fixes the card's exact fixture (role with full delete on A and NOTHING on B, non-empty referencing table) while keeping FLS, RLS `using` and RLS `check` all enforced. Both options fix the reported deployment; only one of them spends three extra guards to do it. That choice is a permission-boundary semantics change above my floor, so no code was written. The branch is pushed but carries NO commits.",
  "gate_a_audit_attribution": {
    "verdict": "GOOD -- attribution survives the elevation intact",
    "method": "Drove the real writeAudit (installAuditWriters, plugin-audit/src/audit-writers.ts) on an afterUpdate whose session is exactly what ObjectQL.buildSession (engine.ts:3353) emits for a sudo()-shaped context. Three arms: elevated, bare-isSystem control, pre-change operator control.",
    "readings": {
      "elevated": "sys_audit_log {action:update, user_id:'u_lead', actor:'u_lead', old_value:{product:'prod-1'}, new_value:{product:null}}; sys_activity {actor_id:'u_lead'}",
      "bare_isSystem_control": "user_id: null, actor: null -- proves the sudo() spread is load-bearing, not decorative",
      "pre_change_operator_control": "user_id: 'u_lead', actor: 'u_lead' -- byte-identical attribution half to the elevated arm"
    },
    "why_it_holds": "The write path has NO isSystem suppression: read-audit.ts:556 returns early on session.isSystem, audit-writers.ts has no counterpart. The docblock's warning that a WRITE is a different animal is correct and the difference runs the safe way. Second channel intact too: updated_by is stamped from session.userId at plugin.ts:1028 with no isSystem gate."
  },
  "gate_b_rls_sharing_spillover": {
    "verdict": "BAD READING -- the elevation bypasses guards unrelated to referential integrity",
    "mechanism": "security-plugin.ts:1560 -- `if (opCtx.context?.isSystem) { return next(); }`. Elevation is total; there is no narrower spelling of system identity in this codebase.",
    "method": "Real SecurityPlugin middleware over a real ObjectQL engine, one fixture per guard, each run as the plain operator and with the sudo()-shaped elevation.",
    "readings": [
      "object-level CRUD (the card's 403): operator=PERMISSION_DENIED op=update | elevated=SUCCESS, FK cleared -- INTENDED",
      "field-level security on the FK column: operator=PERMISSION_DENIED op=update, FK unchanged | elevated=SUCCESS, FK cleared -- BYPASSED",
      "RLS `using` row scope on update (owner_id == current_user.id): operator=PERMISSION_DENIED op=update, FK unchanged | elevated=SUCCESS, FK cleared -- BYPASSED",
      "RLS post-image `check` (product != null): operator=PERMISSION_DENIED op=update, FK unchanged | elevated=SUCCESS, FK cleared -- BYPASSED",
      "declared validation rule (validations, type script): operator=VALIDATION_FAILED | elevated=VALIDATION_FAILED, FK unchanged -- NOT bypassed"
    ],
    "why_bad": "The dispatch defines a bad reading as the elevation bypassing 'a validation rule or sharing restriction that exists for reasons unrelated to referential integrity'. The validation-rule half measured clean; the sharing half did not. The RLS `check` case is the sharpest: `check` is not a reach question at all, so the platform would honour 'this FK must never be empty' when declared as a validations entry and silently ignore it when the same intent is declared as an RLS check clause."
  },
  "guards_bypassed_enumerated": [
    "plugin-security step 2, object-level CRUD check (security-plugin.ts:1953) -- MEASURED bypassed; this is the one the ruling intends",
    "plugin-security step 2.5, field-level security write enforcement (:2293) -- MEASURED bypassed",
    "plugin-security step 2.7, row-level WRITE authorization / RLS `using` pre-image (:2058) -- MEASURED bypassed",
    "plugin-security step 3, RLS filter injection (:2913) -- bypassed (same short-circuit)",
    "plugin-security step 3.6, RLS WRITE `check` post-image (:2581) -- MEASURED bypassed",
    "plugin-security step 3.5, ownership-anchor guard (:2432) -- already exempt via the #3023 marker; unchanged either way",
    "plugin-security step 3.7, Layer-0 tenant post-image check (:2667) -- bypassed (same short-circuit)",
    "plugin-security step 1.5, requiredPermissions AND-gate (:1891); step 2.8, controlled-by-parent write (:2259); step 2.9, field-predicate guard (:2861) -- bypassed (same short-circuit)",
    "objectql readonly-field strip, single-row (engine.ts:10434) and bulk (:10596) -- bypassed by inspection",
    "objectql assertReferencesResolve lookup-target existence validation (engine.ts:5525) -- bypassed by inspection",
    "NOT bypassed: declared validation rules -- evaluateValidationRules (engine.ts:10453) sits outside the isSystem guard closing at :10446. MEASURED."
  ],
  "marker_exemption_answer": "NO -- the #3023 __referentialFieldClear marker does NOT cover the guard that was 403-ing. MEASURED: a context carrying the marker but not isSystem is still refused with PERMISSION_DENIED op=update. The marker exempts only the ownership-anchor transfer guard at step 3.5 (security-plugin.ts:2474); the card's refusal comes from the CRUD check at step 2 (:1953), which the marker does not reach. The card's diagnosis is therefore COMPLETE and CORRECT on this point -- no correction needed.",
  "narrowing_probe": {
    "what": "Exempted contexts carrying __referentialFieldClear from the CRUD check ONLY (security-plugin.ts:1953), leaving every other guard in place. Reversible probe, not an implementation.",
    "mutation_proof_on_disk": "anchor count before=4, injected form count=1, original form count 4->3; file hash e129cc46 -> 6bfef4f4",
    "restore_proof": "post-restore hash-object == HEAD blob e129cc4664515d572124577dd7a50501bd65154f, and `git diff HEAD --name-only` on the file returned EMPTY",
    "marker_absent_on_pre_change_ref": "git show origin/main:...security-plugin.ts | grep -c INJECTED_FORM = 0, with a positive control on the same ref returning 4 -- so the marker is specific to the probe, not merely present in the right tree",
    "result": "The card's exact fixture SUCCEEDS under the narrowing, while FLS, RLS `using` and RLS `check` all still REFUSE. Measured, all three arms."
  },
  "cascade_arm": "UNCHANGED and untouched -- no diff line to quote because there is no diff. The cascade arm (`await this.delete(childName, { where: { id: depId }, context } as any)` in cascadeDeleteRelations) was never edited; the worktree was verified clean and removed with zero commits on the branch. Option C remains excluded.",
  "bump_argument": "N/A -- no changeset, because there is no user-visible change and no implementation. If the maintainer rules for either option, the write-identity change on an existing operation argues for MINOR rather than patch: it changes who a write executes as, which is a behavioural contract change deployments can observe in their audit ledger and permission matrices, not a defect repair.",
  "tests": "No product tests -- nothing was implemented. Measurement runs only, all through scripts/pm/os-verify-lock.sh, all foreground. (1) `pnpm --filter @objectstack/plugin-audit exec vitest run --maxWorkers=2 src/zz-gate-measure-a.test.ts` -- first attempt was NOT MEASURED, not red: prerequisite refusal `Cannot find package '@objectstack/objectql/core'` (unbuilt dist). (2) `pnpm --workspace-concurrency=2 --filter '@objectstack/plugin-audit^...' --filter '@objectstack/plugin-security^...' build` -- lock VERDICT command-exit 0, held 196s. (3) gate (a) re-run -- lock VERDICT command-exit 0, `Tests 3 passed (3)`, readings captured to file. (4) `pnpm --filter @objectstack/plugin-security exec vitest run --maxWorkers=2 src/zz-gate-measure-b.test.ts` -- lock VERDICT command-exit 0, `Tests 7 passed (7)`. (5) narrowing probe (mutate/measure/restore with trap on EXIT INT TERM and absolute paths) -- lock VERDICT command-exit 0, `Tests 1 failed | 7 passed (8)`, the one failure being the probe's own expected flip (B2 asserted PERMISSION_DENIED and returned SUCCESS under the narrowing -- that flip IS the reading). Verdicts read from the lock's own VERDICT lines and vitest's own summary lines, never a bare $?. Ablation discipline applied to the probe: mutation proven on disk by anchored greps in BOTH directions plus a hash change, restore proven by hash-object equality against the HEAD blob plus an empty git diff. Measurement harnesses preserved at /tmp/claude-0/-home-user-objectstack/5b7dbdcd-321c-5e24-9c7d-c179ce356a6a/scratchpad/issue-12597/harness-gate-a.test.ts and harness-gate-b.test.ts; both were deleted from the worktree, which was verified clean before removal.",
  "mcp_calls": "2 -- one targeted search_issues for dedupe (REST /search/issues is blocked for this seat: 'sessions are bound to their configured repositories'), plus one positive-control search to make the zero-hit a reading. All issue/comment reads and both writes went over repo-scoped REST.",
  "open_questions": [
    {
      "question": "The ruling says the set_null cleanup write 'runs under system identity'. Measurement shows that in this codebase system identity is total: it also bypasses field-level security, the RLS `using` row scope and the RLS post-image `check` on the referencing object. A marker-scoped exemption of the CRUD check alone was measured to fix the reported deployment while keeping all three. Which does the maintainer want?",
      "options": [
        "A. Blanket `isSystem` as literally ruled. Matches the cited baselines exactly (PostgreSQL FK SET NULL and Salesforce lookup clearing both bypass row security). Adds no new mechanism. Cost: three guards bypassed that exist for reasons unrelated to referential integrity, most sharply the RLS post-image `check`, which is a data-shape constraint the FK analogy has no equivalent for -- so a deployment's declared `check` becomes declared-but-not-enforced depending on which code path reaches the row.",
        "B. Marker-scoped exemption of the object-level CRUD check only, keeping FLS / RLS `using` / RLS `check` enforced. MEASURED to fix the card's exact fixture (full delete on A, nothing at all on B, non-empty referencing table). Cost: stricter than both cited baselines; adds an exemption path to plugin-security rather than reusing the existing identity flag; a deployment that FLS-locks the FK column or RLS-scopes the referencing rows still gets a refused delete -- truthful and declared, but still refused.",
        "C. Blanket `isSystem` now, with the RLS `check` bypass filed as a separate card. Ships the ruling as written and keeps the sharpest edge visible. Cost: the gap is live in the meantime, and 'we will fix it later' on a permission boundary is the shape that does not get fixed later."
      ],
      "recommendation": "B. Both A and B fix the reported deployment -- that is measured, not argued -- so real business need does not discriminate between them and the tie breaks on what each spends. A spends three guards nobody ruled on; B spends none. On making AI-authored metadata hard to get wrong, B wins clearly: under A a declared RLS `check` is honoured or ignored depending on the code path, with nothing in the authoring surface saying so, which is exactly the declared-but-not-enforced shape this project treats as most expensive. The honest argument for A is that the ruling's own baselines bypass sharing and B is stricter than both -- but neither baseline lets a deployment declare a post-image `check` on the referencing object, so the analogy stops carrying weight precisely where the spillover is. The repo's own authority agrees with B in general terms: content/docs/permissions/system-context.mdx states 'Elevation is total, and it is not granular' and 'prefer a scoped user context whenever one exists' -- and one demonstrably exists here."
    }
  ],
  "out_of_scope_findings": [
    "filed as #12802: the isSystem census page (content/docs/permissions/system-context.mdx) advertises itself as the authority 'built by census, not recall' but its file:line anchors have drifted -- all three rows I checked resolve to unrelated lines (row 18 cites engine.ts:3314, actual :5525; row 13 cites :6860, actual :10434; row 14 cites :7004, actual :10596). Filed unassigned with pm:queue as this dispatch instructs; flagging that my standing rules would have labelled a docs-drift observation `finding` rather than pm:queue, so retag if you prefer that convention."
  ]
}

---

Generated by Claude Code

[os-zhuang]

STOP-AND-REPORT — ruling constraint 2 fired. No implementation, returned for a second ruling.

The dispatched seat ran the two gate measurements before any code, as constraint 2 required. Gate (a) reads clean; gate (b) reads badly in the sense the dispatch defined. Per that instruction it stopped rather than pushing through. Branch claude/issue-12597-set-null-cleanup-system-identity was pushed at base and carries zero commits; no PR exists; the cascade arm was never touched and ⛔ Option C remains excluded.

State: pm:dispatched → needs-user-decision, unassigned.

I re-verified every load-bearing claim below against origin/main myself rather than relaying the seat's report — a ruling will rest on these.

Gate (a) — audit attribution: GOOD, the elevation is safe here

Driven against the real writeAudit (plugin-audit/src/audit-writers.ts) on a session shaped exactly as ObjectQL.buildSession (engine.ts:3353) emits for a sudo()-shaped context. Three arms:

arm	user_id / actor
elevated set_null write	u_lead / u_lead — old {product:'prod-1'} → new {product:null}
bare isSystem control	null / null
pre-change operator control	u_lead / u_lead — byte-identical to the elevated arm

The bare-isSystem control is the part that makes this a reading rather than a hope: it proves the sudo() spread carrying userId is load-bearing, not decorative. The write path has no isSystem suppression — read-audit.ts:556 returns early on session.isSystem and audit-writers.ts has no counterpart — so the asymmetry the referenceCheckContext docblock warns about (a WRITE is a different animal from the elevated READ) runs the safe way here. updated_by is stamped from session.userId at plugin.ts:1028 with no isSystem gate, so attribution has two intact channels.

Gate (b) — RLS / sharing spillover: BAD

Mechanism, verified: plugin-security/src/security-plugin.ts:1559-1561 —

// System operations bypass security
if (opCtx.context?.isSystem) {
  return next();
}

That sits ahead of every later step, so the elevation is total. There is no narrower spelling of system identity in this codebase. The repo's own page says so in as many words — content/docs/permissions/system-context.mdx:19: "Elevation is total, and it is not granular."

Measured, one fixture per guard, each run as the plain operator and again with the sudo()-shaped elevation:

guard	operator	elevated
object-level CRUD (the card's 403)	PERMISSION_DENIED op=update	SUCCESS — ✅ intended
field-level security on the FK column	PERMISSION_DENIED, FK unchanged	SUCCESS, FK cleared — ⚠️ bypassed
RLS using row scope on update	PERMISSION_DENIED, FK unchanged	SUCCESS, FK cleared — ⚠️ bypassed
RLS post-image check	PERMISSION_DENIED, FK unchanged	SUCCESS, FK cleared — ⚠️ bypassed
declared validation rule	VALIDATION_FAILED	VALIDATION_FAILED, FK unchanged — ✅ not bypassed

The dispatch's first-named worst case — "it would let the FK-clear write through a validation rule" — measured clean. I confirmed why: evaluateValidationRules runs in the engine's own update path (engine.ts:10453), outside plugin-security's short-circuit entirely.

The sharpest edge is the RLS post-image check. check is not a reach question at all; it is a data-shape constraint. So the platform would honour "this FK must never be empty" when a deployment declares it as a validations entry, and silently ignore the same intent declared as an RLS check clause — enforcement depending on which spelling the author chose, with nothing in the authoring surface saying so.

The #3023 marker question, answered: NO

The __referentialFieldClear marker does not cover the guard that was 403-ing. Measured: a context carrying the marker but not isSystem is still refused with PERMISSION_DENIED op=update. I verified the structure — the marker gates a different block (:2474, the ownership-anchor transfer guard), while the card's refusal comes from the CRUD check at :1953, which the marker never reaches.

⇒ the card's diagnosis is complete and correct on this point. No correction needed.

The narrowing — measured, not speculated

Rather than argue about a hypothetical, the seat probed it. Exempting __referentialFieldClear contexts from the CRUD check alone, leaving every other guard standing:

the card's exact fixture (role with full delete on A and nothing at all on B, non-empty referencing table) SUCCEEDS, while FLS, RLS using and RLS check all still REFUSE. All three arms measured.

Reversible probe under full ablation discipline: mutation proven on disk by anchored greps in both directions plus a file-hash change (e129cc46 → 6bfef4f4); restore proven by git hash-object equality against the HEAD blob plus an empty git diff; and the probe marker verified absent on the pre-change ref (grep -c = 0 with a positive control returning 4 on the same ref) — so the marker is specific to the probe, not merely present in the right tree.

⇒ both A and B fix the reported deployment. That is measured, not argued.

---

裁定格式,四棱分析(中文):

一句话问题:上一裁把 set_null 的清理写入判为「以系统身份执行」,但实测表明本仓的系统身份是全量的 —— 它同时绕过被引用表的字段级安全、RLS 行域 using、以及 RLS 后像 check。而一个只豁免对象级 CRUD 检查的收窄方案,实测同样修好了原报告的部署。裁决当时未必知道「系统身份」在本仓意味着这么多。

选项 × 真实代价:

• A(按裁决字面,blanket isSystem):与裁决援引的基线完全一致(PostgreSQL FK SET NULL 与 Salesforce lookup 清空都绕过行安全),不新增任何机制。代价:三个与引用完整性无关的守卫被一并绕过,其中 RLS 后像 check 最刺眼 —— 它是数据形状约束,FK 类比里根本没有对应物,于是部署方声明的 check 变成「取决于走哪条代码路径才生效」。
• B(marker 限定豁免,只放行对象级 CRUD 检查):实测修好本卡夹具(对 A 有完整删除权、对 B 毫无授权、引用表非空),同时 FLS / RLS using / RLS check 三者仍然拒绝。代价:比裁决援引的两个基线都更严;在 plugin-security 里新增一条豁免路径,而不是复用既有的身份标志;若部署方对 FK 列上了字段级安全或对引用行设了 RLS,删除仍会被拒 —— 拒得诚实、拒得有声明依据,但仍是拒。
• C(先按 A 发,把 RLS check 外溢另开一卡):照裁决原样落地,把最锋利的那条边留在明面上。代价:缺口在此期间是活的,而「权限边界的问题以后再补」正是那种补不上的形状。

四棱:

• ① 项目长远合理性:A 与工业基线同构,论证现成;但本仓允许部署方在被引用表上声明后像 check,而两个基线都不允许 —— 类比恰好在外溢发生处失效。
• ② 实际业务拉动:不区分。A、B 都实测修好了原报告部署(steedos-labs/os-project-titanwind-ehr#1809),所以真实拉力在这一档上不构成取舍依据,取舍落在各自花掉什么。
• ③ 防 AI 犯错:B 明显占优。A 之下,一条已声明的 RLS check 到底生效与否取决于代码路径,而授权界面上看不出来 —— 这正是本项目视为最贵的 declared-but-enforced 不一致形状,和当初催生 ADR-0049 的是同一个族。
• ④ 创业阶段不扩散:A 不新增机制但扩大了绕过面;B 不扩大绕过面但新增一条豁免路径。两者都不算扩散,B 的新增面更小且可指名。

派发席建议:B。⚠️ 这是受派 dev 席的建议,不是本 PM 的裁定 —— 权限边界语义在我的判定层之上,我只负责把测量如实上呈。仓内既有权威与 B 同向:content/docs/permissions/system-context.mdx:19「Elevation is total, and it is not granular」,并主张「prefer a scoped user context whenever one exists」—— 而此处确实存在一个可用的收窄。
支持 A 的诚实论点:裁决援引的基线确实绕过 sharing,B 比两者都严;若产品语义就是要与 Salesforce 对齐,A 才是忠于裁决的那一档。

置信缺口:仓外部署是否已依赖「引用清理受 FLS/RLS 约束」的现状,未测。B 新增的豁免路径本身是否会成为下一个被滥用的标记,未评估。

---

⛔ Not dispatchable until ruled. ⛔ Option C (cascade under system identity) stays excluded either way — untouched by this report.

---

Generated by Claude Code