"You didn't finish removing the old thing the day you deleted it. You finish removing it every day it stays gone."
Delete Is Not Decommission
Track 1 retired the old TextForge machinery. But a delete on one day is not the same as a decommission that holds. Deleting is an event; decommissioning is a state you have to keep true. The old tool had servers, ports, launch jobs, wrappers, and an environment — and any of those can come back without anyone intending it: a script that recreates an environment, a launch job re-added out of habit, a port that starts listening again after some unrelated change. The removal is only real for as long as it stays real.
Machinery Creeps Back
Old infrastructure has a gravity. It's referenced in scripts, remembered in muscle memory, and easy to resurrect because it used to work. That's exactly why 'we deleted it' is a weak guarantee: nobody has to decide to bring it back for it to return — an automated process or an absent-minded command can do it. Treating the legacy as gone because you removed it once is how a shadow runtime quietly reappears months later, doing work the remake was supposed to have ended.
The Guard That Stays Green
So the decommission is enforced as a check that must keep passing: no legacy process running, no legacy launch job registered, nothing listening on the old ports, no wrapper or environment recreated. It's the same idea as the very first decommission verification, but promoted to a standing invariant — something you can re-run and expect green, not a box you ticked once. A removal you verify on a schedule is a removal that stays removed.
DECOMMISSION GUARD (must stay green over time)
---------------------------------------------
no legacy process pgrep -> empty
no legacy launch job launchctl list -> empty
no old ports listening lsof :OLD_PORTS -> empty
no wrapper / env recreated? -> no
Green once is a delete. Green on a schedule is a decommission.