Changefy isn't just for incidents — it does planned project work too

Most of what we write about here reads like incident response: something breaks, Changefy investigates, plans a fix, and verifies it. That's a real and common case, but it undersells what the same workflow is good for — planned, scheduled operational work that nothing is actually broken to justify.

Take a staged patching cycle across a fleet of session hosts: dev patched a week ahead of production, hosts drained in batches that keep at least half of capacity online, powered-off hosts temporarily started and returned to their prior state afterward, and every host confirmed healthy before the maintenance window closes. Nothing is on fire. The work item exists because a patch cadence says it's time, not because an alert fired.

The workflow is identical to WRK-2041's incident: investigate current state (which hosts are online, which are due), plan the exact batches and order, get the maintenance window approved, execute batch by batch with drain/reboot/restore at each step, verify every host before moving to the next batch, and keep a full record for the change log.

The difference that matters for governance isn't incident versus project — it's the same three questions either way: what exactly is going to change, who authorized it, and how do we know it actually worked. A scheduled fleet-wide rollout has just as much blast radius as an outage fix, sometimes more, and deserves the same plan-review-execute-verify discipline rather than being waved through as "just routine maintenance."