Severity: Info

Files:

• src/Servy.Service/Service.cs lines 112 and 119
• src/Servy.Service/ProcessManagement/ProcessLaunchOptions.cs lines 60 and 66

Description:
Two defaults governing the SCM heartbeat loop are declared independently in two files, with matching values that the reader has to verify by eye:

// Service.cs:112
private const int DefaultWaitChunkMs = 5000;

// ProcessLaunchOptions.cs:60
public int WaitChunkMs { get; set; } = 5000;

// Service.cs:119
private const int DefaultScmAdditionalTimeMs = 15_000;

// ProcessLaunchOptions.cs:66
public int ScmAdditionalTimeMs { get; set; } = 15_000;

If anyone retunes either default (e.g., to give slow Java services more breathing room), the two locations will drift silently. The default is also the same concept in both places — "how long do we wait between heartbeats / how much extra time do we request from the SCM" — so there is no reason for Service.cs to own its own copy.

Suggested fix:
Make ProcessLaunchOptions the single source of truth, or move both defaults to AppConfig and have both files consume them:

// AppConfig.cs
public const int DefaultWaitChunkMs = 5000;
public const int DefaultScmAdditionalTimeMs = 15_000;

// Service.cs
private const int DefaultWaitChunkMs = AppConfig.DefaultWaitChunkMs; // or inline use
// ProcessLaunchOptions.cs
public int WaitChunkMs { get; set; } = AppConfig.DefaultWaitChunkMs;
public int ScmAdditionalTimeMs { get; set; } = AppConfig.DefaultScmAdditionalTimeMs;

The ProcessLaunchOptions approach is cleaner for a DI/options style refactor; AppConfig is fine if you want to keep the current API shape.