From Intent to Evidence

Everything Claude Code (ECC) turns an agent-assisted change into a lifecycle with visible states: intent becomes a plan, the plan becomes a failing test, the test becomes a minimal implementation, and the result is reviewed and verified. The specific question is what each transition proves—and what it still does not prove. Following one authentication change through this path shows how ECC makes work more inspectable without pretending that a passing check is the same as safe autonomous execution.

The value of a lifecycle is that it gives a disagreement somewhere to land. A developer can reject a plan before code changes. A failing test can reveal that the proposed behavior is not actually exercised. A reviewer can challenge a concrete line from a fresh context. An evaluation can compare a new workflow with a baseline. Each state preserves a different kind of evidence, and none should be asked to prove more than it can.

The change starts as a commitment

A request such as “fix authentication expiry” is a goal, not yet an implementation contract. ECC's planning workflow turns it into requirements, affected interfaces, architecture changes, dependencies, risks, testing strategy, and success criteria. The planner is intentionally read-only. It can inspect the repository and produce a plan, but the plan is meant to be confirmed or edited before implementation begins.

That separation changes the first decision. Instead of asking an agent to start editing while it is still discovering the problem, the team can ask whether the intended behavior is clear. Does “expiry” refer to an access token, a refresh token, a session record, or a user-visible login state? Which callers depend on the current behavior? What should happen when a token is stale, malformed, or refreshed concurrently? The plan does not answer all of these automatically, but it makes the questions visible before the cost of an incorrect implementation grows.

A plan is also a persistence boundary. Once the conversation contains a long exploration, the original request can be hard to recover from the latest error message. A structured plan preserves the target behavior and the reasons for the proposed sequence. Later agents can use it as input without receiving the entire earlier conversation. That makes context reduction safer, provided the plan is treated as an inspected artifact rather than as unquestionable authority.

The plan's status should remain modest. ECC's documentation defines an intended workflow; it does not prove that every user approves every plan or that every plan is accurate. A read-only planner can still misunderstand a dependency, and a human can approve a plan without noticing a missing edge case. The plan earns its value by making an error easier to find before implementation, not by making error impossible.

flowchart LR A["User intent"] --> B["Reviewed plan"] B --> C["RED: failing test"] C --> D["GREEN: minimal implementation"] D --> E["REFACTOR: keep behavior green"] E --> F["Fresh-context review"] F --> G["Verification and eval"] G --> H["Evidence artifact"] F --> C G --> B H --> I["Proceed or request human decision"]

The diagram has two deliberate return paths. A review finding can send the change back to a test, because a defect should become a regression case rather than a one-off edit.