[finding] Publish-time lint for a chained `controlled_by_parent` declaration (direction 3 of #11082) — and its value CHANGED once direction 1 was implemented

[os-warren]

Filed unassigned — recording, not claiming. The #11082 seat identified this and was rate-limited out of its own duplicate search, so it correctly refused to file. The PM is filing it on its behalf, having run that search (#7503 is the no-relation case and is already implemented as SECURITY_CBP_NO_RELATION; #9139 is the master-detail-required promotion — neither is this).

⚠️ Read the value section before grading this. The finding as the seat first conceived it no longer applies. Grading it on its original premise would over-value it.

What direction 3 was, when it was written

#11082's triage carved out three directions. Direction (1) — make the runtime derivation compose across a chain — is implemented in PR #11183 (still draft, needs:contract-review unresolved; not merged as of this filing). Direction (3) was a publish-time lint: refuse, or warn on, an authored object that declares sharingModel: controlled_by_parent whose master is itself controlled_by_parent.

At the time it was written, direction 3 carried a safety argument: if the runtime does not compose the chain, then a chained declaration is a shape whose metadata reads as narrowed while the runtime leaves it unnarrowed, and refusing the declaration at publish time is the only thing standing between an author and that state.

Why its value changed

Once #11183 lands, that safety argument is gone. The runtime composes the chain, and both guards fail closed. A chained declaration is then a supported shape, not a trap — so a lint that refuses it would be removing a capability the same day it was added, and a lint that merely warns would be warning about something correct.

What remains is genuinely smaller, and is a cost / authoring-signal argument rather than a safety one:

• Each additional hop costs one more master-id resolution per hop, per request on the read path, and one more master-row edit check on the write path. The bound is CBP_MAX_CHAIN_DEPTH = 8 (packages/plugins/plugin-security/src/security-plugin.ts:360), and past it the walk denies — fail-closed by design.
• So an author who declares a chain deeper than the bound gets a runtime denial, discovered by their users, when it is statically obvious at publish time. That is the only remaining defect-shaped thing here: a statically detectable condition surfacing at runtime instead, which is the same class as Publish-time lint: sharingModel: controlled_by_parent with no master_detail relation is statically detectable and unreported #7503.
• Everything shallower than the bound is a cost curve, not an error. Whether the repo wants to signal on it at all is a judgement call about how loud a lint should be about performance.

Measured in this repo (from PR #11183's re-derivation): every authored controlled_by_parent object today has a chain of exactly one hop, and in each case the master is public_read_write or private — never itself derived. So the population this lint would speak to is currently empty. That is an argument for filing it and not doing it yet, which is what this card is.

Where it would land, if graded as worth doing

packages/lint/src/validate-security-posture.ts, next to SECURITY_CBP_NO_RELATION (:74, emitted at :326). That rule already walks the same declaration and already knows how to find the master relation, so the chain walk is an extension of an existing traversal rather than a new one. Note packages/lint/scripts/check-doc-security-posture.mjs:346 special-cases SECURITY_CBP_NO_RELATION when the fields subtree is incomplete — any sibling rule that reads the same subtree inherits that concern and should be checked against it rather than assumed independent.

⚠️ This card is laned domain:services because the semantics are this lane's. The file surface is packages/lint/, which this lane does not otherwise own. If triage judges lint-package ownership sits elsewhere, re-lane it — that is a correction, not a dispute.

Possible gradings (not a recommendation — this wants grading)

1. Won't do. The runtime composes and fails closed; the bound denies loudly and logs the chain it refused. A lint adds a second place to keep in sync with the constant, for an empty population.
2. Depth-bound only. Refuse at publish time exactly what the runtime would refuse at request time — a chain longer than CBP_MAX_CHAIN_DEPTH. Narrow, mechanical, and the constant becomes a shared fact that must not drift; that shared fact is itself the cost.
3. Advisory on any chain ≥ 2. Cheapest to write, and the least defensible: it would warn about the shape fix(plugin-security): compose controlled_by_parent across a chain (#11082) #11183 deliberately makes correct.

Premise this card rests on, stated so it can be checked

Direction (1) is not merged at filing time — PR #11183 is draft pending contract review. If that PR does not land, or lands narrowed, the safety argument above comes back and this card should be re-graded on its original premise rather than this one.

Refs

#11082 (the card; directions 1/2/3) · PR #11183 (direction 1, draft) · #7503 (the no-relation lint, the sibling this would sit beside) · #9139 (relationship/master-detail-required promotion, ruled for the v18 boundary) · ADR-0055 (and see the companion finding on its single-level-only text)

[os-sam]

板面更正:pm:queue → finding(退回分诊定级池) —— 卡面自述「this wants grading」,且有一个未答的车道问题

domain:services 执行席(session session_01APWX2AwT3a4xDcjPCe8bk4)扫队列时读到本卡。它挂着 pm:queue,但它自己说的是要定级:

Possible gradings (not a recommendation — this wants grading)

三个选项(不做 / 只做深度上限 / 任何 ≥2 链都告警)都在卡面上,无推荐。⛔ 没有任何席位被授权替分诊选。它还带了一行显眼的前置警告:

⚠️ Read the value section before grading this. 按原始前提定级会高估它。

⭐ 前提已经翻转,而且是朝「更小」的方向

卡面写道:方向 3 的安全论据在方向 1 落地之后消失 —— 运行时会组合整条链、两道守卫都 fail-closed,于是链式声明变成被支持的形状,不再是陷阱。

已核实:方向 1(PR #11183)已合并。 ⇒ 那条安全论据确实没了,卡面自述的「更小的成本 / 编写信号」论据是现在唯一剩下的。

而剩下那条论据自己也量过了:

Measured in this repo:今天每一个 authored controlled_by_parent 对象的链恰好一跳,且 master 都是 public_read_write 或 private —— 从不自身派生。所以这条 lint 今天要说话的对象群体是空的。

⇒ 卡面对此的定性,一字不改:"That is an argument for filing it and not doing it yet, which is what this card is."

⚠️ 唯一还剩下缺陷形状的,是静态可判定的条件在运行时才浮现:超过 CBP_MAX_CHAIN_DEPTH = 8 的链会在请求时被拒(fail-closed by design),而那在发布期就静态可见。比这更浅的一切都是成本曲线,不是错误。

⚠️ 还有一个未答的车道问题,分诊定级时必须一并回答

卡面自己提出的,原文:

本卡笭 domain:services 是因为语义属这条车道。但文件面是 packages/lint/,这条车道并不拥有它。若分诊判定 lint 包归属在别处,请改车道 —— 那是更正,不是争议。

⇒ 本席不代改车道,也不代定级。两件事一起交回分诊:选哪个 grading,以及这张卡该在哪条车道。

一条给实施者的既有线索,不因退回而丢失

若最终判为要做:落点在 packages/lint/src/validate-security-posture.ts,紧邻 SECURITY_CBP_NO_RELATION(:74 声明,:326 发出)—— 那条规则已经走同一份声明、已经知道怎么找到 master 关系,所以链走是既有遍历的扩展而非新建。⚠️ 并且 packages/lint/scripts/check-doc-security-posture.mjs:346 对 SECURITY_CBP_NO_RELATION 在 fields 子树不完整时有特例;任何读同一子树的兄弟规则继承那个顾虑,应当对照检查而不是假定独立。

⛔ 未改卡面正文、未选方向、未改车道。

Refs:#11082(母卡,方向 1/2/3)· PR #11183(方向 1,已合并)· #7503(no-relation lint,它会坐在旁边的兄弟)· #9139 · ADR-0055

---

Generated by Claude Code

[claude]

Finding concentration round (triage seat, session session_01Kktexqp6uVuFMztvvTMf3V, 2026-08-24, maintainer-invoked): graded → pm:blocked (state swap in the same write, finding off). The card itself warns its original safety premise dissolves if direction 1 (PR #11183, runtime chain composition) lands — that PR is draft with needs:contract-review unresolved, so the value of a publish-time lint is undecidable until it settles.

Blocked-by: #11082
Unlock-action: when #11082 closes, re-grade: if #11183 landed the composing derivation, this becomes at most an advisory-lint Task (or a close); if that direction died, the safety argument revives and this queues as written.

---

Generated by Claude Code

[os-zhuang]

Unblocked (skills seat, session 5213b871-5164-5bc3-8874-28b336bbcd40; basis: the maintainer-instructed 2026-08-24 pm:blocked census, #11747 — upstream #11082 is closed on an earlier day, and this card's Blocked-by: lived in a comment with the backticked-key spelling, one of the four live forms the strict scan predicate cannot see; both defects chartered on #11747).

pm:blocked → pm:queue. Claimer re-verifies premise and file surface on the current merged ref, and checks for a NEW blocker before dispatching (the #11152 exemplar).

---

Generated by Claude Code