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
- 贊同
- 533
- 已規劃
- 4,984
- 已發布
- (motir-core) A plan snapshot is MERGED into the screen by identity — unchanged snapshot changes nothing, a changed proposal re-renders alone, a withdrawn one disappears, in PlanDetail, usePlanGeneration and usePlanChangeConversationmotir-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 Workbench applies a nudge in place — rows and counts held as client state from the one endpoint, rows merged by identity, no route refresh, and nothing refreshed while an approval is open over 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) ONE Workbench read — an endpoint returning the active tab's window and all five counts from a single server read, sharing the page's pairingmotir-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 live-signal SEAM — one source-agnostic 'something moved' input the Workbench, approval and plan appliers read, with the SSE nudge and the 2.5 s plan poll plugged in as today's sourcesmotir-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) Confirm the refresh-under-an-open-approval cause — a spec that counts RSC refetches and document loads while an approval is open over /workbench and over an item page during a write burstmotir-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
- No correctness depends on one instance — every in-process state in motir-core's `app` (rate-limit buckets, caches, locks, dedup and the live-update hub) found, and either moved to shared state or shown safe per instance, proven by a two-instance test where a request and its follow-up land on different machinesmotir-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) Scripted two-machine staging check — the limit and follow-up cases run against a base URL, each request pinned with `fly-force-instance-id`, output naming which machine served the first and second requestmotir-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) Story integration gate against real Postgres — coverage floor over the Better-Auth storage, the memory-store guard and every moved row, and the guards that no module-scope state returns for themmotir-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) Two-instance follow-up cases — session signed in on A loads an authed page on B, MCP initialize on A then tools/list and a write on B, a repeated idempotent write or double plan approve applied once, an OAuth or device flow started on A completed on B, a write on B shown on a workbench stream held on Amotir-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) Two-instance limit cases — three `/request-password-reset` calls on A and one on B refuses the fourth, the sign-in bucket likewise, an MCP volume budget spent B−1 on A and 2 on B refuses the last with 429 and the JSON-RPC envelope, and one `/api/v1` budget the samemotir-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) Two-instance CI harness — two production-build `app` servers on one Postgres, a client that sends request N to A and N+1 to B, wired into CI for PRs touching lib/, app/ or server.js, with the scratch-commit control run (a module-level counter used as a limiter turns it red)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) Move every inventory row classified "moved" to shared state in Postgres — each reads and writes the shared store, and a row whose answer would be wrong rather than stale on another machine is not left per instancemotir-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) Refuse the `memory` rate-limit store on a multi-instance deployment — a startup guard on `MOTIR_RATE_LIMIT_STORE=memory` in a production build, the guard's choice (refuse to start, or a reported error the deploy fails on) namedmotir-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) Better-Auth's limiter on shared storage — read the installed version's default storage from node_modules, then move `authOptions.rateLimit` to shared storage so the password-reset and sign-in buckets count once across the fleetmotir-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) In-process state inventory — a ref-stamped `git grep` over lib/, app/ and server.js for module-scope Maps, Sets, lets, globalThis slots, timers and library in-memory defaults, every hit a row or an excluded line with its reason, each classified shared / safe per instance (staleness in seconds) / movedmotir-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
- Many concurrent agents per user or workspace are served, not starved — rate limits keyed and sized for agent traffic, enforced the same across every instance, and a refused agent call answers a retryable limit, never a failed job (cf. the ai:internal 30/min per-user bucket, MOTIR-8423)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) The workspace ceiling is spent only after the caller's own limb admits — a runaway agent or job refused at its per-agent / per-job budget draws nothing from the shared `agent:workspace` ceiling, on MCP, `/api/v1` and job read-backs, so it cannot starve its workspacemotir-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) End-to-end — a real `motir run` loop against a local app with the `/api/v1` budget shrunk (`MOTIR_API_V1_RATE_LIMIT`; the CLI is a v1 client, not an MCP one) is refused, prints the wait, carries on, and claims no card twicemotir-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) Story integration gate against real Postgres — 20 agents of one user served with zero refusals (and today's keys refusing them as the control arm), a runaway agent contained at its own budget, the workspace ceiling unwidened by minting, money buckets unchanged, two concurrent jobs' 100 reads/min each served, every refusal machine-retryable; coverage floormotir-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-ai) Story integration gate — a planning job against a core stub that answers 429 with `retryAfterSeconds` on its first N job-token reads waits, retries and ends `succeeded`; an exhausted bound ends as a rate-limit outcome; coverage floor on the changed clientmotir-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