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
- 贊同
- 491
- 已規劃
- 4,998
- 已發布
- `main` is red since #3512 (MOTIR-8188): the readonly-role test fails in CI, and `RAW_CEILING` (30) now counts 32
- Dead letters for `system.platform-meter-report` have stood undisposed for more than 7 days
- A Sentry connection whose refresh token is gone is re-polled every 5 minutes forever: each tick spends a provider call and logs "refresh refused; connection marked degraded", and production errors stop reaching the board
- plan.py drops the gaps an author's completeness RETRY raises: `Walk.author` returns the first session's result and never reads the retry's `gaps`
- The hosted plan briefing's section 3 lists every finished card in the 300-row neighbourhood skeleton (312 unrelated "is done and is left as it is" lines), and section 5 still reports gaps that the re-lay already closed
- A read-only Postgres role on the production motir-core and motir-ai databases, so an operator or a diagnosing agent can query production directly instead of shelling into a Fly machine
- Give motir_readonly a login on the two production Neon databases and store the connection strings for the sandbox
- The hosted walk lays children under a target whose rewrite was refused: the entry author's `author` call is refused, the model ends its turn, and `runWalk` sets `authoredTarget = true` anyway, so the plan keeps the target's old body
- (motir-ai) Migration creating the NOLOGIN read-only role motir_readonly: SELECT on public now and by default, read-only and 30 s timeout defaults, idempotent
- (motir-core) Migration creating the NOLOGIN read-only role motir_readonly: SELECT on public now and by default, read-only and 30 s timeout defaults, idempotent across a shared cluster
- A planner tool call that is refused leaves no record of why: `tool_call_failed` carries only `reason: "refused"`, motir-ai logs nothing, and the refusal text the model read is lost
- An unreadable code graph is an incident: plan-writing turns write no plan and say the code can't be read, questions answer but confirm nothing unread, and the operator is alertedA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-core · test) Story E2E — in the browser, a plan-writing turn shows the outage message with no plan written, a question shows its answer with the notice, and both recover after the graph returnsA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-core · test) Story integration gate — coverage floor and the outage signal driven through the job read into the rendered plan-writing and question statesA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai · test) Story integration gate — coverage floor and real jobs driven through a stopped graph: each plan-writing kind writes no plan, ask_project and debug_bug answer without unread facts, one alert, other tool errors unchanged, recovery after restartA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-core · code) Render the "code can't be read right now" state from the job's outage signal — plan-writing turn shows the message with no plan written, question turn shows the notice beside its answerA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai · code) Raise one de-duplicated operator alert per outage when an unreadable graph is met during a planning job — including debug_bug's grounding-step detection (Grounding.unreadable), which bypasses the retrieval wrapper — naming the repository and the reasonA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai · code) Question jobs (ask_project, debug_bug) answer under an outage rule — say the code could not be read and confirm no code fact taken from memory, work items or a partial file readA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai · code) An unreadable graph is a distinct job outcome — plan-writing jobs (generate/draft, expand, replan, augment, plan edit) write no plan shape and end with the outage outcome motir-core can readA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- plan.py drops every gap the target's own author session raises: `Walk.walk()` never reads `res['gaps']` on the author entry, so the gap reaches neither the lay under the target nor the run's notes, and the work it names vanishes without a trace