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
- 贊同
- 534
- 已規劃
- 4,982
- 已發布
- The page MCP tools cannot change a page's title — create_page sets one, update_page and the rest cannot rename it
- After the run story MERGES — release the `motir` CLI that can run a card inside an agent: merge the Version Packages pull request, see `cli-v*` publish the sandbox images, pull the Claude Code and Codex images by digest and see `motir agent-terminal run` in each, and see a production agent created after it pin that digestYour own agent instances — host Claude Code, Codex or any sandbox agent in Motir's cloud on your own credential, see them on one page, work with one beside it, and let idle ones hibernate
- Planning bug (plan.py): a session copies the 25-character plan id into its tool calls by hand and can mistype it, so every plan write is refused PLAN_NOT_FOUND, the card stays title-only and the retry repeats the same id
- (motir-marketing) Make the request-rendered allowlist a CI guard and the sitemap's site half static, with the project half emitted per host
- (motir-marketing) Build the four generated reference pages and robots.txt at deploy — force-static, artifacts fetched once per build, a failed fetch fails the build
- (motir-marketing) motir.co times out: the four generated reference pages, robots and sitemap still render in the serving process — build them at deploy, per the MOTIR-8838 decision
- After the terminal story MERGES — release the `motir` CLI that carries the terminal server: merge the Version Packages pull request, see `cli-v*` publish the sandbox images, pull the Claude Code and Codex images by digest, and open a production agent's terminalYour own agent instances — host Claude Code, Codex or any sandbox agent in Motir's cloud on your own credential, see them on one page, work with one beside it, and let idle ones hibernate
- After the boot read-out story DEPLOYS — on production, create a real agent and watch its boot read out live to running with a terminal prompt, then hibernate and wake it and watch the clone rows read skippedYour own agent instances — host Claude Code, Codex or any sandbox agent in Motir's cloud on your own credential, see them on one page, work with one beside it, and let idle ones hibernate
- Planning bug (hosted planner): answer_recommendation counts a requirement's recommendations by LINE, so five recommendations numbered inline "(1)…(5)" on one line count as one. Every verdict on 2–5 is refused and never reaches the briefing
- Two planning pools split by job kind: the conversation pool claims ask_project, sharpen_turn, guide_work_item, author_bug and the other kinds the decision's table places there, the planning pool claims plan, plan_sprint and the rest, so a chat turn never queues behind a planning runPlanning capacity follows demand — a conversation turn never waits behind a planning run, the planning machines and the graph service grow and shrink on their own, and a load-tested cost ceiling is the only fixed limit
- (motir-ai) Story e2e: two workers, one per pool, on one database — planning slots filled with long plan jobs, an ask_project is claimed by the conversation worker within one claim tickPlanning capacity follows demand — a conversation turn never waits behind a planning run, the planning machines and the graph service grow and shrink on their own, and a load-tested cost ceiling is the only fixed limit
- (motir-ai) Story coverage and integration gate for the pool split — coverage floor on the changed pool, claim and deploy code, the claim→count→snapshot seams against a real database, the kind-table totality guardPlanning capacity follows demand — a conversation turn never waits behind a planning run, the planning machines and the graph service grow and shrink on their own, and a load-tested cost ceiling is the only fixed limit
- (motir-ai) Each pool sees only itself — poolSnapshot counts and lists only its own pool's jobs and machines, the full-pool resume and the peer wake pick same-pool machines, the exhausted alert names its poolPlanning capacity follows demand — a conversation turn never waits behind a planning run, the planning machines and the graph service grow and shrink on their own, and a load-tested cost ceiling is the only fixed limit
- (motir-ai) pnpm deploy:planning builds both pools — each pool's count from its own template, retire and destroy per pool, refuse to leave a pool at zero, fly config states each pool's countPlanning capacity follows demand — a conversation turn never waits behind a planning run, the planning machines and the graph service grow and shrink on their own, and a load-tested cost ceiling is the only fixed limit
- (motir-ai) A worker reads its pool at boot and claims only that pool's kinds — CLAIMABLE_QUEUED_PREDICATE gains the kind filter, countClaimableQueued agrees per pool, no pool set claims every kindPlanning capacity follows demand — a conversation turn never waits behind a planning run, the planning machines and the graph service grow and shrink on their own, and a load-tested cost ceiling is the only fixed limit
- (motir-ai) docs/decisions/code-graph-service.md gains AMENDMENT 2 — the two pools, naming the decision page and amending items 5's Count, 7 and 8Planning capacity follows demand — a conversation turn never waits behind a planning run, the planning machines and the graph service grow and shrink on their own, and a load-tested cost ceiling is the only fixed limit
- (motir-ai) One kind → pool lookup, total over every registered job kind, an unlisted kind resolving to the planning pool, and no concurrency key shared across poolsPlanning capacity follows demand — a conversation turn never waits behind a planning run, the planning machines and the graph service grow and shrink on their own, and a load-tested cost ceiling is the only fixed limit
- The sharpen_turn ask step returns no usable turn on the planner model, so Grill me never asks a question — cause not yet read
- Planning bug (both planners): a branching leaf can be added or authored with no target repository. Neither planner's completeness check requires one, so the card reaches approval with nowhere to dispatch
- Planning bug (hosted planner): an author session whose walk_position frame fails to append is silently dropped. The card gets no session, no failure is recorded, and the plan ships it as a bare title (MOTIR-7738's plan lost 7 of 16 cards)