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
- 추천
- 380
- 계획됨
- 4,119
- 출시됨
- (motir-core) The Visitor needs a session and a consent — `resolveVisitor` answers `sign_in` with no session and `consent` for a signed-in non-entrant with no record, `visitorRecordsService.recordConsent` writes the record, a Visitor read touches the latest visit, and `public-projects.md` and `role-model.md` are amendedRoles & 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 record — a `project_visitor` table (project, person, consented at, first and last visit), its repository, and the migration, deleted with the person or the projectRoles & 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 work-item page honours the Visitor — a hidden item is not-found by key, and a visible item's edges, child panel, rollups, work-item chips, activity and comments name no private-epic descendantRoles & 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 reader follows a public project's link, signs in, is told their name and email go to the project's Managers, continues, walks the items list, tree, board, roadmap, an item, Plans, Approvals and Runs, meets no write control and no private epic's child, is not asked again, and the project's Manager sees them in the Visitors list with their emailRoles & 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 story's integration gate — the changed surface topped up to the 90% floor, the Visitor's sign-in, consent and reads driven through the real resolver and datastore with a private epic in the fixture, a no-email scan over every Visitor payload with the Managers' list the one email-bearing surface, and a guard that drives every write route and server action as a Visitor and asserts refusal with no row changedRoles & 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 Build-in-public settings page offers the project's Visitor link — copyable, shown only while the project is Public and the cloud capability is on, behind the page's existing keyRoles & 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 route tree at `app.motir.co/p/<identifier>/<view>` — the Visitor layout sending a signed-out reader to sign-in and a first-time reader to the consent screen, the Visitor chrome over the shared page bodies, `proxy.ts` letting the view paths through while the bare path and act pages still 308 to motir.co, a member redirected into their own view, and `public-surface-hosts.md` §2 amendedRoles & 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 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