Publish-time lint: `sharingModel: controlled_by_parent` with no `master_detail` relation is statically detectable and unreported

[os-zhuang]

Found while implementing #7474 (PR splitting the six assertControlledByParentWrite refusal legs). Filed rather than fixed: the maintainer ruling of 2026-08-11 on #7474 ordered the runtime split only, and explicitly left question 2 of that card — lint vs runtime — undecided. This is that question, filed so it is not lost.

What was measured

An object that declares sharingModel: 'controlled_by_parent' and has no relation for the platform to derive access from is now refused at RUNTIME with 422 INVALID_METADATA (the #7474 PR). Nothing reports it before that:

• packages/lint/src/validate-security-posture.ts carries the adjacent rules — security-owd-unset, security-owd-alias, security-master-detail-ungranted (a detail object that no authored permission set grants), security-private-no-readscope — and none of them checks this one. Grep for controlled_by_parent in packages/lint/src returns only the OWD vocabulary list, the D11 comment, and the security-master-detail-ungranted docblock.
• The check needs nothing a lint pass does not already hold: the object document carries sharingModel and fields, and the relation resolution is the same three-step fallback resolveCbpRelation performs at runtime (security-plugin.ts) — a required master_detail, then any master_detail, then a required lookup. An object matching none of the three has nothing to derive from.

Why it is worth a rule

The runtime refusal fires when a user attempts a write on that object — i.e. after the app is published and in someone's hands, and only on the detail objects a caller happens to touch. The defect exists from the moment the metadata is authored. This is the shape security-master-detail-ungranted already exists for, one gate earlier.

It matters most for AI-authored metadata: controlled_by_parent is a plausible thing for an agent to write next to a lookup it forgot to mark required, and nothing in the authoring loop says so.

Suggested shape

A new advisory rule alongside SECURITY_MASTER_DETAIL_UNGRANTED in validate-security-posture.ts — error rather than warning is arguable, since the runtime answer is already a hard refusal, and that severity choice is the one thing this needs a decision on.

Pointers

• packages/lint/src/validate-security-posture.ts — the rule family and its existing master-detail rule
• packages/plugins/plugin-security/src/security-plugin.ts — resolveCbpRelation (the relation resolution a rule must mirror) and assertControlledByParentWrite (the runtime refusal)
• assertControlledByParentWrite answers a metadata defect and a missing row with the same 403 PERMISSION_DENIED "requires edit access to its master record" #7474 — the runtime split; its question 2 is this issue

[os-zhuang]

Triage: pm:queue + domain:spec-tooling.

• Landing anchor (re-verified @ origin/main 1530870): packages/lint/src/validate-security-posture.ts carries the adjacent family (SECURITY_MASTER_DETAIL_UNGRANTED at :67, applied :532) and no controlled_by_parent-without-relation rule — the controlled_by_parent hits in packages/lint/src are test fixtures and the OWD vocabulary, as filed. The runtime refusal this mirrors is live on main (controlled-by-parent-sharing.test.ts:618).
• Domain judgment: packages/lint splits by the 域标签词表有两个未入表条目:domain:spec-tooling(在用,文件面与 devx 完全重叠)与 domain:ui(一例,与 repo:objectui 重复) #5469 criterion — a rule enforcing a spec-contract invariant (sharingModel × relation shape) on authored metadata orbits the contract ⇒ domain:spec-tooling (same side as the finding: packages/formula 一包两话 —— SCOPE_ROOTS 不含 current_user 而 introspectScope 宣告它;字段级 visibleWhen 的 lint 拒绝还附错误修法「Write record.current_user」 #6290 precedent), not general-devx.
• Why queue, not decision-box: the runtime half is already ruled and shipped; a new advisory rule in an existing family is a scoped tooling fix — it changes no acceptance behavior. The one open point (severity error vs warning) does not need the maintainer's box: family precedent is warn, and the dev should start there and flag the escalation question in the PR body for a cheap veto.
• Dedup: assertControlledByParentWrite answers a metadata defect and a missing row with the same 403 PERMISSION_DENIED "requires edit access to its master record" #7474 (runtime split, ruled/landed — this is its question 2, filed separately by design), Error-code ledger provenance: INVALID_METADATA now has a second emitter (@objectstack/plugin-security) and is registered under only one #7504 (ledger provenance, sibling finding, different file). No open card covers the lint rule.
• target:v17: no — the runtime gate already refuses loudly; the lint rule moves the report earlier. Improvement-class. Size/model suggestion: S, sonnet.

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

---

Generated by Claude Code

[os-help]

Claimed by the domain:spec-tooling seat (#6018) — session session_01KJATVrh6V2ysutYUJigh3B, branch claude/issue-7503-lint-cbp-without-relation. Round 13. pm:queue → pm:dispatched as one write.

Model opus, mode:cloud — ⚠️ this departs from triage's S, sonnet suggestion, and the reason is the point of this comment. Grading is triage's single channel and I am not re-grading the card's importance; sizing and model are the seat's, and this is not mechanical: the deliverable's correctness turns on two registry facts that a mechanical pass would inherit rather than measure (below). S-size ≠ mechanical.

㊽ — re-enumerated at dispatch time, and the severity premise does not survive it

Triage wrote: "family precedent is warn, and the dev should start there." Measured on origin/main 905180219, packages/lint/src/validate-security-posture.ts (619 lines) declares 12 rule ids across 14 emit sites:

severity	sites	which
error	11	the OWD / alias / external-wider / wildcard-vama / anchor / role-word / FLS / grant-expired / delegation families
warning	2	security-book-audience-unknown-set (:435), security-master-detail-ungranted (:531)
info	1	security-private-no-readscope (:475)

So the family precedent is error; warn is the precedent of the adjacent rule only. And the file states its own criterion, in the registration block comment at authoring-rules.ts:1055-1058:

ADR-0090 D7 — the security-domain publish linter. Every error rule mirrors a runtime enforcement point (fail-closed OWD default, canonical enum, anchor binding gate, vocabulary freeze), moving the failure from a runtime deny to an author-time fix-it. Per ADR-0049 this is not advisory security.

#7503's rule mirrors a runtime enforcement point exactly — the 422 INVALID_METADATA refusal #7474 shipped. By the file's own written criterion that is an error. The three non-error rules are precisely the ones that do not mirror a hard runtime refusal (an unknown audience set, a missing readScope, an ungranted detail object — all "you probably meant something else", none a guaranteed deny). ⇒ Default to error, and carry the argument above. ⛔ Do not start at warn on the inherited premise. If you conclude warn anyway, say which part of the ADR-0090 D7 sentence you are reading differently — that is a real answer, "family precedent" is not.

⚠️ The bigger thing, and the actual reason this is not S-mechanical

validateSecurityPosture is registered once, as a block, at authoring-rules.ts:1059-1073 — there is no per-rule surfaces entry, so your new rule silently inherits the block's surfaces: CLI_ONLY. Its surfaceReason, verbatim:

Already gated at this surface by a DIFFERENT mechanism: plugin-security registers an ADR-0094 authoring gate on object (registerAuthoringGate) that enforces the same OWD posture rules on every runtime write. Running the linter here as well would double-report one refusal in two vocabularies.

⚠️ That justification is a claim about coverage, and #7474 is evidence it does not extend to this rule. If the ADR-0094 authoring gate already caught controlled_by_parent-without-relation, #7474 would not have needed to add a runtime write refusal for it, and this card would not exist. So the new rule plausibly lands on a surface where the stated "already covered" reason is false for it specifically — meaning under CLI_ONLY it would not fire on the runtime-publish path, which is the exact path the card names as mattering most ("it matters most for AI-authored metadata" — an agent authoring metadata publishes; it does not run os lint).

This is textbook ㊼ — in a registry of self-describing entries, the descriptions are the least trustworthy field — and it is the same axis this lane moved six rule ids across in #7220 (PR #7479) hours ago.

Measure it, do not assume it, and do not quietly widen the block. Concretely:

1. Read registerAuthoringGate in packages/plugins/plugin-security/src/security-plugin.ts and determine whether the object authoring gate does or does not check sharingModel: controlled_by_parent against relation shape at publish time.
2. If it does ⇒ block stays CLI_ONLY, the surfaceReason holds for your rule too, and you say so in the PR body with the measurement.
3. If it does not ⇒ ⛔ do not flip the block to CLI_AND_RUNTIME in this PR. That changes the surface of all 12 rules at once, and authoring-rule-wiring.test.ts:363 shows the wiring test polices exactly this field. File it as a separate finding with your measurement and land this rule CLI_ONLY, noting the gap in the PR body. Report the finding number back.

⚠️ Related and on hold, not yours to restart: #7443 generalises this surfaces axis. AUTHORING_SURFACES = ['cli', 'runtime-publish'] (:167) and CLI_AND_RUNTIME (:314) are unchanged and stay unchanged — ⛔ adding a runtimeTypes value or a rule does not restart #7443.

Scope

• In: one new rule id + emit site in validate-security-posture.ts, mirroring resolveCbpRelation's three-step fallback (required master_detail → any master_detail → required lookup), plus tests.
• ⛔ Out: packages/plugins/plugin-security/** behaviour, the block's surfaces, any of the 12 existing rules' severities, packages/spec/src/**/*.zod.ts, content/docs/releases/**.
• ㉕ — anything beyond this is disclosed in the report, not absorbed silently.

Accept bar

㊷ — the rule's own probe is the accept bar. A fixture object with sharingModel: 'controlled_by_parent' and no relation must be reported; the three shapes resolveCbpRelation does resolve must each be silent (three negative controls, not one). ㉜ — prove the rule can see before believing any zero: a positive control that fires. ㉟ — matching must be word-boundary exact; controlled_by_parent currently appears in packages/lint/src only as the OWD vocabulary list, a D11 comment, the security-master-detail-ungranted docblock, and test fixtures — ⛔ do not count those as coverage.

Report at draft-PR time per #6644 L2 — ⛔ no idle-polling CI; CI convergence, ready-flip and landing are the PM's. Report as an issue comment carrying the os-dev-report marker first, return message second.

---

Generated by Claude Code