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

Traditional workflow locks you into phases: once you are implementing, going back to update the plan is awkward or impossible. So you implement around the wrong plan, because fixing the plan costs more than the implementation. The workflow should match how work actually goes: implement, learn, update the plan, implement again.

The problem with phases

Phase-locked tools have three failures. You cannot go back, so you either restart the whole change or implement against a design you no longer believe in. They are all-or-nothing: one big command creates everything, and you cannot decide halfway through that the proposal was right but the design was wrong. And they are one-size-fits-all: your team's process bends to the tool or gets dropped.

Actions instead of phases

The fix replaces phases with actions you can take anytime, in any order. You do not enter planning; you run a propose action. You can return to propose mid-implementation without a restart. Core profile covers most work: propose creates a change with all planning artifacts, explore helps you think before deciding what to build, apply works the task checklist, archive merges deltas into the source of truth. The expanded profile adds granular steps like scaffolding a change or creating one artifact at a time.

Patterns that phases cannot do

Quick feature: propose, apply, archive, done. Exploratory: start with explore, transition to propose, and the exploration is preserved in the change folder. Parallel changes: mid-implementation on add-dark-mode an urgent bug arrives; create a new change for it, archive it, and resume add-dark-mode at the exact task where you stopped. Phase-locked workflow forces finish-or-abort here; actions let you switch context without losing state.

Verify, then decide

Before archiving, verify checks completeness (all tasks and requirements done), correctness (implementation matches spec intent), and coherence (design reflected in code). It surfaces warnings without blocking; the team decides whether a warning matters, because a deliberately deferred requirement is a note, not a blocker.

The trade-off

Action-based workflow does not fix a team that does not know what it wants; it removes the friction of phase gates, not the need to think. And it does not license endless updating: a change in progress for three months is a project, not a change. Archive what you have and start fresh. Think of it like git branches: keep committing the same feature, branch when it is genuinely new work.

The smallest test

Next time mid-implementation reveals the design is wrong, update the design artifact and keep going. If your current tool fights you, that is the phase lock.