The 3-tier resolution (tool_arg > provider_config > built-in default) lands correctly in media.rs, but there's a buried bug in the fallback path that nullifies it for ElevenLabs specifically:

• synthesize_elevenlabs() (crates/librefang-runtime/src/tts.rs ~175-244) takes only voice_override, not format_override. The call at tts.rs:85 is self.synthesize_elevenlabs(text, voice_override).await — format never gets plumbed in. So the operator's [tts.elevenlabs].output_format is respected via the new media-driver path, but ignored whenever the older engine.synthesize(...) fallback runs at media.rs:581.
  Fix: add format_override: Option<&str> to synthesize_elevenlabs and pass it through at the call site. (#5283 has the exact same gap from the same root cause — fixing them together is cleaner.)

Two more before merge:

• No unit test for the 3-tier resolution chain. The PR description acknowledges this; please land at least one test pinning the precedence so a future refactor can't silently re-introduce the "config ignored" regression.
• For google_tts, effective_voice already carries a hardcoded resolution and config_default_voice is dead in the .or() chain (media.rs:551-552). Functionally correct but confusing — a one-line comment explaining the asymmetry would prevent a future contributor from "fixing" it incorrectly.

Intersection note: this PR stacks cleanly with #5283 (no double-mutation risk), as long as the format_override parameter is added in both.

The core change here is sound. The (config_default_voice, config_default_format) fallback applied via .or() after the LLM args (media.rs:570-577) correctly makes a bare text_to_speech(text=…) respect [tts.elevenlabs] / [tts.openai] config, and the comment explaining why google_tts is deliberately omitted (already resolved into effective_voice and winning the .or() chain first) is accurate — re-adding it would be dead code, agreed.

That said, the same CI blockers that affect #5283 (which this is stacked on) apply here, since the diff carries those commits:

1. Schema baseline drift (OpenAPI Drift job, fail). The inherited TtsElevenLabsConfig.output_format field changes the config JSON schema, so xtask/baselines/config.sha256 is stale. As a fork PR (IS_INTERNAL_PR: false), the auto-commit path can't run — regenerate locally with cargo xtask schema-check gen and commit the result.

2. Formatting (Quality job, fail). All reported diffs are in untouched files (librefang-cli/src/main.rs, tui/event.rs, librefang-migrate/src/openclaw.rs, librefang-types/src/config/types.rs:6542), i.e. stale base — main has reformatted them since this branch's base. A rebase on current origin/main should clear it.

Since both of those originate in #5283, resolving them there and rebasing this branch on top is the cleanest path. I've left the same notes on #5283.

3. Missing unit test for the resolution chain. This is a behavior change to tool_text_to_speech, and the repo prefers a test at the injection site (crates/librefang-runtime/CLAUDE.md: "Always write integration tests at the injection site, not just the implementation site"). The PR description defers it to a separate PR — please add a #[tokio::test] (or a focused unit test) here that asserts: (a) bare text_to_speech(text=…) with ElevenLabs configured resolves to cfg.voice_id + cfg.output_format; (b) an explicit voice/format arg still wins; (c) google_tts still takes the absolute-override path. That locks in exactly the matrix in your behavior-change table and guards against future .or()-chain regressions.

Items 1 and 2 are hard CI gates; item 3 is required by repo test policy for a route/behavior change. Once #5283's baseline + rebase land and a test is added, this should be ready.

Review — config fallback logic is sound; one real CI failure must be fixed before merge

The resolution logic itself is correct and well-tested. Holding the merge only on the OpenAPI Drift check, which is a genuine, in-scope failure (the other two red checks are stale-base and clear on rebase).

CI failure triage

Required fix (OpenAPI Drift) — in-scope, mechanical

TtsElevenLabsConfig derives schemars::JsonSchema (crates/librefang-types/src/config/types.rs:1284), so adding output_format (line 1294-ish in your diff) changes the generated config schema. You also edited librefang.toml.example, which is the input to xtask/baselines/config.sha256 (that baseline currently hashes only librefang.toml.example). Neither openapi.json, the generated SDKs, nor xtask/baselines/* were regenerated, so the drift guard fails:

cargo xtask codegen --openapi
python3 scripts/codegen-sdks.py
cargo xtask schema-check gen

Then commit the regenerated openapi.json, sdk/*, and xtask/baselines/*. This is step 4 of the "Configuration field ritual" in crates/librefang-types/CLAUDE.md — any KernelConfig field change requires regenerating these. Doing this in the same rebase that picks up main will also clear the two stale-base reds.

Logic review — OK

Verified the 3-tier resolution (per-call arg > [tts.<provider>] config > built-in default) holds on both code paths:

• Driver path (crates/librefang-runtime/src/tool_runner/media.rs:551-555): voice: effective_voice.or_else(|| voice).or(config_default_voice) and format: format.or(config_default_format). For elevenlabs/openai effective_voice is None (only set for google_tts), so the effective order is per-call arg → config → driver default. Correct.
• The elevenlabs config default feeds MediaTtsRequest.format, which the driver puts into the ?output_format= query param (crates/librefang-runtime-media/src/elevenlabs.rs:138-140) — so opus_48000_32 is the right shape there. The openai default (mp3) maps to response_format (crates/librefang-runtime-media/src/openai.rs:181-187) — also the right shape. The two providers use different format vocabularies and your tuple routes each correctly.
• TtsEngine fallback path (media.rs:581 → tts.rs synthesize_*): config defaults are resolved inside synthesize_openai/synthesize_elevenlabs via unwrap_or(&self.config…), so this path also respects config.
• Serde forward-compat: TtsElevenLabsConfig has struct-level #[serde(default)] (config/types.rs:1285) and the Default impl now lists output_format, so an absent [tts.elevenlabs] section or missing key never panics. Good.
• The format-label derivation in synthesize_elevenlabs (opus_48000_32 → "opus" via prefix split) is reasonable and the new TtsResult.format is no longer hardcoded to "mp3".
• New unit tests pin the precedence chain — appreciated.

Minor

• The PR description's "Files" table lists only media.rs, but the diff also touches tts.rs, config/types.rs, librefang.toml.example, and packages/whatsapp-gateway/index.js{,.test.js}. Please update the description so reviewers and git log reflect the full scope (the whatsapp-gateway detectAudioMime change is a sensible companion fix, but it should be enumerated, with its own test coverage noted).

No logic blockers. Once the codegen artifacts are regenerated and the branch is rebased onto origin/main, this should go green.

The unique media.rs change is correct — the per-provider (config_default_voice, config_default_format) fallback applied via .or() after the LLM args (tool_runner/media.rs:546-577) makes a bare text_to_speech(text=…) respect [tts.<provider>], and the google-asymmetry comment is accurate. Two blockers.

1. Duplicates #5283. git log origin/main.. shows this branch re-contains #5283's entire change as separate commits (0b0bb622 audio fix + a plumb format_override commit), so this diff is a superset of #5283 rather than stacked on it. Please either base this branch on #5283 (narrowing this diff to the media.rs delta) or have one PR carry the whole cluster and close the other.

2. Injection-site test still missing. The test_three_tier_resolution_* tests in tts.rs::tests re-implement the unwrap_or chain inline — they assert on a local copy of the logic, not on tool_text_to_speech itself (git grep tool_text_to_speech finds zero test call sites). A regression in the media.rs .or() chain wouldn't be caught. Per librefang-runtime/CLAUDE.md ("test at the injection site"), please add a test that actually calls tool_text_to_speech with ElevenLabs configured and asserts the resolved MediaTtsRequest.voice/.format (bare call → config default; explicit arg → arg wins; google → absolute-override path).

Nit: update the Files table — the diff also touches tts.rs, config/types.rs, librefang.toml.example, the whatsapp-gateway files, and config.sha256, not just media.rs.

Rebase required — the branch has a merge conflict in packages/whatsapp-gateway/index.test.js against the feat(wa-gateway): compute wasMentioned commit (#5230) that landed on main after the last merge. Please rebase onto current main and resolve.

The Quality CI failure (doc_lazy_continuation / manual_pattern_char_comparison in validation.rs and webchat.rs) is a pre-existing clippy issue unrelated to this PR — it disappears after a clean rebase against the current main where it was fixed (#5654).

Code review — correctness assessment:

The core fix is sound. Two code paths exist in tool_text_to_speech:

1. Media-driver path (media_drivers cache hit): The new (config_default_voice, config_default_format) tuple correctly populates MediaTtsRequest.voice / .format via .or(config_default_voice) / .or(config_default_format) when the LLM omits those args. The ElevenLabs media driver (crates/librefang-runtime-media/src/elevenlabs.rs:115) and OpenAI media driver (same file, :180–181) both have hardcoded fallbacks ("mp3_44100_128" / "alloy" + "mp3") that are correctly bypassed once request.format / request.voice is Some(...) from the config.

2. TtsEngine fallback path (media.rs:607): engine.synthesize(text, voice, format) passes the raw tool args; config defaults are applied internally in synthesize_elevenlabs (:192, format_override.unwrap_or(self.config.elevenlabs.output_format.as_str())) and synthesize_openai (:116). Both paths are correct and consistent.

The output_format → TtsResult.format conversion in synthesize_elevenlabs (split('_').next().unwrap_or("opus")) correctly extracts "opus" from "opus_48000_32" and "mp3" from "mp3_44100_128" — matching the approach already used in the media driver's parse_output_format.

One issue to address before merge:

The config_default_voice/config_default_format block only activates when resolved_provider is Some("elevenlabs") or Some("openai"). When resolved_provider is None (no provider arg from LLM, no tts.provider in config — auto-detection via detect_for_capability), the block returns (None, None) and the media driver's own hardcoded fallbacks apply, ignoring [tts.elevenlabs] config. This is a narrower version of the original bug: a bare text_to_speech(text=...) call where the provider is auto-detected (not explicitly configured) still ignores config. Given that the PR's description scopes the fix to the configured-provider case and the PR summary table is accurate, this is a documented limitation rather than a regression — but it should be called out explicitly in either a comment or a follow-up issue so it isn't rediscovered. Please add a // TODO: auto-detected provider path does not apply config defaults comment at media.rs:568 (the _ => (None, None) arm), or open a follow-up issue and reference it.

Tests: The three new unit tests in tts.rs correctly pin the unwrap_or resolution chain for both providers. They test the logic directly rather than through a network call, which is appropriate. The detectAudioMime JS tests in index.test.js are thorough and cover the magic-byte edge cases.

#[serde(default)] on TtsElevenLabsConfig is present at the struct level (:1284), so existing configs without output_format will default to "opus_48000_32". This is a behavior change for existing ElevenLabs users who previously got "mp3_44100_128" from the driver's hardcoded fallback — the librefang.toml.example update documents it, but a CHANGELOG entry under [Unreleased] for this user-visible default change would be appropriate.

After rebase + the _ => (None, None) comment + CHANGELOG entry: approve.

Reviewed against main. The core fix (chaining [tts.<provider>] config defaults into the MediaDriverCache path of tool_text_to_speech) is correct and well-targeted — the elevenlabs/openai media drivers genuinely do unwrap_or("alloy") / unwrap_or("mp3_44100_128") (crates/librefang-runtime-media/src/openai.rs:180-181, elevenlabs.rs:112-115), so the (config_default_voice, config_default_format) injection in crates/librefang-runtime/src/tool_runner/media.rs:558-578 is the right place to land it. However:

Blocking

1. Clippy fails with 11 errors on --all-targets — CI gate cargo clippy --workspace --all-targets -- -D warnings will reject. The new tests in crates/librefang-runtime/src/tts.rs:398-505 all hit clippy::unnecessary_literal_unwrap because they call unwrap_or on literal Some("foo") / None. Rewrite the assertions to either bind through a real Option<&str> produced by code, or just assert_eq! against the constants directly (the test body already mirrors the resolution logic verbatim, so the indirection adds nothing).

2. Scope: this PR duplicates ~100% of #5283. gh pr diff 5283 and gh pr diff 5284 are byte-identical in crates/librefang-types/src/config/types.rs, the synthesize_elevenlabs signature change, the URL format-string change, the librefang.toml.example block, the xtask/baselines/config.sha256 bump, the elevenlabs 3-tier tests, AND the whatsapp-gateway detectAudioMime + index.test.js cases. The PR body says "stacked on #5283" but the branch is opened off main, not off pr/audio-mime-fix, so the diff carries both payloads. Per CLAUDE.md "One PR ↔ one issue" — please either (a) rebase this branch onto pr/audio-mime-fix so only the media.rs delta + the new openai test remain, or (b) wait for #5283 to merge and rebase onto updated main. Right now reviewing the two PRs separately is impossible.

Should fix

3. No integration / unit test for the media.rs resolution chain itself (tool_runner/media.rs:558-578). The new tests in tts.rs exercise the TtsEngine fallback path that already had internal fallbacks — they do NOT cover the new (config_default_voice, config_default_format) branch that's the actual subject of this PR. A targeted test under crates/librefang-runtime/src/tool_runner/tests/ (or against start_test_server* in librefang-api) that drives tool_text_to_speech with no voice / format args under a custom [tts.elevenlabs] and asserts the resolved MediaTtsRequest carries the config values would close this gap. CLAUDE.md mandates a #[tokio::test] for any route/wiring change — this is wiring.

Nits

4. crates/librefang-runtime/src/tts.rs:404 and again at :506 reference "houko" / a reviewer handle in test doc-comments. Strip personal names from regression-test rationale; describe the bug instead.

5. The comment block at crates/librefang-runtime/src/tool_runner/media.rs:553-557 is correct but quite long for a fallback note. Two lines about "google_tts handled in the branch above; do not duplicate" would suffice.

Please rebase onto main once #5283 lands (CONFLICTING currently — merge state DIRTY), fix the clippy errors, and add the media.rs resolution test. Happy to re-review.