Severity: Info

Location: src/Servy/ViewModels/MainViewModel.cs:907-908

Code:

var app = (App)Application.Current;
IsManagerAppAvailable = app.IsManagerAppAvailable;

Explanation:
IsManagerAppAvailable is populated once, inside MainViewModel's constructor, from the App singleton. App.IsManagerAppAvailable itself is set in src/Servy/App.xaml.cs:180 as part of the CustomConfigAction lambda, which runs once during bootstrap via File.Exists(ManagerAppPublishPath).

After that, neither value is ever recomputed. The UI's IsManagerAppAvailable-bound affordance (the button that launches the Manager app) is frozen to whatever state the filesystem was in at startup:

• If the Manager is installed after Servy started (e.g., via MSI install while the Desktop app is open), the "Launch Manager" button remains disabled and the user has to restart the Desktop to pick it up.
• If the Manager is removed while Servy is running, the button remains enabled and clicking it will fail at the Process.Start call with a file-not-found error.

This contrasts with other bound properties (service status, service list) which are polled continuously. The availability flag is the odd one out.

Suggested fix — least intrusive:
Recompute on-demand right before the user clicks the launch button. In ServiceCommands.cs:375 (which already reads (App)Application.Current), re-read File.Exists(app.ManagerAppPublishPath) and surface the updated state.

Suggested fix — binding-correct:
Change IsManagerAppAvailable to a property getter that delegates to App, and have App expose it as a notifying property (INotifyPropertyChanged) whose value is recomputed on a periodic timer or via a FileSystemWatcher on the Manager's publish directory.

The same pattern exists in src/Servy.Manager/App.xaml.cs:222 for IsConfigurationAppAvailable (the mirror-image property on the Manager side, detecting whether the Desktop app is installed) — both sides carry this staleness.