Motir

The story's user-flow gate: the verification_recipe on MOTIR-2256, automated. It exists because this story's risk is not "the new gate does not work" — the unit tests cover that — it is "the new gate works somewhere it should not have been put", and that only shows up when a real person drives the real settings area.

Two passes over the project-settings area, in one spec file:

As a project admin — Members, Access, Workflow, Board, Estimation, Fields, Components, Automation, Repositories, Code access, AI planning. Each page loads and each save succeeds. Twelve keys were wired; an admin who lost ANY of them is the story's worst outcome, and it would be invisible to a test that only checks refusals.

As a project member — the same eleven pages load and render read-only exactly as before, and each save is refused. Then the two closed holes: adding a board column and editing a custom-field option, both of which succeed today and must now be refused. And the negatives that keep the story honest — the member can still drag a card on the board, still apply a label and a component to a work item, and still read every vocabulary the issue editor needs.

No acceptance video. This story adds no page, panel or control — its whole deliverable is server-side enforcement, so it takes the non-UI exemption and accepts on its tests. The story that changes what a person SEES is MOTIR-2258, and the receipt belongs there.

Acceptance criteria

• One Playwright spec, seeded with a project carrying an admin, a member and a viewer, covering both passes above. Waits are on authoritative signals — the saved state, the refusal, the disabled control — never a timeout.
• The admin pass asserts a real SAVE per page (a value written and read back), not merely that the page rendered.
• The member pass asserts the refusal AND the four negatives named above. A spec that only proves refusals would pass on a build that locked members out of the board entirely.
• Empty / loading / error states on at least the two pages this story most changes, plus one terminal action (deleting something an admin may delete and a member may not).
• Selectors follow the shipped E2E conventions and do not depend on copy strings that MOTIR-2258 is about to change.
• The spec runs green in CI on the project's Playwright config; the PR body names the shard it lands in and its runtime.
• pnpm lint and the prettier check pass repo-wide.

Context refs

• lib/settings/projectSettingsNav.ts — the eleven entries this spec walks; also the totality test that keeps the route list honest.
• app/(authed)/settings/project/** — the pages.
• The existing settings E2E specs and tests/settings/settings-area-access-matrix.test.ts — the per-role matrix already asserted at unit level; this spec is its click-through twin, not a duplicate of it.
• motir-core/CLAUDE.md — the E2E discipline (authoritative waits, no arbitrary timeouts).
• Every code card in this story: the seam · members · board · workflow · vocabularies · repository · AI settings.