What it is not

Three misreadings come up often enough to clear out of the way before you spend time evaluating the framework.

• Not an application. The template ships a minimal starter app — you replace it with your product.
• Not a managed agent service. Agents run in your terminal, on your account, against your repo.
• Not magic. Bad tickets still produce bad code. Gemba Flow makes the bad code easier to catch.

What it is also not

Not a replacement for engineering judgment. Gemba Flow structures the workflow around human gates — ticket review, PR review, merge decisions — because the framework cannot substitute for the human knowing what they are building. Structured handoffs help you supervise agents; they do not tell you what to build or whether to ship.

Not a one-size-fits-all template. The framework ships with opinionated defaults (Render + Supabase, specific bot accounts, conventional commit format). Those defaults reflect what the authors found to work well in practice. If your stack or team structure differs, the defaults are a starting point, not a constraint.

Not a set-and-forget system. The board needs grooming. Tickets need to meet the Definition of Ready before agents can act on them. Preview deploys need a human to walk the diff. The supervision loop only works if the supervisor shows up.

The honest limits

For a full accounting of when Gemba Flow is not the right tool — situations where the overhead outweighs the benefit — see Honest Limits. That page is deliberately short and direct: it names the failure modes without softening them.