Pr test - #2
Open
hfranklin wants to merge 1694 commits into
Open
Conversation
advancing test migration to polly
… updated snapshots
hfranklin
force-pushed
the
trivir
branch
5 times, most recently
from
June 26, 2023 02:10
b9b1cad to
7e9b189
Compare
hfranklin
force-pushed
the
trivir
branch
3 times, most recently
from
August 22, 2023 04:50
3f4837c to
e3791cc
Compare
hfranklin
force-pushed
the
trivir
branch
2 times, most recently
from
November 3, 2023 04:18
c794132 to
9fd7d58
Compare
phalestrivir
force-pushed
the
trivir
branch
3 times, most recently
from
May 12, 2025 19:05
94375fc to
ebf6df8
Compare
hfranklin
force-pushed
the
trivir
branch
3 times, most recently
from
September 15, 2025 21:37
0d8f73f to
dbadbe9
Compare
|
Can this PR be deleted? These are the files changed after rebasing on main; while letting main files win on merging conflicts: trivir@trivir-frodo-dev-vm:~/work/frodo-lib$ git diff main..HEAD --name-status |
phalestrivir
pushed a commit
that referenced
this pull request
Aug 18, 2026
…ility feat(mcp): semantic skill aliases, config-entity hydration, and executeRecommended auto-dispatch
phalestrivir
pushed a commit
that referenced
this pull request
Aug 18, 2026
…metric caller-identity semantic aliases Two changes, found together while investigating why session.getSessionInfo still couldn't be found despite the notes-weight and operationType-gate fixes earlier today. Both of those genuinely worked — verified with a temporary scoring debug probe that info.getInfo/session.getSessionInfo scored 32, comfortably ahead of idm.managed.resolveIdentity's 18, for "authenticated identity info" — yet the real ranked output still buried them behind ~19 idm.managed.* skills. The scoring fixes were never the problem; something after scoring was overriding them entirely. Found it: findSkills' sort checked routing tier (getRoutingRank(preferred/compatible/unknown/incompatible)) *before* relevance, with relevance only breaking ties within the same tier. idm.managed.* skills are "preferred" on cloud/forgeops (their own preferredDeploymentTypes says so); session.*/info.* skills are merely "compatible" (generic, not deployment-specific). Since JS's || only falls through on an exact zero, any routing-rank difference won outright — no relevance score, however dominant, could ever move a "compatible" result above so much as one "preferred" result. This mechanism exists to pick between genuine alternative implementations of the same operation across deployment types (classic user.countUsers vs cloud idm.managed.countManagedObjects) — a sound idea — but applying it as an unconditional global pre-sort key meant completely unrelated domains got silently tier-locked against each other on every query. Converted it from a hard pre-sort tier into a modest additive bonus folded into relevance itself (+6 for preferred, +0 for compatible/ unknown) — preserves the original intent (break near-ties toward the deployment-native answer) without letting it categorically override a much more relevant result from an unrelated domain. Deliberately no penalty for "incompatible": those are already excluded by default and only reach scoring at all when a caller explicitly asks to see them for diagnostics (includeIncompatible), where a large enough penalty would drop them below the relevance>0 inclusion filter and make them vanish from that diagnostic view entirely rather than just sort last — confirmed by a real test failure when this was first tried with a -100 penalty, now fixed by omitting it and relying on the retained secondary getRoutingRank tiebreak instead. routingRank is kept as that secondary tiebreak (after relevance, before id) for genuine ties, matching the mechanism's original intent. Separately: added semanticAliases to info.getInfo and session.getSessionInfo — 'who am i', 'authenticated identity', 'my identity', 'current session', 'current identity'. "identity" is overloaded between two meanings — a directory record (idm.managed.*, ~10 skills sharing that bonus) vs the caller's own authenticated session (these 2 skills) — and without a symmetric signal for the second meaning, the first always won on sheer numbers regardless of which one a query actually intended. This uses the existing semanticAliases mechanism (already weighted at 10, already used elsewhere in CapabilityMetadata.ts for exactly this kind of otherwise-unfindable-by-literal-fields concept) rather than inventing something new. Verified live against the real packed binary (a real MCP SDK client, not a hand-rolled harness) for both queries that were unfindable before either fix: info.getInfo and session.getSessionInfo now rank #1 and #2 of 65 and 602 real candidates respectively, for both "authenticated identity info" and "who am i current session user". 1 new regression test, confirmed to genuinely fail without the fix (not by coincidental tie-break order) by temporarily reverting it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.