**Change-contract traceability (required for implementation tasks):**
1. Identify this task's completion conditions from the request, plan, and observable existing behavior that must remain unchanged. When the workflow supplies contract IDs, preserve their meanings; do not create IDs for implementation locations or work order.
2. If a later stage discovers a new completion obligation, show its causal link to the request or changed contract. If it changes the root cause or design, request replanning instead of rewriting an existing ID's meaning.
3. Map completion evidence to a test or reproducible check that directly observes each changed contract. A broad test-suite pass alone is not evidence for an individual contract.

**Requirements where a persisting entity's state changes:**

When a requirement names a specific change (such as a change in input, environment, configuration, or connection state), asks behavior to continue following the state at that point after the change, and the same entity (a screen, process, connection, session, cache, or similar) persists across that change, align the unit of observation with that entity's lifetime. A requirement to preserve existing behavior, or a requirement that does not name a change, does not by itself create this contract.
- Use a continuous observation on the same entity of the state before the change → the change → the state after the change as completion evidence. An observation that recreates another entity after changing only the conditions is not evidence for this contract.
- Artifacts that the entity created before the change (such as already-emitted displays, computed results, or retained lists and connection state) are also within scope. Do not limit the scope to things newly created after the change or reinterpret the requirement as leaving artifacts created before the change in the old state.
- In the plan, identify the persisting entity and check whether its structure can react to the change (a structure that creates only once, calculates only initially, or caches cannot react). If it cannot react, include a structural change in the plan.
- Do not send an entity observable in tests to manual verification in a real environment. When this contract applies, do not mark the plan's `State / Ownership` impact-path field or the test report's `Continuous Execution, Ownership, and Concurrency` section as not applicable.
- For a requirement with no entity that persists across the change (an input-to-output transformation, a result newly created on each call, or persistence that is saved and then loaded after recreating the process), or for a requirement that does not name a change, do not add this axis.