fix(jlcpcb): match search_jlcpcb_parts queries word by word

[drakeo338]

Summary

Issue: #432

Closes #432

search_jlcpcb_parts bound the whole query as one LIKE '%query%' phrase against only Description or MFR_Part, so a query matched only when its words appeared in that exact order and spelling ("1x7 header pin" found nothing for "Pin Header 1x7"). The query is now split on whitespace and a part must contain every word, in any order, in its LCSC number, MPN, package, manufacturer or description, case-insensitive, with % and _ treated literally. Matching more fields can return more rows than before for the same query.

Approach

See above.

Architectural fit

Extends the existing JLCPCB search in place; no new module or workaround.

Branch and dependencies

Base branch: main. No dependencies.

Compatibility and safety

Additive only: same tool name, parameters and existing result fields. The response gains tokens and search_fields; results are now ordered by LCSC.

Validation

Changed tool behavior

Behavior	Contract and evidence for this change
Accepted inputs and declared defaults	Multi-word queries match word by word; a single word behaves as before. Tests cover these, including through served tools/call.
Invalid/unsupported inputs and structured errors	N/A, unchanged.
Target, data source and prerequisite state	Local JLCPCB cache, unchanged.
Response and result order	Adds tokens (from the tokenizer that builds the SQL) and search_fields, on fresh and cached responses. ORDER BY LCSC makes each LIMIT page deterministic; both tested.
Observed changes and preserved unrelated objects	N/A, read-only.
Failure before/after mutation, including applied work	N/A, read-only.
Recovery from partial/uncertain results without repeating applied work	N/A, read-only.

Run on the committed head (with PROTOC set, as the sandbox has no system protoc); all passed:

• cargo fmt --all -- --check
• cargo test --workspace --locked --lib --tests (what CI runs) (0 failed)
• cargo test --workspace --locked --doc (0 failed)
• cargo clippy --workspace --locked --all-targets -- -D warnings
• Hosted viewer, plugin, and packaging checks passed; optional real-KiCad design-loop E2E was skipped for this read-only SQLite change.

Review checklist

• The diff is focused and contains no generated output, personal data, or unrelated cleanup.
• The branch includes current upstream/main, has no merge conflicts, and all ten required CI checks passed on exact head 691ce4728b183228375bd9201c8feee9630447ea.
• The branch was based on latest upstream/main, not a release tag (unless this is an approved backport).
• The PR shows only its unique commits and diff; dependencies and series position are explicit.
• No unresolved review threads; the refreshed patch has an identical stable patch ID to the substantive review and received a focused exact-head refresh review.
• New names follow docs/NAMING_CONVENTIONS.md; public renames include compatibility handling. (No new public names.)
• New behavior and failure paths have regression coverage.
• File mutations are atomic and preserve unrelated content. (N/A, none.)
• IPC mutations verify the requested board; atomic/partial behavior and safe recovery are explicit under the reliability contract. (N/A, none.)
• If tools were added/removed: counts and docs updated per CONTRIBUTING.md (registry tool_count, tool-directory.md, DEV.md stats, README count). (N/A, none added or removed.)

Maintainer merge state

• The PR has exactly one current status:* workflow label.
• status:ready-to-merge applies to this exact head SHA.
• All required checks and review conversations satisfy the main ruleset.
• Auto-merge uses a merge commit, or an already-green PR will be merged with gh pr merge N --merge.
• fix(jlcpcb): match search_jlcpcb_parts queries word by word #726 carries Closes #432; there is no dependent successor PR for this issue.

🤖 Generated with Claude Code

Maintainer refresh: the one unique commit was rebased from 45f84f6 onto dfecfa8 as 691ce47, with identical stable patch ID. All ten required checks passed on that exact head. GitHub reports mergeable clean. The contributor remains the claimant. Merge awaits the user's separate exact-head approval.

[neusse]

Please clarify whether you intend to continue this PR. Your comment on #432 says you are releasing the issue, but this PR opened afterward and remains active. If continuing, bring its unique commit onto current main, confirm the regression cases from #432 (reordered terms, tokens across fields, literal percent/underscore, absent token, stock/basic/category/limit/order preservation), and ask for the first-time fork CI run to be approved. No checks ran on this head: the CI workflow is action_required, not green. If you are stepping away, please close the PR so #432 remains clearly available to another contributor. This is the author-action slot; no merge is queued yet.

[drakeo338]

Yes, I'm continuing; the release comment on #432 was premature, sorry for the confusion. Rebased onto current main as one commit (785b14b). Tests in jlcpcb_cache_tests: reordered terms (..._matches_every_token_in_any_order), tokens across fields (..._tokens_may_span_columns), literal %/_ (..._like_metacharacters_are_literal), absent token (..._absent_token_returns_no_row), stock/basic/category/limit (..._preserves_stock_basic_category_and_limit_filters). The search query has no ORDER BY before or after. Could you approve the first-time fork CI run?

[neusse]

Reviewed exact head 785b14b against current main. The token-AND predicate, bound values and literal LIKE escaping address the reported search failure; the new direct tests cover reordered/cross-field terms, absent terms, metacharacters and existing filters. I approved the first-time fork CI run, which is now queued. Before this enters the merge slot, please finish two items from the #432 maintainer contract: (1) expose the normalized tokens and searched fields as additive response evidence derived from the actual tokenizer, including on a cache hit, and cover that through served tools/call; (2) make LIMIT results deterministic with an explicit stable ORDER BY (for example LCSC) and test the first page, or explain a compatibility reason not to. Then update the PR behavior table for the response/order effects and rerun checks on the new head. No extra KiCad GUI evidence is needed for this read-only SQLite change. Next actor: author.

[drakeo338]

Both done on 45f84f6: tokens (from the single jlcpcb_search_tokens() tokenizer) and search_fields are in fresh and cached responses, covered through served tools/call on a miss and a cache hit; the query now ends ORDER BY LCSC LIMIT n, with a first-page test. PR table updated; fmt, tests, doc tests and clippy pass.

[neusse]

Reviewed exact head 45f84f64d8696801f3689e76a176ae4fd4d88cd6 against current upstream/main cef99f09d79a1c09d0ad4b6705baf57f6710f9d4.

Spec: The updated diff addresses the outstanding #432 items: AND matching across the documented fields, literal %/_ escaping, additive tokens and search_fields on fresh and cached responses, stable ORDER BY LCSC, and first-page coverage. Served tools/call tests exercise both cache miss and hit. Existing filters remain in place. No code findings on this head.

Standards: The SQL values are bound; the public contract and behavior table are updated; the new tests exercise dispatch rather than only a private handler. The existing row-error filter_map(Result::ok) is unchanged from the base and is not a new suppression in this patch.

Base is current and clean. The exact-head CI run is currently action_required, so required checks have not passed yet. Next actor: maintainer to authorize this exact fork CI run, then CI. Not merge-ready until all ten required checks pass.

[neusse]

Update on exact head 45f84f6: all ten required checks now pass, the base is current, and GitHub reports no unresolved review threads. However, GitHub still reports mergeable=true with mergeable_state=unstable. I changed the workflow label back from status:ready-to-merge to status:waiting-on-review; please hold merge until the merge-state discrepancy is understood or GitHub recalculates it. Next actor: maintainer.

[neusse]

Please rebase the unique #432 change onto current upstream/main (af1c1855ab7b32faa236666fdb515fee795ff365), push the refreshed head, and rerun the required checks. The PR head 45f84f64d8696801f3689e76a176ae4fd4d88cd6 is now reported BEHIND; its green checks and maintainer review predate the latest main merge, so they do not establish readiness against the current base. Keep this to the unique search change and preserve Closes #432. Next actor: author; no further review is needed until the refreshed head is available.

[neusse]

Focused refresh review of head 691ce4728b183228375bd9201c8feee9630447ea on current main dfecfa88998c26fe4292c8c7b45ba38c591b42b7: the one-commit unique patch has the identical stable patch ID (ec9dcbcd8a98f74bf7748b04c2bcdc64e8e35ccd) as the substantive review of 45f84f64d8696801f3689e76a176ae4fd4d88cd6. The changed files remain integration.rs and tool-directory.md; the diff is 301 additions and 20 deletions, with no semantic change from the reviewed search fix. #432 is still the closing issue, and there are no unresolved review threads. The contributor's claim remains intact. Required CI on this new exact head has not reported results yet, so this is a completed focused review, not merge readiness.