Bug Description

The project uses three different patterns to represent operation success/failure across its layers, making it harder to handle results consistently and increasing the chance of lost error context.

Actual Behavior

Pattern 1 — CLI Commands: CommandResult with message and success flag

// StartServiceCommand.cs
public async Task<CommandResult> Execute(StartServiceOptions opts)
{
    // ...
    return CommandResult.Ok("Service started successfully.");
    return CommandResult.Fail("Failed to start service.");
}

Pattern 2 — Core Services: bare Task<bool>

// IServiceManager.cs
Task<bool> InstallService(...);
Task<bool> StartService(...);

Pattern 3 — Domain Model: bare Task<bool>

// Service.cs
public async Task<bool> Start() { ... }
public async Task<bool> Install(bool isCLI = false) { ... }

The CLI layer wraps the boolean into a CommandResult, but any error context from the core/domain layer is lost in translation — a false return carries no explanation of what went wrong.

Expected Behavior

Consider using a result type with error context at the core/domain level as well, so failure reasons can propagate up to the CLI layer without being reduced to a boolean.

Environment

• Files: src/Servy.CLI/Commands/*.cs (CommandResult), src/Servy.Core/Services/IServiceManager.cs (bool), src/Servy.Core/Domain/Service.cs (bool)