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
- 贊同
- 499
- 已規劃
- 4,959
- 已發布
- E2E acceptance — a red pull request fixed from the Development block in the person's own agent, recorded as a video paced for a human and published to the story, covering the states a person meets on the way
- Behind a project setting that is off by default — a delivery set reported red starts the fix in the card's own agent on its own, when that agent is up and the repair is free, and silently does nothing when the setting is off or the agent is not usable
- `motir fix` in an agent resumes the card's recorded session when that run was in this same agent, and says so in the run's output when it starts a fresh agent on the branch instead
- Translate — zh twins for the new Fix in my agent strings, so the door and its states never fall back to English in the Chinese interface
- The fix run's opening — claim the repair for a red card from the agent door, admit it by its repair class rather than by review-sent-back alone, release the claim when the fix gives up so Fix can be pressed again, and refuse visibly while another repair holds it
- Project settings — the Agent auto-fix switch: its off-by-default project column, the read and save behind it, and its row in the Hosted agent settings room, read under work_item:edit, saved under ai:configure, and read-only to a member who may not configure the hosted agent
- The CI watch's other lanes resume the card's own session too — `motir batch`, `motir auto` and `motir fix`'s repair loop hand each card's own profile and session id to the watch instead of launching a fresh agent for every fixing iteration
- Story gate — top the story's changed surface up to the coverage floor, add the writer→consumer seams the units mock, and assert the guards coverage cannot see: the resume falls back rather than failing, a second fix cannot start while one holds the claim, and one run mode never leaks into another
- Document the fix and continue modes and the Fix in my agent door in the agent-run decision record — what a resumed fix is, what the claim guarantees, and what a profile without a resume form does instead
- Fix in my agent in the Development block and in an ended run's modal — offered only for a red delivery with no repair claimed and an agent this viewer can use, defaulting to the agent the last run used, showing the refusals and the in-progress run, and settling itself when the pull request goes green first
- The agent's terminal server acts on the mode — spawn `motir fix` or `motir continue` for the run instead of `motir run`, with the run's environment and the same supervision that ends a lost session
- CI fix during a run resumes the run's own session — the fix prompt arrives in the existing conversation, and a profile with no resume form falls back to a fresh process on the same branch
- A card's last in-agent run, read back — which agent it ran in, the session id that run recorded, and whether that agent has a resume form — the answer both the door's default and the resume depend on
- The run mode on the agent-run start — run, fix or continue carried from the start input and the POST body through the launch command the agent's terminal executes
- Design — Fix in my agent: the door in the Development block's fix part and the ended run modal's copy of it, drawn for offered, preparing, in progress, refused, fell-back-to-a-fresh-session and gave-up, with its entry affordance and the auto-fix setting's row
- A code graph whose repository no longer exists under that name is never removed; a GitHub org rename orphans every graph
- Planning bug (both planners): no step finds the finished cards a plan makes untrue — marking is pointed at only from reconciling the level's own members, so cards replaced elsewhere stay unmarked
- Planning bug (both planners): a re-lay gap owed under another parent whose WHAT turns on an undecided decision is only reported, so the follow-up has no card, no owner and no edge holding back the cards that create the hazard
- plan.py sessions on the MCP code-read path are still told to run gh / git grep / git ls-tree / git fetch, which they are not granted, and are never told their real Bash grant — so they burn turns on refused commands
- Planning bug (plan.py): author sessions are told what each section holds but never its shape, and the MCP door's `sections` argument is untyped, so they send `deliverables` as a list and the door refuses it; the hosted planner types the argument from the served section sets