fix(acp): accept conventional boolean spellings for env-backed flags

[Pratikkale26]

Summary

BUZZ_ACP_NO_MENTION_FILTER=1 aborts buzz-acp during argument parsing with exit code 2, so the managed agent never starts — it never reaches the relay, never subscribes, and never posts. 1 is the spelling most tools accept for a boolean environment variable, but these flags are bare bool fields whose parser accepts only the literal strings true and false.

Fixes #4881.

Reproduced

Probing the current parser for BUZZ_ACP_NO_MENTION_FILTER:

true   -> OK
false  -> OK
1      -> ERR  error: invalid value '1' for '--no-mention-filter'
0      -> ERR  error: invalid value '0' for '--no-mention-filter'
yes    -> ERR  error: invalid value 'yes' for '--no-mention-filter'
no     -> ERR  error: invalid value 'no' for '--no-mention-filter'
on     -> ERR  error: invalid value 'on' for '--no-mention-filter'
off    -> ERR  error: invalid value 'off' for '--no-mention-filter'

The fix

Every env-backed boolean flag now uses clap's BoolishValueParser (true/false, 1/0, yes/no, on/off), with num_args = 0..=1 and default_missing_value = "true" so the bare switch form keeps working:

#[arg(
    long,
    env = "BUZZ_ACP_NO_MENTION_FILTER",
    num_args = 0..=1,
    default_missing_value = "true",
    default_value_t = false,
    value_parser = BoolishValueParser::new(),
)]
pub no_mention_filter: bool,

num_args = 0..=1 is safe here: CliArgs has no positional arguments (43 #[arg] attributes, 0 positional), so a value-less --flag cannot swallow anything.

Nine flags, not six

The issue lists six and is explicit about not having tested them. Enumerating every bool field carrying an env attribute turns up nine — --memory, --relay-observer and --lazy-pool have the identical bare-bool-plus-env shape and the identical failure:

Flag	Env var
--no-mention-filter	BUZZ_ACP_NO_MENTION_FILTER
--no-ignore-self	BUZZ_ACP_NO_IGNORE_SELF
--no-presence	BUZZ_ACP_NO_PRESENCE
--no-typing	BUZZ_ACP_NO_TYPING
--no-memory	BUZZ_ACP_NO_MEMORY
--no-base-prompt	BUZZ_ACP_NO_BASE_PROMPT
--memory	BUZZ_ACP_MEMORY
--relay-observer	BUZZ_ACP_RELAY_OBSERVER
--lazy-pool	BUZZ_ACP_LAZY_POOL

One existing assertion changed

lazy_pool_cli_flag_enables_deferred_startup asserted that --lazy-pool=true must be an error:

assert!(args.is_err(), "bool flags do not take an explicit value");

That came from #2122, the PR that introduced --lazy-pool, and characterises clap's behaviour for the flag as it was written rather than a product invariant — and it is precisely the behaviour this issue asks to change. It now asserts the boolish form instead. Flagging it explicitly since it's a deliberate change to an existing assertion.

Not addressed

The issue's second suggestion — surfacing the harness's stderr in Desktop's last_error instead of a bare exit code — is a separate change in the Desktop process supervisor and isn't in this PR. Worth doing: it's what turns any future startup failure from a 16-hour outage into a readable message. Happy to follow up.

Testing

Five new tests covering all nine flags:

• conventional spellings resolve correctly (1/yes/on → true, 0/no/off → false)
• the bare switch form still means true
• defaults are preserved when absent — notably --memory staying on
• nonsense values (maybe) are still rejected — this widens accepted spellings, it doesn't accept anything
• --memory / --no-memory still conflict

Validated by running the new tests against the unfixed flags — boolish_flags_accept_conventional_boolean_spellings fails with unexpected value 'true' for '--no-mention-filter' found; no more were expected.

Following the convention documented in this test module, values go through the CLI form rather than std::env::set_var, which would race on process-global state across parallel tests; env values flow through the same value_parser.

cargo fmt --all -- --check                             ✅
cargo clippy --workspace --all-targets -- -D warnings   ✅
cargo test -p buzz-acp --lib                            ✅ 675 passed
just test                                               ✅ 11/11 suites

Related

• buzz-acp: startup config summary omits no_mention_filter, so logs can't confirm the flag took effect #4228 — also concerns no_mention_filter, but from the other side: that one is about the flag's state being unobservable when it works; this is about the failure being unobservable when it doesn't.
• Searched open PRs for buzz-acp: BUZZ_ACP_NO_MENTION_FILTER=1 kills the agent at startup, and Desktop shows only "exit code: 2" #4881 and for boolean-parser work — none found.