Checkpoint: What the Workflow Must Leave Behind

Everything Claude Code (ECC) has so far been examined as a set of connected controls rather than as a catalog. This checkpoint asks whether those controls form one usable model: who owns a behavior, what context it consumed, what evidence it produced, and where its authority stops. The answer gives readers a practical way to inspect an agent workflow before applying the same questions to memory, portability, security, and longer-running operation.

The test is not whether the system has many stages. It is whether the stages preserve the right distinctions while working together. A skill should not be mistaken for a permission boundary. A small context should not be praised if it omitted the fact needed for a safe decision. A green test should not be treated as a security approval. A receipt should not become a promotion authority merely because its hash is intact.

One control model, not a pile of conveniences

ECC's component layers fit together around a change, such as the authentication-expiry repair. A command gives the developer an entry point into planning. A planner agent investigates and turns the request into a reviewable commitment. A TDD skill supplies the RED/GREEN/REFACTOR method, while a rule can hold a standing security constraint. An implementation worker uses a bounded evidence set. Hooks can check or record events around edits. A reviewer inspects the resulting diff from a separate context. Tests and evals provide evidence after the action.

The point is not that every change must invoke every possible component. The point is ownership. The command owns how a person starts a workflow; it should not become a second, drifting copy of the workflow's knowledge. The agent owns a scoped piece of reasoning; it should not silently own project-wide policy. The rule owns a standard that must be present across relevant work; it should not become a dumping ground for every optional technique. The hook owns a timing boundary; it should not be expected to reason about a tool result it cannot see.

That allocation also explains how an ECC workflow crosses a harness boundary. Shared skills, rules, hook logic, session contracts, and memory formats carry durable behavior. An adapter handles the host's loading rules, event names, paths, command conventions, and platform limits. If the adapter is thin, a change to the workflow can be made once and tested at the edges. If each platform keeps a separate copy, behavior can drift while the repository still appears to offer the same feature everywhere.

The distinction is more than maintainability. It determines what a user can rely on. A native host may run a hook before a tool and block it. An instruction-backed host may only show the agent the same guidance. Both can share a skill document, but they do not expose the same enforcement.