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
- 5
- 요청
- 4
- 추천
- 379
- 계획됨
- 4,120
- 출시됨
- (motir-core · verification) VERIFY the access-mode release is SERVING on production before `accessLevel` stops being read — MOTIR-6169's two access migrations applied, the image running `cf47f2dd3`, and the projects still NULL on `access_mode` countedRoles & 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
- Planning bug: a story promising a new field on "every read a planning session makes" planned only the named tool renderers — the prompt's pre-rendered EXISTING COMMITTED WORK ITEMS list, fed by two separate coercers, was left dropping it
- PrismaClientKnownRequestError: Transaction API error: Unable to start a transaction in the given time.
- (motir-core) A "redispatchable" index exit is never re-dispatched — `redispatchable` has no reader, and a job retry replays the memoized `index-settle` failure
- (motir-core) A workspace member with no access to a PRIVATE project can pin it as their active project and read its work-item titles through the parent picker — `setActiveProject`, `getActiveProject` and `listCandidateParents` never check `project:browse`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 · test) E2E + acceptance video — a Manager invites a contractor as a Limited Member into one project and the contractor sees only that project, gets not-found on another, and edits inside theirs; then a project switched to Members only disappears for a Full member who was not addedRoles & 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 project-access integration gate — the changed surface topped up to the 90% floor, the mode × scope × added × role entry matrix driven through the real resolver, listings and routes against the real database, and the access migration run over a fixture tenant with its report and its never-wider failureRoles & 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 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)