Why Phase-Locked Workflow Breaks When the Agent Learns Mid-task

Traditional development workflow forces you through phases. Planning, then implementation, then done. Once you are in implementation, going back to update the plan is awkward. Sometimes impossible. You implement around the wrong plan because fixing the plan costs more than the implementation.

This is not how real work happens. You implement, you learn, you realize the plan was wrong, you update the plan, you implement again. The workflow should match the work. The work should not contort to match the workflow.

The problem with phases

Phase-locked workflows have three problems.

You cannot go back. Once you are in implementation, updating your design is awkward. Sometimes impossible. The tool blocks the move. You either restart the whole change or you implement against a design you no longer believe in.

They are all-or-nothing. One big command creates everything at once. You cannot test individual pieces. You cannot decide halfway through that the proposal was right but the design was wrong.

They are one-size-fits-all. The same workflow for everyone. No customization. Your team's quirks get forced into the tool's structure or dropped.

Actions instead of phases

The fix is to replace phases with actions. Actions are things you can take anytime, in any order.

You do not "enter the planning phase". You run a propose action. You do not "exit planning". You run an apply action whenever you are ready. You can go back to propose whenever you want, without restart.

The commands become things you do, not stages you are stuck in.

Two modes for two styles

Core profile, the default. Four commands cover most work.

/opsx:propose. Creates a change with all planning artifacts. Proposal, specs, design, tasks. One command, one batch.

/opsx:explore. Helps you think through ideas. The agent analyzes your codebase, identifies bottlenecks, presents options. Useful when you do not yet know what to build.

/opsx:apply. Implements tasks. The agent works through the checklist.

/opsx:archive. Finalizes the change. Deltas merge into source of truth.

Expanded workflow, optional. More granular control.

/opsx:new. Scaffold a change without artifacts yet.

/opsx:continue. Create one artifact at a time, in whatever order makes sense.

/opsx:ff. Fast-forward all planning artifacts.

/opsx:verify. Validate implementation against spec.

/opsx:bulk-archive. Archive multiple changes at once.

Most teams stay in core. Expanded is for teams that need to inject their own checkpoints.

Common patterns

Three patterns cover most real work.

Quick feature. You know exactly what you want. /opsx:propose then /opsx:apply then /opsx:archive. Three commands. Done.

Exploratory. Requirements are unclear. Start with /opsx:explore. Investigate the problem space. Once you have decided what to build, transition with /opsx:propose. The exploration is preserved in the change folder for future readers.

Parallel changes. You are mid-implementation on add-dark-mode when an urgent bug arrives. Create a new change for the bug. Implement it. Archive it. Resume add-dark-mode where you left off. /opsx:apply add-dark-mode picks up at the exact task you stopped at.

This is what phase-locked workflows cannot do. You cannot pause one phase to handle another. You have to finish or abort. The action-based workflow lets you context-switch without losing state.

Verifying before archiving

The /opsx:verify action validates your implementation across three dimensions.

Completeness. All tasks done. All requirements implemented.

Correctness. Implementation matches spec intent.

Coherence. Design decisions reflected in code.

The verify action surfaces warnings but does not block archiving. The team decides whether the warnings matter. The tool does not force compliance.

This matters because some warnings are noise. A spec requirement that the team decided to defer is a warning, not a blocker. The team needs to be able to archive with the warning acknowledged.

When to update versus start fresh

A common question. Should you update an existing change, or start a new one.

Update when the intent is the same and the execution is refining. Scope narrows. Learning-driven corrections. The codebase is not what you expected, so the design adapts.

Start new when the intent fundamentally changed. Scope exploded into different work. The original change can be marked done standalone.

Think of it like git branches. Keep committing while you work on the same feature. Start a new branch when it is genuinely new work.

The mistake is updating endlessly. A change that has been "in progress" for three months is not a change anymore. It is a project. Archive what you have, start fresh for what remains.

The honest limitation

Action-based workflow does not fix a team that does not know what it wants. It removes the friction of phase gates. It does not remove the need to think.

If your team's problem is that you cannot decide requirements, the workflow cannot help. If your team's problem is that the workflow blocks you from going back when you learn something, the action-based approach fixes that directly.

Most teams adopting this workflow see the win on day two or three, when they realize they can update a design mid-implementation without restarting. That is the moment the workflow stops feeling like a constraint.

What changes for your team

You stop arguing about whether you are "in planning" or "in implementation". You run the action that does what you need. The state lives in the artifact files, not in a phase variable.

You stop losing work when priorities shift. Parallel changes coexist. Each one resumes where it stopped.

You stop pretending the plan was right. When you learn it was wrong, you update it. The history of what you learned is preserved in the change folder.

The workflow fades into the background. The work moves forward.