[UX] `config set` always prints `[OK]`; status label is redundant/inconsistent

[GiantDragon9090]

Project

cortex

Description

cortex config set success output always includes [OK], but this command currently has no alternate bracketed statuses in normal flow. The label adds noise without conveying extra state. Either remove [OK] for this command or introduce consistent bracketed labels across all outcomes ([INFO], [WARN], [ERROR]) so the prefix carries real meaning.

Error Message

Debug Logs

System Information

Linux 6.14

Screenshots

Steps to Reproduce

1. Run cortex config set <key> <value>.
2. Observe success output always starts with [OK].
3. Compare with error paths, which often use non-bracketed Error:/error:.

Expected Behavior

Use one consistent status system:

• Option A: remove [OK] from this command and print plain success text, or
• Option B: use bracketed labels consistently for success/info/warn/error in this command group.

Actual Behavior

config set always prints [OK], while related failures often use different non-bracketed formats.

Additional Context

No response

[echobt]

The issue reports that cortex config set always prints [OK] on success, which the user finds redundant and inconsistent with other commands.

I verified the codebase and found the exact code responsible for this behavior in src/cortex-cli/src/cli/handlers.rs:

        Some(ConfigSubcommand::Set(args)) => {
            // ...
            print_success(&format!("Set {} = {}", args.key, args.value));
        }

The print_success function is defined in src/cortex-cli/src/styled_output.rs:

pub fn print_success(message: &str) {
    print_styled_internal(MessageType::Success, message, true, false);
}

And MessageType::Success uses the [OK] icon:

    fn icon(&self) -> &'static str {
        match self {
            MessageType::Success => "[OK]",
            // ...
        }
    }

This confirms that cortex config set indeed prints [OK] Set <key> = <value>, which matches the screenshot provided by the user ([OK] Set no = no). The user's complaint about the UX inconsistency is valid and verified by the code. No exact duplicates were found.