Skip to content

describeHighPrivilegeBits's doc comment still cites member_default as the "plain wildcard baseline" example, which it no longer is #6696

Description

@os-zhuang

Observation-class finding, filed from the #5492/#5491 paired PR (#6684). Nothing a user hits today — prose only, no behaviour change, no gate red.

What

packages/spec/src/security/high-privilege.ts, in the JSDoc of describeHighPrivilegeBits:

A plain '*' wildcard grant is NOT high-privilege by itself (D5 permits a read/create/edit-own baseline to cover all objects — the platform's own member_default is exactly that shape); the wildcard ban is the GUEST tier's stricter rule (D9 "explicit objects only")

After #5491 (PR #6684) member_default ships no '*' entry at all — the platform baseline narrowed to explicit-allow by maintainer ruling (2026-08-07). So the sentence's worked example no longer describes the set it names.

What is NOT wrong

The rule is unaffected and the code is correct. describeHighPrivilegeBits never reads member_default; it evaluates whatever set it is handed, and "a plain wildcard is not high-privilege by itself" remains the right ADR-0090 D5 predicate — viewer_readonly still ships exactly that shape and is still legitimately anchor-bindable. Only the illustration went stale.

Worth noting the parenthetical's original purpose survives too: it exists to record why the former blanket wildcard rejection was wrong (#2753 — it made the default baseline unbindable to everyone and forced it through the fallback channel D5 rejected). That history is still true and still worth keeping; it just needs an example that still exists.

Suggested fix

One-line prose edit swapping the example (viewer_readonly is the obvious replacement — plain '*', read-only, still shipped), and optionally a clause noting that member_default no longer carries a wildcard as of #5491 so the next reader is not sent looking for one.

Why filed rather than fixed

packages/spec was a hard ⛔ on PR #6684's dispatched file surface (the ADR-0111/#6428 contract had just landed there via PR #6564 and the lane was serialized). Not fixed in that PR by instruction, not by oversight.

Found while re-verifying #5491's premise against origin/main; no pm:queue — this is a finding for the triage round to grade.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions