Day to day

You talk, it routes

You never need a station name. Say what you want, in any language. The conductor answers in yours.

Fix a bug

Size S when it stays in one plugin. The conductor opens the change and reproduces the bug with a failing test when that is practical. It fixes inside the plugin and runs verify, then the closing checklist. There is no plan, because the public API does not change.

Make quick edits

Size Q. Each message is the next edit, made at once. moku-rails tier counts from the files who makes it: a fast agent, or the builder for an edit that creates a file or touches a public surface. Nothing is checked in between. When you say the edits are right, verify runs once.

Add a feature

Size M when an API changes or a new plugin appears. The conductor proposes the design station, because there is UI. You can say no, and it records your words. Then a delta spec, and you approve it after you saw it. Then build, verify, e2e and release.

Change your mind in the middle

This is scope, not a continuation. The conductor runs moku-rails scope, the change goes back in front of plan, and the new part gets a delta spec. A running builder keeps working. A message of yours does not stop it.

Keep an idea for later

It goes to the backlog with moku-rails idea, and the current work carries on. /moku:status lists it.

Come back after a break

Debts come first. A change left inside a station is named, and you choose.

Last time we left the streak fix unfinished. Finish it first, or set it aside?

Setting it aside takes a reason: moku-rails park <id> --reason "...".

Work on two things at once

Use two git worktrees, one session in each. Nothing in one worktree stops the other: not a station left open, not a wave marked active, not a new message. moku-rails status lists the other checkouts' work under Elsewhere. Decisions, specs and the ledger are shared.

git worktree add ../my-app-search -b feat/search
cd ../my-app-search && bun install

When a worktree is removed, its change stays. moku-rails adopt <id> moves it to the checkout where the work goes on.

Tests

The same rules hold in every station, for the builders and for the conductor:

• Name the bug a test catches before you write it. No bug to name, no test.
• Not a test: a constant compared with its own value, what tsc already proves, a test of plain data.
• Green tests are checked by breaking the code, once per logic file. If no test fails, the hole gets closed.
• Deleting a test takes your word, after the conductor lists it with the reason. So does changing a coverage threshold.

When moku-rails close reports slow tests, the conductor names them and offers a change of its own to speed them up. It never changes a test for speed without your yes.

Clean up

moku:clean archives closed changes, distills a cycle into history.md, and removes the ephemeral files. It keeps the durable knowledge, and it asks first. When the same agent mistake repeats, it proposes a gate.

Move the stack forward

moku:upgrade detects what applies (TypeScript, tooling versions, tsconfig defaults, the engines floor, the framework versions), shows one plan, applies it and verifies.