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
- 5
- prośby
- 4
- głosy
- 370
- zaplanowane
- 4141
- wydane
- (motir-core) A decision WAITING and a decision DECIDED in the lists — `ApprovalRow`'s `decision_confirmation` branch on To approve and in the Approvals room, confirmed or overturned on a decided row (en + zh)Approval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) THE CONFIRM PORT in the frame — the item page and the overlay, Confirm · Overturn, the record link, the confirmed / overturned / no-record bands, defect and read-only states, and the user doc (en + zh)Approval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) The DISPATCHED prompt hands a run its epic's CONFIRMED decisions, oldest first with their dates, and the CALENDAR rule: code newer than a decision that contradicts it is REPORTED, never repairedApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) The AI boundary carries a decision's CONFIRMATION — `get-item` and `get-subtree` return a decision work item's gate state and its confirmed-at / overturned-at stamp, so the planner can date and order themApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-ai) THE SAME RULE in `SHARED_PLANNING_RULES` — the decision-work-item segment, `type-decision`'s record bar and the rung-3 CALENDAR limb, in `motir-meta`'s wordsApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) OVERTURN — the refusal arm built, not described: the decide door's `overturn` verb with its required note, the stamped `overturned` record, its terminal effect, and the re-plan it records as OWEDApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-meta) THE RULE in the runbook packs — a re-plan that moves approved work by WORKFLOW, MORE or LESS lays ONE decision work item at the epic; decisions ACCUMULATE; the rung-3 CALENDAR limb; `type-decision.md`'s record bar; MANIFEST regeneratedApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) REGISTER `decision_confirmation` — the kind and its migration, `parseDecisionRecord` and its defect reasons, the handler, the gate RAISED on a complete `human` decision work item, and Confirm writing `done`Approval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-core) AMEND `approval-gates.md` — the DECISION work item's CONFIRM gate: `decision_confirmation` keyed on a `human` decision, its subject the parsed body, its verbs Confirm · Overturn, the record optional, and decisions that ACCUMULATEApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- The DECISION card — a re-plan that changes already-approved work items records WHY, at the epic, and the gate CONFIRMS it rather than recording itApproval gates — every decision that holds work up happens IN Motir, behind ONE approve language new kinds join
- (motir-meta) `core.md` gate 5's DOOR-is-not-the-room inverse is recorded `one-home:meta`, but the twin's `THE_DESIGN_GATE` (`kind-runnable-lay`) carries it verbatim — the REFINE probes were lower-case against upper-case textSelf-improvement — auto-reported quality bugs
- (motir-meta) run.md stops describing the pull-request Vitest lane as a diff-reached subset — sweep its `ci-affected-tests.md` / `vitest-full` referrers after the revertSelf-improvement — auto-reported quality bugs
- (motir-meta) `MIRROR.map.py --order` is red on `main` at 21 out-of-order pairs against ORDER_PIN 15, and no CI job runs it
- (motir-core) The story's E2E — a fake Sentry issue's evidence shows on the filed bug's Errors row, over `get_work_item` and in its dispatch prompt; a pre-story link is backfilled and enriched once; a refused read leaves the evidence standing — recorded as the acceptance videoProduction 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 story's VITEST gate — the coverage floor over the evidence surface, the read → store → page / MCP / prompt seam and the sweep → enrichment seam on real Postgres, and the guards coverage cannot see (no provider call on a read path; no user-identifying tag anywhere downstream)Production 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 standing BACKFILL sweep in the poll — read evidence for live linked issues never read, and dispatch `author_bug` for monitor-filed bugs never dispatched, within the per-poll context-read budget, idempotent on the link and converging to nothingProduction 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 dispatch prompt carries an ERROR EVIDENCE section for a card with monitor links — `DispatchPromptSource` gains the links' stored evidence, read with no provider call, and a card with no link renders exactly as beforeProduction 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) `get_work_item` returns the card's ERRORS — every monitor link with its stored facts and evidence on the structured payload, through the same read the page renders, with no provider call; the tool's description and `docs/mcp.md` say soProduction 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 Errors section shows the EVIDENCE — each row's evidence block with the exception, the frames, the tags, the request line and the event time, its never-read / no-exception / stale states, and its strings in both localesProduction 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 link KEEPS the evidence — evidence columns on `monitor_issue` and their migration, written by every successful latest-event read (the reconcile visit and the hand-made link) and left standing by a failed one, and the card's error read and its DTO carry itProduction errors become planned work — a monitor connects, its issues arrive as bugs in a container the project chooses, and fixing one closes it back