Skip to content

audience-anchors.test.ts still names member_default as the plain-wildcard shape — the same stale illustration #6696 fixes, one package over #6842

Description

@os-project-manager

Observation-class finding, found while implementing #6696. Nothing a user hits today — a test name and a comment; every assertion involved passes and is correct. No pm:queue; filed for the triage round to grade.

What

#6696 fixes the describeHighPrivilegeBits JSDoc in packages/spec/src/security/high-privilege.ts, which cited member_default as the worked example of a plain-'*' grant after #5491 (PR #6684) removed that set's wildcard entirely. The same stale illustration survives one package over, in the behavioural pin for that very function:

packages/plugins/plugin-security/src/audience-anchors.test.ts:65

it("a plain '*' wildcard without D5 bits is anchor-safe for everyone (#2753 — member_default's shape)", () => {

The fixture on the next line is { objects: { '*': { allowRead: true, allowCreate: true, allowEdit: true } } }. That is no longer member_default's shape — measured against the shipped defaultPermissionSets array on origin/main @ c32944d67, member_default's objects['*'] is undefined.

A secondary, weaker instance sits at line 103, it('allowExport:false / unset stays anchor-safe (member_default keeps binding)'). That title is still true (member_default still carries no allowExport and still resolves anchor-safe), but its line 107 assertion is again a wildcard shape the set no longer has, so the name and the fixture have drifted apart.

Evidence

Probe against the real imported array plus the real predicates (not a transcription):

=== member_default ===
  has '*' entry:         false
  describeHighPrivilegeBits          -> null
  describeAnchorForbiddenBits(everyone) -> null

=== viewer_readonly ===
  has '*' entry:         true
  '*' value:             {"allowCreate":false,"allowRead":true,"allowEdit":false,...}
  describeHighPrivilegeBits          -> null
  describeAnchorForbiddenBits(everyone) -> null
  describeAnchorForbiddenBits(guest)    -> "a '*' wildcard grant (guest bindings admit explicit objects only)"

What is NOT wrong

The assertions are right and the rule is right. D5 genuinely does not flag read/create/edit on '*', so the fixture pins the correct predicate; only the set named alongside it is stale. This is naming drift, not a coverage hole — which is exactly why it stayed green through #5491.

The wider gap this exposes

Nothing mechanically relates "prose names set X as having shape Y" to what defaultPermissionSets actually ships, so this drift is silent by construction: #5491 changed the set and three separate pieces of text went stale without a single gate moving. The repo already has the idiom for this class — packages/spec/src/identity/position-delegatable-enforcer.pin.test.ts (#6628) pins "the JSDoc may name a lint rule only if that rule exists" against a machine-readable rule table, with an explicit anti-vacuity guard.

A pin was deliberately not added in #6696's PR: that card is scoped domain:spec-surface (text face, packages/spec only), and the authority such a pin must read — the defaultPermissionSets array — lives in plugin-security, which packages/spec cannot import without inverting the dependency graph. The natural home is therefore beside audience-anchors.test.ts, which can import the array directly and read spec's source text the way #6628's pin reads packages/lint.

Suggested disposition

Two candidate sizes, for triage to pick:

Related: #6696 (the spec-side half, fixed), #5491 / PR #6684 (the cause), #6628 (the pin idiom).

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions