Severity: Info

Location: src/Servy.Core/Config/AppConfig.cs:123,128,133,138,153

Code:

// Line 123 — UI Debug: 5 levels up
public static readonly string ServyServiceUIDebugFolder =
    Path.Combine(AppDomain.CurrentDomain.BaseDirectory, @"..\..\..\..\..\Servy\bin\Debug\net10.0-windows\");

// Line 128 — UI Release: 4 levels up
public static readonly string ServyServiceUIReleaseFolder =
    Path.Combine(AppDomain.CurrentDomain.BaseDirectory, @"..\..\..\..\Servy\bin\Release\net10.0-windows\win-x64\");

// Line 133 — Manager Debug: 4 levels up
public static readonly string ServyServiceManagerDebugFolder =
    Path.Combine(AppDomain.CurrentDomain.BaseDirectory, @"..\..\..\..\Servy.Manager\bin\Debug\net10.0-windows\");

// Line 138 — Manager Release: 5 levels up
public static readonly string ServyServiceManagerReleaseFolder =
    Path.Combine(AppDomain.CurrentDomain.BaseDirectory, @"..\..\..\..\..\Servy.Manager\bin\Release\net10.0-windows\win-x64\");

// Line 153 — a second Manager Release: 4 levels up
public static readonly string ServyManagerReleaseFolder =
    Path.Combine(AppDomain.CurrentDomain.BaseDirectory, @"..\..\..\..\Servy.Manager\bin\Release\net10.0-windows\win-x64\");

Explanation:
The ..\ depth varies in a way that does not follow a consistent rule:

• ServyServiceUIDebugFolder — 5 levels, ServyServiceUIReleaseFolder — 4 levels
• ServyServiceManagerDebugFolder — 4 levels, ServyServiceManagerReleaseFolder — 5 levels
• ServyManagerReleaseFolder — 4 levels (points to the same physical location as ServyServiceManagerReleaseFolder at 5 levels)

Even if each depth was chosen intentionally for a specific caller's BaseDirectory, there is no code comment explaining which caller each constant is for, so any project-structure change (renaming a folder, adding a wrapper project, changing TFM layout) will silently break some of these constants while leaving others working. The two Manager Release constants with different depths pointing at the same folder are particularly hard to justify.

Suggested fix:

1. Replace ..\..\.. chains with a solution-root anchor (e.g., walk up from BaseDirectory until a sentinel file like Servy.sln is found), then resolve the sibling project's output path from there. This makes the constants caller-agnostic.
2. Alternatively, add an XML doc comment to each constant naming the specific caller it's sized for.
3. Deduplicate ServyServiceManagerReleaseFolder and ServyManagerReleaseFolder — they both mean "Servy.Manager's release publish output".