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
- prośby
- 4
- głosy
- 374
- zaplanowane
- 4116
- wydane
- (decision) Motir's database is always on, so every 30-minute `system.*` job runs every 5 minutes — §21's :00/:30 cluster rule and its quiet-gap invariant are retired
- (motir-core) A Visitor's Plans list never loads past page one — `loadMoreSessionsAction` reads the reader's own active project, not the Public project being viewed
- Release `@motir/cli` with the ready lanes — merge the Version Packages PR, then verify `motir next --parent | --bug` in the published CLI and the sandbox images as a consumer
- (motir-ai) Every rate-sync PR that moves a price fails "Coverage (rate sync)" — the story gate replays the FIRST rate migration from `tests/fixtures/upstream-prices.json`, the file `rates:sync` rewrites on every proposal
- (motir-core · verification) VERIFY Release 1 is SERVING on every `motir-core` machine before anything stops writing `accessLevel` — `access_mode` NOT NULL with its default, the seven public-read policies keyed on it in `pg_policies`, and no access error in its windowRoles & 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) PHASE 2 — `@ignore` the legacy role fields and `@@ignore` `ProjectRoleDefinition` so the generated client stops selecting them, and RELEASE with every column and the table still in placeRoles & 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) Story integration gate — coverage floor over the lanes, the service → v1 / MCP / page / CLI seams, and the partition guard (leaves ∪ bugs = the old ready set)
- (motir-core · docs) `docs/cli.md` documents the three lanes — `motir next`, `motir next --parent`, `motir next --bug`, `motir ready --parent | --bug`, and what `auto` / `batch` / a scoped run read now
- (motir-core · CLI) `motir next --parent` runs the next runnable container as a parent run, `motir next --bug` runs the next bug, and `motir ready --parent | --bug` lists those lanes — flags, command catalog, help and changeset
- (motir-core · test) Story E2E + acceptance video — `/ready` shows a story as one expandable row over its ready leaves, never an epic, and a bug only in the Bugs list
- (motir-core · CLI) The CLI reads the lane endpoints instead of `getProjectReadySet` — regenerated API types, `nextReady` on the leaves lane, scoped runs and `motir batch` over leaves ∪ bugs, `motir auto` leaves then bugs, the link probe and `motir ready`'s read
- (motir-core) `/ready` renders the lanes — expandable runnable-container rows over their ready leaves, standalone leaf rows, and a separate Bugs list with its own count
- (motir-core) The MCP `list_ready` and `next_ready` take a `lane` — `leaf` (default) · `container` · `bug` — so an agent and `/ready` never disagree
- (motir-core) Three `/api/v1` operations — `GET …/ready/leaves`, `…/ready/containers`, `…/ready/bugs` — with their row schemas, OpenAPI entries, contract-version bump and run-token access
- (motir-core) The ready set's three LANES in the service — `listReadyLeaves` grouped by runnable container, `listReadyContainers`, `listReadyBugs`, one group order and one lane-aware cursor over the existing readiness walk
- Ready work in three lanes — `/ready` lists runnable containers that expand to their leaves plus a separate Bugs list, and `motir next` / `--parent` / `--bug` each take their own lane from three new API endpoints
- (motir-core) A Visitor's data doors find their project through a browser-global cookie — a member tab in the same browser clears it, and the Visitor tab's next board, peek or overlay read answers from the reader's OWN project
- (motir-core) The Approvals pager on a Visitor view links to the member `/approvals?page=N` — whenever the `motir_visitor` cookie is gone, Next page lands the reader in their own project
- (motir-core) A Visitor can't switch Work items between List and Tree — the switch pushes `?view=` onto `/p/<id>/items` or `/tree`, whose pages pin the view by path and ignore the query
- (motir-core · verification) VERIFY Release A is SERVING on every `motir-core` machine before the client stops selecting the legacy role fields — `workspace_role` NOT NULL in production, the fallback-free image running, and no not-null or role error in its windowRoles & 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