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
- 488
- planned
- 5,024
- shipped
- (motir-core) The client data doors a Visitor view calls — every API route the eight pages fetch from the browser admits a signed-in, consented Visitor on a Public project through `resolveVisitor`, read-only and per-user limited, and answers everyone else exactly as todayRoles & 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 Visitor sees names, never emails — a name-only person shape on every payload a Visitor view receives (member lists, labels, board swimlanes, component defaults, approval `decidedByLabel` / `routedToLabel`), with a neutral label where a person has no nameRoles & 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) Plans, Approvals and Runs honour the Visitor — each room's Project read takes a Visitor read context, the Mine tab is never offered, and a plan, approval record or run touching a private epic's descendants is withheldRoles & 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 collection reads honour the Visitor — the items list, tree, board, roadmap and search take a `VisitorReadContext` and pass its hidden set as the repository's existing `excludeIds`, with a private epic's row kept and its tells stripped, as `epic-privacy.md` §3–§4 requireRoles & 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 eight read pages take their project from a context, not the active project — each page's body moves into a server component given `{ project, access, actor }`, and the `(authed)` pages become thin wrappers with no behaviour changeRoles & 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 Visitor role and its resolution — `VISITOR_PERMISSIONS` derived from the Viewer set, `projectAccessService.resolveVisitor(identifier, session)` answering visitor · enter · not-found with the private-epic hidden set, and a per-IP `public-read` rate-limit scopeRoles & 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
- A Visitor signs in to watch a public project — told once per project that their name and email go to its Managers, then the real app's items, tree, board, roadmap, plans, approvals and runs read-only at app.motir.co/p/<project>, private epics withheld, other people shown by name only, every write refused, and the project's Managers seeing who visitedRoles & 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-ai) `MODIFY_PATCH_KEYS` lacks core's `targetRepositoryRef`, and the test that claims the two lists are EXACTLY equal copies the same omission into its own fixture
- (motir-meta) `run.md` gets ONE home for the no-`motir-plan` fallback — trigger motir-ai with the WHAT (`submit_plan_session` + `requirement`), or park, comment and stop on its refusal — and every re-plan site and `_shared.md`'s door table point at itMotir skills anyone can install — run, repair a red card, log bugs, fix the Bugs folder and be guided through manual work from the coding agent you already use
- (motir-core) After Approve in the planning overlay, the workbench does a full document reload and drops the decided plan — cloud-plan-change-conversation.spec.ts:414 ejected a merge-queue entry
- (motir-core) The public board read requests three interactive transactions at once per render — the pool-starvation shape MOTIR-6627 removed from the overview
- DECISION — a Visitor signs in, consents once per project, and is recorded for the project's Managers with their email; reading a public project in the app is no longer anonymousRoles & 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 · design) The Visitor view, drawn — the sign-in hand-off and the one-time consent screen that tells a reader their name and email go to the project's Managers, a Visitor shell with no workspace or project switcher, create or settings, its navigation across items, tree, board, roadmap, plans, approvals and runs, the not-found and rate-limited states, the Managers' Visitors section on Access & members, and the Visitor link on the Build-in-public settings pageRoles & 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 · 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