discourse-upcoming-changes-authoring

Auto-promotion lives in the resolved_value method: when a setting's status meets the promote_upcoming_changes_on_status threshold, it resolves to true regardless of the database value. The DB value only changes on explicit admin toggle, keeping promotion reversible without losing opt-in state.

Define a should_display_<change_name>? class method on UpcomingChanges::ConditionalDisplay for core changes, or register a callback via register_upcoming_change_conditional_display in a plugin initializer. The List service and notification jobs consult should_display? and drop changes that return false.

Set requires_plugin_enabled: false when the change's purpose is to get the plugin adopted, such as changes that are the plugin's own enabled_site_setting or that flip the plugin on via a default override. The default gate would otherwise hide the change from exactly the sites it targets.

The current_statuses and permanent_upcoming_changes caches are keyed by Discourse.git_version, so every deploy naturally invalidates them. Within a deploy, TrackStatusChanges calls clear_caches! when it detects metadata changes, and tests must call clear_caches! after modifying metadata.

This Skill covers the framework internals: the Ruby core, services, jobs, and admin UI machinery. Adding a new feature flag using the existing framework is handled by the separate discourse-upcoming-changes skill instead.