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
- 贊同
- 534
- 已規劃
- 4,986
- 已發布
- (motir-core) Two-instance enforcement test — two app processes on one database split one agent's MCP calls and refuse at exactly one per-agent budget, not twomotir-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) Job read-backs metered per job — `/api/internal/ai/*` draws a per-job bucket keyed on the token's `jobKey` (600/min, today's per-user `ai:internal` bucket as the fallback for a keyless token) plus the shared workspace ceilingmotir-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) The core client retries every job-token call refused `RATE_LIMITED` after `retryAfterSeconds`, within a bounded total, and an exhausted bound ends the job as a `rate_limited` outcome — never `validation_error` or "could not be read"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 CLI's `/api/v1` transport honours a rate-limit refusal — on a 429 it says it is waiting, waits `retryAfterSeconds`, retries the same call within a bounded total, ends as a `RateLimitError` when the bound runs out, and a retried claim never claims 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) Volume per agent, ceiling per workspace — named, env-configurable budgets (600/min per agent, 12 000/min per workspace) with their arithmetic, `mcp:call` keyed on the presented credential's fingerprint plus a workspace-ceiling limb, `/api/v1` gaining the same ceiling, money buckets left per `(workspace, user)`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) One retryable refusal contract — every agent-reachable rate-limit refusal (MCP transport 429, billable tool `isError` result, job-token route 429, `/api/v1` 429) carries a numeric `retryAfterSeconds` in a machine-read field plus `Retry-After` on HTTP; code `RATE_LIMITED`, v1 keeping its frozen `RATE_LIMIT_EXCEEDED`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 job token carries a per-job id claim, minted at submission and kept unchanged across `refreshJobToken`, so a job's read-backs can be keyed per job (a token without it falls back to its user key)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) Limiter inventory — every rate-limit call in motir-core from a ref-stamped `git grep`, each with its caller classes, today's scope, key and budget and its new ones, whether its counter write can run inside a request transaction, and the MOTIR-8423 cause settled against motir-ai's job-token 429 handlingmotir-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 auto` never records its legs: the idempotent re-open ignores the new card, so every per-card event 422s
- Enable pg_stat_statements on the production Neon database and read it back with the checked-in command — CREATE EXTENSION over the direct connection, once the story's merge has put the command on main (a staging branch cut from production afterwards inherits it)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
- To resume keeps listing a card that has since reached In Review with its pull request open — resume should reconcile it, not stamp or re-run it
- (motir-ai · motir-core) A planning job that fails reading the project back from core loses its cause and the session says "the AI provider was unavailable"
- To resume keeps listing a parked scope run's old cards after a plan re-shapes its story: new children never appear and re-scoped ones are not flagged
- Planning failure: ai_job_failed in a entry_author session on MOTIR-8239 — gateway: tool "report_findings" arguments were not a JSON object
- Onboarding's GitHub connect says what will happen on GitHub before you leave, brings you back to the step you started from, and has explicit install-cancelled, no-repositories-selected and already-connected statesOnboarding 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 onboarding substrate reads an organisation's connected repositories, so a run let through by the organisation-tier exit gate is not grounded on "no repositories"Onboarding 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 connect step's exit gate — an organisation that already has connected repositories can leave the step, whichever of its workspaces connected themOnboarding 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 the nine other app languages (ja, ko, de, fr, es, it, nl, pl, pt)Onboarding 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
- E2E — the onboarding GitHub connect round trip and every outcome state, in English and Chinese, with a paced acceptance videoOnboarding 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
- Integration — the setup callback's outcomes across both return surfaces, against the real datastoreOnboarding 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