Motir

Settle, in writing, which affordances this story HIDES and which keep the visible-but-disabled treatment they ship with today — and record the amendment where the superseded rule lives, so the next reader finds one rule rather than two that disagree.

The question

design/projects/design-notes.md § Gating affordances (6.4.6) carries a PM directive dated 2026-06-09 that was made when the only distinction available was admin-versus-member. It resolves the in-place half correctly (Create button, board drag, inline field pickers stay visible-and-disabled; navigation to an edit surface is hidden and the route is guarded) and then states "a non-admin sees Members + Access read-only" — which is exactly the behaviour the parent story changes. The question this card answers is not "hide or disable?" in the abstract but which of the affordance families the product actually ships takes which treatment, now that a role is a permission SET rather than a rank.

What must be checked, not asserted

Answer it from the mirror per surface (the decision-authority ladder's rung 1 — a citation is not a check), then from shipped code (rung 2):

• Jira team-managed — what a project member sees under Project settings when their role lacks a permission.
• Plane — the closest open-source equivalent, which shipped custom roles + a permissions redesign in April 2026.
• GitHub — repository-role behaviour for settings tabs a role cannot use.
• Linear — the counter-example the epic already records (no custom roles), useful only for what it does with a read-only member's nav.

Observe each — open the product, read its docs, or web-search the real behaviour — and cite where. A remembered claim is not evidence, and this rule is going to be applied by six sibling cards.

The deliverable

A single amendment to design/projects/design-notes.md § Gating affordances (6.4.6):

1. The superseded sentence is marked superseded, not deleted, with the date and the reason — a directive that is contradicted by shipped code with no record on the page is worse than either version of the rule.
2. The replacement rule is stated in three parts: HIDE an entry point whose destination the actor cannot use at all · DISABLE with a tooltip an in-place control on a surface the actor can see · GUARD every hidden destination on the server, because hiding is presentation and never enforcement.
3. A treatment table naming every affordance family the product ships today and the treatment each takes, so no sibling card has to re-derive it: the settings rail entry, the settings AREA door, the command-palette action, the project-nav entry, the work-item ⋯ action, the in-place field control, board drag, the Create button, the issue-detail Edit link.
4. The mirror evidence, per row, with links.

Scope boundary

In: prose in design/projects/design-notes.md. Out: any code change, any design ASSET (the mock + PNG are the design card's), and the assignment of permission KEYS to individual surfaces (each code card names its own key against that surface's own server guard).

Acceptance criteria

• design/projects/design-notes.md § Gating affordances (6.4.6) carries an amendment block with its date and its reason, and the sentence "a non-admin sees Members + Access read-only" is marked superseded rather than removed.
• The three-part rule (hide the entry point / disable the in-place control / guard the destination) is stated in that section verbatim enough that a sibling card can quote it.
• A treatment table covers every affordance family listed in the deliverable above; each row carries HIDE or DISABLE and a one-line reason.
• Each of Jira, Plane and GitHub is cited with a link to the behaviour observed, and the citation says what was observed rather than what is believed.
• The in-place treatments the 2026-06-09 directive already settled are recorded as UNCHANGED — this amendment widens the hidden set, it does not re-open the disabled set.
• git diff --name-only for this PR lists exactly one file.

Context refs

• design/projects/design-notes.md — § Gating affordances (6.4.6), the directive being amended, and § Source of truth below it.
• lib/permissions/catalog.ts — the 31 keys the treatment table's surfaces will be gated on.
• lib/settings/projectSettingsNav.ts — the settings registry whose access predicate the rule governs.
• The permission-gated UI story — the parent, whose scope boundary this amendment is a deliverable of.
• The per-domain split — the story that made per-domain administrative permissions real, and therefore made the 2026-06-09 reasoning obsolete.