{{include:instructions/requirement-source-discipline}}

Meet these requirements:

- Address unresolved issues and recurrence paths with the same cause together
- Keep the original objective, constraints, and acceptance criteria fixed. Do not turn a reviewer-suggested implementation into a new requirement or narrow the task into an easier problem
- Recheck the feature's role in the system and the owners of its entry points, trust boundaries, state, authority, and side effects, then distinguish unnecessary abstraction from missing required production behavior
- Only when user or external input, authorization, sensitive information, external execution, persistence, retries, or concurrency is actually involved, include the relevant validation, rejection, and failure handling in the plan
{{include:instructions/planning-return-guidance}}
- Before replanning, compare remaining items with the original requirements, accepted contracts, current implementation, and the attempted methods, execution conditions, results, evidence, and confirmed constraints. Repeated plan or report entries do not make work mandatory. Exclude causally unrelated pre-existing failures and out-of-scope work from this task’s remaining work, recording the evidence. Do not exclude issues the change depends on, amplifies, or newly exposes, or explicitly required verification. Do not turn unverified or failed work into success.
- Before adding work carried over from a review adjudication or an earlier plan that targets an input or state not in the original finding's conditions, check the basis for handling that input or state, such as the requirements, an existing contract, an existing input source, or a failure in actual use. Having been raised by an adjudication or plan is not a basis. Do not turn work without a basis into tasks; keep it as a record that does not change the judgment. Do not create an open question asking a person whether to bring into scope an input or state that the requirements or an existing contract show to be out of scope. Raise that scope question only when the requirements and contracts cannot decide it. Keep external operations, answers, or confirmations needed to meet an in-scope required condition as open questions as before
- Carry each distinct attempted method into the next plan with its execution conditions, result, and shared constraint, even when the history came from a prior report rather than an artifact you inspected directly. Identify reported history as such and mark missing direct evidence unconfirmed; do not collapse separate attempts or present them as a new untried method.
- Explicitly determine whether the next implementation step can perform work within the project
- Define an untried code change, test change, investigation, or valid verification method and its verification steps only when it is necessary to resolve an unmet requirement or changed contract of this task and can be performed within the project. A method that already failed under the same constraint is not untried without a difference in inputs, environment, or method that can affect the result and concrete evidence that the constraint was removed or bypassed. A changed name, output path, or execution count with no result-affecting change is insufficient. Do not search for or add unrelated work merely because it is executable
- If concrete implementation and available project-scoped verification evidence support the requirements and acceptance criteria to the extent assessable within the project, no real implementation defect, untouched mandatory work, or executable new project-scoped work remains, and independent review has not already reached BLOCKED for the same implementation, evidence, and external constraint, route to independent review. When only verification that cannot be demonstrated because of an environmental constraint remains, retain its unverified status, constraint, attempted evidence, and any explicit external verification obligation in the plan. Do not call that verification successful or the task finally complete. Reassess the current state when a result-affecting change occurred after BLOCKED
- Do not edit code or tests in this step
- If independent review already reached BLOCKED for the same implementation, evidence, and external constraint, with no subsequent result-affecting change or new project-scoped work, retain the unverified obligation and required external action or answer as a wait. Also state the evidence and required action or answer when the conditions for independent review above are not met and project-scoped changes or investigation cannot resolve an indispensable external action or answer
- If the attempted approaches and confirmed constraints establish that the requirements are mutually unsatisfiable, state that evidence
- Do not conclude that the issue is unresolvable merely because it is uncertain, uninvestigated, or tests cannot be run
- If only mandatory checks that can be run now remain unexecuted, retain the implementation method and carry those checks plus the location, target, and execution conditions of valid existing evidence into the next plan.

{{include:instructions/preserve-acceptance-conditions}}