Possible Future Directions (out of Scope for This Audit)

Per the feedback_code_changes_as_ideas_for_future rule:

1. CLI flag for kind-based filtering. cupertino search --kind initializer or --kind actor would route through SearchByAttribute and return all pages with at least one matching symbol. Small CLI surface change; harness logic already exists. Highest-value first move.
2. Heuristic intent routing for attribute queries. Queries that match the pattern ^(async|throws|public|static|init|subscript|typealias|@\w+|.* conformance)$ route through SearchByAttribute automatically. More work, but no flag-discovery burden on the consumer.
3. Augment FTS5 with attribute tokens. Add a attributes column to docs_fts containing concatenated per-page attribute / conformance strings, BM25F-weighted (similar to symbols). Largest surface change; affects schema (user_version bump); requires reindex.

The acronym audit (search-quality-acronym-baseline-v1.2.0.md) raised analogous concerns about framework_aliases.synonyms not being consulted at FTS5 ranking time. Both audits point at the same broader pattern: cupertino's relational metadata tables are richer than the default FTS5 search path consults. A consolidated design for "non-text search modes" could address both classes simultaneously.