What signals would tell you an Ansible shell task is safe to leave alone versus genuinely needs fixing?

Prioritize by actual downstream impact: a task that notifies a handler (causing unnecessary restarts on every "changed" false-positive), runs frequently (compounding the cost of inaccurate reporting), or is relied upon for check-mode-based decision-making needs fixing; a task that runs rarely, has no downstream consequences from its inaccurate change-reporting, and isn't relied upon for anything beyond "did the command succeed" is safe to leave as-is, even though it's technically non-idempotent.

Handler-notifying tasks are high priority: if a shell task's notify triggers a handler (restarting a service, reloading a config), every false "changed" report causes that handler to fire unnecessarily — a real, recurring operational cost (unnecessary restarts) directly caused by the non-idempotency, not just a cosmetic reporting inaccuracy. This is one of the clearest, most concrete signals a task is actually causing harm, not just technically imperfect.

High-frequency tasks compound the noise cost: a task that runs as part of every deploy, executed dozens of times a day, generates much more cumulative noise (confusing "changed" reports, or unnecessary handler triggers) than a task that runs once during initial provisioning and rarely again — frequency directly multiplies the practical cost of the inaccuracy.

Tasks relied upon for check-mode decision-making are high priority: if anything downstream (a conditional in a later task, a human reviewing --check --diff output before approving a change) depends on this specific task's change-reporting being accurate, its inaccuracy has real consequences beyond noise — it can actually mislead a decision, which is a different, more serious category than just generating clutter.

Tasks with no downstream consequences and infrequent execution are low priority: a shell task that runs once during a rarely-executed setup playbook, with no handler attached and nothing downstream depending on its change-reporting accuracy, causes essentially no real harm from being technically non-idempotent — the cost of leaving it alone is close to zero, making it a low-value target for retrofit effort that could be spent elsewhere.

A task's actual observed behavior matters, not just its category: two shell tasks in the same category (say, both installing something) can have very different real-world impact depending on specifics — checking ansible-playbook -vv output over several real runs to see how often a given task actually reports "changed" when nothing meaningfully changed gives concrete, task-specific evidence for prioritization, rather than assuming every shell task is equally problematic just because it's technically the same anti-pattern.

• Handler-notifying tasks are high priority, since false "changed" reports cause real, unnecessary restarts — a concrete operational cost, not just noise.
• High-frequency tasks compound the cost of inaccurate reporting simply through repetition.
• Tasks whose change-reporting feeds a downstream decision (a conditional, a human review) risk actually misleading someone, a more serious category than clutter alone.
• Infrequent, no-downstream-consequence tasks are safe to deprioritize — the real-world cost of leaving them non-idempotent is close to zero.

• Ansible: Controlling how modules report changes