README documents a Match/Filter/FuzzyOptions/FuzzyResult API that does not exist in the library

[matt-edmondson]

What's wrong

README.md documents a much larger API surface than the library actually ships. The only public members in FuzzySearch/Fuzzy.cs are:

• Fuzzy.Contains(ReadOnlySpan<char> subject, ReadOnlySpan<char> pattern)
• Fuzzy.Contains(ReadOnlySpan<char> subject, ReadOnlySpan<char> pattern, out int outScore)

But the README's "Matching with Scoring", "Filtering a Collection", "Advanced Options", and "Object Collections" sections, plus the whole "API Reference" table, describe types and members that do not exist anywhere in the source (confirmed via repo-wide code search — these strings appear only in README.md):

• Fuzzy.Match(string text, string pattern, FuzzyOptions options = null) → FuzzyResult
• Fuzzy.Filter(IEnumerable<string> items, string pattern, FuzzyOptions options = null) → IEnumerable<FuzzyItem<string>>
• Fuzzy.Filter<T>(IEnumerable<T> items, string pattern, Func<T, string> selector, FuzzyOptions options = null)
• FuzzyResult class (IsMatch, Score, Indices)
• FuzzyOptions class (CaseSensitive, ScoreThreshold, BonusConsecutiveChars, BonusStartOfWord, PenaltyUnmatched, MaxPatternLength)
• A three-argument Contains(string text, string pattern, bool caseSensitive = false) overload — the real overload takes ReadOnlySpan<char> and has no caseSensitive parameter (matching is always case-insensitive)

Why it matters (concrete failure)

Anyone who copies the README's "Matching with Scoring", "Advanced Options", or "Object Collections" example into a project gets a compile error — Fuzzy.Match, Fuzzy.Filter, FuzzyOptions, and FuzzyResult are unresolved symbols. Only the very first "Basic Matching" example actually compiles against the real library. This is the top-level README shown on NuGet.org and GitHub, so it's the first thing a new consumer tries, and it's broken for every use case except the simplest one.

Suggested fix

Either:

1. Rewrite the README's usage examples and API Reference table to describe only what Fuzzy.Contains actually does (including the real return-by-out-score overload and the fact that matching is always case-insensitive), or
2. If Match/Filter/FuzzyOptions/FuzzyResult are a planned feature, add a clear "planned/not yet implemented" note and move those sections out of the current-usage documentation until they exist.

Given the library today is a single static class with two overloads, (1) is the smaller, lower-risk fix.

Acceptance criteria

• Every code sample in README.md compiles against the current public API of ktsu.FuzzySearch.
• The API Reference table lists only members that exist in FuzzySearch/Fuzzy.cs.

[matt-edmondson]

Triage

Category: Bug (documentation — shipped, user-facing)
Priority: High
Area: README.md

Priority is driven by exposure, not complexity. This README is the NuGet.org landing page and the first thing a new consumer copies from, and every example except "Basic Matching" fails to compile against the shipped library — Fuzzy.Match, Fuzzy.Filter, FuzzyOptions and FuzzyResult do not exist anywhere in the source. The whole API Reference table describes an API that was never implemented. The fix is cheap, so the cost/benefit here is unusually good.

Related: #2 in ktsu-dev/ktsu.dev covers a different flavour of the same theme (project descriptions on the homepage being auto-generated junk) but has a separate root cause and owner — no dependency between them.

Not covered by an open PR.

Suggested next step: take option 1 from the issue (rewrite to describe only Fuzzy.Contains and its out int overload, and state that matching is always case-insensitive). Option 2 only makes sense if Match/Filter are actually planned — if nobody is committed to building them, documenting them as "planned" keeps the same trap open. Worth considering a doc test or snippet-compilation check so the README cannot drift from the public surface again.

---

Generated by Claude Code