Severity: Info → Minor (silent inconsistency, masked when EnableHealthMonitoring=false but real when monitoring is on)

File / line: src/Servy.Core/Domain/Service.cs line 191

Code:

public RecoveryAction RecoveryAction { get; set; }   // <-- no initializer

Context — the surrounding pattern in the same class:

public ServiceStartType StartupType { get; set; }     = AppConfig.DefaultStartupType;
public ProcessPriority Priority { get; set; }         = AppConfig.DefaultPriority;
public bool EnableSizeRotation { get; set; }          = AppConfig.DefaultEnableRotation;
public int RotationSize { get; set; }                 = AppConfig.DefaultRotationSize;
public DateRotationType DateRotationType { get; set; } = AppConfig.DefaultDateRotationType;
public bool EnableHealthMonitoring { get; set; }      = AppConfig.DefaultEnableHealthMonitoring;
public int HeartbeatInterval { get; set; }            = AppConfig.DefaultHeartbeatInterval;
public int MaxFailedChecks { get; set; }              = AppConfig.DefaultMaxFailedChecks;
public RecoveryAction RecoveryAction { get; set; }                                            // <-- the odd one out
public int MaxRestartAttempts { get; set; }           = AppConfig.DefaultMaxRestartAttempts;

What's wrong: Every neighboring property in the domain model is initialized to its AppConfig.Default* value, but RecoveryAction is left uninitialized. Because RecoveryAction.None is the first member of the enum (value 0), new Service(serviceManager).RecoveryAction yields RecoveryAction.None — not the documented default of RecoveryAction.RestartService (AppConfig.cs:308).

Today this is partially masked because EnableHealthMonitoring also defaults to false, so the recovery branch never fires for a freshly-constructed Service that the caller never configured. But:

• The moment a UI/CLI flow flips EnableHealthMonitoring = true (e.g. user ticks the checkbox) without explicitly re-confirming a recovery action, the service will silently install with "no recovery" instead of "restart service" — contradicting both the property docs and AppConfig.DefaultRecoveryAction.
• It also makes Service.Install(...) send RecoveryAction.None to the SCM in that path, which then has to be re-set later — an avoidable round-trip and a real test gap.

This is the property-side counterpart of issue #892 (ServiceMapper hardcoded the same default). Even after #892 is fixed, fresh in-memory Service instances will still default to None.

Suggested fix:

public RecoveryAction RecoveryAction { get; set; } = AppConfig.DefaultRecoveryAction;

One-line change, brings RecoveryAction in line with every neighboring property declaration.