Refactor Operator: Domain-Specific Transformations

• Refactor Operator is a family of structure-preserving transformations that maintain designated equivalences while optimizing domain-specific objectives.
• In temporal action localization, refactor operators decouple action from context in feature representations, thereby enhancing detection accuracy.
• In logic synthesis and software refactoring, these operators enable compact circuit designs and improved code maintainability through learned and composite strategies.

Searching arXiv for the cited papers to ground the article in current records. A refactor operator is a transformation operator that restructures an existing artifact while preserving a designated notion of equivalence, but the artifact, preservation criterion, and optimization target vary substantially by domain. In temporal action localization, the operator is a learned transformation on snippet features that decouples action and co-occurrence information and recombines them into an action-dominated representation (Xia et al., 2022). In logic synthesis, refactor is a factorization-based local Boolean resynthesis operator on And-Inverter Graphs, and recent work has studied learned pruning of unsuccessful refactor attempts (Tsaras et al., 11 Aug 2025). In software refactoring theory, a refactor operator can be formalized as the composition of substitution and rewriting (Thompson et al., 2022), while in logic programming it is an optimization-based transformation that introduces invented rules and preserves semantics through unfolding (Liu et al., 2024). Software-engineering research further treats refactoring operators as extract-method transformations supporting single responsibility (Ardalani et al., 2023), as composite operators built from recurring sequences of atomic refactorings (Brito et al., 2022), and as named behavior-preserving operations whose practical motivations extend well beyond code-smell removal (Silva et al., 2016, Pantiuchina et al., 2021).

1. Operator concept and domain-specific semantics

Across the cited literature, “refactor” does not denote a single universal mechanism. It denotes a family of structure-preserving transformations whose invariants depend on the representational domain.

In temporal action localization, the refactor operator acts on a snippet feature vector $\mathbf{f} \in \mathbb{R}^C$ that entangles action and co-occurrence information. RefactorNet defines learned encoders $\boldsymbol{\phi}_{\mathrm{A}}$ and $\boldsymbol{\phi}_{\mathrm{C}}$ that decouple the feature into action and co-occurrence components and then recombine them by concatenation,

$$\mathbf{f}^{\prime} = \boldsymbol{\phi}_{\mathrm{A}(\mathbf{f})} \oplus \boldsymbol{\phi}_{\mathrm{C}(\mathbf{f})},$$

so that the downstream detector operates on a refactored representation rather than on the original feature sequence (Xia et al., 2022). Here, the preserved object is not exact feature identity but task-relevant action information under standard TAL supervision.

In logic synthesis, refactor is a core optimization operator in ABC-style flows over combinational logic represented as an And-Inverter Graph. For each node, it forms a reconvergence-driven cut, computes a sum-of-products representation, factors that SOP into a more compact form, maps it back to an AIG, and commits the change only if

$$\text{Gain} = \text{nodes removed} - \text{nodes added} > 0.$$

The invariant is Boolean functional equivalence of the rewritten subgraph, while the optimization target is primarily area reduction measured by AIG node count (Tsaras et al., 11 Aug 2025).

In program refactoring theory, the operator is abstracted as

$$\text{Refactor} = \text{Substitution} + \text{Rewriting},$$

or equivalently $R = \mathsf{Rewrite} \circ \mathsf{Subst}$. Substitution is language-independent in the sense that references to an old entity are replaced by an adapter expression implementing it in terms of a new entity, while rewriting is language-specific and captures beta-reduction, eta-reduction, desugaring, and related semantics-preserving transformations (Thompson et al., 2022).

In knowledge refactoring for definite logic programs, the operator maps a program $\mathcal{P}$ to a smaller program $\mathcal{Q}$ by introducing invented rules and replacing repeated literal patterns with calls to invented predicates, subject to exact recovery of $\mathcal{P}$ by unfolding:

$\boldsymbol{\phi}_{\mathrm{A}}$0

Its target is compression measured by program size, with semantic preservation given by syntactic equivalence after unfolding (Liu et al., 2024).

This suggests that “refactor operator” is best treated as a domain-indexed abstraction: it is always a transformation toward a more useful representation or structure, but the meaning of “same” and “better” is domain dependent.

2. Learned feature refactoring in temporal action localization

The paper “Learning to Refactor Action and Co-occurrence Features for Temporal Action Localization” defines the refactor operator most explicitly as a learned mapping on video snippet features (Xia et al., 2022). The motivating problem is that, in untrimmed videos, co-occurring ingredients such as context and background often dominate the actual action content, impairing temporal precision.

The overall pipeline has three stages. An untrimmed video is split into 16-frame snippets. A pre-trained two-stream I3D network (RGB + optical flow) extracts a $\boldsymbol{\phi}_{\mathrm{A}}$1-dimensional feature $\boldsymbol{\phi}_{\mathrm{A}}$2 for each snippet, forming a feature sequence $\boldsymbol{\phi}_{\mathrm{A}}$3. RefactorNet then transforms each snippet into

$\boldsymbol{\phi}_{\mathrm{A}}$4

yielding the refactored sequence $\boldsymbol{\phi}_{\mathrm{A}}$5. A boundary-based proposal generator (e.g., BSN) operates on $\boldsymbol{\phi}_{\mathrm{A}}$6, followed by RoI pooling and three MLP heads for action class, proposal completeness, and boundary refinement; final confidence is classification score × completeness score, and Soft-NMS produces detections (Xia et al., 2022).

The operator is trained from action samples $\boldsymbol{\phi}_{\mathrm{A}}$7 and coupling samples $\boldsymbol{\phi}_{\mathrm{A}}$8. An action sample is a snippet inside an annotated action interval. A coupling sample is a non-action snippet whose feature is highly similar (in cosine similarity) to some action sample, so that it shares co-occurrence but not the target action. The action encoder is trained to separate action latents via

$\boldsymbol{\phi}_{\mathrm{A}}$9

while the co-occurrence encoder is trained to align co-occurrence latents via

$\boldsymbol{\phi}_{\mathrm{C}}$0

A VAE-style KL term regularizes the co-occurrence latent toward $\boldsymbol{\phi}_{\mathrm{C}}$1,

$\boldsymbol{\phi}_{\mathrm{C}}$2

and the overall refactoring loss is

$\boldsymbol{\phi}_{\mathrm{C}}$3

with $\boldsymbol{\phi}_{\mathrm{C}}$4 in experiments (Xia et al., 2022).

Empirically, the refactored representation improves TAL performance. On THUMOS14, RefactorNet reports 58.6% mAP at $\boldsymbol{\phi}_{\mathrm{C}}$5 and 54.8% average mAP over $\boldsymbol{\phi}_{\mathrm{C}}$6, compared with 53.4% for the previous best MUSES. On ActivityNet v1.3, it reports 56.6% mAP at $\boldsymbol{\phi}_{\mathrm{C}}$7, 40.7% at $\boldsymbol{\phi}_{\mathrm{C}}$8, and 38.6% average mAP over $\boldsymbol{\phi}_{\mathrm{C}}$9 (Xia et al., 2022). Ablation further shows that adding $$\mathbf{f}^{\prime} = \boldsymbol{\phi}_{\mathrm{A}(\mathbf{f})} \oplus \boldsymbol{\phi}_{\mathrm{C}(\mathbf{f})},$$0 raises THUMOS14 average mAP from 52.6 to 53.8, and adding $$\mathbf{f}^{\prime} = \boldsymbol{\phi}_{\mathrm{A}(\mathbf{f})} \oplus \boldsymbol{\phi}_{\mathrm{C}(\mathbf{f})},$$1 raises it further to 54.8. Using only the action component yields 57.2 [email protected] and 81.3% classification accuracy, whereas using action + co-occurrence yields 58.6 [email protected] and 85.9% classification accuracy (Xia et al., 2022).

A common misconception is that this operator simply discards context. The paper does not support that reading. The co-occurrence component is retained and concatenated into $$\mathbf{f}^{\prime} = \boldsymbol{\phi}_{\mathrm{A}(\mathbf{f})} \oplus \boldsymbol{\phi}_{\mathrm{C}(\mathbf{f})},$$2, but it is regularized so that it does not dominate the decision process (Xia et al., 2022).

3. Factorization-based refactor in logic synthesis

In logic synthesis, refactor is a classical local resynthesis operator rather than a representation-learning module. The cited work studies this operator in the ABC ecosystem and characterizes both its baseline behavior and a learned acceleration scheme called ELF (Tsaras et al., 11 Aug 2025).

Baseline refactor iterates over nodes of an AIG. For each node, it constructs a relatively large reconvergence-driven cut, extracts the Boolean function of the cut as an SOP, factorizes that SOP into a more compact factored form, reconstructs a new AIG fragment, and commits the change if the gain is positive. The per-node template is: $\mathcal{P}$4 The operator is more expensive per node than rewrite, because its cuts are larger and its resynthesis attempt is more substantial, but it can unlock further downstream optimizations by restructuring logic around reconvergences (Tsaras et al., 11 Aug 2025).

The key empirical observation is that most refactor attempts fail. Across EPFL arithmetic benchmarks and industrial circuits, only about 0.5–1% of nodes are actually refactored on many designs; the worst cases are as few as 0.05% and the maximum reported is 10.8% on one industrial design. Equivalently, about 89.2–99.9% of formed cuts fail to get optimized, with an average failure rate of about 98% (Tsaras et al., 11 Aug 2025). On a synthetic EPFL arithmetic circuit with about 23 million nodes, conventional ABC refactor can take up to 1.5 hours, and the paper attributes most of that time to unsuccessful attempts (Tsaras et al., 11 Aug 2025).

ELF inserts a lightweight classifier in front of the expensive resynthesis call. It first collects per-node cut features, classifies nodes as likely successful or unsuccessful, and skips refactor on predicted failures. The paper reports that 69.4–95.1% of nodes can be skipped (Tsaras et al., 11 Aug 2025). Because heavy models would be counterproductive, ELF uses a small MLP with 6 features, architecture

$$\mathbf{f}^{\prime} = \boldsymbol{\phi}_{\mathrm{A}(\mathbf{f})} \oplus \boldsymbol{\phi}_{\mathrm{C}(\mathbf{f})},$$3

and 325 parameters. The six structural cut features are root fanout, root level, total cut fanout, cut size, number of reconvergent nodes, and number of leaf nodes (Tsaras et al., 11 Aug 2025).

On EPFL arithmetic benchmarks, ELF yields runtime speedups from 2.50× to 7.69×, with AND-count difference ≤ +0.27% and unchanged depth. A specific example is hyp with 214,335 nodes, where baseline refactor takes 6.82 s and ELF takes 0.93 s, both producing AND = 212,341 and levels = 24,801, for a 7.33× speedup and 0% area change. On industrial designs, speedups are 2.01× to 4.29×, with worst-case AND-count increase +0.08%. On very large synthetic circuits of 16.2M, 20.7M, and 23.3M nodes, ELF gives 2.85–2.97× speedups with +0.06–0.07% AND-count increase (Tsaras et al., 11 Aug 2025).

This suggests a second meaning of “refactor operator”: not the structural transformation alone, but the control policy deciding where that transformation is worth attempting.

4. Program refactoring as substitution, rewriting, and extraction

In software refactoring theory, the paper “Refactoring = Substitution + Rewriting” abstracts a broad class of refactorings as a generic operator with two phases (Thompson et al., 2022). One specifies a new definition for an entity and an equation implementing the old entity in terms of the new one. The operator then substitutes the adapter expression at use sites and rewrites the result into idiomatic code. For a program $$\mathbf{f}^{\prime} = \boldsymbol{\phi}_{\mathrm{A}(\mathbf{f})} \oplus \boldsymbol{\phi}_{\mathrm{C}(\mathbf{f})},$$4 and an old-to-new entity transformation, the operator can be expressed as

$$\mathbf{f}^{\prime} = \boldsymbol{\phi}_{\mathrm{A}(\mathbf{f})} \oplus \boldsymbol{\phi}_{\mathrm{C}(\mathbf{f})},$$5

where $$\mathbf{f}^{\prime} = \boldsymbol{\phi}_{\mathrm{A}(\mathbf{f})} \oplus \boldsymbol{\phi}_{\mathrm{C}(\mathbf{f})},$$6 is substitution and $$\mathbf{f}^{\prime} = \boldsymbol{\phi}_{\mathrm{A}(\mathbf{f})} \oplus \boldsymbol{\phi}_{\mathrm{C}(\mathbf{f})},$$7 is a set of rewriting rules (Thompson et al., 2022).

The paper’s examples are function-oriented refactorings such as renaming, generalization, and argument reordering. In Erlang, renaming a function $$\mathbf{f}^{\prime} = \boldsymbol{\phi}_{\mathrm{A}(\mathbf{f})} \oplus \boldsymbol{\phi}_{\mathrm{C}(\mathbf{f})},$$8 to $$\mathbf{f}^{\prime} = \boldsymbol{\phi}_{\mathrm{A}(\mathbf{f})} \oplus \boldsymbol{\phi}_{\mathrm{C}(\mathbf{f})},$$9 can be specified by giving the new function and the equation $\mathcal{P}$5 so that call sites are first transformed into applications of the adapter and then simplified by beta-reduction (Thompson et al., 2022). The argument is that substitution is largely language-independent, while rewriting carries language-specific semantics such as beta-reduction, eta-reduction, desugaring, and handling of surface syntax such as Haskell infix notation (Thompson et al., 2022).

A more operational software-engineering instance appears in work on automated extract method refactoring for the Single Responsibility Principle (Ardalani et al., 2023). There, the refactor operator is an Extract Method transformation driven by backward slicing. Responsibility is defined through deliverables, including return values, printed values, writes to files or databases, changes to object fields or global variables, and changes to parameters passed by reference or mutated objects (Ardalani et al., 2023). For a method $$\text{Gain} = \text{nodes removed} - \text{nodes added} > 0.$$0 and output instruction $$\text{Gain} = \text{nodes removed} - \text{nodes added} > 0.$$1 using variable $$\text{Gain} = \text{nodes removed} - \text{nodes added} > 0.$$2, the backward slice $$\text{Gain} = \text{nodes removed} - \text{nodes added} > 0.$$3 is the set of all statements and control predicates that can affect $$\text{Gain} = \text{nodes removed} - \text{nodes added} > 0.$$4 at $$\text{Gain} = \text{nodes removed} - \text{nodes added} > 0.$$5 (Ardalani et al., 2023).

The tool SBSRE computes output-based slicing criteria, constructs PDGs and CFGs, derives block-based candidate slices, and extracts them as independent methods if nine behavior-preservation and usefulness rules are satisfied. The rules include: keeping return statements in the original method, requiring that parameters be initialized before extraction, conservative handling of final variables, rejecting local-name clashes, avoiding trivial extractions, rejecting output slices with overlap > 0.75, and preserving object-state, object-creation, and anti-dependence constraints (Ardalani et al., 2023).

The reported results are concrete. On the GEMS extract method refactoring benchmark and three real-world projects, the approach improves precision by at least 29.6% and recall by at least 12.1% relative to state-of-the-art approaches, and improves method-level cohesion metrics by an average of 20% after refactoring (Ardalani et al., 2023). On the GEMS benchmark, SBSRE reports average precision 55.6%, recall 65.2%, and F1 57.5%, compared with JDeodorant’s 26.0%, 22.4%, and 22.8% respectively (Ardalani et al., 2023).

A plausible implication is that software refactor operators are best understood as structured semantics-preserving transformations whose implementation can range from equational substitution to graph-based slicing, depending on whether the focus is formal specification or automated opportunity detection.

5. Optimization-based refactor in logic programs

The paper “Scalable Knowledge Refactoring using Constrained Optimisation” defines a refactor operator over definite logic programs that explicitly targets compression (Liu et al., 2024). A rule has the form

$$\text{Gain} = \text{nodes removed} - \text{nodes added} > 0.$$6

with rule size

$$\text{Gain} = \text{nodes removed} - \text{nodes added} > 0.$$7

and program size

$$\text{Gain} = \text{nodes removed} - \text{nodes added} > 0.$$8

Knowledge refactoring introduces invented rules whose predicates do not appear in the original program, rewrites original rules to call these invented predicates, and requires exact recoverability of the original program by unfolding (Liu et al., 2024).

A refactored program $$\text{Gain} = \text{nodes removed} - \text{nodes added} > 0.$$9 of $$\text{Refactor} = \text{Substitution} + \text{Rewriting},$$0 relative to a set of invented rules $$\text{Refactor} = \text{Substitution} + \text{Rewriting},$$1 must satisfy

$$\text{Refactor} = \text{Substitution} + \text{Rewriting},$$2

and

$$\text{Refactor} = \text{Substitution} + \text{Rewriting},$$3

A proper refactoring further requires that no strict subset of the invented rules suffices (Liu et al., 2024). The optimization problem, called Optimal knowledge refactoring (OKR), is to find a refactored program of minimum size (Liu et al., 2024).

MaxRefactor implements this operator as a constrained optimisation problem using literal-based rather than rule-based decision variables. For invented rule index $$\text{Refactor} = \text{Substitution} + \text{Rewriting},$$4 and predicate symbol $$\text{Refactor} = \text{Substitution} + \text{Rewriting},$$5, an integer variable $$\text{Refactor} = \text{Substitution} + \text{Rewriting},$$6 counts how many body literals with predicate $$\text{Refactor} = \text{Substitution} + \text{Rewriting},$$7 occur in invented rule $$\text{Refactor} = \text{Substitution} + \text{Rewriting},$$8. Boolean variables $$\text{Refactor} = \text{Substitution} + \text{Rewriting},$$9 represent the $R = \mathsf{Rewrite} \circ \mathsf{Subst}$0-th use of $R = \mathsf{Rewrite} \circ \mathsf{Subst}$1 when refactoring rule $R = \mathsf{Rewrite} \circ \mathsf{Subst}$2, and $R = \mathsf{Rewrite} \circ \mathsf{Subst}$3 states that literal $R = \mathsf{Rewrite} \circ \mathsf{Subst}$4 in rule $R = \mathsf{Rewrite} \circ \mathsf{Subst}$5 is covered by that use (Liu et al., 2024). The objective is

$R = \mathsf{Rewrite} \circ \mathsf{Subst}$6

which is equivalent to minimizing the size of the refactored program up to the constant $R = \mathsf{Rewrite} \circ \mathsf{Subst}$7 (Liu et al., 2024).

A central theoretical result is that linear invented rules suffice. Theorem 2 states that if the optimal refactoring problem has a solution using arbitrary invented rules, then it has a solution using only linear invented rules $R = \mathsf{Rewrite} \circ \mathsf{Subst}$8 (Liu et al., 2024). Another result gives an upper bound on the number of invented rules needed:

$R = \mathsf{Rewrite} \circ \mathsf{Subst}$9

where $\mathcal{P}$0 is the number of rules and $\mathcal{P}$1 the maximum rule size (Liu et al., 2024).

Empirically, MaxRefactor is compared with Knorf. On Lego, it gains at least 27% more compression than Knorf across all programs. On Strings, it finds better refactorings on 172/196 programs, with compression increasing by about 30% on average on those cases. Using the MaxSAT backend on Strings, it yields better compression on all 196 programs, with improvements between 30% and 60% and average 53% (Liu et al., 2024). It can handle real-world program sizes around 600 on DrugDrug and Alzheimer and up to 1000 on WordNet; in one DrugDrug task it finds a refactoring of size 630 within 300 seconds, compared with the eventual optimum of 623 found after about 2440 minutes (Liu et al., 2024).

Here, the refactor operator is neither local rewriting nor developer-facing code cleanup. It is a global optimization operator over a symbolic search space constrained by semantics-preserving unfoldability.

6. Composite operators and developer motivations in software evolution

Software-engineering studies distinguish not only atomic refactoring operators but also composite refactorings, treated as higher-level operators built from recurrent sequences of atomic ones (Brito et al., 2022). The cited catalog identifies eight composite refactorings: Class Decomposition, Method Decomposition, Method Composition, Composite Inline Method, Composite Pull Up Method, Composite Push Down Method, Composite Pull Up Field, and Composite Push Down Field (Brito et al., 2022).

These operators are defined by grouping single refactorings through source or target identity conditions. For example, Method Decomposition groups multiple Extract Method or Extract and Move Method refactorings from the same source method, while Method Composition groups extractions targeting the same new method (Brito et al., 2022). In the oracle study, 60.5% of the selected single refactorings participate in some composite, forming 366 composite refactorings across 81 projects. The most frequent are Method Composition with 142 composites (38.8%), Method Decomposition with 125 (34.1%), and Class Decomposition with 55 (15.0%). In the full-history study of ten projects, the authors mine 2,886 composite refactorings, including 957 Class Decomposition, 683 Method Decomposition, 582 Method Composition, and 450 Composite Pull Up Method instances (Brito et al., 2022).

The practical meaning of software refactor operators is further clarified by empirical studies of why developers apply them. “Why We Refactor? Confessions of GitHub Contributors” studies 748 active Java repositories over 61 days, detects 1,411 true-positive refactorings across 185 projects, and builds a catalog of 44 distinct motivations for 12 refactoring types from 222 commits and 463 refactoring instances (Silva et al., 2016). It concludes that refactoring activity is mainly driven by changes in the requirements and much less by code smells, and that Extract Method is the most versatile operation, serving 11 different purposes (Silva et al., 2016).

The larger mining-based study analyzes 287,813 refactoring operations in 150 Java systems, spanning 213,102 commits, with about 17% of commits containing at least one refactoring (Pantiuchina et al., 2021). It reports that refactoring correlates more strongly with readability and semantic cohesion signals than with code-smell counts. In a mixed-effect logistic model, LackStructRead has OR = 3.14, LackComRead OR = 2.68, LackC3 OR = 1.87, HsLCOM OR = 1.94, and several process metrics are also significant, including LackFileExp with OR = 8.93, FilesRelatedToIssueFix with OR = 2.09, AvgLinesImpactedInCommit with OR = 1.93, and DistanceNextRelease with OR = 1.43 (Pantiuchina et al., 2021). The authors derive a taxonomy with 6 root categories and 67 detailed motivations, including Improve Code Design, Improve Understandability / Readability, Improve Quality of Test Code, Prevent Bugs, Preparing Code for Changes, and Other Motivations (Pantiuchina et al., 2021).

A common misconception is that refactor operators in software engineering are primarily smell-removal operators. The cited studies explicitly contradict that interpretation. They describe refactoring as deeply entangled with feature work, bug fixes, testing, naming, reuse, API evolution, and release timing (Silva et al., 2016, Pantiuchina et al., 2021).

7. Comparative structure, limitations, and broader implications

The surveyed literature supports a comparative view of the refactor operator as a reusable design pattern with three recurring ingredients: an equivalence criterion, a search or construction mechanism, and an improvement objective.

Domain	Preservation criterion	Improvement target
Temporal action localization	standard TAL supervision; action/co-occurrence decoupling with refactored features	more salient action information and more accurate localization
Logic synthesis	same Boolean function in AIG resynthesis	area reduction, with some attention to depth
Program refactoring theory	semantics-preserving substitution and rewriting	idiomatic, reusable, language-specific refactoring instances
Logic program refactoring	exact recovery by unfolding	compression via invented rules
Software extract/composite refactoring	behavior preservation under Extract Method or composite sequences	SRP, cohesion, readability, maintainability, reuse

The limitations are likewise domain specific. RefactorNet depends on the expressiveness of I3D two-stream features, on the quality of coupling sample mining, and it imposes no explicit orthogonality constraint between $\mathcal{P}$2 and $\mathcal{P}$3 (Xia et al., 2022). ELF may miss profitable refactor attempts because the classifier is imperfect; its reported area loss is small but nonzero, and its batching strategy means some feature vectors are stale relative to the graph state at refactor time (Tsaras et al., 11 Aug 2025). The substitution-plus-rewriting account does not cover all refactorings, especially purely rewriting-based transformations or cases such as arbitrary recursion-to-iteration replacement (Thompson et al., 2022). MaxRefactor is limited to definite logic programs, disallows recursive invented predicates and invented predicates depending on other invented predicates, and solves an NP-hard optimization problem (Liu et al., 2024). SBSRE is conservative, Java-specific, and semi-automated, rejecting some valid but complex transformations (Ardalani et al., 2023). Composite-refactoring mining is heuristic and dependent on source/target identity predicates and tool detection quality (Brito et al., 2022).

Taken together, these works suggest that “refactor operator” is not merely a software-maintenance term. It is a cross-domain operator family characterized by semantics-preserving restructuring in service of a domain-specific objective: disentangling action from context in video, pruning redundant Boolean resynthesis attempts in circuits, compressing logic programs via invented predicates, or reorganizing source code for readability, modularity, and changeability (Xia et al., 2022, Tsaras et al., 11 Aug 2025, Thompson et al., 2022, Liu et al., 2024, Ardalani et al., 2023, Brito et al., 2022). A plausible implication is that future research will continue to generalize the concept into operator-selection or operator-composition frameworks, such as the unified operator envisioned in logic synthesis for choosing among rewrite, refactor, resubstitute, skip (Tsaras et al., 11 Aug 2025), or composite refactoring systems that expose higher-level macro-operators rather than isolated atomic edits (Brito et al., 2022).