Changes and workflow

Conflux becomes much easier to reason about when you treat each change as a small, auditable unit.

The change directory is the contract

In practice, each OpenSpec change gives Conflux a durable contract:

• proposal.md: why the change exists
• tasks.md: concrete implementation work
• specs/.../spec.md: expected behavior or deltas

The orchestrator is strongest when these files are specific enough that an acceptance agent can judge the result without guessing the intent.

Daily loop

A typical operator loop looks like this:

1. Create or refine a proposal.
2. Commit the proposal so the repository is clean.
3. Run cflx or cflx run.
4. Inspect the resulting diff, logs, and acceptance verdict.
5. Archive, resolve, or split the change depending on the outcome.

Why worktrees matter

Conflux uses git worktree to isolate changes. That has two practical benefits:

• Independent changes can move in parallel.
• A failed or noisy change does not have to corrupt the main workspace.

This is one of the main differences between Conflux and a single chat-driven coding session.

TUI versus headless execution

Use the TUI when you want to make execution decisions interactively.

cflx

Use headless execution when you already know which change should run.

cflx run cflx run --change add-feature-x

Acceptance is not optional polish

Conflux explicitly separates the implementation role from the acceptance role. This is not cosmetic. It changes the behavior of the system:

• the implementation agent can move fast,
• the acceptance agent can stay conservative,
• the final decision is less likely to collapse into self-confirmation.

Teams that skip this distinction often recreate the same blind spots as a single-agent workflow.

When to split a change

Split a change when:

• tasks.md covers too many unrelated areas,
• acceptance keeps failing for independent reasons,
• the review diff is large enough that a human cannot judge it comfortably,
• you want some work to finish and merge earlier than the rest.

Operational checkpoints

These checks keep runs boring in the good way:

After a run

Once a run completes, ask these questions:

1. Did the diff satisfy the proposal and tasks?
2. Did acceptance fail for a real issue or because the scope is underspecified?
3. Is this ready to archive and merge, or does it need a follow-up change?

That final triage step is where Conflux stops being a cool demo and becomes a real workflow.