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
- 需求
- 4
- 贊同
- 535
- 已規劃
- 4,982
- 已發布
- 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
- (motir-core · test) Story test gate — coverage floor over `loadtest/` and the side-effect switches, the seams between seed manifest, scenarios, run output and report run for real, and guards that the preflight refuses a live sink, a Fly count ≠ N aborts, an `unmeasured` threshold never yields PASS and a 429 is never counted as success or errormotir-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) The runbook, `loadtest/README.md` — from a clean checkout: provision or reuse staging, refresh its branch from production, deploy a chosen SHA, seed, set N and run with one command, how each side-effect sink is checked, and how to read a report; every step one command and what it printsmotir-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) Report generator — a PASS/FAIL line per per-instance threshold and, at N > 1, the scale-out threshold against a named 1-instance report; P2028 counted from the staging app's logs; the 429 reading on its own line; one ranked first bottleneck from per-route latency, Fly CPU/memory, the wait/hold sink, pg_stat_statements, Neon load and the proxy limit; `unmeasured` blocks PASS; a saturated generator flagged; the full what-answered headermotir-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) The checked-in profile and the one run command — smoke and default shapes with mix ratio, agents per user and workspace, ramp, duration and every threshold; `--instances N` scales the staging `app` group, reads N back from Fly and aborts on a mismatch, scales offered load with N, runs the preflight and starts k6 on the `iad` generator machinemotir-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) k6 reader scenarios — signed-in sessions render /workbench and hold /api/workbench/stream open like a tab (open or reconnected counted at the end), and read the board, the items list and /api/plans/[id]motir-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) k6 run-lifecycle scenario — each "runs" agent opens a dispatch run, reports step events and closes it through the same API calls `motir run` makes, against seeded scratch cards, with no agent container startedmotir-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) k6 agent scenarios over MCP — reads (get_work_item, search_work_items, skeleton, get_plan), writes (update_work_item, transition_status, add_comment, move_to_parent, add_plan_items on scratch plans), claims (claim_next_ready / claim_work_item) and the scalable 2026-10-13 move_to_parent burst, many agents per user and workspace, 429s tagged as their own outcomemotir-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) Seed synthetic tenants into a staging branch — signed-in users in real workspaces, many agents (personal access tokens) per user and per workspace as the profile sets, a resettable pool of scratch cards to claim and scratch plans to append to, and a manifest the k6 scenarios readmotir-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) Staging side-effect switches — email, GitHub writes, Sentry, motir-ai calls, fleet machines and billing each off or pointed at a sink under the staging environment, and a preflight that reads the deployed staging app and refuses to start a run while any of them is livemotir-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's emails arrive in the recipient's language — every transactional and notification email rendered in the recipient's saved language, the language they used with Motir when they have no account, English when Motir knows neitherMotir in eleven languages — app.motir.co and motir.co in en·zh·ja·ko·de·fr·es·it·nl·pl·pt, per-language font sets, and work content in an org content language with per-user translation
- Story integration test: per-recipient language through every sender, and all 18 templates rendered in all eleven languagesMotir in eleven languages — app.motir.co and motir.co in en·zh·ja·ko·de·fr·es·it·nl·pl·pt, per-language font sets, and work content in an org content language with per-user translation
- Guard test: every template arm and sender supplies a recipient language, none reads the current requestMotir in eleven languages — app.motir.co and motir.co in en·zh·ja·ko·de·fr·es·it·nl·pl·pt, per-language font sets, and work content in an org content language with per-user translation