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
- 0
- głosy
- 370
- zaplanowane
- 4067
- wydane
- (motir-marketing) `/docs/skills` gains the `motir-continue` usage section, the install commands move to the new release tag, and the page E2E covers the section
- CI's orchestrator job never measures coverage: `test -- --coverage` turns `--coverage` into a file filter under pnpm 11
- (deploy) Release `motir-skills` with `motir-continue` and the CI-aware `motir-fix` — bump `plugin.json` to the next minor, tag it, publish the GitHub release, then install it from the tag as a consumer would
- A hard-killed `motir run` never sends its `checkout_ready` — the server never learns the branch, so `motir continue` refuses the dead run `no_branch`
- (motir-gateway) When models.dev disagrees with a provider-direct price, the catalog refresh PROPOSES the new price — it rewrites that entry in `provider_direct_prices.json`, dates it to the fetch, flags it UNCONFIRMED with the provider's own pricing URL, and amends ADR §8.4/§8.5
- (motir-skills) The two-mode `motir-continue` skill — runbook mode routes to `prompts/continue.md`; standalone mode condenses the claim and its refusals, the checkout on the dead run's own branches, the CONTINUE prompt, liveness, delivery with the CI-aware acceptance step, the close and the report
- (motir-meta) The CONTINUE protocol — `prompts/continue.md`: claim a dead run's card, check out its branch in every repository, read the CONTINUE prompt, keep the continue alive, deliver by `run.md`, let CI publish the acceptance receipt where the lane carries the uploader, close, report; and `_shared.md`'s door list names it
- Continue a dead run from your own agent — confirm the continue tools live, then the continue protocol in the runbook (`prompts/continue.md`) and the two-mode `motir-continue` skill on `motir-skills` `main`, CI-aware from the start
- (motir-ai · test) E2E — two planning processes and a stand-in Fly API: a fifth job waits on a full machine, a peer is woken, a "suspended" machine is resumed, an idle one suspends, and the exhausted alert fires onceA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai · test) Integration gate — the pool story's coverage floor, slot claims and the scale-out debounce against the real database, and the seams between slots, idle tracking, peer wake and resumeA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai) `fly.toml` provisions the pool by suspend — `min_machines_running = 0`, Fly auto-stop off, the private wake port, rewritten scaling comments — and the deploy step starts every machine afterwardsA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai) With every running machine 4/4 busy, a queued job resumes exactly one suspended machine — debounced 10 s across the pool, checked at submit, at finish and every 5 s while busy — and with none left raises "planning pool exhausted"A dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai) A full machine hands a queued job to an idle running peer — a private wake listener on port 8081, called at submit and at job finish when another running machine has a free slotA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai) The planning pool's view of itself — running peers from `vms.motir-ai.internal`, each machine's busy slots from `PlanJob`, and a Machines API client that lists and resumes suspended machinesA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai) A planning machine idle for 5 minutes suspends itself — job slots and in-flight HTTP tracked, re-checked at the moment of suspend, through the local `/.fly/api` socketA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai) The first database query after a resume reconnects — stale pooled sockets dropped before suspend, and one retry on a connection error at the worker's and submit's first queryA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai) The worker runs up to 4 jobs at once — claim slots instead of the `ticking` single-flight guard, per-job lease renewal, and a drain that waits for every slotA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai · research) MEASURE suspend → resume on a real 2 GB motir-ai machine — first response ≤ 1 s and a clean database reconnect, the pool's rollout conditionA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- Planning machines run four sessions each, suspend when idle, and resume in about a second when someone starts planningA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-gateway) The refresh report, pricecheck and the catalog generator still tell a person to edit a sourced price in `model.go` and its ReadDate in `price_provenance.go`, which no longer hold them