tui.go:1081

• openViewer parses r.LineRange with fmt.Sscanf but ignores the return values and always does startLine--. If parsing fails, startLine remains 0 and becomes -1, which is an unexpected sentinel and can leak into viewStartLine. Consider only decrementing when the scan succeeded and startLine > 0 (or defaulting to 0 when parsing fails).

	// Parse start line from LineRange (e.g. "42-58")
	startLine := 0
	if r.LineRange != "" {
		fmt.Sscanf(r.LineRange, "%d", &startLine)
		startLine-- // convert to 0-based
	}

tui.go:1067

• openViewer reads the entire file with os.ReadFile, ignoring the existing MaxReadSizeBytes limit used by the search pipeline. Opening a very large matched file could cause a big memory spike or stall the TUI. Consider reusing the same size-limited read helper (or adding a viewer-specific cap / streaming approach).

func (m *model) openViewer(r searchResult) error {
	data, err := os.ReadFile(r.Location)
	if err != nil {
		return err
	}

	lines := strings.Split(string(data), "\n")

README.md:75

• This README section claims the structural ranker "uses declaration detection to boost matches that appear on declaration lines". In the current changes, declaration detection is used for filtering (--only-declarations/--only-usages) in the search pipeline, but there's no ranker-side boost implemented. Please adjust the documentation to match the behavior (or implement the described boosting).

The structural ranker also uses declaration detection to boost matches that appear on declaration lines 
(e.g. `func`, `class`, `def`) over plain usages. This currently works for the following languages:

Go, Python, JavaScript, TypeScript, TSX, Rust, Java, C, C++, C#, Ruby, PHP, Kotlin, Swift

For unsupported languages, all matches are treated as usages and ranked by text relevance only. 
Structural filtering (`--only-code`, `--only-comments`, `--only-strings`) still works for any language recognised 
by [scc](https://github.com/boyter/scc).

http.go:241

• In the codeFilter switch, the only-declarations / only-usages cases (and the default case) don't clear the other mutually-exclusive filter flags. Because searchCfg is copied from the server config, a request can end up with multiple filters enabled (e.g. server started with --only-code and request sets cf=only-declarations), which also affects HasContentFilter() and the search cache key prefix. Consider resetting all Only* filter booleans to false before applying the requested filter (or explicitly clearing the others in every case).

			switch codeFilter {
			case "only-code":
				searchCfg.OnlyCode = true
				searchCfg.OnlyComments = false
				searchCfg.OnlyStrings = false
			case "only-comments":
				searchCfg.OnlyCode = false
				searchCfg.OnlyComments = true
				searchCfg.OnlyStrings = false
			case "only-strings":
				searchCfg.OnlyCode = false
				searchCfg.OnlyComments = false
				searchCfg.OnlyStrings = true
			case "only-declarations":
				searchCfg.OnlyDeclarations = true
			case "only-usages":
				searchCfg.OnlyUsages = true
			default:
				searchCfg.OnlyCode = false
				searchCfg.OnlyComments = false
				searchCfg.OnlyStrings = false
			}

mcp.go:327

• The MCP code_filter argument handler sets a specific Only* flag but never clears the other mutually-exclusive filter flags inherited from cfg. This can lead to multiple filters being active at once (despite the docs stating they're mutually exclusive), and can also skew cache keys and ranking auto-selection via HasContentFilter(). Reset all Only* flags to false before setting the selected one.

		if v, ok := request.GetArguments()["code_filter"]; ok {
			if s, ok := v.(string); ok && s != "" {
				switch s {
				case "only-code":
					searchCfg.OnlyCode = true
				case "only-comments":
					searchCfg.OnlyComments = true
				case "only-strings":
					searchCfg.OnlyStrings = true
				case "only-declarations":
					searchCfg.OnlyDeclarations = true
				case "only-usages":
					searchCfg.OnlyUsages = true
				}
				if searchCfg.HasContentFilter() {
					searchCfg.Ranker = "structural"
				}
			}

tui.go:450

• openViewer returns an error, but the caller ignores it. If the file can't be read (deleted, permission error, etc.), the UI will silently do nothing. Consider capturing the error and surfacing it in the TUI (e.g., via a status line message) or at least logging it.

		case tea.KeyF5, tea.KeyCtrlO, tea.KeyCtrlP:
			if len(m.results) > 0 && m.selectedIndex < len(m.results) {
				m.openViewer(m.results[m.selectedIndex])
			}
			return m, nil