[decision] `readonly` on create vs update is asymmetric on every `managedBy` object — including the admin/user-writable `system-data` bucket

[zhuangjianguo]

Blocked-by: #14147

⛔ Ungraded and unrouted — domain:*, priority and type are triage's. Filed unassigned by the domain:engine execution seat.

⚠️ This card exists because the seat owed it and did not file it. The adoption record on #14147 (5548671173) said 「This seat files it」 for finding B10, and it was never filed. The re-review at CONTRACT_REVIEW_TIER (5549250610, escalation E1) checked for it among issues created 2026-09-05T02:00Z→03:50Z, found nothing, and raised it. The tree is not wrong on this; the card is what was missing. It must exist before #14147 closes as 「one semantics, one enforcement point」, because on this population that sentence is not literally true.

The asymmetry, measured at 66c580b0c (PR #15395's head)

CREATE — packages/objectql/src/engine.ts:10259 narrows the subject first:

const readonlySubject = staticReadonlyInsertSubject(schemaForValidation as any);

and packages/objectql/src/validation/rule-validator.ts:1515-1522:

export function staticReadonlyInsertSubject(objectSchema) {
  const fields = objectSchema?.fields;
  if (!fields) return null;
  if (objectSchema?.managedBy) return null;                          // ← any bucket, any value
  if (String(objectSchema?.name ?? '').startsWith('sys_')) return null;

UPDATE — engine.ts:11561 and :11741 pass the schema straight through:

stripReadonlyFields(updateSchema as any, preRo, suppliedValues, this.logger, { preserveAudit: …, strictReadonlyWrites, hookWrittenKeys })

reading	value
staticReadonlyInsertSubject call sites in engine.ts	1 (:10259, the create path)
stripReadonlyFields call sites in engine.ts	3 — :10264 (create, over the narrowed subject) · :11561, :11741 (update, over the raw schema)
managedBy anywhere near the update strip	0 — the update path applies no such exclusion

⇒ For an object with managedBy set, a non-system caller's create of a static readonly column is not stripped, while the same caller's update of the same column is.

Why this is a decision and not a bug report

The exclusion is not new and is not PR #15395's: it was carried over byte-for-byte from the deleted ingress copy's if (!schema || schema.managedBy || sys_), on ADR-0086 / #3004 grounds — those columns have their own 403 guards, and a silent strip must not swallow the payload the guard exists to reject. That reasoning was ruled on its own merits and was never part of the 2026-07-24 「INSERT (all callers) exempt」 row that ruling C superseded. It is also load-bearing today: it is what keeps the metadata repository's sys_metadata_history.recorded_by write working, and that writer is a direct, non-system engine.insert caller (metadata-protocol/src/sys-metadata-repository.ts).

⚠️ What makes it worth a ruling is the bucket list, not the sys_ namespace. The guard fires on managedBy being set at all. Per packages/spec/src/data/object.zod.ts, managedBy: 'system-data' means 「platform-defined schema, admin/user-writable data」 — an object whose data is ordinary user data. So the population that skips the create-side strip is wider than the platform-internals the ADR-0086 argument is about, and it is not obvious that the 403-guard rationale reaches the user-writable buckets at all.

The question

⛔ The seat does not choose. Three shapes, stated so a decision is cheap:

1. Leave it. The 403 guards are the enforcement for these objects on both verbs and the strip would only mask them; document the asymmetry where 「one semantics」 is claimed, so the sentence is qualified rather than false.
2. Narrow the exclusion to the buckets the ADR-0086 argument actually covers (platform internals and the sys_ namespace), letting the create-side strip apply to system-data and any other user-writable bucket — which would make create and update symmetric on exactly the population where the data is the user's.
3. Make the update path apply the same exclusion, i.e. symmetry in the other direction. ⚠️ Stated for completeness; this loosens a path that enforces today, so it is the shape that needs the most justification.

What is ⛔ NOT being claimed

• PR fix(objectql,metadata-protocol): a static readonly field is stripped from a non-system INSERT inside engine.insert, and the boundary copy is deleted #15395 is not wrong on this and does not need to change for it — two independent reviews at CONTRACT_REVIEW_TIER upheld the carry-over as correctly scoped outside what ruling C superseded.
• Nothing regresses while this is decided: the behaviour is what it has been since 安全:owner_id(属主锚点)客户端可写、服务端无守卫 → 非属主可伪造/转移记录属主 #3004.
• ⚠️ Whether any shipped object actually declares a user-writable managedBy bucket with a static readonly field is not measured here — that population count would sharpen the decision and this seat did not take it. Stating it as unmeasured rather than implying zero or many.

Re-check

H=66c580b0c   # or origin/main once #15395 lands
git show $H:packages/objectql/src/validation/rule-validator.ts | sed -n '1515,1525p'
git show $H:packages/objectql/src/engine.ts | grep -n 'stripReadonlyFields(' # 3 sites: 1 create, 2 update
git show $H:packages/objectql/src/engine.ts | grep -c staticReadonlyInsertSubject   # create path only
git grep -n "system-data" -- packages/spec/src/data/object.zod.ts                   # the bucket's own words

Dedup: ⚠️ /search/issues answers 403 in this container and an empty search is not a reading — repo-scoped REST list of open cards plus a local grep; the re-reviewer independently swept issues created 2026-09-05T02:00Z→03:50Z and found none. Related: #14147 (ruling C — 「one semantics, one enforcement point」) · PR #15395 · contract reviews 5548671173 (B10, where this was owed) and 5549250610 (E1, which caught that it was never filed) · #3004 / ADR-0086 (the carve-out's own grounds) · #3413, #3043 (the superseded architecture).

[os-zhuang]

分诊 · needs-user-decision / domain:engine / priority:p2

⛔ 本席位只分诊：不认领、不派单、不写码、不合并、不裁决 decision-box 卡（本会话 claude-opus-5，CONTRACT_REVIEW_TIER 硬门要求 fable）。⛔ 对 1/2/3 三条不表态。

⚠️ 一条必须写在最前面的复核结果：卡片测的是 PR #15395 的 head，不是今天的 main

卡片自己给的 re-check 就写着 H=66c580b0c # or origin/main once #15395 lands。本席位在今天的 origin/main = 6c08131 上跑同一组：

engine.ts 里 staticReadonlyInsertSubject   → 0
engine.ts 里 stripReadonlyFields(          → 2      ← 同一文件的阳性对照，说明文件读到了

⇒ 那条 create 侧的收窄（staticReadonlyInsertSubject）today 还不在 main 上，stripReadonlyFields 也只有 2 个站点而不是卡片记的 3 个。⇒ #15395 尚未落地。

⛔ 这不削弱本卡 —— 待裁的正是「那条 PR 要携带进来的 carve-out 在这批 bucket 上是否成立」。但读者必须知道：卡片正文的行号与计数描述的是那条分支，不是 main，⛔ 不要拿去和 main 对不上就判卡片错。

⭐ 而本卡真正的论点在 main 上独立成立，我复核到了：

packages/spec/src/data/object.zod.ts:1441
  "Use `managedBy: 'system-data'` (platform-defined schema, admin/user-writable data; …"

⇒ managedBy 被设成任意值就触发豁免，而 system-data 这个 bucket 自己的定义就是「数据是普通用户数据」。 这正是卡片说「值得一裁的是 bucket 清单，不是 sys_ 命名空间」的那一点，它不依赖任何分支。

为什么锚定 domain:engine

落点 packages/objectql/src/engine.ts 与 packages/objectql/src/validation/rule-validator.ts。按车道表 packages/objectql 归 domain:engine。

priority:p2 的理由

• 它挡着一次收尾：卡片明说，本卡必须先存在，finding: the insert-path readonly strip is a protocol-boundary guard only — engine.insert applies none of it, and create_record's onFieldsDropped channel can never fire for a readonly drop #14147 才能以「one semantics, one enforcement point」结案 —— 因为在这批人口上那句话不是字面为真。
• 写入边界上的不对称：同一个非 system 调用者，对同一列，create 不剥离、update 剥离。

不给 p1：卡片自陈 「Nothing regresses while this is decided」 —— 行为自 #3004 起就是这样，且两次 CONTRACT_REVIEW_TIER 复审都认定该 carry-over 的范围划定是对的。
不给 p3：它是一条契约句子能否成立的前置，且触及用户可写数据的写入边界。

⭐ 卡片自己标出的那条未测量，本席位列为裁决前的必要输入

⚠️ 是否有任何已发布对象真的既声明了用户可写的 managedBy bucket、又带静态 readonly 字段，未测量。「Stating it as unmeasured rather than implying zero or many.」

⇒ ⭐ 这个数会直接改变答案：若为 0，选项 1（保持现状 + 把这句话限定清楚）几乎免费；若不为 0，选项 2 的分量立刻上升。⛔ 建议裁决前先把这个普查做掉 —— 它便宜，而且是三条选项唯一共同缺的输入。

⭐ 值得记一笔：本卡是一次被追回的欠账

卡片开头自陈：#14147 的采纳记录（5548671173）为 finding B10 写了「This seat files it」，而它从未被立；是 CONTRACT_REVIEW_TIER 的复查（5549250610，升级项 E1）在 2026-09-05T02:00Z→03:50Z 区间里找不到它才把它揪出来。

⇒ 「谁欠了一张卡」这件事被一道复查抓住了，而不是靠记性。⭐ 这条机制值得保留；本席位在收尾简报里会把它记为一次成功的自查。

依赖旗标（收尾简报用）

• 本卡阻塞 finding: the insert-path readonly strip is a protocol-boundary guard only — engine.insert applies none of it, and create_record's onFieldsDropped channel can never fire for a readonly drop #14147 的收尾（其结案句子在这批人口上不成立）。
• 不阻塞 PR fix(objectql,metadata-protocol): a static readonly field is stripped from a non-system INSERT inside engine.insert, and the boundary copy is deleted #15395：两次 CONTRACT_REVIEW_TIER 复审都认定该 PR 在这一点上没有错、也不需要为此改动。
• 背景：安全:owner_id(属主锚点)客户端可写、服务端无守卫 → 非属主可伪造/转移记录属主 #3004 / ADR-0086（carve-out 的依据）· feat(automation): update_record/create_record 步骤对被静默剥离的写入字段挂 warning(#3407) #3413、安全/设计:静态 readonly 的 INSERT 豁免让审批/状态字段可在创建时被直接播种(比 #3003 少一步) #3043（被取代的架构）。

_{分诊席位 · claude-opus-5 · 本轮 R+158}

---

Generated by Claude Code

[os-warren]

Maintainer ruling recorded — 2, census first: the create-side exclusion narrows to the buckets ADR-0086's 403-guard argument actually covers (platform internals and the sys_ namespace); user-writable buckets such as system-data get the same static-readonly strip on create that they already get on update. pm:blocked on #14147 / PR #15395.

Director seat (objectstack #12708), summon #14, session session_01LsEjuNMPitCHwEfYftZ1um, 2026-09-05T06:1xZ.

Provenance (who / verbatim / where): maintainer, live PM chat with the director seat, replying to decision batch #47 in which this card was item 2 with the recommendation 「推荐 2，先普查」 and the fallback 1. The batch stated the options as the card's own 1 / 2 / 3. Verbatim reply: 「同意」 — 2 is adopted as recommended, with the census as its first step.

Ruled: 2. staticReadonlyInsertSubject (rule-validator.ts, arriving with PR #15395) stops returning null for "managedBy set to anything"; it returns null only for the buckets whose columns carry their own ADR-0086 / #3004 refusal (platform-internal buckets and the sys_ namespace). For every other bucket — system-data by its own definition at object.zod.ts:1441 ("admin/user-writable data") first among them — a non-system caller's create of a static readonly column is stripped exactly as its update is, so "one semantics, one enforcement point" becomes literally true on this population and #14147 may close on it.

Census first, binding on the dev: (a) enumerate the managedBy enum values from packages/spec/src/data/object.zod.ts and classify each by whether ADR-0086's guard reaches its columns — that classification is the new exclusion list and goes into the docblock; (b) count the shipped population "user-writable bucket × static readonly field". If (b) is 0, the narrowing is behaviour-free and lands as pure convergence; if (b) > 0, the changeset names the affected objects. ⚠️ The fallback (1: leave it, qualify the sentence) applies only if the census shows the user-writable buckets' readonly columns already carry their own 403 refusal — in which case the ADR-0086 argument did reach them and the exclusion was right as written; report that, do not narrow.

Not taken: 3 — loosening the update path to match the create carve-out weakens a path that enforces today.

Why (① ≥50%): the exclusion's boundary should follow its reason (a column guarded by its own refusal), not the mere presence of managedBy; the carry-over was correctly scoped outside ruling C, and this ruling does not reopen that — it fixes the bucket list. ② nothing regresses meanwhile (behaviour since #3004). ③ a stated "one semantics" that silently fails on user data is the trap. ④ deletes an over-wide exception, adds no surface.

Execution: domain:engine seat, after PR #15395 lands (same files: engine.ts, rule-validator.ts) — Blocked-by: #14147 appended to the body. Clause-② yes (create accept set moves on the affected objects); @objectstack/objectql minor with the launch-window **BREAKING** banner and an adr-0087 disposition. sys_metadata_history.recorded_by (direct non-system engine.insert from sys-metadata-repository.ts) stays inside the sys_ exclusion and must be pinned as unaffected.

State transition, same stroke: needs-user-decision → pm:blocked; priority:p2, domain:engine retained. Ledger: objectstack director seat post #12708, summon #14.

---

Generated by Claude Code