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
- 493
- planned
- 4,823
- shipped
- 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
- (motir-ai) The pool never hands work to, resumes or peer-wakes a retiring or old-release machine — `pickPeer`, the scale-out resume and the pool snapshot skip them
- (motir-ai) A machine can be told to RETIRE over the private network — it stops claiming, answers `/health` 503, keeps every lease renewing, never suspends itself, and exits once it holds no running job
- (motir-ai) A paid invoice with only a tracker seat line grants the org's full AI pool again
- (motir-ai) A deploy never kills a planning job in flight — the planning workers deploy by starting the new machines, retiring the old ones, and each old machine exits by itself once it holds no running job
- The gateway cannot mint a `translation`-lane token, so every motir-ai translate job fails with internal_error
- The app type-check project sits at 84.4% of the heap budget, the next project to trip the 90% headroom guard
- Approving a conversation-session plan leaves a hand-parked target at Planning — the session's lock is not adopted, so neither approve nor the session release rests it
- The auto-resume acceptance spec reads the plan row once right after the resume submit is recorded, but the bind that re-points sourceJobId commits after the submit, so it can read the old job id under load