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
- 贊同
- 537
- 已規劃
- 4,989
- 已發布
- A conversation plan's target leaves Planning 30 minutes after the session's last turn while its plan still waits for approval: the sweep spares only plan-held locks
- Planning bug (plan.py): a plan whose author sessions failed still closes as planned, and the briefing only mentions the failure if the brief model chooses to
- plan_inbox.story.test.py scenarios 10, 12, 13 and 14 race the pause gate and fail intermittently under CPU load
- Planning bug (plan.py): a gap the re-lay neither answers nor lists as unanswered is silently dropped. Its re-lay never answers each gap by name.
- Design — the connect step's pre-flight and every outcome state it can return inOnboarding 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-ai) The planning-deploy e2e test fails by 1 ms: its 310 s hold wakes a millisecond early against Date.now(), and step 6 then fails behind it
- plan.py deadlocks after a paused change is answered: the resuming thread keeps the pause gate while its relay's author sessions wait at that gate
- Planning bug: a re-lay marks every gap it was handed "raised and closed" by whatever it added, so a gap nothing answered reads as done in the plan briefing
- plan_inbox.story.test.py flakes under CPU load: section 10/12's walk_world assumes sessions B and C open before A's verdict pauses the walk
- Planning bug (plan.py): a blocked_by added during authoring never re-orders or re-authors the consumer. Seam siblings are written blind to each other's boundary.
- plan.py pauses silently: a START OVER offer or an unclear question is written only to the run directory, so the launching session sees a run that looks stuck
- plan.py --resume-plan / --plan-id silently drop the free-text words: a change passed with a resume never reaches any session
- A plan Motir AI writes never records its planning model on the Plan row — `plan.author_model` is null on every native plan, so model analysis has to reconstruct it from the proposals
- (motir-ai) A deploy exits 2 on every run with a sleeping old machine, because the new machine's boot sweep has already destroyed it and the deploy's own DELETE then gets a 404
- (motir-ai) A failed deploy never takes the pool from the old release — machines from a run that exits 3 stop setting the pool's current release the moment the command retires them, so the old release keeps resuming its suspended machines and handing off to its peers
- (motir-ai) End-to-end across a simulated deploy — a job on a retired machine outlives 300 s and completes there, a job submitted during the overlap goes to a new-release machine, an idle and a suspended old machine are gone without being woken, and the old machine exits by itself
- (motir-ai) Story integration gate — coverage floor over the retire, pool, deploy-command and sweep files, the retire → pool → command seams against real Postgres, and a guard that no pool path can pick a retiring or old-release machine
- (motir-ai) CI's deploy job runs the new command and the start-every-machine step goes; `fly.toml` and the runbook mark a direct `fly deploy` unsafe; the first rollout, against machines that have no retire signal, is handled and written down
- (motir-ai) A retired machine is destroyed once it exits, and one still busy at the 6-hour ceiling is force-destroyed with one log line naming it and its job — swept on every deploy and on a schedule, outside the CI deploy job
- (motir-ai) One deploy command for the planning workers — build and push the image, run the release command, start new-release machines and wait for health, then retire the running old machines and destroy the suspended and stopped ones without starting them