declare-when-a-setting-takes-effect

You are exposing a setting in a user interface, and the code that consumes it reads the value at some point other than every use: at process start, when a session is built, or into a cached object.

It does not apply to a setting read on every use. Those apply immediately and should say nothing — a note about a delay that does not exist teaches the same distrust as a missing one.

1. For each setting, find the line that reads it. When it applies is a property of that line, not of the control.
2. Prefer making it read live. A property that resolves on access usually costs nothing and removes the problem instead of describing it.
3. Where it genuinely cannot — something is started at boot — label it, and generate the label from the server or the same module that knows the read site, so the label cannot drift.
4. Group the labels into meaningful classes: applies now, applies to your next conversation, applies after a restart.

Labels add noise to a settings screen, and a screen where every row has a badge is a screen where badges mean nothing. Only the delayed ones need one.

The deeper risk is treating the label as the fix. Declaring that a control is inert until restart is honest; making it live is better, and the label should not become a comfortable way to avoid the harder change.