A repaired test can still be wrong
If a button label changes, updating a locator may be safe. If the new button leads to a different approval step, the same repair could hide a product regression. Green status is not the objective; trustworthy evidence is.
Classify before changing
A failed step can come from a product defect, test drift, unstable data, an unavailable dependency, environment configuration, timing, or an invalid expectation. A maintenance system should expose that classification and its uncertainty before proposing code or selector changes.
Keep the proposed diff narrow
A reviewer should see the prior target, proposed target, observed evidence, and expected destination together. Broad regeneration makes review harder because unrelated changes are mixed with the necessary repair. Prefer the smallest change that restores the documented intent.
Make approval proportional to risk
Low-risk presentation changes may be eligible for lightweight review. Changes to permissions, money movement, external communication, destructive actions, or compliance-critical outcomes deserve explicit human approval and often a fresh test-design review.
Preserve the rejected path
A rejection is useful information. Record why the proposal was rejected and whether the underlying result became a product defect, environment issue, or revised requirement. This prevents the same unsafe suggestion from resurfacing without context.
Measure what healing saves—and costs
Track avoided maintenance time, but also false repairs, reviewer effort, reopened failures, and defects hidden by accepted changes. A system that heals frequently may be adapting to a volatile interface, masking weak test design, or simply creating more review work.