{{include:instructions/repair-plan-path-check}}
{{include:instructions/fix-root-cause-analysis}}
{{include:instructions/fix-plan-validity}}

**Tasks:**
1. Enumerate every remediation target and acceptance criterion, mapping each finding to one repair or follow-up verification without omissions
2. Separate independent problems, problems that share a cause, and items that cannot be demonstrated in the current environment. Exclude an item from implementation remediation as environmental only when the task states exclusion criteria and every condition is met
3. The displayed policies are truncated. Before deciding repair boundaries or what to carry forward, read the policy files at the supplied paths from beginning to end and confirm the rules on repair boundaries, carry-forward decisions, and exclusions
4. For each problem, confirm its cause, violated observable condition, acceptance criteria, the source that defines the condition, and the paths actually affected. Trace code from a real entry to its observable result, and record paths whose success can be checked independently instead of substituting a representative example. Treat paths requiring change for the same cause as one repair and distinguish them from a neighboring contract
5. When the same problem remains after a repair, determine whether the earlier work missed a path, assumed the wrong cause, changed too narrow a location, or used insufficient verification. When code shows that a shared definition or validation point must change, plan to prevent the problem there rather than adding another location-specific patch
6. Define dependency order and completion criteria without separating source changes, consumer migration, and removal of obsolete paths midway through the repair
7. Check that each repair method matches the cause and acceptance criteria
   - For each result covered by the acceptance criteria, list every input or state used to produce it
   - If those inputs or states can each change the result on their own, treat them as separate paths even when they lead to the same result
   - For each path, write where its input or state is defined and which functions it passes through from the entry to the result
   - Write a concrete input or state and its expected result without omitting values that will be checked
   - Change exactly one input or state used by that path, and record how the result seen from the same entry changes. Use the before-and-after results as the counterexample
   - Give every path one successful example and one counterexample. A change that affects only another path, or a repeat of the successful example, is not a counterexample
   When a path cannot yet be checked, make it executable as a concrete plan-scoped investigation followed by safe repair and verification that depend on its result. Do not finalize the plan only when the current requirements, scope, or method cannot execute the investigation or its follow-up work. Do not list quality-gate commands in the plan; follow the instructions supplied during implementation
8. Before finalizing a method, confirm the cause it assumes. When the cause cannot be confirmed while planning, specify fixed conditions, the single varied condition, the observation target, the execution method, and the repair and verification that depend on the result as the first repair unit. Separate confirmed facts, possible causes, evidence for the selected cause, and causes that were checked and ruled out. For concurrency, shared-resource, or timing causes, use repeated equivalent conditions, one-variable comparisons, tracing of the failing operation, logs, or measurements. Neither success in isolation nor success after avoiding the problem establishes the cause by itself
9. Change concurrency, timeouts, retries, test selection, or a public contract only when its relationship to the cause and its necessity for the acceptance criteria are confirmed. Do not present a change that merely avoids the problem as the root fix
10. When a plan-scoped investigation can confirm the cause or safe repair method, include it as the first repair unit. Do not finalize the plan only when an investigation method cannot be defined or its result cannot lead to safe repair and verification, and changing the plan would enable concrete project-local work; state the decision required in that case