AST semantic search should filter out low-signal symbols (operators, boilerplate)

[mihaelamj]

Problem

The AST semantic tools (search_concurrency, search_property_wrappers, search_conformances) return technically correct but unhelpful results. The signal-to-noise ratio is low because operator overloads and boilerplate symbols dominate the results.

Examples

search_concurrency with pattern: mainactor returns:

• ==(_:_:) from RealityKit (AudioFileGroupResource, AudioFileResource, TextureResource) — all just @MainActor @preconcurrency operator overloads
• ABNewPersonViewController — a deprecated AddressBookUI class

A developer searching for mainactor wants to see how @MainActor is applied to real view models, view controllers, or service classes — not synthesized equality operators.

search_concurrency with pattern: task returns:

• ==(_:_:) on Task<Success, Failure>
• <=(_:_:) on TaskPriority
• <(_:_:) on TaskPriority

All operator definitions, zero useful Task usage patterns.

search_concurrency with pattern: sendable returns only AVAudioRecorderDelegate, AVAssetWriterDelegate, etc. — AV framework delegate protocols. Not the most representative Sendable examples.

search_property_wrappers with @MainActor — same issue, dominated by == operators.

Proposed Solution

Add ranking/filtering heuristics to AST search results:

1. Deprioritize operator overloads — Symbols named ==, !=, <, <=, >, >=, hash(into:) should rank lower than named types and functions
2. Deprioritize synthesized/protocol-requirement symbols — Especially Equatable/Hashable/Comparable conformance operators
3. Prioritize primary type declarations — Actors, classes, structs, and protocols should rank higher than individual member functions
4. Prioritize symbols from commonly-used frameworks — SwiftUI, Foundation, Swift stdlib results should rank above niche frameworks like AddressBookUI or RealityKit operators

Impact

This would make search_concurrency, search_property_wrappers, search_conformances, and search_symbols significantly more useful by surfacing representative, educational examples rather than boilerplate.

Related

• Run AST extraction over stored doc_code_examples, not just page.declaration #176 (AST indexing coverage — addresses sparse results; this issue addresses noisy results)
• Add smart tokenization for CamelCase symbols #77 (Smart tokenization — adjacent search quality improvement)