fix(search): a licence republished as a tag is no longer searchable

[Broccolito]

The finding, measured in the running app

The Browse-extensions modal on merged main, driven against the live 37-entry registry:

query	matches
(empty)	37
PACS	31
pac	31
apache	31
Apache-2.0	32
zzzznope	0

PACS ≡ pac ≡ apache = 31 is the proof: PACS → the matcher's plural→singular fallback → pac → substring of "Apache-2.0" → 31 of 37 entries, none PACS-related (BenchlingAgent, DNAnexusAgent, LatchBioAgent, LabArchivesAgent, OMEROAgent…). Every match displays an Apache-2.0 tag.

Diagnosis — the tag is the live path, verified

PR #242 (Rust) and PR #255 (the TypeScript port) both stopped searching the license field. But the licence value is also published in each entry's tags array, and tags are searched — legitimately; MCP, Imaging, ELN, Registry are what a tag is for. So the field was removed and the same string kept matching through a different field, and search.test.ts's does not search the license, in either catalog kept passing because its fixture entry has no tags.

Confirmed three ways rather than inferred:

1. Data. Exactly 31 of 37 extensions carry an Apache-2.0 tag — the same 31, by id, that the modal returned. 49 of 129 skills carry it too, and a separate apache keyword.
2. Field assembly. MarketplaceCatalog::search_extensions / search_skills (crates/biorouter/src/marketplace.rs) and rankSkills / rankExtensions (ui/desktop/src/components/baam/registry.ts) both omit license and both extend the field list with every tag (and, for skills, every keyword).
3. Fail-before. Neutralising the new predicate reproduces exactly 31 extensions for apache in Rust and fails 4 of the new TS assertions.

One detail worth recording: extCardHtml and buildExtChips in landing/baam.html already filter /^apache/i — for tag-row space and chip noise, not for search. That near-miss is part of why this looked handled.

The fix

One rule, in all three copies: when assembling an entry's searchable text, drop any label that says nothing the entry's own license does not. Compared by words, not by equality.

Equality is not enough, and this is the crux: the tag is Apache-2.0 and the skills keyword is apache. An equality test drops the tag and leaves the keyword matching 49 skills — the same half-fix, one field further over.

• crates/biorouter/src/catalog_search.rs — names_only_the_license, applied by the two field builders in marketplace.rs.
• ui/desktop/src/components/baam/search.ts — namesOnlyTheLicense, applied by labelFields in registry.ts. (Its header says "A change to a rule below is a change to both files"; this is that change.)
• landing/baam.html — the third copy, as searchHaystack.

Measured over all 166 live entries, the rule drops the 129 licence labels and nothing else.

Rejected alternatives

• Drop all tags — loses real search value (MCP, ELN, Imaging, Registry).
• Hard-code "Apache" — every future licence reopens it. (buildExtChips already does this, which is how the near-miss above happened.)
• Disable the plural→singular fallback — it is wanted, and pac/apache match directly anyway, so it would fix nothing.
• Equality with license — the suggested shape, and it is the half-fix described above.

The cost, stated

A licence id built from a topical word (Python-2.0, Ruby, PostgreSQL) on an entry that also tags itself with that word would lose that tag. No entry in the registry is such a case, and an equality test pays a smaller version of the same cost. Documented at both call sites.

Before / after

The two app matchers — identical counts, both sides

query	ext before → after	skill before → after
(empty)	37 → 37	129 → 129
PACS	31 → 1	51 → 7
pac	31 → 1	51 → 7
apache	31 → 0	49 → 0
Apache-2.0	32 → 1	49 → 0
zzzznope	0 → 0	0 → 0
R scripting ggplot visualization	1 → 1	11 → 11
r-scripting	1 → 1	9 → 9
SPOKE knowledge graph	3 → 3	4 → 4
ggplot	0 → 0	2 → 2
heatmap	0 → 0	1 → 1
python	0 → 0	6 → 6

The surviving PACS hits are the substring rule working, not the defect: pac inside PacBio (long-read-sequencing), package (replication-package-audit, skill-creator), workspace (latchbioagent), plus biomedical-imaging-pathology, which really does keyword pacs. Every legitimate query is unchanged, ids included.

The website shelf — the same defect, and worse

data-license is on every card, not only the 31/49 that carry the tag, so the licence matched the whole shelf:

query	ext cards before → after	skill cards before → after
apache	37 → 0	132 → 0
Apache-2.0	37 → 0	132 → 0
pac	37 → 1	132 → 7
MCP	37 → 37	1 → 1
ggplot / heatmap / python	0 → 0	3/1/6 → 3/1/6

Three licence paths there: data-license, the Apache-2.0 chip inside an authored skill card's textContent, and the apache keyword in a skill's data-tags. All three closed; the chip still renders. Registry data is untouched — build-registry.mjs --check and check-consistency.mjs --check both pass.

Parity

Differential harness re-run over 1,192 shared queries × 2 catalogs (both sides fed one generated query file: every registry id, name, organization, tag and keyword, plus description phrases and the QA queries):

• 0 set mismatches, after the change — and 0 before it, so nothing diverged.
• 391 tie-order-only differences, which is the one divergence search.ts's header already documents: "Only a tie can fall differently, because each side breaks ties by its own registry order — the document's here, the id's in Rust."

Tests

Each fails before the fix and passes after.

• crates/biorouter/src/marketplace.rs — a_licence_republished_as_a_label_is_not_searchable_through_it, against the embedded live registry, not a fixture (a fixture without the licence tag cannot fail — that is how this got through). Carries a vacuity guard: it asserts the registry still republishes its licence through all three label paths, and says so loudly if it stops.
• crates/biorouter/src/catalog_search.rs — a_label_naming_only_the_licence_is_recognised_in_either_spelling.
• ui/desktop/src/components/baam/search.test.ts — does not search the license republished as a tag or a keyword; a namesOnlyTheLicense block mirroring the Rust cases; and a block over the bundled registry.fallback.json including "changes nothing else about any query", which compares the real registry against a copy with the licence labels removed from the data, so an over-broad rule (dropping every tag) fails there even though it would satisfy every other assertion.
• landing/scripts/baam-privacy-facet.test.mjs — two Playwright tests driving the real #baam-search input on both shelves, with their own vacuity guards. This file is in the shelf job and in the check job the Pages deploy depends on, so the website gate is consulted before publishing.

Verification run

gate	result
cargo test -p biorouter --lib	3969 passed, 0 failed
cargo test -p biorouter --lib -- catalog_search marketplace	34 passed
vitest src/components/baam/	102 passed (5 files)
node --test landing/scripts/baam-privacy-facet.test.mjs	16 passed
node --test landing/scripts/build-registry.test.mjs	56 passed
node --test landing/scripts/check-docs-privacy.test.mjs	passed
build-registry.mjs --check / check-consistency.mjs --check	both current
cargo fmt --check, tsc --noEmit, eslint, prettier --check	clean

⚠ ./scripts/clippy-lint.sh fails on something this PR does not touch. clippy::too_many_lines on handle_execute_code (crates/biorouter/src/agents/code_execution_extension.rs:1837, 102/100 lines), from PR #246. Verified pre-existing: reverting this PR's two Rust files to origin/main and re-running reproduces the identical failure. Nothing else in the script fails.

🤖 Generated with Claude Code