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
- 497
- planned
- 4,801
- shipped
- (motir-core) The org switcher cannot switch to an organization that has no workspace — the shell stays on the org that owns the pinned workspace cookie
- A dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (verify) On production, the planning pool suspends when idle, resumes in about a second on a turn, scales out to a second machine under five concurrent sessions, and suspends again after a deployA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- Planning bug (both planners): cards state what existing code DOES, logs or supports without reading it, and nothing checks the finished cards against the code or against each other — the same plan written by a cheap and by an advanced model carries the same wrong facts
- Provision staging — its own Fly app (`app` + `worker`, `app` machines the size production runs, read back with `fly machine list --json`), a Neon branch copied from production with its own pooled and direct URLs, secrets pointing every side effect at a sink, and a load-generator machine in `iad`, each read back from the platformmotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) "New workspace" creates the workspace in the org the stale `motir.org` cookie names, not the org the shell shows; the public-project submit hint names that org too
- (motir-core) The org settings pages (usage, billing, members, security) read the stale `motir.org` cookie, so after a workspace switch they show another organization than the shell names
- A realistic sample project, committed as one reusable vendor-neutral fixture — epics, stories, subtasks, statuses, assignees, labels, comments, links and sprints / cycles — for the import proofs to loadOnboarding that matches motir.co — the Motir look and "vibe the project" voice, a GitHub connect that does not lose you, no waiting on the index, a generated first-project name, and import proven against real Jira, Linear and Plane
- Story test gate: the check passes on the committed fixture, fails naming the item on a broken parent id and passes after undoOnboarding that matches motir.co — the Motir look and "vibe the project" voice, a GitHub connect that does not lose you, no waiting on the index, a generated first-project name, and import proven against real Jira, Linear and Plane
- Build the CI check that validates the fixture: kind-parent matrix, depth, dangling ids, person emails, iteration membership, naming the offending itemOnboarding that matches motir.co — the Motir look and "vibe the project" voice, a GitHub connect that does not lose you, no waiting on the index, a generated first-project name, and import proven against real Jira, Linear and Plane
- Write the per-vendor expected-result file: each fact marked must-arrive or known-not-read by the shipped connectorOnboarding that matches motir.co — the Motir look and "vibe the project" voice, a GitHub connect that does not lose you, no waiting on the index, a generated first-project name, and import proven against real Jira, Linear and Plane
- Write the per-vendor translation table: Jira, Linear and Plane representation of every fixture concept, incl. kind without a native type and iterationsOnboarding that matches motir.co — the Motir look and "vibe the project" voice, a GitHub connect that does not lose you, no waiting on the index, a generated first-project name, and import proven against real Jira, Linear and Plane
- Write the vendor-neutral sample project: 3 epics, 10 stories, 20 subtasks, bugs, tasks, one orphan, people, labels, comments, links, iterationsOnboarding that matches motir.co — the Motir look and "vibe the project" voice, a GitHub connect that does not lose you, no waiting on the index, a generated first-project name, and import proven against real Jira, Linear and Plane
- Define the fixture format: schema, types and location for the vendor-neutral project, translation table and expected-result filesOnboarding that matches motir.co — the Motir look and "vibe the project" voice, a GitHub connect that does not lose you, no waiting on the index, a generated first-project name, and import proven against real Jira, Linear and Plane
- Both planners owe a to-do list only on `type: manual`, so a person's card of any other type (review, verification, deploy…) is planned with no steps — and is given command-running criteria and a merge-gated place between code cards
- Design the non-blocking index states: onboarding-chrome indicator + detail, generate-step 'drafted when indexing finishes' notice, plan-ready moment, failed-index state with retryOnboarding that matches motir.co — the Motir look and "vibe the project" voice, a GitHub connect that does not lose you, no waiting on the index, a generated first-project name, and import proven against real Jira, Linear and Plane
- Design — the connect step's already-installed accounts: account list, GitHub sign-in prompt, repository picker with unavailable and nothing-left states, and every link outcomeOnboarding that matches motir.co — the Motir look and "vibe the project" voice, a GitHub connect that does not lose you, no waiting on the index, a generated first-project name, and import proven against real Jira, Linear and Plane
- Anyone can re-run one load test against a staging copy of production data — an agent-dominated mix (MCP tool calls: reads, writes, claims, runs, many agents per user and workspace) beside signed-in readers, run at 1 and at N `app` instances, with a per-instance and a scale-out pass/fail target and a report naming the first bottleneckmotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) Run-window capture — the run command also records the staging app's logs from every machine, a database load sample every 10 s over the branch's direct URL, the Neon endpoint state, pg_stat_statements before and after, and k6's raw points, into the run directory the report readsmotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core · test) End-to-end — the one run command at a tiny profile against a local production build on a real Postgres, Fly and Neon reads stubbed, produces a complete report with every section, at N=1 and at N=2 against a named 1-instance reportmotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test