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
- 贊同
- 537
- 已規劃
- 4,987
- 已發布
- The connect step — pre-flight, one action per outcome state, and no control that does nothingOnboarding 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
- Translate — the connect step's new copy and the owner-approval banner into ChineseOnboarding 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
- Copy — the connect step's pre-flight, every outcome state and the owner-approval banner, in the message cataloguesOnboarding 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
- Service + route — the connect step's read: the organisation, its usable repositories, and whether an installation is boundOnboarding 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
- The App-install round trip — starts on the connect step, returns there with the run's context, and reports an owner-approval request honestlyOnboarding 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
- The Workbench live stream keeps polling the database after the reader leaves
- A parent run over MCP never reports a manual child as skipped / needs_human, so no manual_work gate is raised and the card is missing from Waiting on you
- Usage & cost hides the Translation line when an organisation's only AI spend is translation (hasUsage ignores translation)
- Planning bug: post-deploy after-measurement card MOTIR-8588 laid inside the story whose merge it waits on
- (motir-ai · motir-core) Resume is offered for a planning job that failed before any conversation settled, and motir-ai refuses it with "no settled conversation" — shown as "the AI provider was unavailable"
- Planning rail shows "Nothing came back to change" after a declined code-unreadable turn
- A slow request in production names its slow query — pg_stat_statements on Neon and performance traces on the hot routes and every MCP tool call (reads, writes, claims, runs), each tagged with its instance, with each request's transaction and pool-wait time visiblemotir-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
- A streaming route sends every post-response poll to Sentry as its own transactionmotir-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
- An MCP request's Sentry transaction keeps the name POST /api/mcp instead of its tool's namemotir-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 — a running server with tracing on and a local capture endpoint for its DSN: opening /workbench and a plan and calling move_to_parent and add_plan_items over MCP yields traces named by route and tool, with wait/hold transaction spans, placeholder-only SQL spans and instance tags, and every request recordedmotir-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) Integration gate — coverage floor over the trace-rate setting, the transaction seam spans, the every-request recorder, MCP tool naming and the pg_stat_statements command; the seam-to-span-to-sink path; and the guards that no DSN means no init, the P2028 tag set is unchanged and no span carries a bound valuemotir-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) Every hot-route request records its transaction wait and hold time and pool occupancy, sampled or not — per route (and per MCP tool), to a named sink whose p50/p95/p99 a person can query over a time windowmotir-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) A checked-in read command lists pg_stat_statements' top statements by total time, mean time and calls — normalized SQL, call count, mean and max ms, and when the statistics were last reset — over the direct (unpooled) connection stringmotir-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) Every MCP tools/call is traced under its tool's name — reads, writes, claims and runs alike — so a slow move_to_parent or add_plan_items is found by tool in Sentry's trace search, with its transactions beneath itmotir-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) Every interactive transaction is its own span, split at bodyStarted into waiting-for-a-connection and holding-it — attached at the retryOnceBeforeBody / $transaction seam so every with*Context helper is covered, carrying pool occupancy at acquire, with its SQL statements as child spans in placeholder form and no bound valuesmotir-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