dough-post-change-refactor · git:20260909.3784459 · 2026-09-09 · sha256 2110d7798ad423a3

dough-post-change-refactor git:20260909.3784459A

Immutable. This exact content is served forever at /api/v1/blob/2110d7798ad423a3.

---
name: dough-post-change-refactor
description: >-
  Refactors concepts implicated by the current uncommitted change before commit.
  Includes untouched code needed for coherence, stops before unapproved
  cross-subsystem refactoring, and tests only after edits. Use after a slice,
  for post-change refactoring, or to clean up the current change.
---

# 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, file-size limits and exemptions, 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](references/refactor-checks.md) 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.

Include untouched code when it represents the same concept, duplicates the same
knowledge, or must change for coherence. Dependency adjacency alone does not
establish scope. Do not initiate unrelated cleanup discovered during tracing.

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. Generic cleanup authorization 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 `proof:` commands, rerun only those 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 observable stable boundaries, real lower layers,
and crafted data; mock external services rather than internal collaborators.
Do not run the full suite. 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, report checks that changed code, files renamed, extracted, split,
or deleted, passing test commands or `skipped — no refactor edits`, and approximate
active elapsed time. End with `## REFACTOR COMPLETE`.

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.