The Iteration Cycle

Every piece of work in Michi follows the same cycle:

Explore → Brainstorm → Plan → Execute → Verify → Document

This applies at every scale. A single milestone goes through the cycle. So does an entire epic. So did the process of building this toolkit. The cycle is fractal — zoom in on any phase and you’ll find smaller cycles within it.

Spirals, not circles

The critical property is that iterations progress spirally. Each cycle produces both a deliverable (working software, a research finding, a design decision) and richer context for the next cycle (patterns discovered, assumptions validated, scenarios refined).

Circles are waste. Progress means the process is better, the understanding deeper, or the system more capable. Ideally all three.

A real example

While building a CLI tool for Playwright trace capture, the first epic (audio narration) went through the full cycle. Unit tests passed across all four milestones. Then human testing revealed five bugs — orphaned processes, oversized files, SDK version mismatches — that the test suite couldn’t catch.

The second epic (terminal recording) was planned after that debrief. The agent wrote in its plan: “From narration: unit tests with mocks caught zero of five bugs. For terminal recording, we can do real integration tests.” The terminal epic had real PTY integration tests from the start, caught a permissions bug during the spike, and had zero post-verification bugs.

Same developer, same project, same agent. The second epic was measurably better because the first one’s learnings informed it. That’s the spiral at work.

The iteration cycle is governed by the four North Stars — What Over How, Minimize Latency, Sustain the System, and S-M-L-XL. They exist in tension; navigating that tension well is the craft. See Principles for the full picture.