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
- 513
- planned
- 5,093
- shipped
- (motir-core) *Retry merge* after a HOST REFUSAL decides the re-asked gate — the §8 retry-on-the-standing-approval door is closed, the no-reuse predicate reads a recorded refusal, and a CAN'T-LAND refusal offers no retryApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) PERSIST the host's merge REFUSAL on the pull request — a migration-backed record of the refusal code, the head it refused and when, and the card leaves `approved` by the refusal's reason class through the re-ask entry pointApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) CONVERGE the cards left stranded before this ships — an idempotent dry-run/apply script and its `workflow_dispatch` that, through `settleUnlandedOutcome`, moves RETRYABLE/SETTING cards at Implemented to In Review with ONE gate, re-asks Approved cards holding a standing neutral exit or an unrecorded host refusal, and COUNTS (leaves) CAN'T-LAND cardsApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core · test) Playwright acceptance E2E + VIDEO — a queue FAILURE re-asks at In Review and the PR row's *Queue again* is the approve (page and overlay, `motir fix` beside it); a CONFLICT drops to Implemented with only `motir fix`; a host `branch_protected` refusal names the setting and *Retry merge* approves (en + zh)Approval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core · test) Story VITEST gate — one sequence per class on real Postgres: RETRYABLE (failure and neutral) and SETTING re-ask at In Review with ONE gate and the row verb decides it; CAN'T LAND goes to Implemented held until a push; a host refusal is recorded and classed; no door reuses a spent approval; the pre-deploy convergence; auto unchangedApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) The frame and the OVERLAY render every un-landed class — RETRYABLE / SETTING at In Review with *Queue again* / *Retry merge* on the PR row AS the approve, CAN'T-LAND at Implemented with `motir fix` only, the named setting, the refusal after a reload, `motir fix` passed into the overlay, and the rail (en + zh)Approval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) EVERY QUEUE EXIT is handled BY REASON CLASS — one total class map in `lib/mergeQueue/queueExit.ts`; a manual RETRYABLE (failure or neutral) or SETTING exit moves the card `approved → in_review` and `resolveGateSet` raises ONE fresh gate (design gate untouched); a CAN'T-LAND exit moves it `approved → implemented` with the promotion HELD at that head; one exported entry point serves every sourceApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) The workflow EDGES — `implemented → approved` REMOVED and `approved → in_review` DECLARED in `DEFAULT_TRANSITIONS` and the seed, with a key-joined migration that deletes and inserts on default workflows and leaves custom ones aloneApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) `motir fix` CLAIMS an un-landed card BY CLASS — a CAN'T-LAND card at Implemented (already admitted) and a queue `CI_FAILURE`/`CI_TIMEOUT` card at In Review; a SETTING-blocked or NEUTRAL card is refused with a reason that names what to do instead; the CLI help and catalog say soApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) NO DOOR REUSES A SPENT APPROVAL after a QUEUE EXIT — *Queue again* and *Retry merge* on the pull-request row DECIDE the re-asked gate (a new approval) and perform ONE enqueue/merge; without an awaiting gate they refuse `MERGE_REQUEUE_NEEDS_APPROVAL` for EVERY exit disposition, neutral included; auto mode keeps `requeueAutoMember`Approval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) FOURTH AMENDMENT to `approval-gates.md` — ONE APPROVAL = ONE MERGE/ENQUEUE ACTION: every un-landed outcome (any queue exit, any host refusal) is classed by reason — RETRYABLE and BLOCKED-BY-A-SETTING re-ask at In Review with ONE fresh gate, CAN'T-LAND goes to Implemented held — *Retry merge* / *Queue again* decide a new approval, and `implemented → approved` leaves the workflowApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- ONE APPROVAL = ONE MERGE/ENQUEUE ACTION — a merge that does not land (a queue ejection of any kind, or a host refusal at the press) is classed by REASON: retryable and setting-blocked re-ask at In Review with ONE fresh gate and *Retry merge* / *Queue again* on the PR row as the approve, a conflict drops to Implemented with only `motir fix`, on the page and in the overlay; `implemented → approved` leaves the workflowApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core, production) TRIAGE the 1,381 unreplayed dead letters — a verdict per function, then dispose of the residue under a stated ruleProduction errors become planned work — a monitor connects, its issues arrive as bugs in a container the project chooses, and fixing one closes it back
- (motir-core) The SIX low-level installation-token mints that resolve no role — three in the GitHub provider, three in `checkRuns.ts`, where the `Motir / work item link` check has never been written on a hosted repositoryApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) The acceptance-video switch's copy COMPLETES its sentence — "its status cannot be moved by hand" ships once the acceptance gate is on the contract AND the manual flip is refused (en + zh)Approval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) DECIDE whether a dead letter should FILE a work item — the dead-letter → Sentry → bug path already exists, so the open question is the THRESHOLD and the duplicateProduction errors become planned work — a monitor connects, its issues arrive as bugs in a container the project chooses, and fixing one closes it back
- (motir-core · test) Story E2E + ACCEPTANCE VIDEO — one Approve on a story run decides the acceptance and merges the story's pull request; a single-card run's E2E subtask shows no acceptance question and the story does (en + zh)Approval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core · test) VITEST gate — coverage floor over the acceptance gate's changed surface, the placement matrix (story run vs single-card run), one press → acceptance decided + members merged, and the no-second-door guardApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) THE STORY SAYS WHICH QUESTION — the acceptance frame leads with the receipt and renders the story's pull requests + How to test beneath it as what Approve merges, and stands alone when the story delivers nothing (en + zh)Approval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) THE GATE SET LEARNS ACCEPTANCE — `acceptance_result` joins the predicate as a PRIMARY carrier, and pressing it on a story run also merges the story's pull requests through the existing merge-or-enqueue pathApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join