Lifted from docs/plans/backlog.md (retired 2026-07-20).
rmcp ≤ 1.7's internally-tagged PromptMessageContent has no Audio variant, so a spec-conformant {"type": "audio"} prompt block fails the whole get_prompt fetch at deserialization, before our capture layer sees it — crate::prompt::PromptContent::Audio is unreachable in practice (prompt.rs stubs to_text as NotImplemented). Upstream fixed it in modelcontextprotocol/rust-sdk#865, after 1.7.
Upgrading makes the arm reachable with no factor-q change needed — prompt::tests::capture_round_trips_losslessly_for_all_variants already covers the owned type. But this is not a plain version bump: rmcp 1.8 broke fq-runtime's resolve on first attempt (see the pin comment in services/fq-dashboard/Cargo.toml), so expect API churn. Current pin: services/fq-runtime/crates/fq-runtime/Cargo.toml (rmcp 1.7).
Lifted from
docs/plans/backlog.md(retired 2026-07-20).rmcp ≤ 1.7's internally-tagged
PromptMessageContenthas noAudiovariant, so a spec-conformant{"type": "audio"}prompt block fails the wholeget_promptfetch at deserialization, before our capture layer sees it —crate::prompt::PromptContent::Audiois unreachable in practice (prompt.rsstubsto_textas NotImplemented). Upstream fixed it in modelcontextprotocol/rust-sdk#865, after 1.7.Upgrading makes the arm reachable with no factor-q change needed —
prompt::tests::capture_round_trips_losslessly_for_all_variantsalready covers the owned type. But this is not a plain version bump: rmcp 1.8 broke fq-runtime's resolve on first attempt (see the pin comment inservices/fq-dashboard/Cargo.toml), so expect API churn. Current pin:services/fq-runtime/crates/fq-runtime/Cargo.toml(rmcp 1.7).