Refactor the current change

Preserve observable behavior while making implicated concepts cohesive, clearly
named, and justified. Return to the caller without starting another slice,
committing, pushing, amending, or triggering CI.

Discover scope

Run git status, git diff, and git diff --cached. If there is no uncommitted
change, report empty scope and use the completion handoff below without edits
or tests.

For a nonempty change, resolve this project's navigation, domain vocabulary,
production subsystem boundaries and applicable architectural decisions, tooling wrapper,
whitespace check with generated-artifact exclusions, and focused test commands.
Resolve generation triggers and commands only when affected. If necessary
context is missing, report it and stop without claiming completion.

Use the caller's active plan and current slice when supplied. Code may be
justified by the current change or the immediate next slice in that plan;
without a plan, only the current change supplies justification. Later slices
cannot justify speculative code. The next slice can justify retaining code but
cannot independently trigger refactoring.

Decide before editing

Read refactor checks and make one read-only pass
through them. For each candidate, identify:

1. An issue introduced, exposed, or materially aggravated by the current change.
2. The smallest complete set of representations, callers, tests, fixtures, and
   configuration needed to make the concept coherent.
3. The production subsystems that the refactoring would change.

Trace the concept through its representations and orchestration, including
untouched code that repeats its knowledge or must change for coherence. Apply
delivery scope versus implementation reach:
story membership cannot exclude a necessary edit. Dependency adjacency alone
does not establish scope. Do not initiate unrelated cleanup discovered during
tracing.

If a candidate exposes a disputed plan restriction, use the shared
plan-conflict handoff
before editing that behavior. Preserving it is not a clean review result when its
justification is disputed; return a decision stop without disguising a behavior
change as refactoring.

Identify real production boundaries from domain responsibilities and this
project's architectural decisions; delivery groupings and story-named handlers
do not establish separate subsystems. If product organization coincides with
story boundaries, require independent domain justification. Whole-concept
examination does not authorize overriding an architectural decision; surface
any conflict for human resolution before the conflicting edit.

If a candidate needs coordinated production refactoring in more than one
production subsystem, stop before editing unless the human has authorized that
named concept and those subsystems, or the active plan specifically identifies
the cross-subsystem structure as necessary for the current authorized
responsibility. The plan must connect the concept, affected boundaries, and
current outcome; an inferred benefit, generic cleanup authorization, or a later
story is insufficient. Tests, fixtures, generated artifacts, and configuration
following one production seam do not alone constitute a crossing; neither does
the original behavior change spanning subsystems.

If this crossing becomes apparent during editing, stop before the first
cross-subsystem edit and reverse only this agent's edits for that candidate.
Preserve others' changes and return the decision handoff below. Do not substitute
a partial refactor or proceed with other candidates while the gate is unresolved.

With no candidates, report none — already clean and complete without tests.
Otherwise edit in refactor-check order, without repeating broad discovery.
Use this project's whitespace check. Regenerate affected artifacts through their
source generator and validate consumers; never manually repair generated output.

Verify edits

When the caller supplied accepted proof, compare each refactor edit with its
reported boundary, implementation, setup, and observation locations. Identify
which accepted proof remains unchanged and which the refactor invalidated;
unchanged proof requires no rerun. Rerun only commands whose covered behavior or
paths the refactor invalidated. If the covered boundary moved, explain why the
original command no longer applies and run a focused replacement. Without
supplied proof, run focused tests related to the refactor edits. Use this
project's literal commands and the shared
behavioral test guidance.
Do not run the full suite. Own any verification command that yields a running
command identity through its terminal result under the shared
verification ownership
rule. Fix failures caused by the refactor and require
passing relevant proof before completion. Report other unresolved failures to
the caller; do not claim success.

Return control

On completion, return a targeted report with the refactor outcome, every path
and conceptual or product boundary changed by refactoring, and checks that
changed code. For each relevant accepted proof, name whether its boundary and
inspected locations stayed unchanged or which edit invalidated them. For
invalidated or replacement proof, report the literal command, result, and
concrete setup and assertion or signal locations. Also report files renamed,
extracted, split, or deleted; unresolved gaps or contradictions; consequential
learnings; passing test commands or skipped — no refactor edits; and
approximate active elapsed time. Do not attach routine raw traces, full command
logs, or a duplicate full diff; the caller inspects the reported locations. End
with ## REFACTOR COMPLETE.

For a disputed plan restriction, return the shared plan-conflict handoff and end
with ## REFACTOR JIDOKA STOP; the caller must resolve it before treating the
review as complete or committing.

When the subsystem gate stops work, report the triggering issue, concept,
affected subsystems and representative files, why a narrower change would be
incomplete, expected risk and focused validation, and elapsed time. Ask the human
to authorize the refactoring, defer it, or approve a described narrow exception.
End with ## REFACTOR JIDOKA STOP. The caller must resolve this decision before
considering refactoring complete or committing.