fix lint, ready to merge

Real-world validation — we hit this exact cliff

We independently built a _isolate_query() function in our integration after #333 nearly silently killed our cross-domain discovery pipeline. 208 discoveries across 5 domains, and one morning our Orient phase (broad cross-domain sweeps) was returning garbage — similarity scores looked normal (~0.7-0.8) but every result was semantically wrong. It took hours to trace back to system prompt contamination because the scores don't collapse, they just become meaningless (the embedding is coherent, just representing the wrong text).

So: strong +1 on the 減災 philosophy. This is the right framing.

How your approach compares to ours

Our _isolate_query() does roughly the same thing but with different heuristics:

• We detect known system prompt signatures (e.g., "You are", "MEMORY.md", "## ", markdown headers) and strip everything before the last occurrence
• We have a character-ratio heuristic: if the query is >3× longer than the median query length for that session, assume contamination
• We use a newline-based split similar to your Step 3, but we look for the last segment that doesn't match known prompt patterns rather than just taking the tail

Your 4-stage pipeline is more principled than our pattern-matching approach. A few observations:

What works well

1. The passthrough gate (≤200 chars) — this is critical. Our telemetry shows ~85% of queries are under 100 chars. Zero overhead for the common case.

2. Question mark extraction as Step 2 — simple and effective. In our experience, the actual user query almost always ends with ? when it's a retrieval question. Your approach of scanning backwards (reversed(all_segments)) is the right direction since system prompts are prepended.

3. The context parameter in MCP schema — this is the real long-term fix. By giving agents a structured place to put background info, well-behaved agents (Claude 3.5+, GPT-4) will use it, and the query field stays clean. Defense in depth: schema guidance for cooperative agents + sanitizer for uncooperative ones.

4. Sanitizer metadata in response — query_sanitized: true + method is invaluable for debugging. We logged our _isolate_query() interventions and discovered that one of our OODA phases was contaminating 40% of queries. Without the metadata, we'd never have found it.

Edge cases from our experience

1. Multi-line system prompts with ? in them: We've seen system prompts that contain questions like "Are you sure you want to proceed?" or "What tools are available?". Your Step 2 scans backward and takes the last question, which helps, but if the system prompt ends with a rhetorical question after the real query (some agent frameworks append "Is there anything else?"), the sanitizer would extract the wrong sentence. We handle this with a blocklist of common rhetorical questions. Might be worth considering for a follow-up.

2. Queries that are legitimately long: Research queries can be 300+ chars without contamination — e.g., "What are the thermodynamic constraints on photosynthetic efficiency in C4 plants under elevated CO2 concentrations and how do they compare to C3 pathways?" (168 chars, but domain-specific queries in our astrophysics wing can be longer). The 200-char SAFE_QUERY_LENGTH threshold means these hit the sanitizer unnecessarily. Not harmful (Step 2/3 will extract the right thing) but generates false-positive was_sanitized=true metadata. A minor concern — just noting it.

3. The maxLength: 500 on the schema — some MCP clients silently truncate at maxLength. If a 600-char query gets truncated to 500 by the client before the sanitizer sees it, the tail (the actual query) may be cut off. Our approach is to not set maxLength on the schema and let the sanitizer handle length internally. Worth checking how Claude Desktop and other MCP clients handle maxLength.

Minor code notes

• query_sanitizer.py line ~90: the _SENTENCE_SPLIT regex splits on . which will incorrectly split on decimal numbers (e.g., "R@10 dropped to 1.0% after contamination"). Unlikely to cause real issues since you then check MIN_QUERY_LENGTH, but worth noting.

• The context parameter is accepted but not used yet (result["context_received"] = True and nothing else). The PR description says "for future re-ranking" — might be worth adding a TODO comment in the code so it's not forgotten.

Summary

This is a clean, well-tested mitigation for a genuinely nasty silent failure. The 4-stage pipeline with graceful fallback is better architecture than our pattern-matching approach — we'll likely refactor our _isolate_query() to match this structure. The context parameter is the right long-term direction.

Main suggestion: consider the maxLength client-side truncation risk. Everything else is solid.