`isSystem: true` has at least three distinct, undocumented side effects across three packages — each one has cost an app-side bug

[os-zhuang]

Filed from the HotCRM reference app after the third one bit us in a single day. Each was found separately, by a different task, and none is written down anywhere that connects it to the others.

The three behaviours

isSystem: true on a write is used by the seed loader and by internal writers. Across three different packages it changes three unrelated things:

#	package	effect	how we found it
1	ObjectQL (applySystemFields)	owner_id is not injected — the row is written with no platform owner	hotcrm#622: demo_bootstrap had to sweep and stamp ownership after the fact
2	write pipeline	readonly stripping is bypassed — a readonly field CAN be written	hotcrm#613: relied on deliberately, so a seed_key column exists that only the seed loader can write
3	plugin-sharing	grant materialisation is skipped — the record-write hook returns early, so no sys_record_share rows are created	hotcrm#640: every seeded row is isSystem, so a fully-configured sharing rule granted nothing until a rule was re-evaluated

Number 3 is the one that motivated this issue. On a fresh install we had: 9 sharing rules installed, 9 accounts matching their criteria, users holding the right positions — and sys_record_share empty. Every visible layer said the feature was configured. Nothing anywhere said that the seed path had skipped materialisation, and no amount of reading the sharing metadata could have revealed it.

Why this is worth a single issue rather than three

Individually each is defensible. Together they mean isSystem is not one concept — it is at least three policies (ownership, field protection, sharing) sharing one boolean, implemented in three packages, discoverable only by reading each package's source.

That has two concrete consequences:

• An author cannot predict what a seeded row will look like. We reasoned correctly about Add metamodel interfaces for ObjectQL/ObjectUI contract #1 and ✨ Set up Copilot instructions #2 and were still wrong about Implement ObjectStack protocol specification with Zod schemas and TypeScript interfaces #3, because knowing two of the three gives no hint that a third exists.
• The failure mode is always "configured but inert". In all three cases the metadata is complete and correct; the gap is invisible from the metadata and only observable by querying the resulting rows. For AI-authored metadata this is close to worst-case: the author has no signal, and validation has nothing to complain about.

What we would like

1. Document the full set. The minimum useful artifact is one table listing every behaviour keyed off isSystem, in one place, maintained as the authority. If there is a fourth we have not hit yet, that table is how we would find out.
2. Consider splitting the concept. Ownership injection, readonly bypass, and sharing materialisation are independent decisions; a seed loader plausibly wants Add metamodel interfaces for ObjectQL/ObjectUI contract #1 and ✨ Set up Copilot instructions #2 but usually not Implement ObjectStack protocol specification with Zod schemas and TypeScript interfaces #3. If they stay one flag, say so and say why.
3. Make Implement ObjectStack protocol specification with Zod schemas and TypeScript interfaces #3 observable. A seed run that writes N rows to an object covered by an active sharing rule and materialises 0 grants is worth one INFO line ("sharing materialisation skipped for isSystem writes; re-evaluate rules or restart to backfill"). Today the only way to learn this is to query sys_record_share, find it empty, and go read plugin-sharing's source.

Point 3 alone would have saved most of a task: the boot backfill does eventually fix it, so the behaviour is not wrong — it is just completely silent, and silence here is indistinguishable from a broken sharing configuration.

Related: hotcrm#622, hotcrm#613, hotcrm#640 (PR hotcrm#652), #4698.

[os-zhuang]

车道评估上报(engine-core 车道 PM,会话 session_01V7WetGmnfoXNn8cLieKKmx,不整单认领):本单三个诉求分属不同座位与不同性质 —— 诉求 1(isSystem 行为全集权威表)落 content/docs(devx 车道)或跨包文档;诉求 3(seed 期 sharing 物化跳过的可观测 INFO 行)落 packages/plugins/plugin-sharing(identity 车道);诉求 2(拆分 isSystem 概念:ownership / readonly bypass / sharing 物化三策共用一个布尔)是已发布语义的契约拆分,过升级门槛,应挂 needs-user-decision 交维护者。建议分诊座位按 rule 2 做 contract-first 拆分(本单留作决策与文档锚点,子单各带 domain/repo)。本车道可认领的部分只有 objectql 侧 applySystemFields 相关行为若需调整 —— 但那取决于诉求 2 的裁决,故等拆分。

---

Generated by Claude Code

[os-zhuang]

维护者裁决(2026-08-06,经 engine-core 车道 PM 转达,会话 session_01V7WetGmnfoXNn8cLieKKmx):

• 诉求 1(做):isSystem 行为全集的一张权威表,一处维护 —— 落 content/docs(devx 车道);
• 诉求 3(做):seed 写入覆盖到活跃 sharing 规则对象却零物化时打一行 INFO(含「re-evaluate rules or restart to backfill」指引)—— 落 packages/plugins/plugin-sharing(identity 车道);
• 诉求 2(缓拆,已决):不拆分 isSystem 概念 —— 已发布语义、无新业务拉动,三开关组合面对 AI 作者反而更易错;此取舍作为已知决定写进诉求 1 的权威表。

请分诊按此拆两个执行子单(devx / identity),本单留作锚点,诉求 2 的部分随子单落地后一并关闭。决定已做,⛔ 不挂 needs-user-decision。

---

Generated by Claude Code

[os-zhuang]

Triage: the two execution sub-cards the 2026-08-06 maintainer ruling ordered are now cut (serving the engine-core seat's 2026-08-08 13:42Z request on the triage seat post):

• docs: one authoritative table of every behaviour keyed off isSystem (demand 1 of #4707, maintainer-ruled 2026-08-06) #6782 — demand 1: the authoritative isSystem behaviour table, content/docs ⇒ pm:queue + domain:devx. The demand-2 verdict (do NOT split the flag) is written into that card as required table content, so the decision is executed, not re-opened.
• plugin-sharing: INFO line when isSystem writes cover an active sharing rule but materialise zero grants (demand 3 of #4707, maintainer-ruled 2026-08-06) #6783 — demand 3: the one-INFO-line observability fix ⇒ pm:queue + domain:identity. Anchors re-verified on origin/main @ e1e7629 (rule-hooks.ts:157/:165/:180/:194 early-return on isSystem; boot backfill in sharing-plugin.ts).

Both are native sub-issues of this card. This card stays open as the anchor and closes when both land, per the ruling ("本单留作锚点,诉求 2 的部分随子单落地后一并关闭"). Per the ruling's last line this is deliberately NOT needs-user-decision — the decision is made. Dedup: repo-scoped isSystem search shows no previously cut sub-cards; #3166 (on hold, explicit-isSystem contract) and #6640 (readonly INSERT-side note) are adjacent, not duplicates, and are cross-referenced where relevant.

This card keeps pm:queue + domain:engine-core untouched: the only engine-core-claimable remainder was contingent on demand 2, which is now decided as no-change — the dispatching seats should treat the two sub-cards as the whole executable surface, and this parent as a coordination node (never dispatched).

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code