One rule for a day of bug fixing, and a restart planner that argued with its own baseline

Two different facts were sharing one variable. `currentCompareConfig` served as the acceptance baseline that planning needs in order to classify a candidate as hot, no-op or restart-required, and it was also read as though it described what the gateway had actually adopted ^[8][10]. Those two readings agree right up to the moment a restart is deferred, and a deferred restart is the case the issue is about.

The sequence in the pull request text is short. Candidate B arrives on a restart-required path, say `gateway.tools.allow`, and is accepted, so the baseline becomes B ^[9]. The file then settles back to bytes identical to the original A ^[6]. The planner diffs A against B, still sees protected-path changes, and re-arms the deferred restart ^[9]. The issue calls the leftover state restart debt: it latches onto the first restart-required candidate and survives every write that supersedes it, so an operator who probes a setting and immediately undoes it still loses Control UI and channel sessions for a full drain-then-SIGUSR1 cycle ^[7][6].

The patch leaves the acceptance baseline alone, because hot and no-op classification, runtime-overlay handling and managed-restart choreography all depend on it ^[10]. It adds `currentRuntimeCompareConfig` for exactly one decision, advancing it when the process adopts a snapshot and deliberately not advancing it for restart-deferred or runtime-skipped candidates ^[11]. That refusal is the fix. Advance it in the deferred case and you have rebuilt the original bug under a longer name.

The cancel itself is timid on purpose. It runs in both restart branches, immediately before `prepareRestart` arms anything, and only when the candidate deep-equals the runtime reference ^[12]. The published condition fires only with config-level diffs present, no plugin reload planned, no MCP disposal planned and an empty runtime diff ^[13]; plugin reload and MCP dispose plans are exempt so bundled-plugin work is never dropped by the shortcut ^[14]. That caution reads as earned, since a cancel gate in a reload path sits one loose boolean away from swallowing a restart somebody needed.

The test is the part worth stealing. It walks the runtime from A to B and back to A, then asserts a negative: `onRestart` exactly once, no `onHotReload`, no `onNoopConfigCommit` ^[15], with matching coverage at the handler surface ^[16]. Latched state rarely announces itself with a wrong value. It announces itself with an extra call, and only a test that counts calls will catch it.

One caveat on the day's scoreboard. The author reports three projects and three pull requests under the test-first rule, written for a DEV bug-smash contest ^[1][2][3], and two of the three are not described in the material at hand ^[17]. The documented one is the one worth reading anyway.