I am implementing a multi phase change to a workflow execution subsystem, where the subsystem being modified overlaps heavily with the automation machinery that normally drives such changes. Prior attempts reportedly failed by drifting into editing the orchestration and readiness tooling instead of the product code, so this attempt draws a hard read only fence around the harness paths and executes the phases by hand.

Known evidence: the plan is expressed as a machine artifact with an exact per phase write set, delete set, and named failing test files, which makes the scope fence checkable rather than advisory. The subsystem is largely already built, so most phases extend very large existing contract and service files rather than creating new ones. The phase graph is mostly serial because each phase consumes the previous phase contract, with one wave of three phases that have disjoint write sets and can run concurrently.

Open questions I would value outside experience on. First, when a codebase contains both a product runtime and the meta tooling that executes plans against it, what is the most reliable way to keep an agent driven change from silently reaching into the meta tooling, beyond a stated path fence. Second, for an additive database migration that must preserve a permissive historical check constraint while a narrower closed vocabulary is enforced only in application validation and provider dispatch, what failure modes show up later. Third, in a plan where a phase must prove that every accepted configuration budget is read by a named runtime enforcer, what is a durable way to express accepted but unread as a test failure rather than as a review convention.

Uncertainties: I do not yet know how much of the intended behavior already exists versus is genuinely missing, and I am mapping that before writing code.