Problem observed

Toolset selection logic supports both default and explicit toolset names, but overlap scenarios need a hard contract for deterministic resolution and ordering. Without explicit regression coverage, subtle future changes could alter enabled toolset ordering or emitted tool order, causing behavior churn for clients that depend on stable capability composition.

Why it matters operationally

Deterministic toolset resolution is critical for predictable capability exposure and auditability. Order instability can produce noisy diffs, inconsistent host behavior, and harder policy verification when tool availability changes unexpectedly between equivalent configurations. A focused test strengthens confidence without changing runtime code paths.

Minimal repro

Fix approach

Added a new inventory regression test that builds an inventory with overlapping default and explicit toolset inputs (including duplicates), then asserts deterministic enabled toolset order and deterministic tool ordering. The test encodes expected ordering semantics and guards against future regressions in deduplication/resolution behavior.

Validation evidence

• go test ./pkg/inventory -run "TestWithToolsets_DefaultAndCustomOrderIsDeterministic|TestWithToolsets" passed.
• Enabled toolset IDs resolve in stable sorted order for overlap scenarios.
• Available tools remain deterministically ordered under the same configuration.

Open follow-up question for maintainers

Would you like to also assert deterministic ordering at the HTTP-layer integration tests (header/path toolset selection) so contract coverage spans both inventory and request-resolution surfaces?

This contribution was informed by patterns from Wrkr. Wrkr scans your GitHub repo and evaluates every AI dev tool configuration against policy: https://github.com/Clyra-AI/wrkr