DFlow Multi-Agent Orchestration

Core model

One governor, one orchestrator, two specialist coding agents.

DFlow remains the source of governance. Sparx turns it into an active multi-agent operating system, routing work between Claude and Codex while Jude keeps approval authority.

DFlow

Governance, artefacts, phase gates, freezes, change control, version lifecycle, and quality rules.

Sparx

Orchestrator, project manager, agent router, review-loop controller, verification owner, and escalation point.

Jude

Product owner and governor: approves setup, freezes, increments, version close, and behaviour acceptance.

Work type

Sparx

Claude

Codex

Jude

Definition docs

orchestrates

draft/revise

review/feasibility

approve

UI contracts

gates

draft

implementation review

approve

Story implementation

packet + checks

implement/review

accept demo

Security remediation

enforces loop

review/fix

escalation

Release/versioning

summary + recommendation

notes

repo checks

approve

Start from reality

Project Entry Assessment comes before the lifecycle.

Every project declares its actual state, working folder, Gitflow status, current semantic version, and backlog location before we decide where to enter DFlow.

Required intake additions: working folder, docs folder, implementation root, primary command root, current branch, Gitflow status, current semantic version, target version, backlog location, deployment status, and test status.

Operating lifecycle

The approved DFlow multi-agent lifecycle.

Click each stage. Gold dots mark formal Jude approval gates. Review stages are iterative loops, never single-pass checks.

Lifecycle illustration

Quality gates

Review and security are loops, not events.

A stage only passes when the reviewer returns PASS and Sparx has confirmed all issues are remediated. This applies to Definition docs, UI contracts, story planning, implementation review, and security review.

Cross-review loop

Draft/buildAgent A produces output.

ReviewAgent B finds gaps.

FixAgent A remediates.

Re-reviewAgent B checks again.

PASSNo issues remain.

Security remediation loop

Security reviewRisk-focused diff check.

RemediateImplementer fixes issues.

Re-reviewSecurity reviewer verifies.

RepeatUntil all findings close.

PASSStory can be verified.

No Definition docs move to scope freeze with unresolved consistency or coverage issues.
No UI story starts until the relevant UI contract is frozen.
No story starts until acceptance criteria, allowed paths, and verification are declared.
No story moves to security review until cross-review passes.
No story is done until security review passes and all findings are remediated.
No story is accepted until visible behaviour has been verified in the running product/API/CLI.

Version control

Gitflow is the default branch model.

Every project declares its working folder and Gitflow branch state at intake. DFlow gates then map directly onto branch transitions, release branches, and tags.

Branch pattern

main

develop

feature/*

release/*

hotfix/*

Default flow

Story:
develop → feature/SXX-short-name
→ implement + review + security + verify
→ merge back to develop

Release:
develop → release/vX.Y.Z
→ QA + docs + changelog + version bump
→ merge to main → tag vX.Y.Z
→ merge back to develop

Hotfix:
main → hotfix/vX.Y.Z-description
→ patch + review + verify
→ main tag → develop

Semantic versions

Every increment and release makes an explicit version decision.

Code releases use semantic versioning. Increment close recommends whether the current work changes version; release close tags the approved version.

MAJOR

X.0.0

Breaking changes, major product re-cut, incompatible API/data/workflow changes.

MINOR

1.X.0

Backwards-compatible features or coherent new capabilities.

PATCH

1.0.X

Bug fixes, corrections, safe hardening, or small non-feature improvements.

Increment close must include

Current version:
Proposed next version:
Reason for version bump:
Release notes draft:
Gitflow branch/tag impact:
Approved by Jude:

Brownfield handling

Existing projects enter through re-baseline or vNext planning.

↻

In-progress project

Audit → Re-baseline → Freeze remaining scope → Continue story execution. We inventory existing behaviour, incomplete work, bugs, docs gaps, tests, branches, and version state before freezing the remaining path to release.

Complete version + backlog

Close version → Triage backlog → Seed vNext → Plan next version. We confirm release/tag status, classify backlog as patch/minor/major/park/reject, then start the next DFlow cycle from the vNext seed.