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
- 499
- planned
- 4,801
- shipped
- 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
- (motir-core) The trace sample rate is a per-deployment setting, not a constant — read at boot (unset ⇒ 0), passed to the server and edge Sentry init, the worker kept at 0, every event and span tagged with its instance (Fly machine, process group, region), and its span-volume cost documentedmotir-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 design mock rendered with renderMock from @motir/design-system 0.14.0 fails the mock-utility correspondence guard on two `.style-vignette` rules no mock uses
- Record the before-measurement of the job tables on productionmotir-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
- The job worker full-scans job_queue about every 1.3 s: under FORCE RLS the non-leakproof enum `state =` filter cannot use the (state, run_at) index, and the table holds 268k finished rows to find 3 pending
- MonitorLinkNotYetVisibleError: The monitor link for work item cmv76wrj40nznhnpxk8lxg9v3 (connection cmv3kxq6z00k5hwsh69rqeybk) is not visible yet.
- (motir-core) The acceptance video in the approval overlay cannot go full screen — it snaps straight back into the in-page player
- Planning failure: validation_error — planning: the target MOTIR-8239 could not be read for this user
- Translate a work item on demand — a Translate button when the content is not in your language, cached per field, revision and language, billed to the organisation at model cost + 50%, with its loading, failed, no-credit and stale statesMotir 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