fix(config): parse list/mapping literals in hermes config set

[sam7894604]

What

hermes config set <key> <value> stored list/mapping values as raw strings. A value that looks like a list or a map — e.g. ["line","discord"] or {line: false} — was saved as a plain string instead of the structured value the config consumer expects.

Why

Structured config keys (lists of platforms, mapping overrides, etc.) could not be set from the CLI: the value round-tripped as a string, so downstream code expecting a list/dict either broke or silently ignored it, and the only workaround was hand-editing the YAML. This makes config set parse list/mapping literals before storing, so structured values can be saved naturally from the CLI.

Fixes #40545 #50168

Changes

• hermes_cli/config.py — detect and parse list/mapping literals in config set before persisting.
• tests/hermes_cli/test_config_set_list_values.py — new coverage for list and mapping values.

Testing

pytest tests/hermes_cli/test_config_set_list_values.py -q -> 5 passed.

Cleanly cherry-picked onto current main; touches only the two files above (no unrelated changes).

[teknium1]

Thanks for the focused reproduction and coverage. Current main still has the reported failure: hermes_cli/config.py:8267-8279 only coerces scalar values, while hermes_cli/tools_config.py:1661-1664 requires a native list for an explicit platform toolset.

Problems

• website/docs/user-guide/configuring-models.md:216 currently says hermes config set only writes scalar values. This behavior change would make that statement incorrect.
• The branch predates the current string-typed-value safeguard from e4ea0a0ed and is currently marked dirty by GitHub. Salvage must retain the guard at current hermes_cli/config.py:8268 so string settings do not regain YAML coercion.

Suggested changes

• Update the scalar-only documentation statement and add a quoted list/mapping-literal example where useful.
• Integrate the parser within the current non-string coercion block; the PR's persistence tests are a good base for that focused salvage.

Automated hermes-sweeper review.

[sam7894604]

Thanks for the review — addressed both points and rebased onto the latest main.

• Preserve the string-typed-value guard. The parser now lives inside the existing not isinstance(_default_value_for_key(key), str) coercion block (the guard added in e4ea0a0ed) rather than running unconditionally. A genuinely string-typed setting whose value merely starts with [ or { is therefore left untouched, while non-string keys get inline JSON/YAML flow literals parsed into real lists/dicts. Existing coercion (approvals.mode, bool/int/float) is unchanged.
• Docs. Updated website/docs/user-guide/configuring-models.md — the "config set only writes scalar values" note is no longer accurate; it now documents list/mapping support with a quoted example (platform_toolsets.line, display.tool_progress_overrides).
• Tests. tests/hermes_cli/test_config_set_list_values.py passes (5/5), including the string-passthrough (tts.provider) and scalar cases; the broader set_config_value / config suites stay green under this change.

Rebased cleanly on top of current main.

[teknium1]

Merged via PR #88163 — your commit was cherry-picked onto current main with your authorship preserved in git log. Yours was the only variant in the 8-PR cluster that folded the structured parse inside the string-typed-key guard, which is why it was chosen as the base; on top we widened the trigger to multi-line YAML blocks while keeping dash-prefixed scalars as strings. First-submitter credit for the bug goes to @liuhao1024 (#37460). Thanks for the clean implementation!