Fix Serena MCP context, then decide whether to keep Serena at all

Start with ERIC/.mcp.json and compare Serena's claude-code.yml with ide.yml, then run one genuinely refactor-shaped task with Serena and one without. Done means making a keep-or-drop decision; if dropping it, remove the server from .mcp.json, the prefer-serena.py PreToolUse hook, and the Serena guidance section from CLAUDE.md.

Narrowed. The original issue listed six tasks, four of which were phrased as things to
"consider" (modes, memory prompting, decision trees). Those are dropped. What remains is a
five-minute configuration fix, followed by an actual decision about whether Serena earns its
place - which is the question worth answering, and which cannot be answered fairly while the
configuration is wrong.

1. Fix the context (small, do first)

ERIC/.mcp.json currently specifies --context ide-assistant. That context no longer
exists. Serena ships these:

agent  antigravity  chatgpt  claude-code  codex  copilot-cli
desktop-app  ide  jb-ai-assistant  jb-copilot-plugin  junie
oaicompat-agent  vscode

ide-assistant was evidently renamed to ide upstream at some point after this workspace was
configured. Meanwhile claude-code exists and is purpose-built for this client.

Diffing claude-code.yml against ide.yml, switching gains:

• search_for_pattern added to excluded_tools (it duplicates the built-in search).
• A materially different prompt, which explicitly directs the agent to prefer Serena's
  editing tools and warns that built-in edit tools will refuse edits to files that were read
  through Serena. That is a real failure mode, not a stylistic preference.

Change:

"--context", "claude-code",

Note that ENABLE_TOOL_SEARCH=true, suggested in the original issue, is now likely redundant:
Claude Code defers MCP tool schemas itself, so Serena's tool descriptions are not loaded into
every request.

2. Then decide whether to keep Serena

The genuine question, and worth answering deliberately rather than by drift.

The case against, honestly stated. The main historical objection was context cost - every
connected MCP server's tool descriptions riding along in every request. That objection is now
largely obsolete in Claude Code specifically, because tool schemas are deferred. What is left
is a weaker but fair argument: Claude Code's built-in search and editing have improved, and if
symbol-level navigation were essential, it would plausibly be built in.

The case for, measured against this codebase. Excluding vendored and generated code:

The common rule of thumb is that semantic tooling starts paying somewhere above ~20k lines, so
these repos straddle the threshold. But total lines is the wrong measure - individual file size
is what determines whether whole-file reading is wasteful, and the distribution here is
lopsided: api_server.py is 3,051 lines, MockDashboard.tsx 1,437, fs_parser.py 1,276,
consumer.py 1,267.

The workload also matters. Recent work has been greenfield front-end development, where
symbol-level navigation earns little. Upcoming work is the opposite: changes that touch the
prediction weight tables across update.py, initialise_prediction_model_weights.py and
consumer.py at once, and event-contract changes requiring every consumer to be found. Those
are cross-file symbol operations, which is where this class of tool actually pays.

How to decide

Not by another configuration change. Fix the context, then run one genuinely
refactor-shaped task with Serena and one without, and compare. A decision either way is a good
outcome; leaving it configured-but-unused is the only bad one.

If the decision is to drop it, the cleanup is: remove the server from .mcp.json, remove the
prefer-serena.py PreToolUse hook, and remove the Serena guidance section from CLAUDE.md.