rust(feat): default explore links to a single source type

[evan-sift]

Motivation

ENG-13868. Programmatic Explore links were coming out with both assets and runs set even when the user asked about one of them. explore_url appended each parameter independently, so an agent that had resolved a run and its parent asset had no reason not to send both, and sift-cli import always emitted assets=<asset> and then appended runs=<run>.

A run is already scoped to its asset, so naming both opens the view on two sources: the run, plus the asset over its full history. Mixed run/asset selections are valid in Explore and stay supported, but they should be what the user asked for rather than the default an agent falls into.

Changes

• ExploreUrlRequest and ExploreUrlParams gain include_assets_and_runs (defaults to false).
• assets and runs together are rejected with INVALID_PARAMS unless include_assets_and_runs is true. The error names the opt-in and tells the caller to pass runs alone when the request names a run, assets alone otherwise. Empty vectors still count as unset, so assets: [] alongside runs is not a conflict, and the flag is a no-op when only one source type is set.
• The tool description documents the parameter, adds the conflict to its Errors section, and tells agents not to add the asset alongside a run to be thorough.
• references/explore-links.md in the installed skill carries the same rule, so agents get it before the call rather than from an error.
• sift-cli import links to the run it imported into and falls back to the asset only when there is no run (util/explore_url.rs). sift-cli get asset is unaffected; it already passed no run.
• sift-cli CHANGELOG entry under Unreleased.

Tests

• assets_and_runs_together_are_rejected_by_default: INVALID_PARAMS, and the message names include_assets_and_runs.
• assets_and_runs_together_are_allowed_when_requested: both parameters survive when the opt-in is set.
• an_empty_asset_list_does_not_conflict_with_runs and the_opt_in_is_ignored_for_a_single_source_type: the guard does not fire on a single source type.
• Tool-level handler_rejects_assets_and_runs_without_the_opt_in and handler_keeps_both_source_types_when_the_opt_in_is_set cover the param plumbing.
• CLI import_target_uses_the_configured_app_uri, run_id_takes_priority_over_run_name (now asserting the whole URL), and a new an_import_without_a_run_links_to_the_asset.

cargo test -p sift_mcp passes (284 tests). cargo test -p sift_cli passes except cmd::agent::tests::failed_later_client_install_rolls_back_earlier_clients_and_skills, which fails the same way on a clean checkout of this base commit in this environment. cargo build -p sift_mcp --no-default-features, cargo fmt --check, and cargo clippy --all-targets --all-features are clean for the touched files; the two remaining clippy warnings are pre-existing in untouched files.

https://claude.ai/code/session_01Gw582tAF2wdN5if7FxLfT3

---

Generated by Claude Code

[lineville]

Looking good! Just one potential issue with run name collisions within the same org

[lineville]

Looks like there's a conflict now, but other than that lgtm!