moooon
Motir
Vibe the 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
- 6
- requests
- 4
- upvotes
- 486
- planned
- 5,026
- shipped
- (motir-core) The workspace Members page shows and sets each person's access scope — the Full / Limited column and control (a Manager's row locked Full), the invite modal's scope and project picker, and the migration notice's `project_access_lost` rowsRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- (motir-core) The Access & members page offers the three modes — the mode control, the confirm naming how many people lose entry when switching to Members only, the people list with add and remove, read-only for anyone without `project:manage_access` / `member:manage`, and the Build-in-public dialogs moved onto the modeRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- (motir-core) Reads across projects honour entry at READ time — the notification list drops rows from projects the reader can no longer enter, and a dashboard gadget refuses a project its viewer cannot enter, at configure and at renderRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- (motir-core) The active project is always one the person can enter — the fallback picks the first enterable project, a Limited person added to none lands in the no-project shell the design draws, and a revoked active project is replaced on the next requestRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- (motir-core) Every reader of the old access level moves to the mode — the assignable-members and mention gates admit exactly the people who can enter, the project DTOs, API v1 schema and MCP `list_projects` carry `accessMode` (with `accessLevel` kept as a derived, deprecated field), and the seeds and fixtures are rewrittenRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- (motir-core) An invite carries the access scope — the invite payload and route take `accessScope` and, for Limited, the projects to join; accepting creates the membership with that scope and adds the person to those projects in one transactionRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- (motir-core) A Manager sets a member's access scope — `workspacesService.setMemberAccessScope`, the route and the server action, Manager-only, a Manager's own scope refused as meaningless, and the change effective in every project at onceRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- (motir-core) A Manager sets a project's access mode — `projectMembersService.setAccessMode` behind `project:manage_access`, the access route taking `accessMode`, switching to Members only no longer adding every workspace member, Public still cloud-only, and both columns written togetherRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- (motir-core) One entry rule — `canEnter` decides who may enter a project from its access mode, the person's scope, whether they were added and the Manager rail; `resolvePermissions` and `filterBrowsable` read it; a person who cannot enter gets not-found; and `public-projects.md` is amended to the three modesRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- (motir-core) The access migration — every project given its access mode by the DECISION's mapping, every membership Full, a `project_access_lost` report row for each person a `limited` project stops admitting, and a check inside the migration that fails if the new modes admit anyone the old levels did notRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- (motir-core) The access storage, added beside the old — a `ProjectAccessMode` enum (workspace · members · public) and a nullable `project.access_mode` that means "derive from `access_level`" while NULL, a `WorkspaceAccessScope` enum (full · limited) and `workspace_membership.access_scope` defaulting to full, a `project_access_lost` migration-report reason, and their repository methodsRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- ACCESS lives on the project — Open to the workspace · Members only · Public, and a Limited membership scope, so a contractor with a Member role enters only the one project they were added toRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- motir.co still defaults to the old warm palette — it pins `@motir/design-system@0.1.3`, which predates the Graphite→Motir rename (motir-marketing)
- (motir-ai) A plan REVISION closes without a finishability check — `revise_plan` sets `validate: { mode: 'none' }`, so the closing validation and its re-open never run on the plan it just changed
- IndexDispatchFailedError: Indexing moooon-B-V/motir-core into project cmqfb4d8q000e2d0i6n62otyc failed (upload_failed): the graph was built but object storage refused or dropped the upload
- (motir-core · test) E2E — a new workspace's creator is its Manager, an invited person accepts and lands as a Member, a Manager makes them a Viewer and adds them to a project, and they read it but cannot edit it; no acceptance video, because this story adds no surfaceRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- (motir-core · test) The legacy-storage integration gate — the changed surface topped up to the 90% floor, every membership-creating path and a pre-release invite driven against the real database under RLS, and the architecture guard widened so no module reads or writes a legacy role column, imports `MemberRole` or touches `ProjectRoleDefinition`Roles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- (motir-core) Nothing writes the legacy role columns — workspace creation, invites (a new token carries a workspace role and a pre-release token still redeems), org member add and fold-in, and project membership add stop writing `workspace_membership.role` / `project_membership.role`, and `MemberRole` leaves application code and the seedsRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- (motir-core) The workspace role is NOT NULL and read directly — a migration that backfills any NULL from the legacy column and then constrains it, `resolveWorkspaceRole`'s fallback deleted with every caller reading `workspaceRole`, and the stand-in Manager ordered by the workspace roleRoles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do
- The legacy role storage stops being read or written — `workspace_role` NOT NULL and read directly, nothing writing `workspace_membership.role` / `project_membership.role`, and `MemberRole` out of application code (Release A of the three-release retirement)Roles & permissions, refined — org Owner · Admin · Member, ROLE on the workspace and ACCESS on the project, an automatic Visitor on public projects, and a UI that offers each role only what it can do