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
- 已發布
- Copy — the account list, identity prompt, repository picker, nothing-left state and every link outcome, in English and Chinese, 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
- motir.co's setup prompt and install guides pin the plugin at v0.7.0 while motir-skills is at v0.8.1 — every release needs a hand bump that nobody does
- (motir-core) A member of one org has no way to create their own organization — "Create organization" only exists in the switcher of an account that already belongs to two
- The published CLI (@motir/cli 0.12.0) drops a dispatched agent's unbuildable report: the deployed prompt tells the agent to write it to $MOTIR_AGENT_REPORT instead of calling the tool, and 0.12.0 never posts it
- `sync-project-runner-groups.ts --project MOTIR` refuses in production because two workspaces own a project keyed MOTIR — the operator script has no way to name the project by id
- A container never completes when one of its repositories shipped through a child's OWN merged pull request: the repo-set gate counts only the container's linked deliveries and rejects any leaf that has one
- The fleet readiness verdict's image coverage counts jobs that never request the fleet, so motir-gateway's macOS and Windows release jobs hold the Motir-CI-on-fleet switch off for ever
- Workbench stream route test can leave a read open after cancel, ejecting PRs from the merge queue
- (manual) In production, sync project MOTIR's runner groups once and read its `moooon-B-V` group back from GitHub — private repositories only, public refused
- "Grill me" is silently skipped: the sharpen_turn ask step comes back `unavailable` twice, and the failure is hidden once the run hands off to planning, so the plan is written with no question asked
- Live updates reach an open page by server push, not polling, on whichever instance holds it — Postgres NOTIFY fanned out across every `app` instance replaces the Workbench stream's per-tab watermark poll and the plan overlay's 2.5 s poll, one stream per tab, paused in a background tab, resuming after a drop without a page refreshmotir-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
- Story E2E with acceptance video: one stream per tab, no timer polls, hidden-tab close and resume, offline Reconnecting and resume, no document load or RSC refreshmotir-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
- Story test gate (integration): coverage floor, every-writer-heard, leak fixture, burst coalescing, one LISTEN session, missed-notification backstopmotir-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
- useGeneratingPlanPoll: replace the 2.5 s timer with plan frames from the one tab stream, caller contract and existing tests keptmotir-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
- Host-held stream client: close after the hidden grace period, reopen with the held cursor on show, reconnect with backoff after a drop, Reconnecting chip, en/zh stringsmotir-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
- Plan frames on the same stream: watched-plan set carried on the stream, per-plan notification routing with the reader's read gate, frame carries plan id and reviewVersionmotir-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
- Workbench stream route: replace the per-second watermark poll with hub notification, per-project coalesced re-read under the reader's context, 60 s backstopmotir-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
- Per-process listener hub: one LISTEN on the direct URL, in-memory fan-out to open streams, bounded-backoff reconnect with a degraded log linemotir-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
- NOTIFY triggers on every table the Workbench watermark and plan review read from, ids-only payload, plus a test that every input table has onemotir-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 the staging check on two `app` machines and read production and staging back from the platform — `fly machine list --json` showing two started machines, `fly secrets list` showing no `memory` store, the check's pass lines posted on the story with both machine IDs and the timemotir-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