Skip to Content
ReferenceFramework SDLC

Framework SDLC

How Gemba Flow itself is developed, tested, and released. Written from the perspective of a contributor to the framework — not a user building on it.

Framework vs. downstream

Gemba Flow is a framework product. Its consumers are downstream variants — cloud-specific forks, workshop forks, and user repositories provisioned from those variants. The framework owns: agent definitions, slash commands, validation scripts, CI workflow structure, doc templates, and starter projects.

A PR against Gemba Flow is not a product change — it is a framework change. Every such change propagates to all downstream variants. That carries obligations no other PR type does.

Sync paths

PathWhen usedMechanism
pull-upstream.shRoutine updates — new agents, improved scriptsFile-level diff against syncDirectories; skips .gembaflow-overrides
upgrade.shMajor version changes or restructuringThree-way merge with conflict resolution modes

Version significance

Change typeBumpChangelog
Bug fix, doc correctionPatchYes
New agent, command, script, workflowMinorYes
Renamed/removed agent, restructured dirs, changed bootstrapMajorYes + migration guide

Protecting downstream customizations

Downstream forks maintain .gembaflow-overrides — one path per line. Both sync paths skip files listed there. The override mechanism works by exact file path, which is why renaming any file in syncDirectories is a breaking change requiring a major version bump and a migration guide.

Historical: agile-flow → Gemba Flow rebrand

The framework was renamed from agile-flow to gembaflow in 2026-Q2 across six phases. Downstream forks running /upgrade against framework version 1.1.0 or later get the rename transparently via redirect-aware sync.

The rebrand phases for reference (no action required):

  1. Phase 0.5 (v1.1.0) — /upgrade (template-sync.sh) made redirect-safe; canonical PAT scope set documented
  2. Phase 1 — GitHub repo rename (operational, not a PR)
  3. Phases 2a–2c — URL rewrites in scripts, env var dual-read shim, package metadata rename
  4. Phase 3 — variant fork .agile-flow-version files updated to point at their own forks
  5. Phase 4 (v1.2.0) — dotfile renames (.agile-flow-*.gembaflow-*); sync branch prefix rename
  6. Phase 5 — GCP resource naming forward-only update

Where this shows up

  • /upgrade runs pull-upstream.sh (the routine sync path) and respects .gembaflow-overrides.
  • /report-issue files defects against the framework from a downstream fork, closing the contributor feedback loop.
  • /doctor flags stale framework versions and recommends /upgrade when the gap matters.
Last updated on

Book a Demo