fix(fff-mcp): omit git:clean from find_files output

[gustav-fff]

Closes #844

Root cause

format_git_status_opt(None) returns Some("clean") (crates/fff-core/src/git.rs:142-144), so file_suffix() (crates/fff-mcp/src/output.rs:23) materialized the default git state as git:clean on every find_files result line (crates/fff-mcp/src/server.rs:537). pi-fff already suppresses it (packages/pi-fff/src/index.ts:160).

Fix

One filter in the MCP presentation layer only. Core keeps the full status, so git:modified / git:untracked query constraints are unaffected. Dirty and staged states still render.

format_git_status_opt(git_status).filter(|status| *status != "clean"),

Steps to reproduce

cargo build --release -p fff-mcp

# fixture: 8 files, one modified, one staged, one untracked
rm -rf /tmp/fff-844 && mkdir -p /tmp/fff-844/src && cd /tmp/fff-844
git init -q . && git config user.email b@b && git config user.name b
for n in a b c d e f g h; do printf 'export const %s = 1\n' $n > src/svc_$n.ts; done
git add -A && git commit -qm init
printf 'export const a = 2\n' > src/svc_a.ts
printf 'export const b = 3\n' > src/svc_b.ts && git add src/svc_b.ts
printf 'export const n = 1\n' > src/svc_new.ts

# then call find_files(query="svc") over stdio against this dir

Expected (this PR) vs actual on pre-fix main:

  expected                         actual (main)
  src/svc_a.ts git:modified        src/svc_a.ts git:modified
  src/svc_b.ts git:staged_modified src/svc_b.ts git:staged_modified
  src/svc_new.ts git:untracked     src/svc_new.ts git:untracked
  src/svc_d.ts                     src/svc_d.ts git:clean
  src/svc_e.ts                     src/svc_e.ts git:clean
  ...                              ...

How verified

• cargo test -p fff-mcp green, plus 2 new unit tests in output.rs pinning that clean/CURRENT/empty/None produce no tag while dirty + staged states and frecency words survive.
• cargo clippy -p fff-mcp clean.
• Live stdio probe of the built binary on the fixture above — output matches the table.
• scripts/benchmark-claude.sh A/B, baseline binary vs this one, fff arm, 11 concepts each: task completion 10/11 in both arms, 0 errors in both. Concept 2 fails in both (its target path no longer exists in the corpus — stale ground truth, unrelated). Cost/turn deltas are pure noise (turn-count variance swamps the change): $1.8214 baseline vs $1.7151 patched.
• Context saved where it applies: on a 20-result find_files page over chromium, git:clean was 200 of ~1600 chars, i.e. -12.4% of payload. The eval suite itself only calls find_files 3-6 times across 11 concepts (grep dominates: 21 calls), so suite-level byte savings are small — the win shows up in find_files-heavy sessions.

Automated triage via Gustav. Honk-Honk 🪿

Summary by CodeRabbit

• Bug Fixes
  • Clean files no longer display an unnecessary Git status annotation.
  • Git status indicators continue to appear for modified, untracked, and staged files.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b6461e79-ba9c-4d0c-95d5-4d73cd81ee18

📥 Commits

Reviewing files that changed from the base of the PR and between c9d1302 and 3e3596a.

📒 Files selected for processing (1)

• crates/fff-mcp/src/output.rs

Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

fff-mcp no longer displays git:clean for clean files. Tests confirm that dirty Git states retain their annotations.

Changes

MCP Git annotations

Layer / File(s)	Summary
Filter clean status and validate output crates/fff-mcp/src/output.rs	file_suffix omits the clean Git status. Tests verify that clean states produce no Git suffix and dirty states retain their specific suffixes.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Merge Risk: ⚪ Minimal · up to 3e359

This change removes redundant git:clean text from file-search results while preserving meaningful Git status labels, reducing output noise and payload size with no actionable merge-blocking risk remaining.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 60.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 1 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly states the main change: omit git:clean from fff-mcp find_files output.
Linked Issues check	✅ Passed	The change satisfies issue #844. It suppresses clean Git annotations in the MCP presentation layer, preserves non-clean statuses, and adds coverage for clean, empty, dirty, and staged states. Core Git…
Out of Scope Changes check	✅ Passed	The changes are limited to file suffix formatting and related unit tests. No unrelated code changes are identified.

Full details: Linked Issues check

Explanation

The change satisfies issue #844. It suppresses clean Git annotations in the MCP presentation layer, preserves non-clean statuses, and adds coverage for clean, empty, dirty, and staged states. Core Git status handling remains unchanged.

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch triage-bot/issue-844

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[dmtrKovalenko]

@gustav-fff whats wrong with the CI?

[gustav-fff]

[triage-bot] DIRECTED: Not this PR. Exactly one job failed — Python bindings (macos-latest) — on a flaky fff-python grep pagination test.

tests/test_finder.py::test_grep_cursor_paginates_by_file
>           assert second.total_matched >= 1
E           assert 0 >= 1
E            +  where 0 = GrepResult(items=0, total_matched=0, next_file_offset=0).total_matched
1 failed, 27 passed in 12.26s

Rerun of the identical SHA 3e3596a is green: https://github.com/dmtrKovalenko/fff/actions/runs/33409845165. Everything else was green on the first pass, including python on ubuntu/windows. Diff touches only crates/fff-mcp/src/output.rs; fff-python does not depend on fff-mcp.

Mechanism, hypothesis — 15/15 local passes on macOS, so it needs runner load: the cursor is a plain numeric offset into the prefiltered candidate list, which is re-sorted on every call (crates/fff-core/src/grep/prefilter.rs:171) then sliced with split_off (:178), and files without a bigram entry are appended to the tail (:134-145). wait_for_scan_blocking() waits for the file scan, not for content indexing, so page 1's offset can be computed against a different ordering than page 2 sees and page 2 skips the only other file matching def. Pagination is ordering-dependent by construction — separate issue if you want it fixed.

Honk-Honk 🪿