[Suggestion]: omit git:clean annotations from fff-mcp output

[uknfire]

Which fff frontend(s)?

MCP server (fff-mcp)

What problem are you trying to solve?

Summary

fff-mcp currently appends git:clean to clean files returned by find_files, for example:

src/a.ts git:clean
src/b.ts git:clean
src/c.ts git:modified

I think clean files should have no Git annotation, while dirty states such as modified, untracked, deleted, and staged states should continue to be shown.

Why this matters

clean is the overwhelmingly common/default state in a repository. Repeating it for nearly every result adds visual noise and consumes unnecessary LLM context without adding much information.

The absence of a Git annotation can already imply the default state, similar to how git status --short only surfaces files that differ from the default state.

For an MCP tool used by coding agents, the higher-value information is the exceptional/actionable state:

src/a.ts
src/b.ts
src/c.ts git:modified
src/new.ts git:untracked

This preserves the useful Git signal while making the output more compact and easier for models to scan.

Existing inconsistency in this repository

pi-fff already follows this behavior in fffFileAnnotation(): it explicitly suppresses clean, unknown, and empty Git states, and only surfaces actionable Git state.

By contrast, fff-mcp uses format_git_status_opt() inside file_suffix(). Since format_git_status_opt(None) returns Some("clean"), file_suffix() ends up materializing the default state as git:clean for every clean file.

There is also already a useful separation in the core implementation: during the initial scan, git_status: None effectively means clean, so clean is represented internally as the absence of an exceptional state. The MCP presentation layer could preserve that idea instead of turning it back into a visible annotation.

Expected behavior

Keep full Git status information in the core/query layer so constraints such as git:modified continue to work, but suppress clean in the MCP presentation layer.

Conceptually, fff-mcp could treat the formatted Git status as absent when it is clean:

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

Then only non-default Git states would be appended to file results.

I think this would be better as the default MCP behavior rather than a new configuration option, because clean is the default state and hiding it loses no actionable information. A verbose/debug mode could still expose the complete status if needed.

Proposed solution

No response

[gustav-fff]

[triage-bot] NEEDS EVALUATION: no PR.

Technical part of the report is correct, verified on origin/main:

• crates/fff-core/src/git.rs:142-144 — format_git_status_opt(None) returns Some("clean").
• crates/fff-mcp/src/output.rs:23-33 — file_suffix() therefore emits git:clean for every clean file.
• crates/fff-mcp/src/server.rs:532-537 — that suffix is appended to every find_files result line.
• packages/pi-fff/src/index.ts:160 — pi-fff does suppress clean/unknown/empty. Inconsistency is real.

The one-line .filter(|s| *s != "clean") is trivial to write. That is not the problem. The claim being made is that dropping the token makes models scan output better and saves context worth having. That is a model-behaviour claim, and this repo has no eval harness to measure it — see the existing warning at packages/pi-fff/src/index.ts:171 (DO NOT ATTEMPT TO RESORT OUTPUT HERE IT ONLY CONFUSES MODELS). Output shape here is load-bearing, not cosmetic. Absence-means-clean also silently collides with None from a non-repo path, where nothing is known rather than known-clean.

So: needs an evaluation layer before landing. Cannot be fixed blind right now. Leaving for @dmtrKovalenko to decide, since flipping default MCP output is his call, not a bot's.

Honk-Honk 🪿

[dmtrKovalenko]

That makes sense @gustav-fff go try it out and execute our eval suite to see if it affects task completion rate

[gustav-fff]

[triage-bot] DIRECTED: eval ran, no effect on task completion. PR #845.

Suite: scripts/benchmark-claude.sh, fff arm only (native arm irrelevant here), 11 concepts, baseline binary vs patched binary, isolated frecency DB per arm. 22 runs, $3.54.

 # concept                    found B/P turns B/P  in-tok B  in-tok P     $ B     $ P clean B/P
 1 fuzzy-function-search            T/T       4/4   101,657    98,752  0.2340  0.1175       0/0
 2 api-endpoint-discovery           F/F       4/5    99,536   125,017  0.1323  0.1473       0/0
 3 cross-service-config             T/T       3/7    72,162   149,827  0.0953  0.1585       0/0
 4 test-file-discovery              T/T       5/4   100,651    99,824  0.1253  0.1210      10/0
 5 error-type-definition            T/T       5/5   127,936   106,824  0.1490  0.1665       0/0
 6 database-model-search            T/T       4/4    97,997    97,343  0.1125  0.1092       0/0
 7 auth-flow-tracing                T/T      12/9   167,735   198,355  0.2513  0.2392       0/0
 8 todo-tech-debt                   T/T       6/5   149,790    98,817  0.1614  0.1294       0/0
 9 cross-language-pattern           T/T       6/6   126,599   125,844  0.1546  0.1496       0/0
10 broad-pattern-search             T/T       8/11  226,865   231,801  0.3019  0.2702       0/0
11 file-by-name-lookup              T/T       4/4    72,342    72,252  0.1038  0.1068      30/0

completion: baseline 10/11, patched 10/11. errors 0/0.
cost: baseline $1.8214, patched $1.7151. turns: 61 vs 64.

Completion rate unchanged. Concept 2 fails in both arms — its target user_files_service/graphql/src/mutation.rs does not exist in the checkout anymore (stale ground truth in the harness, scripts/benchmark-claude.sh:87). Cost/turn deltas are noise: concept 3 took 3 vs 7 turns, concept 10 8 vs 11, that variance is orders of magnitude bigger than 200 chars of removed tags.

The suite is a weak instrument for this specific change: across 11 concepts the model called find_files 3 times (baseline) / 6 (patched) versus 21 grep calls, and grep output never carried the tag. Total git:clean tags the model ever saw: 40 baseline, 0 patched. So this eval proves no regression, not a win.

Where the win is measurable — 20-result find_files page over a real 124K-file tree (~/dev/chromium): 200 of 1797 chars were git:clean, -12.4% payload, 20/20 lines tagged. That is the number worth having, not a completion delta.

Harness notes for rerunning: it hardcodes $HOME/dev/lightsource (scripts/benchmark-claude.sh:26) but the checkout is at ~/dev/ls, and it has no way to A/B two binaries — I ran it from two /tmp copies with the path patched and each arm's binary in its own PROJECT_ROOT. Worth making both overridable if you plan more output-shape evals. Corpus verified untouched afterwards (git status --porcelain empty, HEAD still 4c2b22539fc).

Honk-Honk 🪿