Rank exact plugin identities across mention sources - #2203
Open
brsbl wants to merge 3 commits into
Open
Conversation
brsbl
force-pushed
the
bb/mention-relevance-core-thr_94xb8a4nk2-v3
branch
from
August 21, 2026 22:37
1e6fe7c to
f1f39af
Compare
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
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.
What was wrong
The composer merged mention sources in fixed source order and ranked plugin rows only by their display title. That let weaker built-in matches outrank exact plugin matches, and it lost installed/catalog plugin identity when a provider used a friendlier visible title. The host also had no bounded, compatibility-safe way for a provider to expose identity aliases without supplying policy-bearing numeric ranks.
What changed
@bb/client-corenow owns one stable cross-source policy on desktop and mobile: exact visible-title or identity-alias matches, then prefix matches, then remaining results. Existing source order remains the tie-breaker, and each rendered provider section remains contiguous.The plugin SDK adds optional experimental
PluginMentionItem.experimental_searchAliases. The server validates at most eight non-empty aliases of at most 256 UTF-8 bytes each, normalizes omission to an empty internal list, and never accepts a provider-supplied numeric rank. Desktop and mobile preserve the aliases through route decoding and client mapping, while treating a missing wire field as an empty list for backward compatibility. Exact plugin IDs can therefore beat weaker built-in matches even when the visible plugin title differs.This is additive only: there are no removals or meaning changes, no SDK/version/engine-floor change, and no host-daemon protocol change. The experimental API is recorded in
docs/api_to_audit.mdand the plugin-authoring skill.How you verified
origin/main8a2150f448c263b51e0e3ce7e229c72e49c0d59d; the cumulative stable patch ID is unchanged. Every required GitHub CI job passed at exact headf1f39af8d30848e875ca50286f666b0ff35e2c68.origin/mainand final-bottom desktop dev apps used the same fictional project, installed-plugin fixture, route/state, and persisted 1280×900 native window bounds. Five repeated query cycles, four viewport captures, and transition widths 389/390/391, 767/768/769, 1023/1024/1025, and 1919/1920/1921 all passed with no horizontal overflow. Full immutable evidence manifest.Before — fixed source order puts the weaker project match first
After — the exact installed-plugin identity is first
Fixes: no issue; this is the host-policy foundation for the
@Pluginreference stack.BB-Thread-ID: thr_94xb8a4nk2