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
- 490
- planned
- 4,830
- shipped
- (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
- A targeted planning run never gets its target's parent or siblings: `parentKey` is read off the target's own subtree root row, where core always returns it null, so the parent body and sibling list are never put in the grounding
- A gap raised by the target's own author session never reaches the lay under that target: it is filed against the target's PARENT level, which the walk never lays, so the work it names is silently dropped
- The hosted planner cannot run on Opus 5.5 at all: every `structured()` call forces `tool_choice: {type: "tool"}`, which Opus 5.5 rejects with HTTP 400, so the first classification step fails and the rail shows "That didn't go through"
- The live planning rail still prints the planner's tool calls (a RETRIEVAL / SEARCH / DRILL row per lookup) and raw `frame: model_stop` / `frame: session_summary` lines, and they vanish when the overlay is reopened. Draw none of them
- The generating-plan review read still does a full read on every poll: answer "unchanged" (after auditing what writes lastActivityAt), send narration as a delta, and cut the approval gate's item read and the sequential transactions
- (motir-core · design) The "code can't be read right now" state on a planning turn — plan-writing turn with no plan written, question turn answered with a could-not-read-the-code noticeA 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
- A changed tick of the generating-plan poll still re-sends the newest 100 narration sentences and the projection still loads the project's whole live item set
- (motir-core) Approving a plan fails when a `modify` proposal's `blockedByAdd` names an edge that already exists — `applyModify` inserts with a plain `create`, so the unique `(fromId, toId, kind)` aborts the whole approve and the overlay shows only "That didn't go through"