Skip to content

moooon

Motir

Vibe your whole project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.

  • Vibe Project
  • Open Source
  • AI Agent
  • AI Loop
1
requests
0
upvotes
145
planned
1,361
shipped

Motir · Work items

MOTIR-2265Done

Story E2E (Playwright) — open Roles & permissions as each role, and record the acceptance video

Drive the story's verification_recipe as a Playwright test against the real stack, and record the acceptance video the story is accepted on. The story has a user-observable surface, so the video is required, not optional.

⚠️ RE-SCOPED 2026-08-07. This card asserted a single screen — "the three built-in roles are present with their Built-in chips, that permissions render grouped by domain", all in one step. The design that landed on 2026-08-07 (commit 1273ff32) made the surface a drill-down: the role list carries the chips and the counts, and a role's permissions live on a detail screen you navigate to. Those two assertions now belong to two different screens, and the navigation between them is itself part of what must be verified. See the story's re-plan note.

The flow to drive

  1. Reach the surface. Sign in as the project admin, open the project-settings area, and click through to Roles & permissions from the rail's Access group — clicking the entry, never navigating by URL, because the door is part of what is being verified.
  2. The role list. Assert the three built-in roles are present as rows, each with its Built-in chip, its purpose, its N of M permissions count and its member count — and that the member count matches the memberships the spec seeded, so the number is proven to come from the data rather than from a placeholder.
  3. Drill in. Activate a role row, assert the detail screen renders that role's permissions grouped by domain with human labels rather than raw keys, and spot-check a permission that this role holds and one it does not. Then return via the ← All roles link and assert the list is back.
  4. The member view. Sign in as a project member and reach both screens: the content is there, and nothing on either is editable — no Create role, no Edit, no Delete.
  5. The no-access state. As a user who cannot browse the project, a direct navigation to each route — the list and a role's detail — renders the shipped no-access panel rather than a crash or an empty shell.
  6. Nothing regressed. As a project viewer, the shipped read-only affordances behave exactly as before: the Create button is present and disabled with its tooltip, and the issue-detail Edit link is absent.

The video

The clip is what a reviewer watches to accept the story, so it must be paced for a human — chaptered through the flow above at a speed someone can actually follow, not a four-second blur that satisfies the letter of "it records". The drill-down and the return are the two moments a viewer most needs to see land, so they get their own chapters rather than being folded into one. The harness paces chapter() by default and the uploader refuses to publish an unwatchable clip; the card states it anyway so the pacing is planned rather than discovered from a red publish step.

Acceptance criteria

  • A Playwright spec drives all six steps above against the real stack and is green in CI.
  • Every wait is on an authoritative signal — a rendered role row, a settled navigation to the detail route — never a fixed timeout.
  • The spec reaches the list by CLICKING the rail entry at least once, and reaches the detail by ACTIVATING a role row at least once, so a screen that ships unreachable fails here even if its route resolves.
  • The member-count assertion is tied to the memberships the spec seeded, so a hardcoded or absent count fails.
  • The run records a chaptered acceptance video covering steps 1–4, paced for a human viewer, with the drill-down and the return as their own chapters, and publishes it to the story.
  • An axe sweep over both rendered screens reports zero violations.
  • The spec seeds its own fixtures — a project with a membership at each of the three roles, and one user with no access — and cleans up after itself, so it can run on a shared worker database.

Context refs

  • The parent story's verification_recipe — the flow this automates.
  • app/(authed)/settings/project/roles/ — the list and detail routes, plus the Access-group rail entry, from the screens card this drives.
  • motir-core/CLAUDE.md § E2E — the authoritative-wait discipline and the fixture conventions.
  • design/projects/roles-permissions.mock.html — the list and detail panels, the states this asserts.