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 (both planners): a requirement that narrows WHO may do an act ("only the STOP branch files a planning bug") is laid without enumerating every site that does the act today, so the log-bug.md route that misfiled MOTIR-8646 got no card
- motir.co's subscribe form does not send the page language, so an email-only follow records the browser's language instead of the page's
- Motir AI chat panel: an assistant message's long lines and code spans run past the panel instead of wrapping, and the log scrolls sideways
- Guide me through shows each step twice — the model restates the step and the code appends the same step block after it
- Read back from Fly's managed Prometheus that production's app machines are scraped on the [metrics] port, and that the per-route and per-tool p95 wait/hold queries return data — name the machines and release that answeredmotir-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
- Decision — the generated first-project name is never rendered on onboarding, and its settled shape is a lowercase hyphenated adjective-noun-number placeholderOnboarding 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
- A run that stops on an unbuildable card reaches Motir's planning-bug home only from the runbook and a tenant's own machine — hosted runs, agent-instance runs, an agent with no Motir MCP, and Motir's own CLI dispatch never file one
- Planning bug (both planners): a re-lay gap with a BODY half is reported "raised and closed" when only its structural half was answered, and a gap raised after the re-lay about stale sibling bodies is handed back and never reaches the briefing, so the person approves stale cards believing they were reconciled
- Planning bug (both planners): a committed card re-titled in a level's RE-LAY is never re-authored. MOTIR-8644's authoring list is drained only before the re-lay, and the re-lay is told never to re-draft a body, so the card keeps its stale body under the new title
- A plan's change to an existing card cannot set its to-do list — `todos` is refused on a `modify` patch, so a re-plan can neither give a person's card steps nor replace a stale list
- A run builds through a plan that is wrong only about the HOW — it records each discrepancy on the run and the card, and stops, re-plans and may file a planning bug only when the WHAT breaks
- (motir-meta) `log-bug.md`, `_shared.md` and `core.md` gate 15 stop routing a defect into `Bugs / Planning bugs` — a planning bug comes only from a run's STOP (THE RUN-FOUND CONDITION, `unchanged`) or `plan-procedure.md` act 5; every bug `motir log bug` files takes the two placement branches, whatever it is about
- (motir-core · test) E2E and acceptance video — a scripted MCP client claims a card, starts its run, records a three-point discrepancy and closes it delivered; the run modal's findings strip shows the discrepancy row beside a filed bug, and its door opens the card's comment listing all three points
- (motir-core · test) Story integration gate — `record_run_discrepancy` over the real database on a CLI leg, an agent-reported leg, a parent run's child leg and a card with no open leg; one record per leg with three points; pointer-only data; the `CLI_TOKEN_GRANT` call; refusals; the prompt's two branches in both lanes; the coverage floor
- (motir-skills) The `motir-run` skill's standalone mode builds through a wrong HOW — the same WHAT test, BUILD THROUGH with `record_run_discrepancy` and the missing-record line, STOP and its fallback unchanged, regular bugs unchanged; `SYNC.json` re-hashed against the changed `run.md` sections
- (motir-meta) `run.md` teaches BUILD THROUGH beside STOP — one test on the WHAT ahead of THE RUN-FOUND CONDITION; the falsified-premise rule, guard #4, THE REPLAN ACTION's triggers and the parent run's step 4 route a wrong HOW to a build-through recorded with `record_run_discrepancy`; non-plan guards still stop; `_shared.md`'s door table gains the row
- (motir-core) `RunFindings` renders a `discrepancy_recorded` event as its own row — the designed marker, label and point count from the pointer-only data, opening the card's comment, in the run's own order beside bugs and plans; its i18n strings and component tests
- (motir-core) The dispatch prompt's card-is-wrong steps split in two, in both lanes — `cardIsWrongSteps` asks the WHAT test first; BUILD THROUGH builds to the WHAT, calls `record_run_discrepancy`, states the deviations in the PR description and says when the record is missing; STOP keeps today's comment, `report_unbuildable_target`, park and re-plan
- (motir-core) The `record_run_discrepancy` MCP tool — a transport over `recordDiscrepancy`, gated `work_item:edit` so a `CLI_TOKEN_GRANT` agent and a `motir-run` skill session can both call it, its acknowledgement-only answer, its registry entry and `docs/mcp.md`
- (motir-core) `runDiscrepancyService.recordDiscrepancy` — validate one-or-more points (plan asked · built · why), write ONE comment on the card, and record a `discrepancy_recorded` finding on the card's open leg with pointer-only data; the `DispatchEventKind` member and its migration, the DTO, `findFindingOnRun`, one record per leg