Severity: Info

Location: src/Servy.Core/Domain/Service.cs:107, 112, 144

Code:

// Line 107 — no default initializer
public ServiceStartType StartupType { get; set; }

// Line 112 — no default initializer
public ProcessPriority Priority { get; set; }

// Line 128 — sibling property, HAS default
public bool EnableSizeRotation { get; set; } = AppConfig.DefaultEnableRotation;

// Line 133 — sibling property, HAS default
public int RotationSize { get; set; } = AppConfig.DefaultRotationSize;

// Line 139 — sibling property, HAS default
public bool EnableDateRotation { get; set; } = AppConfig.DefaultEnableDateRotation;

// Line 144 — no default initializer
public DateRotationType DateRotationType { get; set; }

// Line 150 — sibling property, HAS default
public int MaxRotations { get; set; } = AppConfig.DefaultMaxRotations;

// Line 162 — sibling property, HAS default
public bool UseLocalTimeForRotation { get; set; } = AppConfig.DefaultUseLocalTimeForRotation;

// Line 168 — sibling property, HAS default
public bool EnableHealthMonitoring { get; set; } = AppConfig.DefaultEnableHealthMonitoring;

Explanation:
Most value-type and enum properties on the Service domain model are initialized inline from AppConfig.Default* constants, but three are not: StartupType, Priority, and DateRotationType. All three have matching constants that are used elsewhere (verified):

• AppConfig.DefaultStartupType = ServiceStartType.Automatic (AppConfig.cs:311)
• AppConfig.DefaultPriority = ProcessPriority.Normal (AppConfig.cs:317)
• AppConfig.DefaultDateRotationType = DateRotationType.Daily (AppConfig.cs:323)

The defaults are eventually applied via ConfigParser.ParseEnum() in ServiceMapper (lines 111, 112, 121) and via ServiceDtoHelper.EnsureDefaults (lines 25, 26, 40), but any code path that constructs a Service directly via new Service() and doesn't go through those mappers — e.g., unit tests, new object initializers — gets ServiceStartType.Boot (enum default 0, which semantically means "Boot" instead of "Automatic"), ProcessPriority.Normal (happens to coincide with the default only because Normal = 0, but this is fragile), and DateRotationType default 0.

For StartupType, this is a real behavioral difference: default-constructed Service sets StartupType = Boot (a very-early-boot driver start mode) rather than Automatic. A caller forgetting to go through a mapper silently gets a different service-start behavior.

Suggested fix:

public ServiceStartType StartupType { get; set; } = AppConfig.DefaultStartupType;
public ProcessPriority Priority { get; set; } = AppConfig.DefaultPriority;
public DateRotationType DateRotationType { get; set; } = AppConfig.DefaultDateRotationType;

This brings consistency with the sibling properties and ensures default-constructed Service objects match the mapper-applied defaults regardless of construction path.