● muda
↑ subaud · one binary · MIT

The loop

Measure, diagnose, fix, verify.

Each phase is a skill your agent loads. Each one stops at a checkpoint and waits for you. Decisions are kept in a reviewed record under .muda/ in your repository, so the work can stop and resume.

measure

Where the delivery time goes.

muda measure reports where the delivery time goes over a window: run counts, p50 and p90 durations, queue time, re-runs, per-job and per-step times and the top time sinks. muda gates lists the merge and deploy gates a fix must keep.

checkpointYou confirm the workflow roles, the stacks, the gate inventory and the window, and that becomes the baseline. Gates muda could not read are listed as unavailable, not dropped.
in .muda/muda.toml with the confirmed settings, baseline.json, gates.toml and scan.json.

diagnose

The waste behind each time sink.

The agent works through the time sinks and the signals from muda scan and muda notices. For each one it reads every matching recipe and runs its Detect steps against the real logs. Each finding names its waste class, its evidence and an estimate.

checkpointYou agree which candidates become findings, their order, and any exemptions, each with a reason. A suspected finding is approved only as an experiment with stated pass criteria.
in .muda/The findings in findings.toml, and any exemptions in exemptions.toml.

fix

One finding, one pull request.

The agent first shows the plan for the change: the files it will edit, the expected effect, the risk and the gates it touches. Once the plan is approved, the agent makes a branch and opens a pull request. It merges after verify, once you say yes.

checkpointYou approve the plan for this one finding. Two findings are two approvals and two pull requests.
in .muda/The finding's status and its pull request in findings.toml, in a separate record commit.

verify

Proved on the real pipeline.

muda compare checks the change on the PR's real pipeline, and again after merge. It reports before and after timings with the runs it used, and a gate result.

checkpointYou confirm the timings, the jobs that ran and the gate result. Then you decide: the finding is fixed, it is reopened, or it stays in its pull request with a receipt that says why.
in .muda/A receipt under receipts/, and the finding's new status in findings.toml.

Every write goes through muda record. Record changes arrive on a branch as a pull request, merged by you or by the agent once you say so. Never edit .muda/ by hand. The gate results are on the proof page.